Article 14: human oversight
Almost every organisation answers this with “a human reviews the output”. Article 14 does not ask whether a human is present. It asks whether that human can understand the system, resist deferring to it, override it, and stop it, and whether they have the authority to do so.
The five capabilities
Article 14(4) is unusually concrete. The person assigned to oversight must be enabled, as appropriate and proportionate, to:
| Capability | What it means in a real workflow |
|---|---|
| Understand capacities and limitations, and monitor operation, including detecting and addressing anomalies, dysfunctions and unexpected performance | The overseer needs to know what the system is bad at. That is a training and documentation obligation, sourced from Article 13. |
| Remain aware of automation bias: the tendency to automatically rely or over-rely on output | Named in the Regulation. Interface design that presents a recommendation as a default answer works against this and is a defensible criticism of your design, not just of your training. |
| Correctly interpret the output | Confidence scores nobody can calibrate, or rankings with no explanation, fail here. |
| Decide not to use the system, or disregard, override or reverse the output | Requires authority, not just a button. A reviewer measured on throughput and overruled by a manager when they deviate is not able to disregard output. |
| Intervene or interrupt through a stop button or similar procedure | The system must be able to be halted in a safe state. An architectural requirement. |
The design/operations split
Article 14(3) says measures are either built into the system by the provider, or identified by the provider as appropriate to be implemented by the deployer. There is no third option where nobody does it. If you are the provider and you leave a measure to the deployer, you must say so in the instructions for use under Article 13.
Where this usually goes next
Three situations account for most people reading this page. Each has a different answer.
A deal is blocked on an AI questionnaire
Legal will not sign until you can evidence how AI is governed. HumanAudit’s AI Trust Package is a fixed $3,500 over five business days: a public trust page, a pre-filled SIG Lite / CAIQ / SSPA Section K questionnaire bank, and your AI inventory and classification.
You need ISO/IEC 42001 documentation
23 clause-mapped AIMS documents with all 38 Annex A controls pre-populated, editable and yours to keep, from $199. Or score your gaps first: 18 questions, free, no signup to begin.
You are not sure what reaches you
Twenty minutes with the founder. No prep, no deck, straight to the person accountable for the work. If none of this applies to you, you get told that on the call.
This reference is published by HumanAudit Inc. Not a law firm, not an accredited certification body, not a registered auditor. We build documentation, your counsel interprets it, and an accredited body of your choosing certifies you. How this is funded →
Article 14(5): the four-eyes rule
For remote biometric identification systems under Annex III point 1(a), no action or decision may be taken by the deployer 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.
A derogation applies where Union or national law considers the requirement disproportionate in the context of law enforcement, migration, border control or asylum.
The deployer side: Article 26(2)
Deployers must assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support. Three of those four words are about organisational design, not about staffing a queue.
What an assessor will actually probe
Expert analysis, not the text. In our experience the questions that separate real oversight from nominal oversight are: How long does the reviewer have per case? What proportion of recommendations do they overturn, and is that number tracked? What happens to a reviewer who overturns often? Can they see why the system produced this output? Who can they escalate to, and how fast?
An override rate of approximately zero is not evidence that the system is accurate. It is evidence worth explaining.
Why this article matters beyond compliance
Article 14 is the provision that makes the AI Act a human accountability regulation rather than a technology one. It assumes that the meaningful control point is a person with the information, the authority and the time to disagree with a machine. Designing for that is harder than adding a review step, and it is the difference between oversight that survives an incident investigation and oversight that does not.
Status labels on this page
Verified fact: The five Art. 14(4) capabilities, the Art. 14(3) design/operations split, the Art. 14(5) four-eyes rule and its derogation, and the Art. 26(2) deployer duty.
Expert analysis: The assessor questions above and the reading that override rates near zero require explanation.
Unsettled: What proportionality means for oversight staffing in high-volume workflows. No guidance or enforcement decisions yet.
Evidence oversight, do not assert it
Oversight is proved with artefacts: role definitions with explicit override authority, training records, the information given to reviewers, override rates and how they are reviewed, and the escalation path. That set is also what an ISO 42001 audit asks for.
Not sure where you sit?
The classifier maps your system against Articles 5, 6, 50 and Annex III. Twelve questions, no email.
Questions
What does Article 14 of the EU AI Act require?
Article 14 requires high-risk AI systems to be designed and developed in such a way, including with appropriate human-machine interface tools, that they can be effectively overseen by natural persons during the period in which they are in use. Oversight measures must be commensurate with the risks, level of autonomy and context of use, and are either built into the system by the provider or identified by the provider as appropriate to be implemented by the deployer.
What must a human overseer be able to do?
Article 14(4) requires that the person assigned to oversight is enabled to properly understand the relevant capacities and limitations of the system and duly monitor its operation including detecting and addressing anomalies, dysfunctions and unexpected performance; remain aware of the possible tendency of automatically relying or over-relying on output, known as automation bias; correctly interpret the output; decide in any particular situation not to use the system or otherwise disregard, override or reverse the output; and intervene in the operation or interrupt the system through a stop button or a similar procedure.
What is the four-eyes rule for biometric identification?
Article 14(5) provides that for high-risk AI systems referred to in Annex III point 1(a), no action or decision may be taken by the deployer on the basis of the identification resulting from the system unless that identification has been separately verified and confirmed by at least two natural persons with the necessary competence, training and authority. A derogation exists where Union or national law considers this requirement disproportionate in the context of law enforcement, migration, border control or asylum.
Is a human in the loop enough to satisfy Article 14?
No, and this is the most common misreading. Article 14 requires oversight to be effective, which the article defines through specific capabilities: understanding the system, resisting automation bias, correctly interpreting output, being able to disregard or override it, and being able to stop it.
A reviewer who lacks the authority to overrule a recommendation, the time to examine it, or the information to interpret it is not exercising oversight within the meaning of Article 14. Article 26(2) reinforces this by requiring deployers to assign oversight to people with the necessary competence, training and authority, and the necessary support.
Obligations, article by article
- Art. 5 prohibitions
- Art. 4 AI literacy
- Art. 50 transparency
- Art. 9 risk management
- Art. 10 data governance
- Art. 11 / Annex IV
- Arts. 12–13 logging
- Art. 15 accuracy & security
- Art. 17 QMS
- Arts. 43–48 conformity
- Art. 49 registration
- Art. 57 sandboxes
- Open source
- Art. 72 monitoring
- Art. 73 incidents
- Arts. 51–56 GPAI
- Art. 99 penalties
- Compliance checklist
- FRIA template (Art. 27)
- When Annex III does not apply →