EU AI Act Article 14: Five Oversight Patterns

EU AI Act Article 14 requires that high-risk AI systems be designed so they can be effectively overseen by natural persons. The word doing the work is effectively. The article goes on to describe what that person must be able to do: understand the system's capacities and limits, stay alert to automation bias, interpret the output correctly, decide not to use it, and intervene or halt it.

None of that is satisfied by a person existing on an org chart. Article 14 describes a capability, and a capability has to be demonstrated. That is the gap most teams find late: they built the oversight mechanism, and they cannot show anyone that it fired.

How the oversight question arrives

In a bank's vendor-risk review the human-oversight question almost never arrives as "do you have human oversight?" It arrives as "how many outputs were reviewed last quarter, how many were overridden, and by whom?"

That is a question about records, and it separates two situations that look identical from outside: a mechanism that works, and a mechanism that was switched off in production six weeks ago and nobody noticed. Both produce a confident yes to the first question. Only one survives the second.

An oversight step that has never fired is indistinguishable from an oversight step that is broken. The count is the control.

Pattern 1 — the approval gate

The agent pauses before a consequential action, presents what it intends to do and why, and waits for a decision. This is the most direct implementation of intervene, and the easiest to evidence: a decision by a named person at a known time is exactly the shape of record an auditor wants.

Common triggers, in rough order of how often teams reach for them:

• Actions that modify production systems or infrastructure.
• Outbound communication — anything a customer, regulator or counterparty will see.
• Spend above a threshold, whether a single call or a cumulative run.
• Anything touching a category of personal data the policy names.
• Changes whose blast radius exceeds a size the team has agreed on.

The evidence this leaves: one row per decision — who, when, what was proposed, what was decided, and what actually executed afterwards. That last field matters more than it looks. An approval that does not link to the action that followed it proves somebody clicked a button, not that the approved thing is what ran.

Pattern 2 — auto-approve conditions, written down

Not every action needs a person, and pretending otherwise produces the failure mode Article 14 explicitly warns about. A reviewer facing forty low-stakes approvals an hour stops reading them. That is automation bias arriving from the other direction: the human is present, and their attention has been spent on noise.

Auto-approve conditions are the boundary, and the useful discipline is that they are a written policy rather than a habit. A condition set that lives in configuration can be shown to a reviewer, versioned, and argued about. One that lives in a reviewer's judgement cannot.

{
  "agent": "backend-worker",
  "requires_approval": true,
  "auto_approve_conditions": {
    "max_files_changed": 3,
    "max_cost_usd": 5,
    "forbidden_paths": ["infra/", "secrets/"],
    "outbound_communication": false
  }
}

The evidence this leaves: the condition set itself, versioned, plus the count of runs that took each path. "We auto-approved 74% of runs under these five conditions" is a defensible answer. "Most things go through automatically" is not.

Pattern 3 — the halt

Article 14 names the ability to interrupt or stop the system. That is a distinct capability from approving individual actions: it applies when the problem is the agent's behaviour as a whole rather than any single decision it wants to make.

A halt has a second life under DORA, where it forms part of incident response — the thing you can tell a financial customer you did, inside the window their own reporting obligation runs on. The two frameworks want the same mechanism for different reasons.

The evidence this leaves: whether it has ever been used, by whom, how long it took to take effect, and what the system did in between. A halt with no elapsed-time record answers the design question and leaves the operating-effectiveness question wide open.

Pattern 4 — escalation on the model's own uncertainty

The patterns above trigger on what the agent is about to do. This one triggers on how sure it is. When confidence falls below a threshold, or an output fails a validation the policy defines, the run routes to a person instead of proceeding.

This addresses correct interpretation of the output most directly, because it puts a person in front of exactly the cases where interpretation is hardest. It is also the pattern most easily tuned into uselessness — a threshold set low enough never to fire is a feature in the codebase and nothing in the evidence pack.

Pattern 5 — graduated autonomy

Start strict and relax deliberately. Week one, everything is reviewed. After a few hundred decisions you have data: which categories were ever overridden, which never were, and where reviewers actually spent their attention. Those are the categories that can move to auto-approve, and the move is now an argument rather than a guess.

The reason to do it in this order is not caution for its own sake. It is that the strict phase generates the record that justifies the relaxed one. A team that starts permissive and tightens after an incident ends up with the same configuration and no story.

What ties the five together

Each pattern is a mechanism plus a record, and the record is the half that gets skipped. Approval logs kept for two weeks answer nothing about last quarter. An override count that cannot be produced per system and per period is not evidence of anything.

Worth being precise on timing, because published guidance is often stale: the AI Act's high-risk obligations under Annex III were deferred by the Digital Omnibus of May 2026 and apply from December 2027, not August 2026. DORA has been in force since January 2025, and the vendor questionnaire asking these questions is on your desk regardless.

Where Dobby fits

Dobby reads run telemetry out-of-band — from CrewAI, LangChain, OpenAI, Google ADK or a custom SDK — and never sits in the request path. Approvals, overrides and halts land as records against the run they belong to, and the compliance scan evaluates them against the frameworks you have activated, Article 14 among them.

The verdict has four states rather than two: compliant, violated, needs-review, and unverifiable. Human oversight is the control where the fourth earns its keep. When the telemetry cannot show that a mechanism fired, Dobby reports unverifiable rather than passing it — because a control that passes on absent evidence is precisely what this article exists to prevent.