EU AI Act
Article 14 — Human oversight
Article 14 requires high-risk systems to be designed so they can be effectively overseen by people. It is a provider obligation about design, not a rule that a human must approve each output — and the measure it names as the failure mode, automation bias, is the one most oversight arrangements are built to produce.
§ 1 — Who it binds
Whose duty this is: the provider, at design time
Provider
Every high-risk AI system, under either Article 6 gateway, with no internal exemption. The four-eyes rule in 14(5) — no action on an identification unless two competent people separately verify it — triggers only for remote biometric identification under Annex III point 1(a), which itself excludes one-to-one verification, and is disapplied for law enforcement, migration, border control and asylum where Union or national law considers it disproportionate.
§ 2 — In practice
HITL, HOTL, and what Article 14 actually requires
"Human in the loop" is not what Article 14 asks for, and treating it as the standard produces both over- and under-compliance. The provision offers either or both of two routes — measures built into the system by the provider where technically feasible, and measures the provider identifies for the deployer to implement — and requires that they be commensurate with the risk, the level of autonomy and the context of use. Nowhere does it require a person to approve each output. A blanket approval gate on a high-volume, low-stakes system is a design choice; a highly automated system with a tested escalation and interruption path can satisfy the article on its face.
The five capabilities in 14(4) are read as a checklist and are expressly conditional: they apply "as appropriate and proportionate", and that qualifier governs all of them, including the stop button. What is not optional is that the capabilities be real. Being able to "duly monitor" the operation is a tooling obligation, not a documentation one; correctly interpreting output points at the interpretation tools available. An oversight design that consists of a paragraph in a standard operating procedure has satisfied none of it — the same gap between a stated process and an operating one that Article 9 turns on.
Article 14(4)(b) is the only mention of automation bias anywhere in the Regulation, and it is where oversight designs actually fail. The duty is that the assigned person *remain aware* of the tendency to over-rely on output — a state maintained through training, calibration and measurement, not a warning in a manual. The Act singles out the configuration that carries it: systems providing information or recommendations for decisions taken by people. That is the advisory architecture organisations adopt precisely because they believe it lowers their exposure.
The provider/deployer seam runs straight through this article and catches people. Article 14 obliges the provider to design for oversight; the deployer’s mirror duty — assigning people with the competence, training and authority to exercise it — sits in Article 26. Two articles, two parties, two separately fineable failures on one deployment. And when an oversight assessment fails, the defect is often upstream of both: people cannot understand a system’s limitations if the instructions never state them, which is a technical-documentation problem wearing an operational disguise.
§ 3 — What a weak answer looks like
The reviewer who rubber-stamps: automation bias as a finding
Oversight that has never changed an outcome. The arrangement exists, the policy names it, a person occupies the role — and no decision in the system’s history has gone differently because of them. This is the rubber stamp, and it is the specific failure Article 14(4)(b) anticipates rather than an unfortunate side effect. It is also the easiest thing on this page to test, which is why an assessor asks for the override log before asking for the policy.
§ 4 — What discharges it
Evidence that oversight was designed in, not asserted
The artefacts an assessor asks to see, and what makes each one sufficient rather than merely present.
01
Override rate, measured and trended
The single most diagnostic number available. A rate at or near zero over a meaningful period is the automation-bias condition made visible, and it is measurable without any access to the model.
02
The interruption path, tested rather than described
Article 14(4)(e) contemplates bringing the system to a halt in a safe state. Evidence is a test that exercised it and a record of what the safe state actually was, not a screenshot of a button.
03
What the oversight person is given to work with
Confidence scores, contributing factors, cases the system finds hard, known limitations. If the interface presents only a conclusion, the capabilities in 14(4)(a) and (c) have not been provided whatever the policy says.
04
Automation-bias treatment that someone maintains
Not a slide in induction. Periodic calibration, seeded disagreement cases, or measured agreement against an independent standard — something that keeps awareness current, because the duty is to remain aware.
05
For biometric identification, the two-person verification record
Article 12(3)(d) requires the logs to capture who performed the verification, which exists precisely so 14(5) can be audited. The two people may include the operator, and the log entry may be the whole of the evidence.
§ 5 — Worked example
Worked example — a stop button nobody reaches for
A hospital group uses a triage system that flags radiology studies as likely-urgent. Policy requires a radiologist to confirm every flag before escalation. Audit finds confirmation takes a median of four seconds, the agreement rate with the system is 99.2%, and in eighteen months no radiologist has ever overridden a flag. The vendor’s file records a compliant Article 14 design.
The policy is followed to the letter. Is human oversight actually operating?
On these numbers, no — and the vendor’s file may well be accurate at the same time, which is what makes this hard. Article 14 is a design obligation, and a system that presents its reasoning, permits override and halts safely can be conformant as shipped. What the audit has found is the automation-bias condition the Act names in 14(4)(b): a four-second median and an eighteen-month absence of any override are not evidence of agreement, they are evidence that the confirmation step is not a decision. The failure sits with the deployer, under its own duty to assign people with competence, training and authority — authority being the limb in question, since a reviewer who has never once dissented may not believe dissent is available. The remedy is not a longer mandatory pause. It is measuring override rate as a control in its own right, sampling flags against independent read, and establishing that a radiologist who disagrees has somewhere for that to go.
§ 6 — Elsewhere
The same requirement elsewhere
Where another instrument addresses the same obligation. These are correspondences, not comparisons — the Council does not rank one framework against another.
NIST AI RMF
MANAGE 2.4 addresses mechanisms and assigned responsibilities to supersede, disengage or deactivate a system performing inconsistently with intended use — the same ground as the disregard, override and interruption capabilities in Article 14(4).
GDPR and data-protection law
GDPR Article 22(3) provides a right to obtain human intervention, exercisable by an individual after a decision. Article 14 is a design duty on the provider that exists whether or not anyone invokes anything.
A correspondence indicates that two instruments address the same underlying obligation. It is not a mapping endorsed by either body, not a statement that one satisfies the other, and not a judgement about which is more demanding.
§ 7 — When it applies
When the oversight design duty applies
2 December 2027
Annex III standalone high-risk systems. Moved from 2 August 2026 by the Digital Omnibus — a sixteen-month extension driven by undesignated national authorities and the absence of harmonised standards, not by any relaxation of the Section 2 requirements themselves.
2 August 2028
Annex I embedded high-risk systems — medical devices, machinery, vehicles — where AI Act requirements fold into the existing sectoral conformity assessment. Moved from 2 August 2027.
§ 8 — Exposure
Exposure — provider design, deployer staffing, two routes
€15 million or 3% of worldwide annual turnover, whichever is higher
Article 99(4)(a), reached through Article 16(a): a provider must ensure its high-risk system meets the Chapter III Section 2 requirements, and Article 14 sits in that section. Article 14 is not itself enumerated in Article 99(4). The deployer-side failure — no competent, trained, authorised person assigned — is a separate exposure at the same ceiling under Article 99(4)(e) via Article 26(2), and both can arise on one deployment. Articles 99(6) and 99(6a) give SMEs and small mid-caps the lower figure.
§ 9 — provenance
The provision itself
This page sets out what the instrument requires and what discharges it. The official text is the authority — these go straight to it.
§ 10 — Also read
Also read
Article 9 — risk management system
Certification
Assessed on the same standard of evidence
Every Council credential is examined on applied judgement against a published anchor, set out the way the obligations on this page are. The free AI Literacy Certificate is open to any adult today, and the register lists what is open for enrolment.