EU AI Act Article 14: Human Oversight for High-Risk AI

Article 14 of the EU AI Act requires high-risk AI systems to be built so that people can actually oversee them, yet most programmes treat it as "a human signs off somewhere" and never test whether that human can understand, override or stop the system. The article splits the work between the provider, who must design oversight into the system and its instructions, and the deployer, who must staff it with people who have the competence, training and authority to act. This guide takes Article 14 point by point and turns it into design requirements, staffing decisions, tests and evidence. It is written for providers building high-risk systems such as credit scoring, recruitment or biometric tools, for deployers putting them into service, and for the risk, security and audit teams asked to show that oversight is real. For the wider regime start with the EU AI Act High-Risk AI Systems Guide; for approval gates on general-purpose agents see the Human-in-the-Loop for AI Agents Guide.

Key takeaways

Oversight is a design property, not a job title. Article 14(1) requires the system itself, including its human-machine interface tools, to be designed so natural persons can oversee it effectively while it is in use.
Five capabilities define "effective". Article 14(4) lists them: understand capabilities and limits and spot anomalies, stay aware of automation bias, interpret outputs correctly, decide not to use or to override the output, and intervene or halt the system safely.
The provider designs, the deployer staffs. Measures can be built in by the provider or identified for the deployer to implement (Article 14(3)), and Article 26(2) requires deployers to assign oversight to people with competence, training, authority and support.
Two people for remote biometric identification. For Annex III point 1(a) systems, no action may be taken on an identification unless at least two competent people have separately verified and confirmed it (Article 14(5)), with exceptions for law enforcement, migration, border control and asylum where law deems it disproportionate.
Identity makes oversight provable. Overseer accounts, override rights and the stop control are access decisions; each intervention should be logged against a named person and the stop path should revoke the system's own credentials.

What Article 14 requires, paragraph by paragraph

The table below paraphrases Article 14 of Regulation (EU) 2024/1689 as shown on the European Commission's AI Act Service Desk, checked on 9 November 2026. The Service Desk marks changes made by the Digital Omnibus on AI, Regulation (EU) 2026/1744, and showed none on Article 14 when checked. The Omnibus did move the application dates for high-risk obligations; confirm the current dates in the EU AI Act Implementation Timeline Tracker.

Paragraph	What it requires	Who acts	Design question it raises
14(1)	Design and develop the system, including suitable human-machine interface tools, so natural persons can effectively oversee it during use	Provider	What does the overseer see, and where, at the moment of decision?
14(2)	Oversight aims to prevent or minimise risks to health, safety or fundamental rights, under intended use and reasonably foreseeable misuse, especially risks that remain after other requirements are applied	Provider	Which residual risks from the Article 9 risk register does oversight mitigate?
14(3)	Measures commensurate with the risks, level of autonomy and context of use; built in by the provider where technically feasible, identified for the deployer to implement, or both	Provider, then deployer	Which measures are in the product, and which are handed to the deployer in the instructions?
14(4)(a)	Overseers can properly understand capacities and limitations, monitor operation, and detect and address anomalies, dysfunctions and unexpected performance	Provider enables, deployer uses	What signals tell an overseer the system is out of its operating envelope?
14(4)(b)	Overseers remain aware of the tendency to over-rely on outputs (automation bias), in particular where the system gives information or recommendations for human decisions	Both	How does the interface and training counter rubber-stamping?
14(4)(c)	Overseers can correctly interpret outputs, taking account of available interpretation tools and methods	Provider enables	What explanation, confidence or evidence accompanies each output?
14(4)(d)	Overseers can decide not to use the system, or to disregard, override or reverse its output, in any particular situation	Both	Is there a working, recorded override path, and does the process allow it to be used?
14(4)(e)	Overseers can intervene in operation or interrupt the system through a "stop" button or similar procedure that brings it to a halt in a safe state	Provider enables, deployer uses	What is the safe state, and what happens to in-flight work and credentials when it is reached?
14(5)	For Annex III point 1(a) systems, no action or decision on an identification unless separately verified and confirmed by at least two natural persons with the necessary competence, training and authority; exception where Union or national law deems it disproportionate for law enforcement, migration, border control or asylum	Deployer	How are two independent confirmations captured and enforced?

Recital 73 adds useful intent: where appropriate the system should include operational constraints it cannot override itself, it should be responsive to the human operator, and it should help overseers decide whether, when and how to intervene. It also notes that for the two-person check the persons may come from different entities, and that automatic logging of the separate verifications may be sufficient.

How Article 14 connects to the rest of the Act

Article 14 does not stand alone. The same oversight design has to appear in four other places, and assessors will check that they agree.

