Article 14 requires high-risk AI systems to be designed so natural persons can oversee them effectively while in use. Overseers must be able to understand the system, resist automation bias, interpret output, decide not to use it or override it, and stop it safely. A human clicking approve without information does not meet that.
What the article lists
Oversight aims to prevent or reduce risks to health, safety and fundamental rights. Measures should match the system's risk, level of autonomy and context. Providers can build features into the system, identify measures for deployers, or both.
The person overseeing must be enabled to:
- Understand the system's capabilities and limits and monitor it for anomalies, malfunctions and unexpected performance.
- Stay aware of automation bias, meaning over-reliance on output.
- Interpret output correctly, using available interpretation tools.
- Decide not to use the system in a situation, or override or reverse its output.
- Intervene or halt the system, for example with a stop button or similar procedure.
For biometric identification under Annex III point 1(a), no action may be based on the identification unless two competent, trained and authorised people separately verify it, with exceptions for certain law enforcement and border uses.
Where oversight fails
The most common failure is rubber stamping. A reviewer sees a score and a button, has thirty seconds and no way to see why. Others:
- The reviewer is not trained on the system's known weaknesses.
- Overriding takes more effort than accepting.
- The reviewer is measured on throughput.
- There is no stop procedure, so concerns go nowhere.
Design choices that help
- Show reasons, inputs and confidence next to the output, not behind a click.
- Make declining or overriding one step, and log it.
- Sample accepted outputs for second review to detect complacency.
- Give reviewers examples of past errors.
- Set workload limits so review time is real.
- Define who can pause the system and under what conditions.
Deployer side
Article 26 requires deployers to give oversight to people with the competence, training, authority and support. Authority matters: a reviewer who cannot overrule a manager's target is not an overseer.
Measuring whether it works
Track override rates, review time, and the share of reviewed cases where the reviewer found an error. A rate near zero is not necessarily good news. It can mean nobody is really looking.
Write the oversight design down as part of your documentation. A one page description of who oversees, what they see, how they intervene and how you check it works will help both the provider and deployer sides. Review it after every incident and after any change in how the output is used.
Quick check
Is a human in the loop enough?
Only if that person has the information, training, authority and ability to override or stop the system.
What is automation bias?
Excessive reliance on a system's output, which Article 14 says overseers must stay aware of.
Sources
Last reviewed: 19 October 2026.
