EU AI Act Article 14 for engineers: what "human oversight" means in code

Most writing about the EU AI Act is aimed at people who will never open a pull request. This one is aimed at the person who has to make the system actually behave that way.

The Act became generally applicable on 2 August 2026, and the high-risk obligations follow later: 2 December 2027 for the Annex III categories, and 2 August 2028 for high-risk systems embedded in regulated products under Annex I. Both dates were extended by the Digital Omnibus, in force since 27 July 2026.

That gap is the useful part. If you are in scope, two of the obligations land squarely in engineering rather than in policy: Article 12 (record-keeping) and Article 14 (human oversight). They are also, unusually for regulation, close to a specification. You can read them as a list of things your system must be able to do, and then go and make it do them.

This is not legal advice. Whether your system is high-risk, and whether you meet your obligations, depends on your use case and your deployment. That is a conversation with your own counsel. What follows is the engineering half: given that the obligations apply, what has to exist in the code.

Article 14: four capabilities, not a policy document

Strip the language back and Article 14 asks that a designated human can effectively oversee the system. In practice that decomposes into four capabilities, and each one is buildable.

1. A human can intervene before a consequential action

Oversight that only reviews after the fact is not oversight, it is reporting. For the actions that matter, a person has to be able to get in front of the thing.

The engineering shape is a gate: the action is not a call your agent makes and you audit later, it is a call that does not happen until someone decides.

const refund = client.approvals.gate(
  { title: 'Refund a customer?', timeoutMs: 10 * 60_000 },
  issueRefund,
);

await refund('ord_42', 129.99); // does not run until a human approves

The property that matters for an assessor is not that a notification was sent. It is that the function provably cannot run undecided. Denied throws. Expired throws. A wait that elapses while the decision is still pending throws too, and the underlying function still does not run. The approval simply stays open for someone to decide later.

Added 23 September 2026. Be exact about what that wrapper proves. It runs in your process, so it proves your code waited for a decision before calling the function. It cannot attest that the function ran, or did not, and the credential stays with you. For the strongest evidence, route the call through a hosted action instead: the agent invokes refund-order by name, the invocation parks with 202 until someone decides, and Anlyon itself sends the reviewed request and records what the destination replied. Then "could not run undecided" is a property of the system making the call, not of your code remembering to use the wrapper.

Two details are worth building in from the start, because retrofitting them is painful:

• The decider must be a distinct person. If the agent, or the agent's own credentials, can approve the agent's request, you have a log entry rather than an oversight control. Deciding should require a separate permission from requesting, and self-approval should be blocked by the system rather than by everyone remembering not to do it.
• Some decisions need more than one human. Two of three named reviewers, say. N-of-M is a common requirement for anything irreversible, and it is much easier to support in the policy engine than to bolt on later.

2. A human can override or disregard the output

The reviewer has to be able to say no, and no has to mean the action does not occur, not that it occurs and gets flagged. If your "override" writes a row somewhere while the side effect proceeds, it is not an override.

This falls out of the gate above if the gate is real: deny means the function never runs.

3. A human can interrupt or halt the system

Article 14(4) is explicit that oversight includes the ability to stop the system, and the obligation is best read as stoppable at any moment rather than stoppable at the next convenient checkpoint.

This is the requirement that catches most architectures out, because "stop" is usually implemented as "stop accepting new work." That leaves everything already in flight to complete: queued deliveries still fire, tool calls already dispatched still land, workflows resume on their next tick. From the outside, the system did not stop.

A halt worth the name has to reach the work that already exists. In Anlyon, halting an environment refuses the agent's action calls, hosted function runs and event publishes, and prevents even already-approved calls from running. A halt stops new dispatch. A request another server already accepted is not recalled. Approvals can still be decided and every read still answers, which matters, because a stop button people are afraid to press is not a control either.

The test to run against your own system: start a long workflow, halt, and count the side effects that still occur. If the answer is not zero, you do not have a kill switch, you have a moratorium on new work.

4. The oversight itself is auditable

An assessor will not take "a human reviewed it" on trust. Each decision needs the decider, the timestamp, the reason, and the policy that required the decision in the first place, including which version of that policy, since policies change.

Article 12: the logging obligation, and the part people get wrong

Article 12 requires automatic recording of events over the system's lifetime, granular enough to identify the cause of an error, retained for at least six months, and available to authorities on request.

Three things follow that are easy to get wrong.

Logging has to be automatic. An obligation met by developers remembering to add log lines is an obligation you will fail on the day someone ships in a hurry. Instrumentation belongs in the layer the calls pass through, not in the calls.

Six months is longer than most hot storage windows. This is the one that quietly breaks compliance stories. Plenty of platforms retain traces for 30, 60, or 90 days and describe the rest as "archived," which can mean anything from "in cold storage and retrievable" to "aggregated into metrics and gone."

Worth being precise about our own numbers here rather than hiding behind the same word. Anlyon keeps traces in a hot, queryable window. During Early Beta Access that window is 14 days and there is no archive. The planned paid plans list 90 days or more with an archive. The archive writes each run to object storage as gzipped OpenTelemetry JSON before it leaves that window, under a key that includes the workspace and the month, so an audit can list a period by prefix.

So the six-month floor would be met on the planned paid plans by the archive, not by the hot window. Paid plans arrive after the beta (the pricing page shows the current terms), so under those terms no workspace has the archive. Two practical notes. The free plan does not archive: traces there are deleted at 14 days, which is shorter than the six-month floor. And retrieving an archive is planned as a support request, not a self-serve API call.

Added 3 October 2026. This section was corrected. An earlier version described the 90-day window and the archive as if a workspace could have them today. Paid plans arrive after the beta, so no workspace has an archive today.

Records should leave in a standard format. If your audit trail can only be read inside one vendor's UI, you have made your compliance position depend on that vendor's continued existence. OpenTelemetry export is the low-effort insurance policy: the records are portable, and an assessor can be handed a file rather than a login.

A concrete oversight loop

Putting it together, the loop an assessor can actually be walked through:

1. A policy routes a risky action to require approval, optionally N-of-M.
2. A human approves or denies. The decision, decider, note, and governing policy version are recorded.
3. If something looks wrong, an operator halts the environment. The agent stops acting and no new dispatch leaves. A request another server already accepted is not recalled.
4. A bad agent version is rolled back to a previous immutable version. That restores the action definitions it pinned for what happens next. It does not undo an effect already dispatched.
5. The whole sequence sits on one exportable trace.

Steps 1 and 2 are Article 14's intervention and override. Step 3 is the halt in 14(4). Steps 4 and 5 are what make the first three provable rather than asserted.

What to do this week

If you think you are in scope, the useful first move is not to read the Act again. It is to run three tests against what you have already built:

1. Pick your most consequential action and try to make it happen without a human. If you can, the gate is advisory.
2. Halt the system mid-flight and count the side effects that still land. Anything above zero is the gap.
3. Ask for every record of one agent run from seven months ago. If you cannot produce it, in a format someone else can read, the Article 12 position is theoretical.

Those three answers will tell you more about your exposure than any amount of further reading. The obligations are, for once, testable.

The full Article 12/14 mapping → · How approvals work →