EU AI Act Article 14: Human Oversight of High-Risk AI Systems

Article 14 of Regulation (EU) 2024/1689 requires that every high-risk AI system be designed and used so that a named, competent natural person can understand what the system is doing, detect when it goes wrong, and stop it. This is not a governance aspiration; it is a binding technical and procedural obligation that shapes both how Providers build high-risk systems and how Deployers run them. Under the Digital Omnibus agreed in May 2026, stand-alone high-risk systems (the Annex III list — recruitment, credit, biometrics, education, law enforcement, and others) must meet this obligation from 2 December 2027. Systems that are safety components of regulated products under Annex I must comply from 2 August 2028. Non-compliance with Article 14 and associated high-risk obligations carries fines of up to €15 million or 3% of worldwide annual turnover, whichever is higher (Article 99).

Two things distinguish Article 14 from lookalike obligations. First, it is not the same as Article 13 transparency, which concerns what information Providers must give Deployers about the system. Article 14 is about operational control: the live ability to intervene. Second, it is not the same as GDPR Article 22, which restricts solely automated individual decisions with legal or similarly significant effects and gives data subjects the right to request human review. Article 14 is broader — it applies to the entire operation of a high-risk AI system, not only to outputs that trigger Article 22, and it creates duties for the organisation rather than rights for individuals. The two regimes overlap when a high-risk AI informs decisions about individuals; organisations subject to both must satisfy each on its own terms.

---

What Article 14 actually requires: the five obligations

The text of Article 14 breaks into five numbered paragraphs. Each creates a distinct obligation.

Article 14(1): design for oversight

High-risk AI systems must be designed and developed — including with appropriate human-machine interface tools — so that they can be effectively overseen by natural persons during the period of use. This places the primary design duty on the Provider: by the time a system reaches market, human oversight must be technically feasible, not retrofitted.

"Effectively" is the load-bearing word. A system that generates outputs a non-specialist cannot interpret, or that operates at a speed or scale that makes review impractical, does not satisfy Article 14(1) regardless of how many approval checkboxes are bolted on.

Article 14(2): the aim — prevent and minimise risk

The oversight measures are aimed at preventing or minimising risks to health, safety, and fundamental rights. This paragraph anchors the whole Article to the harm-prevention purpose of the Regulation: oversight is not bureaucratic recordkeeping, it is an active risk control.

Article 14(3): allocation between Provider and Deployer

Oversight measures must be identified and, where technically feasible, built into the system by the Provider. Where technical feasibility limits what can be built in, the remaining measures must be implemented by the Deployer.

In practice this creates a split responsibility:

• Provider: designs interpretable outputs, explainability tools, monitoring dashboards, alert thresholds, and a mechanism to halt the system. Documents the oversight design in Annex IV technical documentation.
• Deployer: assigns trained, competent persons to exercise oversight; establishes operational procedures; ensures the Provider's built-in mechanisms are actually used.

Neither party can discharge its obligation by pointing at the other.

Article 14(4): what the overseer must be able to do

Article 14(4) is the substantive core. The persons assigned to oversee a high-risk AI system must be enabled to:

(a) Properly understand the system's capacities and limitations. Not a high-level summary, but working knowledge of what the system can and cannot do, where its training data came from, what use cases it was not designed for, and what failure modes look like in practice. A credit-scoring AI overseer who does not know that the model was trained on a particular demographic profile cannot meaningfully assess whether its outputs are reliable for a given applicant.

(b) Monitor operation, including by detecting anomalies, dysfunctions, or unexpected performance. Ongoing vigilance, not a post-incident review. For a recruitment AI, this means noticing when rejection rates for a protected group shift. For a fraud-detection system, it means catching when the false-positive rate climbs above baseline.

(c) Remain aware of automation bias — the tendency to over-rely on AI recommendations without sufficient critical scrutiny, especially for systems that provide information or recommendations to individuals. The Regulation names this explicitly because it is a documented cognitive hazard. Organisations must design their processes to counteract it: mandatory review of high-confidence outputs, documented override rationale, periodic audits of approval rates. An overseer who approves 98% of AI recommendations without documented reasoning is exhibiting automation bias, whatever their subjective confidence.

