Designing Human Oversight That Satisfies Article 14

A recruitment team pushes 900 applications a month through a CV-ranking tool. A hiring manager sees the top twenty, each with a score and no reasons. She may overrule the ranking, but cannot see the candidates it discarded, has no view of the model's known weaknesses, and has under a minute per profile. On paper, a human in the loop. Measured against Article 14 of the EU AI Act, close to nothing.

Article 14 is the requirement most often assumed to be met and least often met in fact. It is not satisfied by placing a person in the workflow, but by building a system a competent person can oversee and giving them the time, information and authority to act. It applies to high-risk systems — the Annex III uses such as employment, credit and essential services, plus the Annex I product-safety cases.

What Article 14 actually requires

The obligation is framed as a design outcome: a high-risk system must be designed and developed, including through appropriate human-machine interface tools, so that natural persons can effectively oversee it while it is in use. Measures must be proportionate to the risks, autonomy and context of use, and may be built into the system or identified by the provider for the deployer to implement. In practice, both.

The substance is in Article 14(4), which sets out what the assigned overseer must be enabled to do: understand the system's capacities and limitations well enough to detect anomalies, dysfunctions and unexpected performance; stay alert to over-reliance on the output, which the Act names as automation bias; correctly interpret the output, given the interpretation tools available; decide in any case not to use the system, or to disregard, override or reverse its output; and intervene or stop the system so it halts in a safe state. Each is testable. "A manager reviews the output" answers none of them.

Who the duty falls on

Article 14 is a provider obligation. It sits among the requirements a provider must meet before a high-risk system reaches the market, and Article 16 makes the provider answerable for it, together with the technical documentation and instructions for use describing the oversight measures.

The deployer duty is separate and narrower. Article 26 requires deployers to use the system in accordance with the instructions for use, and to assign human oversight to natural persons with the necessary competence, training, authority and support. A deployer cannot invent oversight the product does not support — but it routinely destroys oversight the product does support, by assigning it to someone too junior to override or measured on throughput.

The line between the two moves, and this is the most confused point in the Act. Under Article 25, a deployer, distributor or importer becomes the provider, carrying every provider obligation including Article 14, if it puts its own name or trade mark on a high-risk system already on the market; substantially modifies such a system so that it remains high-risk; or changes the intended purpose of a system not classified as high-risk — including a general-purpose AI system — so that it becomes high-risk. White-labelling a bought-in tool into your own branded portal can therefore transfer the provider duties to you, as can pointing a general-purpose model at an Annex III purpose. Configuration within documented parameters normally does not; changing what the system is for does.

Mapping the five capabilities

Article 14(4) capability	Provider must supply	Deployer must operate
Understand limits; monitor anomalies	Documented performance, known failure modes, visible drift indicators	Reviewers trained on those limits; a routine that reads them
Remain aware of automation bias	Uncertainty surfaced honestly; no bare score presented as fact	Independent judgement recorded before the output is shown
Correctly interpret the output	Interpretation tooling; a statement of what the output cannot mean	Competence testing, not attendance at a briefing
Disregard, override or reverse	An override path in the product, capturing reasons	Authority to override without penalty; override rate monitored
Intervene or stop safely	A stop function halting in a documented safe state	A named person able to trigger it in operating hours

Why a sign-off box is not oversight

Oversight fails predictably: the reviewer lacks the seniority to contradict the system, the time to read the case, or sight of the inputs. None of that is cured by a checkbox marked "reviewed". Override rate is the most useful number you can start collecting on Monday — if reviewers essentially never depart from the output, that is the first thing an assessor will ask about.

The two-person rule for biometric identification

Article 14(5) adds a requirement for the remote biometric identification systems in point 1(a) of Annex III: the deployer may take no action or decision on an identification unless at least two natural persons with the necessary competence, training and authority have separately verified and confirmed it. The Act carves out law enforcement, migration, border and asylum uses where Union or national law considers this disproportionate. If you deploy facial identification commercially, assume it applies and staff for it — it changes rotas, not policy documents.

Evidence that satisfies an assessor

• A written oversight design per system, mapping each control to the Article 14(4) capability it delivers.
• The provider's instructions for use, plus a gap note wherever you do not implement a measure identified for you.
• Named individuals assigned oversight, with competence evidence, training records and written override authority.
• Interface evidence of what the reviewer actually sees, including uncertainty and limitation information.
• Override and stop logs: volume, rate, reasons, and resulting changes.
• A dated record of at least one deliberately exercised stop or intervention test.
• Workload data showing the task is achievable in the time allowed.
• The Article 25 assessment of whether you have become the provider.

Article 14 does not discharge your data protection duties

These are separate regimes with separate regulators. Where a high-risk system drives a decision with legal or similarly significant effects, UK and EU GDPR restrictions on solely automated decision-making apply independently. The standard there — meaningful intervention by someone competent and authorised to reach a different outcome — is materially similar, but separately enforced and carrying fines of up to 4% of global annual turnover. The AI Act also gives affected persons a right to an explanation of individual decision-making for certain Annex III decisions, and requires some deployers to describe their oversight measures in a fundamental rights impact assessment. Discrimination law applies on top, with no AI-specific defence.

Where this guidance stops

This is general guidance, not legal advice, and two uncertainties deserve flagging rather than false precision. The detailed technical expectations for human oversight are intended to come through harmonised standards and Commission guidance, and that work is not concluded; until it is, "state of the art" means documented, defensible judgement, not a settled specification. The application timetable for the high-risk requirements has itself been subject to proposed amendment, so confirm the dates in force for your classification rather than trusting one quoted in any article, including this one.

Breach of provider or deployer obligations of this kind attracts fines of up to 3% of global annual turnover; the 7% ceiling is reserved for the prohibited practices in Article 5. An oversight failure rarely arrives as an AI Act fine first. It arrives as a tribunal claim, a subject access request, or a customer asking why a decision was made — and the answer is whatever your logs can show. Take specialist advice where you deploy biometrics, where a vendor relationship may have made you the provider, or where you rely on a claimed exemption from high-risk classification.