CorrectionsThis page replaces /key-issue/4, which was written against the 2021 Commission proposal. Where that page and the adopted Regulation disagree:
Recital 48 of the AI Act proposal.
The recitals were renumbered on adoption. Human oversight is addressed in Recital 73 of Regulation (EU) 2024/1689.
Article 14 provides little detail on the human overseers' responsibilities.
The adopted Article 14(4) sets out five specific capabilities oversight must enable, and Article 26(2) puts competence, training, authority and support duties on the deployer. The proposal was thinner than the Regulation.
Article 14(4)Oversight measures must enable the person assigned to it to:
- (a)Properly understand the system's relevant capacities and limitations, and monitor its operation, including to detect and address anomalies, dysfunctions and unexpected performanceDocumented limitations the overseer can actually read, plus live monitoring surfaced in the interface rather than buried in logs.
- (b)Remain aware of the possible tendency to automatically rely or over-rely on the output: automation biasInterfaces that do not present output as settled fact: confidence signalling, and friction where a decision is consequential.
- (c)Correctly interpret the system's output, taking into account the interpretation tools and methods availableExplanations pitched at the overseer's actual expertise, not at the model's developers.
- (d)Decide, in any particular situation, not to use the system or otherwise to disregard, override or reverse its outputAn override that is available, recorded, and does not require escalation to exercise.
- (e)Intervene in the operation of the system or interrupt it through a stop button or a similar procedure that allows it to halt in a safe stateA stop control that brings the system to a safe state, not merely a pause.
What Article 14 requires
High-risk AI systems must be designed and developed so that they can be effectively overseen by natural persons during the period in which they are in use. The aim, set by Article 14(2), is to prevent or minimise risks to health, safety and fundamental rights.
The word carrying the weight is designed. Article 14 is addressed to how the system is built, which is why it sits in Chapter III alongside data governance and logging rather than in the deployer obligations. An organisation cannot satisfy it by writing a procedure that says a human will check the output; the system has to make that check possible.
Article 14(3) then splits the delivery. Oversight measures are either built into the system by the provider before it is placed on the market, or identified by the provider as appropriate for the deployer to implement. Both are provider responsibilities: even the second one, because it is the provider that must work out and communicate what the deployer needs to do.
The five capabilities
Article 14(4) lists five things the oversight measures must enable the assigned person to do. Read as design requirements rather than aspirations, they constrain the interface fairly tightly.
Two of the five are commonly under-built. The ability to disregard, override or reverse output under 14(4)(d) means an override that is actually reachable, not one that requires escalation to a second team, which in practice means it will not be used. And the ability to interrupt through a stop button or similar procedure under 14(4)(e) requires halting in a safe state, which is a different engineering problem from stopping execution.
| Capability | Fails when | Evidence a reviewer would look for |
|---|---|---|
| Understand capacities and limitations | Limitations are documented for developers, not for the person doing oversight | Written limitations at the overseer's level of expertise |
| Monitor operation and detect anomalies | Monitoring exists but is not surfaced where the decision is made | Anomaly signals in the operator interface, not only in logs |
| Stay aware of automation bias | Output is presented as a settled answer with no uncertainty signal | Confidence indication, and friction on consequential actions |
| Correctly interpret output | Explanations assume knowledge the overseer does not have | Explanation tooling tested with the actual oversight population |
| Disregard, override or reverse | Override requires escalation, or is not recorded | A reachable override, logged under Article 12 |
| Intervene or stop | Stop halts execution but leaves the system in an unsafe state | A defined safe state, and a tested path into it |
Provider builds it, deployer staffs it
Article 26(2) requires deployers to assign human oversight to natural persons who have the necessary competence, training and authority, and to give them the necessary support. That is the other half of Article 14, and it is where oversight most often fails in practice.
The three words in Article 26(2) are each doing work. Competence means the person can actually evaluate the output: a domain expert, not whoever has capacity. Training means specific to this system, which connects to the Article 4 AI literacy duty. Authority means the organisational standing to overrule the system without needing permission, which is the one that most often does not exist: an overseer whose override is reviewed by their manager as an exception is not exercising authority.
The four-eyes rule for biometrics
Article 14(5) provides that for remote biometric identification systems under Annex III point 1(a), no action or decision may be taken on the basis of an identification unless at least two natural persons with the necessary competence, training and authority have separately verified and confirmed it.
This is the strictest oversight requirement in the Regulation and the only place it prescribes a specific number of people. The operative word is separately: two people confirming independently, not one confirming and another countersigning. The requirement is on the action, not on the match: the system may produce an identification, but nothing may be done on the basis of it until it has been twice verified.
Narrow carve-outs disapply the two-person requirement for certain uses in law enforcement, migration, border control and asylum, where Union or national law finds it disproportionate. Those are exceptions to read carefully rather than assume.
Automation bias is in the text
Article 14(4)(b) requires oversight measures to enable the person to remain aware of the possible tendency to automatically rely or over-rely on the output of a high-risk AI system.
This is unusual drafting. Most regulation specifies what a system must do; this specifies a cognitive failure the design has to work against. It has a practical consequence: an interface that presents model output as a confident, unqualified answer is arguably non-compliant on its face, because it does nothing to help the overseer resist over-reliance.
The design responses are well understood outside regulation: surfacing uncertainty, showing the basis for a recommendation rather than only the recommendation, requiring an affirmative action on consequential decisions, and measuring override rates to detect rubber-stamping. What Article 14(4)(b) adds is that doing none of these is now a compliance question rather than only a product-quality one.
What makes oversight meaningful
The Regulation does not define meaningful oversight, but it does supply a test in the form of the five capabilities. Oversight that leaves any one of them unavailable is not compliant, whatever the procedure says.
| Pattern | Why it fails | Provision |
|---|---|---|
| A human approves every output, at volume, in seconds | Throughput makes genuine interpretation impossible; this is rubber-stamping, and override rates will show it | Article 14(4)(b), (c) |
| Oversight assigned to whoever is available | Competence is a stated requirement, not a preference | Article 26(2) |
| Override exists but requires manager approval | The overseer lacks the authority the provision requires | Article 26(2), Article 14(4)(d) |
| A stop control that halts mid-transaction | Halting is required to reach a safe state | Article 14(4)(e) |
| One person confirms a biometric identification | Two are required, separately, before any action | Article 14(5) |
Frequently asked questions
- What does Article 14 of the EU AI Act require?
- That high-risk AI systems be designed and developed so they can be effectively overseen by natural persons while in use. Article 14(3) requires oversight measures to be either built into the system by the provider or identified by the provider for the deployer to implement, and Article 14(4) sets out five specific capabilities those measures must enable.
- Is a human-in-the-loop always required?
- Not in the sense of a person approving every output. Article 14(3) requires measures commensurate with the risks, the level of autonomy and the context of use. What is always required is that a natural person can understand the system, interpret its output, disregard or override it, and stop it. Whether that person sits in the loop, on the loop or over the loop is a design question governed by proportionality.
- Who is responsible for human oversight: provider or deployer?
- Both, for different things. The provider must build the oversight measures in, or specify them for the deployer to implement, under Article 14(3). The deployer must assign oversight to natural persons who have the necessary competence, training and authority, and provide the necessary support, under Article 26(2). A provider cannot discharge the duty by shipping a feature nobody is staffed to use.
- What is the four-eyes requirement?
- Article 14(5) provides that for remote biometric identification systems under Annex III point 1(a), no action or decision may be taken on the basis of an identification unless it has been separately verified and confirmed by at least two natural persons with the necessary competence, training and authority. Narrow carve-outs apply for certain law enforcement, migration, border control and asylum uses.
- Does the EU AI Act mention automation bias?
- Yes, explicitly. Article 14(4)(b) requires oversight measures to enable the person to remain aware of the possible tendency to automatically rely or over-rely on the output: automation bias. It is one of the few places where a regulation names a specific cognitive failure mode as a design constraint.
- When do the human oversight obligations apply?
- With the rest of Chapter III: 2 December 2027 for Annex III high-risk systems and 2 August 2028 for Annex I product-safety systems, as deferred by Regulation (EU) 2026/1744.
- Is there a right to human review of an AI decision?
- Article 14 is a duty on operators, not a right held by affected people. The nearest individual right is Article 86, which gives a right to an explanation of individual decision-making for certain Annex III systems. Separately, Article 22 GDPR gives a right not to be subject to a decision based solely on automated processing with legal or similarly significant effects.
Sources and verification
Every date and provision cited here was checked against the consolidated text on 11 August 2026. The EU AI Act is being amended as it is implemented; where this page and EUR-Lex disagree, EUR-Lex governs.
- Regulation (EU) 2024/1689: consolidated text on EUR-Lex (controlling source)
- Regulation (EU) 2026/1744: Digital Omnibus on AI, amending the AI Act (in force 27 July 2026)
- Article 14: Human oversight
- Article 26: Obligations of deployers
- Article 86: Right to explanation of individual decision-making
- Recital 73: Human oversight
This page is an independent information resource. It is not legal advice, and it does not create a lawyer–client relationship. Take advice on your own facts before making a compliance decision.
Next: see which systems this attaches to in the high-risk classification guide, or read Article 14 and Article 26 in full.