Human oversight in practice: designing the approval step an auditor will accept
Article 14 asks for oversight that works: people who understand, can override and can stop. Six design rules for the approval step in an AI agent.
“A human reviews every decision” is the most common safety claim in AI, and the easiest to make meaningless. If the reviewer sees a green button and a summary, approves four hundred cases a day and has never seen the agent fail, the human is a formality.
The EU AI Act is specific about what oversight must achieve. Article 14 asks that high-risk systems “can be effectively overseen by natural persons during the period in which they are in use”. Article 26(2) asks deployers to give that job to people with “the necessary competence, training and authority”. GDPR Article 22 adds, for decisions with significant effects, a right to human intervention.
Here are six design rules we use for the approval step in an agent, mapped to what Article 14(4) says the overseer must be able to do. We read the articles on 9 November 2026.
1. Decide what needs a person, and write it down
Not every step needs approval. An agent that drafts a reply to a routine question can send it; an agent that proposes a payout, a refusal or a change to a customer’s record should not.
Draw the line in the agent’s specification, per action:
- acts alone: reading, searching, drafting, internal notes;
- waits for a person: anything that pays, refuses, commits, changes a record in a system of record, or leaves the company;
- never does: what you would not let a new employee do on their first day.
A line written into the spec can be tested and audited. A line that lives in someone’s head cannot.
2. Show the reviewer what they need to judge
Article 14(4)(a) asks that the overseer can “properly understand the relevant capacities and limitations” of the system and monitor it. Point (c) asks that they can correctly interpret its output.
In the approval step, that means showing:
- the proposed action and its amount or effect;
- the sources the agent used, with the passage, not just a link;
- what the agent was unsure about, in its own words;
- anything unusual about the case compared with the ones it was tested on.
A one-line summary with an Approve button fails this rule.
3. Design against automation bias
Point (b) is the one teams forget: the overseer must “remain aware of the possible tendency of automatically relying or over-relying on the output”. After a hundred correct proposals, people stop reading the hundred-and-first.
Some counter-measures:
- put the evidence before the button, so approving requires scrolling past it;
- make Send back as easy as Approve;
- send a known-bad case to reviewers now and then, as a check, and track how often it is caught;
- keep the reviewer’s daily volume to a number someone can actually read.
4. Make override and stop real
Point (d) asks that the overseer can “decide not to use” the system, or “disregard, override or reverse” its output. Point (e) asks for a way to “interrupt the system through a ‘stop’ button or a similar procedure”.
Test both. Override means the reviewer can change the amount or the text, not just reject it. Stop means a person with access can pause the agent at once, and paused means no new runs start, not “the queue drains overnight”.
5. Record the human part too
Article 12 asks for automatic logging over the system’s lifetime, and Article 26(6) asks deployers to keep logs for at least six months. The approval is part of that record: who approved, when, what they saw and whether they changed anything.
That record is also your evidence that oversight was not a formality. Approval rates, override rates and time per review, per reviewer, tell you whether the human is still in the loop.
6. Train the reviewers on the agent, not on AI
Article 26(2) asks for competence and training, and the most useful training is specific: what this agent is good at, where it failed in testing, what its typical mistakes look like, and when to send a case back. An hour with the test report teaches more than a general course on AI.
Oversight is a design problem
None of this is exotic. It is the same discipline a bank applies to a four-eyes check, applied to a new kind of colleague. The difference is that an agent can produce far more work than a person can review, so the approval step must be designed, measured and tested like any other part of the system.
On our platform, releases wait for a person on a review card that shows the score, the safety cases and what changed, and risky actions in a live agent are held for a person before they run. The demo on the platform page lets you be that person. Two sector pages show the same step in a live process: a claims handler approving a payout on the insurance page, and a person approving a payment plan on the consumer lending page. We build that step into every custom AI agent.
Questions
Does every AI agent need a human in the loop?
Not for every step. Decisions with legal or similarly significant effects on people need a person under GDPR Article 22, and high-risk systems need effective oversight under AI Act Article 14. Decide per action, in writing, what waits for a person.
How do you stop reviewers rubber-stamping an AI agent?
Show the evidence behind each proposal, not only a summary; put known hard cases into the review queue; record when reviewers change or reject a proposal; and look at those numbers. Article 14(4)(b) names automation bias as a risk the overseer must be aware of.
Sources
- artificialintelligenceact.euartificialintelligenceact.eu/article/14/
- artificialintelligenceact.euartificialintelligenceact.eu/article/26/
- artificialintelligenceact.euartificialintelligenceact.eu/article/12/
- gdpr-info.eugdpr-info.eu/art-22-gdpr/
Read on or before 12 November 2026. Not legal advice: your counsel and data protection officer decide.