(d) Correctly interpret the output. The system must provide tools and methods — confidence scores, feature importance, explanations, uncertainty ranges — that allow the overseer to understand what the output means, not just accept or reject it as a number.

(e) Decide not to use the system, or disregard, override, or reverse the output in a specific situation. And where necessary, intervene or stop the system via a "stop button" or similar procedure. This is the kill-switch requirement: the overseer must have the technical means and the organisational authority to halt operation. Authority that exists on paper but cannot be exercised without approval from three management levels is not compliance.

Article 14(5): two-person verification for remote biometric identification

For high-risk AI systems that are remote biometric identification systems (Annex III, point 1(a)), Article 14(5) imposes an additional, stricter rule: 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 competent natural persons. This two-person rule applies whether the identification is used for law enforcement, border control, or any other Annex III purpose, with a narrow carve-out for law enforcement where the urgency of the situation makes prior dual confirmation impossible — in which case retrospective verification is required.

This provision reflects the particular potential for harm from biometric misidentification. It is separate from and additional to the general Art 14(4) oversight obligations.

---

The deployer's Article 26 duty: assign the right people

Article 14 defines what oversight looks like. Article 26 makes the Deployer responsible for ensuring it happens: Deployers must assign human oversight to persons who have the necessary competence, training, and authority.

All three elements are non-negotiable.

Competence is domain-specific. A loan officer overseeing a credit-risk model needs to understand the model's training data, its accuracy across demographic groups, and what a false negative costs in practice. A radiologist overseeing a medical imaging system needs clinical knowledge to distinguish a system hallucination from a genuine finding. Neither person needs to be a data scientist, but both need enough technical literacy to recognise anomalies.

Training must be documented and specific to the system. General AI ethics awareness is not sufficient. Training must cover: the system's intended use and known limitations (Art 14(4)(a)); how to read its outputs (Art 14(4)(d)); what anomalies look like (Art 14(4)(b)); how to recognise and resist automation bias (Art 14(4)(c)); and the override and escalation procedure (Art 14(4)(e)). When the system is substantially modified, training must be refreshed.

Authority must be real. The overseer's decision to reject, override, or halt the AI must be binding within their assigned scope. No routine approval layer can override it without documented justification. Assigning oversight to a junior analyst who must escalate every override to a manager who then routinely approves the AI's original output does not satisfy Article 26.

A common failure pattern: assigning oversight to a job title rather than a named individual. Regulators will ask who performed oversight on a specific date. Have a name.

---

Article 14 is not Article 13, and not GDPR Article 22

Because Article 14 sits in the middle of a dense compliance stack, it is worth being precise about what it is not.

Article 13 (transparency to deployers) requires Providers to supply instructions, system descriptions, performance metrics, and known limitations so that Deployers can use the system correctly. It is a documentation obligation. Article 14 is an operational control obligation. A system can have excellent Article 13 documentation and still fail Article 14 if the Deployer's overseer lacks the training or authority to act on it.

GDPR Article 22 prohibits solely automated decisions that produce legal or similarly significant effects on individuals, and gives data subjects the right to request human intervention, express their point of view, and contest the decision. Article 22 creates individual rights and prohibits certain decisions absent human involvement. Article 14 creates organisational obligations to maintain oversight capacity regardless of whether any individual invokes Article 22. In practice, if your high-risk AI makes individual decisions that also engage Article 22 — credit denials, employment rejections — you must satisfy both: the Article 22 human review must be genuine, and the Article 14 oversight framework must underpin the process. The Article 14 overseer and the Article 22 human reviewer can be the same person, provided they have the competence and authority each regime requires.

---

Provider obligations: building oversight in

For a Provider placing a high-risk AI system on the market, Article 14 is a design specification, not an afterthought. The system must arrive with the technical infrastructure for oversight already built.

Concretely, this means:

