EU AI Act
Human Oversight of AI Agents Under the EU AI Act (Articles 12, 14, 26)
If your AI agent is high-risk, the EU AI Act requires human oversight you can demonstrate and logs you can produce. Here is what Articles 12, 14, and 26 mean in practice — and how to satisfy the mechanisms without slowing your agents down.
In short
If your AI agent is high-risk under the EU AI Act, you must provide human oversight you can demonstrate (Article 14), keep automatic logs over the system’s lifetime (Article 12), and, as a deployer, retain those logs and assign oversight to competent people (Article 26). A runtime approval gate that pauses an action for a person to approve, edit, or reject — paired with a tamper-evident, append-only audit trail you can verify — maps directly to those mechanisms. This is general information, not legal advice, and whether an agent is high-risk depends on its use case.
Key takeaways
- The EU AI Act (Regulation (EU) 2024/1689) puts three relevant duties on high-risk systems: human oversight (Art. 14), record-keeping (Art. 12), and deployer obligations (Art. 26).
- Not every agent is high-risk — classification follows Article 6 and Annex III, and a documented determination is part of governance.
- Article 14’s “ability to intervene or interrupt” is, mechanically, an approval gate. Article 12’s “automatic recording of events” is, mechanically, an audit trail.
- High-risk (Annex III) obligations are set for 2 August 2026; a possible timeline adjustment was under discussion — date your compliance copy and verify it.
- The strongest evidence is a log you do not have to be trusted on: append-only, hash-chained, independently verifiable.
First: is your agent high-risk?
Most of the AI Act’s heavy obligations attach to high-risk systems. Under Article 6, a system is high-risk if it is a safety component of a product already regulated under EU law, or if it falls into one of the areas listed in Annex III — among them employment and worker management, access to essential private and public services, creditworthiness, education, law enforcement, and migration. An agent that drafts marketing copy is almost certainly not high-risk; an agent that decides who gets a loan, or takes actions in a hiring pipeline, may well be.
The classification is use-case dependent, and getting it documented is itself part of good governance. The rest of this guide assumes you have a high-risk (or borderline) agent and want to meet the oversight and record-keeping mechanisms cleanly. If you are unsure, that determination is a question for legal counsel on your specific use case.
What the Act requires: Articles 12, 14, and 26
Three articles do most of the work for an agent that takes actions. In plain terms:
Article 14 — Human oversight. High-risk systems must be designed so natural persons can effectively oversee them. The measures include being able to understand the system’s capacities and limits, staying alert to automation bias (over-trusting the output), and — critically for agents — being able to intervene in the operation or interrupt it, for example through a stop function. A person must be able to decide not to use the output, or to halt the action.
Article 12 — Record-keeping. High-risk systems must technically allow for the automatic recording of events (logs) over the lifetime of the system, to ensure a level of traceability appropriate to the intended purpose. The point is that what the system did can be reconstructed and examined later.
Article 26 — Deployer obligations. If you operate a high-risk system, you must use it per the provider’s instructions, assign human oversight to competent and adequately supported people, monitor operation, and keep the logs the system generates for an appropriate period — generally at least six months unless other law applies.
How a human-in-the-loop control plane maps to the obligations
You do not satisfy the Act by buying a tool — you satisfy it with your process, your documentation, and your governance. But the technical mechanisms the Act describes line up almost one-to-one with what a human-in-the-loop control plane provides:
| Dimension | What the Act asks for | The mechanism that shows it |
|---|---|---|
| Art. 14 — intervene / interrupt | A person can stop or change an action | Runtime approval gate: approve, edit, or reject before execution |
| Art. 14 — avoid automation bias | Oversight is meaningful, not rubber-stamping | Policies auto-handle only the safe majority; humans see full context on the rest |
| Art. 12 — automatic record-keeping | Events logged over the lifetime, traceable | Append-only, SHA-256 hash-chained audit trail of every decision |
| Art. 12 — traceability of why | Reconstruct why an action went through | Per-event provenance: policy, tool flag, standing grant, or named human |
| Art. 26 — competent oversight | Named, authorised people perform oversight | Approver groups, delegation, and authorisation enforced across channels |
| Art. 26 — keep the logs | Retain logs for an appropriate period | Retained, exportable, Ed25519-signed audit you can verify offline |
The verifiable part matters more than it looks. An auditor does not have to trust your database: with a hash-chained, signed export they can confirm the record themselves. That turns “we have logs” into “here is the evidence, check it” — a much stronger position when the question is whether oversight actually happened.
Timeline and the honest caveats
The AI Act entered into force on 1 August 2024 and applies in phases. Prohibited practices (Article 5) have applied since February 2025; obligations for general-purpose AI models since August 2025; and the obligations for high-risk systems listed in Annex III are set to apply from 2 August 2026, with certain product-related high-risk systems from 2 August 2027.
What to do now
Preparation does not require waiting for the final date. A pragmatic sequence:
- 1
Inventory your agents and what they can do
List every agent in production and the real-world actions each can take (pay, delete, send, decide). You cannot govern what you have not enumerated.
- 2
Classify risk and write it down
For each agent, make and document a high-risk determination against Article 6 and Annex III. The written reasoning is part of the evidence, whichever way it goes.
- 3
Add runtime oversight to the high-risk paths
Put an approval gate in front of the actions that need it, so a competent person can approve, edit, or reject before execution — the Article 14 mechanism, in code.
- 4
Turn on tamper-evident record-keeping
Record every decision to an append-only, hash-chained audit trail with per-event provenance — the Article 12 mechanism — and make sure it survives a GDPR erasure request.
- 5
Set retention and assign oversight
Keep logs for an appropriate period (generally at least six months) and assign oversight to named, trained people with real authority — the Article 26 duties.
- 6
Document and rehearse
Keep your determinations, policies, and an exportable, verifiable log ready to hand to an auditor — and test that the export actually verifies before anyone asks.
The bottom line
The EU AI Act does not ask for magic. For high-risk agents it asks that a person can step in, that the system records what it did, and that you keep and can produce that record. Those are mechanisms you can ship: an approval gate for oversight, a tamper-evident audit trail for record-keeping, and retention plus named approvers for the deployer duties. Build them now, date your compliance copy, and confirm the specifics with counsel — the deadline is close enough that “later” is already late.
Sources & further reading
Frequently asked questions
Does the EU AI Act require human oversight of AI agents?
For high-risk AI systems, yes. Article 14 of the EU AI Act (Regulation (EU) 2024/1689) requires that high-risk systems be designed and developed so that natural persons can effectively oversee them — including understanding the system’s limits, watching for automation bias, and being able to intervene in or interrupt the system. Whether a specific AI agent is "high-risk" depends on its use case under Article 6 and Annex III. A runtime approval gate that lets a person approve, edit, or reject an action before it executes is a direct way to provide that oversight.
What does Article 12 of the EU AI Act require for logging?
Article 12 requires that high-risk AI systems technically allow for the automatic recording of events (logs) over the lifetime of the system, to ensure a level of traceability appropriate to the intended purpose. In practice that means a durable, complete record of the system’s relevant events. A tamper-evident, append-only audit trail — where each decision is hash-chained and independently verifiable — meets the mechanism and goes beyond a plain logs table that can be edited after the fact.
When do the EU AI Act high-risk obligations apply?
The AI Act entered into force on 1 August 2024 and applies in phases. Prohibited-practice rules (Article 5) applied from February 2025 and general-purpose AI model obligations from August 2025. The obligations for high-risk systems listed in Annex III are set to apply from 2 August 2026, with certain product-related high-risk systems from 2 August 2027. A simplification package (the "Digital Omnibus") that could adjust some timelines was under discussion at the time of writing — verify the current status before relying on a specific date. This is general information, not legal advice.
What are the deployer obligations under Article 26?
Article 26 sets obligations for deployers (the organisations using a high-risk AI system). These include using the system in line with the provider’s instructions, assigning human oversight to competent, trained people with the authority and support to perform it, monitoring operation, and keeping the logs the system automatically generates for an appropriate period (generally at least six months unless other law says otherwise). Approver groups, delegation, and a retained, verifiable audit trail map directly to these duties.
Is my AI agent high-risk under the EU AI Act?
Not necessarily. An AI system is high-risk mainly if it falls under Article 6 — either it is a safety component of a regulated product, or it is listed in Annex III (areas such as employment, education, essential private and public services, credit scoring, law enforcement, and migration). Many agents that draft text, summarise, or automate internal tasks are not high-risk. The classification is use-case dependent, and a documented determination is itself part of good governance. When in doubt, get legal advice for your specific use case.
Keep reading
The record-keeping mechanism behind Article 12, built so a GDPR erasure never breaks it.
The oversight mechanism behind Article 14 — and what it costs to build vs buy.
EU-hosted by default, RLS on every table, and an audit you verify yourself.