Regulation

EU AI Act Article 14: human oversight for AI agents, and what an oversight record should prove

Traceseal · 13 October 2026 · 7 min read

"Human in the loop" is the usual answer to the question of who is in charge of an AI agent. Article 14 of the EU AI Act (Regulation (EU) 2024/1689) turns that answer into a legal requirement for high-risk systems, and it is more specific than the slogan. This piece covers what the article says, who carries the duty, when it applies now that the deadlines have moved, and the question most teams skip: if someone later asks whether a person really oversaw a particular agent action, what record could you show them?

When it applies: later than first planned

Article 14 sits in Chapter III, Section 2, the requirements for high-risk AI systems. Following the 2026 Digital Omnibus amendments, the consolidated text of Article 113 now applies those requirements from 2 December 2027 for systems that are high-risk under Article 6(2) and Annex III, and from 2 August 2028 for systems that are high-risk under Article 6(1) and Annex I. The original date for most of them was 2 August 2026.

The delay changes the timetable, not the obligation. It also does not move the transparency duties covered in our Article 50 piece.

Whether an agent is high-risk depends on what it is used for, not on the fact that it is an agent. A coding agent that edits your repository is unlikely to be in scope. An agent that filters job applications or evaluates candidates is, because recruitment and selection are listed in Annex III, point 4(a). So is one that evaluates the creditworthiness of natural persons, under point 5(b).

What Article 14 actually says

The core requirement is in Article 14(1):

High-risk AI systems shall be designed and developed in such a way, including with appropriate human-machine interface tools, that they can be effectively overseen by natural persons during the period in which they are in use.

Article 14(3) says the oversight measures "shall be commensurate with the risks, level of autonomy and context of use". That is the clause that matters most for agents. A system that recommends is one thing. A system that plans and then acts on its own plan has a higher level of autonomy, and the oversight is expected to scale with it.

Article 14(4) then lists what the people assigned to oversight must be enabled to do, "as appropriate and proportionate":

Article 14(5) adds a stricter rule for remote biometric identification under Annex III point 1(a). No action may be taken on an identification unless it has been "separately verified and confirmed by at least two natural persons". Few agent deployments will fall under it. It is still the one place where the Act spells out a two-person check.

Who carries the duty

The work is split. Under Article 14(3), the provider builds oversight measures into the system, or identifies measures the deployer should implement. The deployer then has to staff them. Article 26(2) is short:

Deployers shall assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support.

Breaching the deployer obligations in Article 26 falls under Article 99(4)(e). Fines there go up to €15 million or 3% of total worldwide annual turnover, whichever is higher.

Why agents strain the model

Article 14(4)(d) speaks of overriding or reversing the system's output. For a model that recommends, the output is a suggestion, and a person can ignore it. For an agent, the output is often an action: an email sent, a record updated, a payment initiated. Some actions can be reversed afterwards. Many cannot.

In our reading, that leaves agent deployments with two practical places to put oversight. The first is a gate before any action that cannot be undone, where a named person sees what the agent proposes and approves or rejects it. The second is a stop mechanism that works while the agent runs, as Article 14(4)(e) describes. Reviewing a dashboard after the run meets neither. It is monitoring, which point (a) asks for as well, but it does not let anyone override an email that has already gone.

Automation bias, point (b), gets worse with agents for a simple reason: volume. A reviewer approving the fortieth tool call of the morning is not overseeing it in any sense a regulator would recognise. That argues for gating fewer, higher-consequence actions rather than every step.

What an oversight record should show

Article 14 states what oversight must make possible. It does not prescribe a record of each oversight decision. Logging duties for high-risk systems sit separately in Articles 12, 19 and 26(6), which we covered in AI agent audit trails. In a dispute, though, "a person approved this" is a factual claim, and someone will ask you to back it up. Our view is that a useful record of an oversight decision answers five questions:

  1. Who decided? A named person, identified by something other than the agent's own credentials.
  2. What did they see? The exact proposal put in front of them, or a hash of it, so a later reader can tell they were not shown something different.
  3. What did they decide? Approve, reject, modify, or stop.
  4. Did the decision come before the action? An approval logged after the email went out is not oversight. That needs a time someone other than the agent's host vouches for. Our piece on trusted timestamps covers what that takes.
  5. Does the action match what was approved? The inputs the agent finally executed with should be the inputs the person approved, not a later variant.

The common failure is a record that cannot answer the first question honestly. If the approval is a row written by the agent platform, signed (if at all) with the platform's key, then it shows the platform says a person approved. That may be true. It is still the system under review describing itself.

Where signed receipts help, and where they stop

Traceseal receipts address question five directly, and they say plainly what they cannot do. A receipt binds the code that ran to hashes of its inputs and outputs, signed with the operator's ed25519 key, and anyone can check it offline:

$ pip install traceseal-verify
$ traceseal-verify receipt.json

If the approver's decision covers the same inputs hash that appears in the receipt, a third party can confirm that what ran is what was approved. Change one byte of the inputs and the hashes no longer match.

The published receipt format has no field for a human approval. A receipt shows who signed the execution record, not that a person looked at it first. The receipt specification is explicit about the limit that matters here:

The receipt proves that the operator's key signed the attestation. It does NOT prove the operator is honest.

An oversight record therefore needs its own signature from a key the approving person controls and the agent cannot reach, made before the action and over the same inputs hash. It is the same separation the OWASP agentic guidance insists on for signing keys, which we covered in our OWASP Top 10 piece. A receipt on its own does not give you that. A receipt beside an approver-signed decision lets a third party check the chain from "this person approved these inputs" to "these inputs are what ran".

The practical test: pick one consequential action your agent took last month. Can you show, without trusting the agent platform's own database, who approved it, what they were shown, and that the approval came first?

What to do before December 2027

The receipt format, verifier and transparency log are open: the spec, the verifier on PyPI, and the public log. You can adopt the format without adopting us.

Give your agents receipts.

Open spec, open verifier, one command to check.

How Traceseal works →