Interpretable outputs. A system that returns a binary classification without explanation makes Article 14(4)(d) impossible. Outputs must include the information an overseer needs to correctly interpret them — confidence scores, the factors that drove the output, the ranges the system was trained on, and any caveats about edge cases or out-of-distribution inputs.

Monitoring capability. The system must generate logs, alerts, and performance metrics that enable an overseer to detect anomalies (Art 14(4)(b)) in real time or near-real time. A system that can only be audited by pulling database records six months later does not comply.

A functional stop mechanism. Article 14(4)(e) requires a "stop button or similar procedure." This must be a documented technical capability: a named person can halt the system, and the system will halt. The mechanism must be tested.

Documentation for deployers. Under Annex IV §8, technical documentation must specify: the human oversight design, the competence requirements for overseers, the decision points where oversight is mandatory, the interfaces and tools that enable it, and the escalation and override procedures. This is what Deployers receive and must implement.

Where it is technically infeasible to build a particular oversight measure into the system itself — for example, because the system is deployed in contexts the Provider cannot control — Article 14(3) permits the Provider to specify that the Deployer must implement those measures operationally. But this must be documented and cannot be used as a blanket exception: the default is built-in, with deployer-side measures as the fallback for what is genuinely infeasible.

---

Deployer obligations: making oversight real

Most companies are Deployers — they purchase or licence a high-risk AI system from a Provider and put it to use in their operations. Article 14(3) and Article 26 together define what Deployers must do.

Follow the Provider's instructions. The Provider's Article 13 documentation specifies how the system is intended to be used and what oversight measures the Deployer must implement. Not following those instructions is itself a compliance failure.

Assign named, competent, trained overseers with real authority. See the Article 26 section above.

Establish documented operational procedures. How does the overseer receive outputs? What information do they see? Which outputs require mandatory review before action is taken? What is the escalation path? What triggers a halt? These procedures must be written down, tested, and updated when the system changes.

Monitor and log. Article 26 requires Deployers to retain logs of operation for at least six months, or longer where other EU or national law requires it. Logs must capture inputs, outputs, and human oversight actions — approvals, rejections, overrides, escalations.

Report serious incidents. Where a high-risk AI system causes or could cause serious harm, Article 26 requires the Deployer to notify the Provider and, where applicable, competent authorities under Article 73 without undue delay.

A Deployer cannot claim that the Provider's system was inadequate as a defence. Article 26 places the duty to make oversight work squarely on the Deployer. If the Provider's system does not support adequate oversight, the Deployer should not deploy it.

---

The automation bias problem in practice

Article 14(4)(c) singles out automation bias because it is the most common practical failure mode for human oversight. It is worth understanding what it looks like in production.

A medical records team deploys an AI that predicts patient deterioration risk. The system is accurate 89% of the time. Overseers receive a queue of flagged patients. After three months, analysts pull the override log: overseers have disagreed with the system in 1.2% of cases. The system is overriding human judgment, not the other way around. The overseers believe they are exercising oversight; they are actually ratifying the AI's decisions.

The fix is procedural, not just technical. Effective automation bias mitigation includes:

• Randomly selecting outputs for mandatory detailed review, including high-confidence outputs (not only edge cases)
• Requiring overseers to document their reasoning, not just approve or reject
• Auditing override rates and investigating systematic under-use of override authority
• Periodically testing overseers with synthetic cases where the AI is wrong and measuring detection rates

These are not optional good practices. They are the operationalisation of Article 14(4)(c)'s requirement that overseers "be aware of the possible tendency to automatically rely on or over-rely on the output."

---

Special case: remote biometric identification under Article 14(5)

Remote biometric identification systems — systems that identify individuals at a distance without their active cooperation, such as facial recognition in public spaces — are treated as the highest-stakes subclass of high-risk AI. Article 14(5) therefore imposes a specific two-person rule: no action or decision on the basis of a biometric identification is permitted unless at least two competent natural persons have separately verified and confirmed it.