Provision	Oversight link	Evidence to keep
Article 9 risk management	Residual risks that oversight is meant to catch	Risk register entries that name the oversight control
Article 11 and Annex IV point 2(e)	Technical documentation must assess the oversight measures needed under Article 14, including the measures that help deployers interpret outputs	Oversight design assessment and test results
Annex IV point 3	Detailed information on monitoring, functioning and control, including the Article 14 measures	Interface specification, stop procedure, monitoring signals
Article 13(3)(d)	Instructions for use must describe the oversight measures and the technical measures for interpreting outputs	The deployer-facing oversight section of the instructions
Article 12(3)(d)	For Annex III point 1(a) systems, logs must identify the natural persons involved in verifying results under Article 14(5)	Verification log records with named verifiers
Article 26(2) and 26(5)	Deployers assign competent overseers, monitor operation, and suspend use and inform the provider and market surveillance authority where they believe use presents a risk	Overseer assignments, training records, suspension decisions
Article 4	AI literacy duty for staff dealing with AI systems	Literacy and role training records

See the EU AI Act AI Literacy Obligations (Article 4) Guide for the general training duty; Article 14 needs role-specific training on top of it.

Designing the five oversight capabilities

For each Article 14(4) capability, the provider needs a concrete design feature and a test that shows it works with real overseers, not only in a specification.

Capability	Design features that support it	How to test it
(a) Understand and monitor	Plain statement of intended purpose and known limits in the interface; drift and data quality indicators; out-of-distribution or low-confidence flags; a monitoring view of volumes and error rates	Inject inputs outside the operating envelope and measure whether overseers notice within the agreed time
(b) Automation bias awareness	Show the recommendation after the overseer has seen the case evidence where workable; require a reason when accepting high-impact outputs; periodic seeded cases with known wrong outputs	Track agreement rate with seeded wrong outputs; a rate near 100 percent means overseers are not checking
(c) Interpret outputs	Confidence or uncertainty indication, the main factors behind the output, and the source data used, in language the overseer understands; the accuracy metrics declared under Article 13	Ask overseers to explain sampled outputs; compare with the system's actual basis
(d) Decide not to use, override or reverse	An override control on every decision screen, a reverse path for outputs already applied, and no performance target that penalises overrides	Time an override end to end and confirm downstream systems honour it
(e) Intervene or halt in a safe state	A stop control that pauses intake, holds or completes in-flight work to a defined safe state, and switches the process to a documented manual fallback	Pull the stop in a controlled exercise and verify the safe state and fallback

Define the safe state first: for a recruitment screening tool it may be "no automated rejections, all applications queued for manual review"; for a credit model it may be "decline to decide, refer to underwriter". Without a defined safe state the stop button has nothing to stop to.
Operational constraints the system cannot override: recital 73 points to built-in limits, such as hard thresholds above which the system must refer to a human, or decision types it may never finalise alone. Enforce these outside the model, in application logic.
Interface is part of compliance: Article 14(1) names human-machine interface tools explicitly, so screen designs and usability tests belong in the technical documentation.

Choosing the oversight mode

Article 14(3) asks for measures commensurate with risk, autonomy and context. In practice that means choosing where the human sits. The guidance below is an NHI Mgmt Group recommendation, not text from the Act.

Mode	How it works	Fits when	Watch out for
Human in the loop	Every output is reviewed before it takes effect	Individual decisions with significant effect on a person, low to moderate volume	Fatigue and rubber-stamping at volume
Human on the loop	System acts; humans monitor, sample and can intervene or stop	High volume, reversible outcomes, strong monitoring signals	Harm occurs before anyone looks; needs fast reverse path
Threshold referral	System decides within limits; cases outside thresholds or below confidence go to a human	Mixed portfolios where most cases are routine	Thresholds tuned for throughput rather than risk
Two-person verification	Two competent people separately confirm before action	Required for Annex III point 1(a) remote biometric identification; useful for other irreversible actions	Second check becoming a formality; both reviewers seeing each other's view

Small deployers: one high-risk system with a few overseers can rely on the provider's built-in controls, a written assignment, training and a quarterly stop exercise.
Large deployers: several systems across business units need a central register of overseers per system, standard override and stop procedures, and oversight metrics reported to the risk committee.
Reversible versus irreversible: the less reversible the effect on a person, the further left in the table you should sit.

Staffing oversight: the deployer's side

Article 26(2) requires deployers to assign oversight to natural persons who have the necessary competence, training and authority, and to give them the support they need. Each element can be evidenced.

Competence: domain knowledge to judge the case without the system, for example an experienced underwriter rather than a junior operator.
Training: the provider's instructions for use, the system's known limits, automation bias, how to override and how to stop. Record completion per person and refresh it when the system changes materially.
Authority: written authority to override and to stop without seeking permission, and protection from targets that punish overrides. An overseer who must escalate before pressing stop does not meet the intent of 14(4)(e).
Support: time per case, staffing that matches volume, and a route to raise concerns that feeds the Article 26(5) duty to inform the provider and suspend use where a risk is suspected.

Where identity fits

Oversight is only provable if every human action and every system action is tied to a distinct identity, and the stop control works at the access layer as well as in the interface.