"Separately" means independently: not one person signing off on another's conclusion, but two independent assessments each reaching the same result. Both persons must be competent — which, for a law enforcement application, typically means trained officers with the legal authority to act on the identification.

The narrow carve-out for urgency applies only in law enforcement contexts where prior two-person confirmation is genuinely impractical. Even then, retrospective dual verification is required. Organisations deploying remote biometric identification for commercial purposes — access control, attendance monitoring, customer recognition — have no urgency carve-out.

---

Implementing Article 14: what a workable oversight structure looks like

Abstract requirements become clearer with a concrete example. Consider a 60-person logistics company using a high-risk AI system to screen job applicants (Annex III, point 4 — employment). The system ranks candidates and recommends a shortlist.

Provider-side design (Article 14(1) and (3)): The system generates a ranked list with a score and the top three scoring factors for each candidate. It flags any candidate where confidence is below 70% or where a protected characteristic appears in the top five factors. It includes a documented override button in the interface, and the interface requires the reviewer to record a reason before confirming or overriding the shortlist.

Deployer-side implementation (Article 26): The HR Manager is designated the named overseer. She has five years of recruitment experience and completes a two-hour system-specific training covering the model's accuracy by demographic group, its known failure modes on non-standard CVs, and the override procedure. The training is recorded in the HR system. Her authority to reject or modify the shortlist is documented in the IT governance policy — no approval is required to exercise it.

Operational procedure: Every shortlist recommendation is routed to the HR Manager's review queue before being communicated to candidates. She reviews the scoring factors, checks for anomalies, and approves or modifies the shortlist. Her decision is logged with a timestamp. If the system flags more than three candidates with protected-characteristic warnings in a single batch, she escalates to the compliance officer.

Monitoring: Monthly, the compliance officer reviews the override log. Override rate below 3% triggers an automation bias review. Any serious incident (a discriminatory output that causes harm) is reported to the Provider within 48 hours per Article 73.

This is a proportionate Article 14 implementation for a company of that size. A larger financial institution deploying a credit-decisioning system would need more elaborate controls — multiple overseers, formal competence assessment, integration with the risk management system under Article 9 — but the structure is the same.

---

Documentation requirements

For Providers, Article 11 and Annex IV §8 require technical documentation to include the human oversight design:

• The oversight function and its role in the system lifecycle
• Competence and training requirements for overseers
• Technical interfaces, alert mechanisms, and logging
• The stop mechanism and how it works
• Escalation and override procedures

For Deployers, documentation takes the form of operational procedures — written records of who oversees what, what training they have completed, what the monitoring cadence is, and what the escalation path looks like. These operational procedures are separate from the Provider's technical documentation; they are the Deployer's own compliance record.

Article 11(5) requires both Providers and Deployers to retain documentation for the duration of deployment plus five years. A system deployed in 2027 and retired in 2033 requires documentation through 2038. Competent authorities may request it at any time; failure to produce it is a separate violation under Article 99.

---

How Confir supports Article 14 compliance

Confir's AITO compliance area (Transparency and Human Oversight) covers Articles 13, 14, 27, and 50. For Article 14 specifically, the human-oversight assessment record within AITO walks you through naming the overseer, documenting competence and authority, specifying monitoring cadence, and recording the stop mechanism. The same assessment feeds Confir's Annex IV §8 documentation output for Providers and the operational procedures template for Deployers.

The Compliance Health Score flags any high-risk system without a completed human-oversight assessment record as a critical gap. For Deployers whose systems touch sensitive Annex III domains — employment, law enforcement, justice — the Fundamental Rights Impact Assessment (Article 27) includes a dedicated human oversight section where oversight adequacy is assessed against the rights at stake.

---

Penalties and enforcement context

Non-compliance with Article 14 falls into the middle penalty tier under Article 99: up to €15 million or 3% of worldwide annual turnover for the preceding financial year, whichever is higher. For companies with fewer than 250 employees, the fine is capped at the lower of the percentage or the fixed amount — a proportionality protection Article 99(6) extends specifically to SMEs and start-ups.