Named overseer accounts: no shared logins for review, override or stop. Article 12(3)(d) already requires verifier identities in logs for biometric identification systems; apply the same pattern to all high-risk systems.
Override and stop as privileged actions: grant them through role assignments with an owner, review them in access certifications, and remove them at role change.
Separation of duties for two-person checks: enforce that the two verifiers are different identities and that neither can see the other's decision before submitting their own.
The system's own credentials: the stop path should disable or revoke the service accounts, API keys and tokens the AI system uses to act on other systems, so a halted interface does not leave a running integration. See the AI Agent Kill Switch and Containment Guide.
Attributable logs: record who reviewed, what they saw, whether they accepted or overrode, and their reason. See the AI Agent Audit Trails for Regulators Guide.

Implementing Article 14 in phases

Map residual risks to oversight (provider): from the Article 9 risk register, list each risk that oversight mitigates and the capability in 14(4) that addresses it.
Specify the measures: decide which are built in and which the deployer implements, define the safe state and manual fallback, and write the oversight section of the instructions for use under Article 13(3)(d).
Build and usability-test the interface: run sessions with representative overseers, including seeded wrong outputs and out-of-envelope inputs, and record results in the Annex IV documentation.
Pilot with the deployer: run in shadow mode, where the system's outputs are recorded but humans decide, and compare agreement and override behaviour before outputs take effect.
Assign and train overseers (deployer): named people, written authority, role training and a support model sized to volume.
Exercise the stop and override paths: pull the stop in a controlled window, confirm the safe state, the fallback and credential revocation, then restart from a known-good configuration. Rollback is restarting with the previous approved model and configuration.
Operate and review: monitor the metrics below, feed findings into post-market monitoring under Article 72, and repeat the stop exercise at least quarterly (NHI Mgmt Group recommendation).

Detection and measurement

Log every review, override, reversal, stop and restart with the overseer's identity, timestamp, case reference and reason. These metrics show whether oversight is working.

Override rate per overseer and per system: both near zero and very high values need investigation.
Seeded-error catch rate: share of deliberately wrong outputs that overseers reject; the clearest automation bias measure.
Time to stop: from decision to verified safe state in exercises.
Review time per case: times consistently below what a genuine check needs suggest rubber-stamping.
Overseer coverage: share of in-use high-risk systems with named, trained overseers holding current authority.
Suspension and provider notifications: count and time to act under Article 26(5).

Framework mapping

Article 14 element	NIST SP 800-53 Rev. 5	NIST CSF 2.0	Other references
Overseer roles and authority	AC-5 Separation of Duties	GV.RR-02	ISO/IEC 42001:2023 AI management system roles and responsibilities
Overseer training	AT-3 Role-based Training	PR.AT-02	AI Act Article 4 and Article 26(2)
Logging of oversight actions	AU-2 Event Logging; AU-6 Audit Record Review, Analysis, and Reporting	DE.CM-09	AI Act Article 12
Stop and suspension	IR-4 Incident Handling	RS.MI-01	AI Act Article 26(5)
Oversight in risk management	RA-3 Risk Assessment	ID.RA-05	NIST AI RMF 1.0 Govern and Manage functions

Common failure patterns

The rubber stamp: a human approves every output but has no time, information or authority to disagree. Agreement rates near 100 percent and review times of seconds are the signal.
A stop button with no safe state: the interface stops, but queued jobs, scheduled batches or integrations keep acting with the system's credentials.
Oversight left entirely to the deployer: the provider writes "the deployer shall ensure human oversight" in the instructions without building interpretation aids or a stop path, which does not meet 14(1) or Annex IV point 2(e).
Override that downstream systems ignore: the overseer reverses a decision but the case management or payment system has already acted on the original output.
Two-person checks that are not independent: the second verifier sees the first verifier's answer, or both use one shared account, so the record cannot show two separate confirmations.
Targets that punish overrides: throughput metrics make overriding the system costly for the overseer, quietly removing the authority Article 26(2) requires.

Practitioner checklist

Map each residual risk in the Article 9 register to the Article 14(4) capability that addresses it.
Define the safe state and manual fallback for every high-risk system before go-live.
Document built-in and deployer-implemented oversight measures in the Annex IV file and the Article 13(3)(d) instructions.
Usability-test the oversight interface with seeded wrong outputs and out-of-envelope inputs.
Assign named overseers with written authority to override and stop, and record their training.
Make override and stop privileged roles with owners and periodic access review.
Ensure the stop path revokes or disables the system's service credentials and integrations.
Enforce independent, separately logged confirmations for any two-person verification.
Exercise stop and restart at least quarterly and track override, seeded-error and time-to-stop metrics.

Standards and references

This guide summarises Article 14 of the EU AI Act and related provisions and is not legal advice. Related NHI Mgmt Group resources: EU AI Act High-Risk AI Systems Guide · EU AI Act Provider vs Deployer Obligations Guide · EU AI Act Article 15 Guide · Human-in-the-Loop for AI Agents Guide

EU AI Act Article 14 Guide: Designing Human Oversight for High-Risk AI