Market surveillance authorities, national competent authorities, and the AI Office can investigate compliance, require documentation, and order corrective measures or system suspension. For high-risk systems in the law enforcement, justice, or biometrics domains, the Article 14(5) two-person rule will be a specific audit focus.

The deadline matters: stand-alone Annex III systems must comply from 2 December 2027. That is roughly 18 months from now. Technical documentation, oversight design, competence assessment, and operational procedures all take meaningful time to produce. Starting in the second half of 2026 is reasonable; starting in the third quarter of 2027 is not.

---

Frequently asked questions

What exactly is Article 14 about, and why is it sometimes mislabelled as Article 6?

Article 14 is the human oversight requirement for high-risk AI systems in Regulation (EU) 2024/1689. It requires that high-risk systems be designed so that natural persons can understand, monitor, and stop them. The mislabelling occurs because older guides — and some professional summaries — incorrectly map oversight to Article 6, which is actually the classification rule that determines whether a system is high-risk in the first place. Article 6 asks "is this system high-risk?" Article 14 asks "given that it is, who oversees it and how?"

Does Article 14 apply to every AI system my company uses?

No. Article 14 applies only to high-risk AI systems as defined by Article 6 and Annex III (and Annex I for product-safety components). A customer service chatbot, a marketing recommendation engine, or an internal scheduling tool is almost certainly not high-risk. You must first classify each system against Annex III before Article 14 obligations apply. If your system does not land in an Annex III category, or if it qualifies for the Article 6(3) filter (narrow procedural task, no profiling of natural persons), Article 14 does not apply.

Who must implement Article 14 — the Provider or the Deployer?

Both, in different ways. Providers must build oversight capability into the system: interpretable outputs, monitoring tools, a stop mechanism, and documented competence requirements. Deployers must make oversight operational: assign named, trained, authorised persons, establish documented procedures, and maintain logs. Article 14(3) draws the line by technical feasibility — what can be built in must be; what cannot is the Deployer's responsibility to implement. A Deployer cannot point to a Provider's shortcomings as a defence for inadequate oversight.

What is automation bias and how does Article 14 address it?

Automation bias is the cognitive tendency to accept AI output with less scrutiny than the same information presented by a human — particularly when the AI expresses high confidence, when the overseer is busy, or when overrides are rarely needed. Article 14(4)(c) explicitly requires that overseers be equipped to remain aware of this tendency. In practice, compliance means: procedural checkpoints that require documented reasoning rather than passive approval; periodic audits of override rates; random sampling of high-confidence outputs for mandatory detailed review; and training that explicitly addresses the phenomenon.

What is the Article 14(5) two-person rule for biometric identification?

For remote biometric identification systems (Annex III, point 1(a)), Article 14(5) prohibits any action or decision based on the identification unless at least two competent natural persons have separately verified and confirmed it. This is independent of the general Article 14(4) oversight obligations — both apply. The two-person rule has a narrow law-enforcement urgency carve-out, but no equivalent exception exists for commercial deployments.

How does Article 14 relate to GDPR Article 22?

They are distinct obligations that can overlap. GDPR Article 22 restricts solely automated individual decisions with legal or similarly significant effects, and gives data subjects rights to request human intervention and contest the decision. Article 14 creates organisational obligations to maintain oversight of high-risk AI systems regardless of whether any individual invokes Article 22. When a high-risk AI produces individual decisions that engage both — a credit denial, an employment rejection — the Article 22 human review must be genuine and must meet Article 14's competence and authority requirements. Satisfying one does not automatically satisfy the other.

What is the compliance deadline for Article 14?

Under the Digital Omnibus agreed in May 2026, Article 14 obligations for stand-alone Annex III high-risk systems apply from 2 December 2027 (deferred from the original 2 August 2026 date). High-risk AI embedded as safety components of Annex I regulated products must comply from 2 August 2028. The political agreement was reached on 7 May 2026; formal adoption is expected before the original August 2026 date.

---

Related guides

• EU AI Act compliance requirements
• AI governance for high-risk systems
• AI risk classification requirements
• AI system inventory management tools