Skip to content
AIAssuranceLabs
Menu

Art. 14: Human oversight under the EU AI Act

Art. 14 requires the provider to design and develop a high-risk AI system so that natural persons can oversee it effectively during use, with appropriate human-machine interface tools, and to identify the oversight measures before the system is placed on the market. In this mapping, seven elements are testable, eight are documentation and four are process. Regulation (EU) 2026/1744 moved the Annex III application date Deferred and the Annex I date and left the text of Art. 14 unchanged.

Where this applies

What the text requires

Art. 14(3)(b) hands part of the oversight design to the deployer, whose duty to implement the measures and to assign natural persons sits in Art. 26(1). The measures built into the system are described in the technical documentation under Art. 11 and Annex IV section 2(e), and the measures for the deployer appear in the instructions for use under Art. 13(3). An override or a stop leaves a record only where the logging capability under Art. 12 captures the oversight action.

What the text requires and how each element is verified
RequiresTestableDocumentationProcess
  1. Art. 14(1)The provider designs and develops the high-risk AI system so that natural persons can oversee it effectively during the period in which it is in use. The design includes appropriate human-machine interface tools.
  2. Art. 14(2)Human oversight aims to prevent or minimise the risks to health, safety or fundamental rights that may emerge when the system is used in accordance with its intended purpose or under conditions of reasonably foreseeable misuse. The intended purpose includes the specific context and conditions of use as specified in the instructions for use, in promotional or sales materials and statements, and in the technical documentation. Reasonably foreseeable misuse includes reasonably foreseeable human behaviour and interaction with other systems, including other AI systems. The aim applies in particular where such risks persist despite the application of the other requirements in Chapter III Section 2.
  3. Art. 14(3)The oversight measures are commensurate with the risks, the level of autonomy and the context of use of the high-risk AI system. The provider provides the measures through one or both of the two types in points (a) and (b).
  4. Art. 14(3)(a)The provider identifies measures and, when technically feasible, builds them into the high-risk AI system before it is placed on the market or put into service.
  5. Art. 14(3)(b)The provider identifies measures before placing the high-risk AI system on the market or putting it into service that are appropriate for the deployer to implement.
  6. Art. 14(4)For the purpose of implementing paragraphs 1, 2 and 3, the provider provides the high-risk AI system to the deployer in such a way that the natural persons to whom human oversight is assigned are enabled, as appropriate and proportionate, to do the five things in points (a) to (e).
  7. Art. 14(4)(a)The assigned persons can properly understand the relevant capacities and limitations of the high-risk AI system. The assigned persons can duly monitor its operation, including in view of detecting and addressing anomalies, dysfunctions and unexpected performance.
  8. Art. 14(4)(b)The assigned persons remain aware of the possible tendency to rely automatically or to over-rely on the output of the high-risk AI system, which the Act calls automation bias. This applies in particular to high-risk AI systems that provide information or recommendations for decisions to be taken by natural persons.
  9. Art. 14(4)(c)The assigned persons can correctly interpret the output of the high-risk AI system. The interpretation takes into account, for example, the interpretation tools and methods available.
  10. Art. 14(4)(d)The assigned persons can decide, in any particular situation, not to use the high-risk AI system. The assigned persons can otherwise disregard, override or reverse the output of the high-risk AI system.
  11. Art. 14(4)(e)The assigned persons can intervene in the operation of the high-risk AI system. The assigned persons can interrupt the system through a stop button or a similar procedure that allows the system to come to a halt in a safe state.
  12. Art. 14(5)For high-risk AI systems referred to in Annex III point 1(a), the measures under paragraph 3 are such that, in addition, the deployer takes no action or decision on the basis of the identification resulting from the system unless at least two natural persons have separately verified and confirmed that identification. The two natural persons have the necessary competence, training and authority. The requirement for a separate verification by at least two natural persons does not apply to high-risk AI systems used for the purposes of law enforcement, migration, border control or asylum where Union or national law considers the application of this requirement to be disproportionate.
  • Human-machine interface tools are present, and a natural person assigned to oversight can operate them while the system is in use (Art. 14(1)).
  • The assigned person can monitor operation from the interface: an anomaly, dysfunction or unexpected performance injected during the test is visible to the assigned person and can be addressed (Art. 14(4)(a)).
  • A measure against automation bias is present in the interface or the workflow and has an observable effect, for example the output is not pre-filled as the decision and the assigned person records an active choice (Art. 14(4)(b)).
  • Interpretation tools or methods are available to the assigned person and return a result for a sampled output (Art. 14(4)(c)).
  • The assigned person can decide not to use the system for a particular case, and can disregard, override or reverse the output; the recorded decision then carries the person's choice and not the system output (Art. 14(4)(d)).
  • A stop button or a similar procedure exists; when it is used the system comes to a halt, and the state after the stop matches the safe state the provider declares (Art. 14(4)(e)).
  • For an Annex III point 1(a) biometric identification system, the workflow blocks any action or decision until two natural persons have separately verified and confirmed the identification; one confirmation, or two confirmations from the same person, does not release the action (Art. 14(5)).
  • The measures built into the system are identified before it is placed on the market or put into service, and are described in the technical documentation (Art. 14(3)(a); Annex IV section 2(e)).
  • The measures appropriate for the deployer to implement are identified before placing on the market or putting into service, and are stated in the instructions for use (Art. 14(3)(b); Art. 13(3)(d)).
  • A written rationale links each oversight measure to the risks, the level of autonomy and the context of use of the system (Art. 14(3)).
  • The risks to health, safety or fundamental rights under the intended purpose and under reasonably foreseeable misuse that persist despite the other Section 2 requirements are listed, with the oversight measure that addresses each (Art. 14(2), read with the Art. 9 risk management file).
  • The relevant capacities and limitations of the system are stated so that the assigned person can understand them (Art. 14(4)(a); Art. 13(3)(b)).
  • The automation bias risk and the measures against it are described for the deployer, in particular where the system provides information or recommendations for decisions taken by natural persons (Art. 14(4)(b)).
  • The interpretation tools and methods available to the assigned person are described (Art. 14(4)(c)).
  • Where a law enforcement, migration, border control or asylum system does not apply the two-person verification, the Union or national law that treats the requirement as disproportionate is identified (Art. 14(5) second subparagraph).
  • The oversight measures stay effective during the whole period in which the system is in use; a change to the system or to its interface is followed by a repeat of the oversight verification (Art. 14(1)).
  • The deployer implements the measures the provider identified for the deployer and assigns oversight to natural persons (Art. 14(3)(b), read with Art. 26(1) and (2)).
  • Persons assigned to oversight are kept aware of automation bias during use; the awareness measure is repeated over time rather than given once (Art. 14(4)(b)).
  • For an Annex III point 1(a) biometric identification system, the two natural persons who verify an identification have the necessary competence, training and authority, and the assignment is maintained for each person who takes the role (Art. 14(5)).

Metrics and where thresholds come from

Threshold sources, in order of precedence

  1. A harmonised standard cited in the Official Journal (none as of the anchor date)
  2. A JTC 21 draft standard (prEN), with its stage
  3. An ISO/IEC standard or technical report, with its stage
  4. A Commission guideline or code of practice, with its date from the standards data
  5. NIST AI RMF or a sector framework
  6. The state of the art, which the provider justifies and documents

Regulation (EU) 2024/1689 sets no numeric performance threshold for Art. 14. The only number in the article is a count: Art. 14(5) requires at least two natural persons to separately verify and confirm a biometric identification before the deployer acts on it, and this count is not a performance metric. No harmonised standard is cited in the Official Journal, so level 1 of the source hierarchy is empty. The level used today is level 2, a JTC 21 draft: prEN 18229-3 is at drafting stage with no public text, and prEN 18229-1 is under enquiry and supplies the record of oversight actions. Because no published document states what counts as an effective override, stop or monitoring measure, level 6 applies: the provider justifies each oversight measure against the risks, the level of autonomy and the context of use, and documents that justification; the rationale-recording step of PR-14-OVR captures it.

Metric sources and their stage
Source and stageTitleWhat it provides hereVerified on
prEN 18229-3DraftAI trustworthiness framework, part 3: transparency and human oversightdraft requirements for the Art. 14 human-oversight measures, the information the interface gives the assigned person and the measures a deployer implements; at drafting stage with no public text, so it fixes the categories a verification covers, not a threshold

Verified on kla.digital, JTC 21 standards tracker (29 June 2026)

prEN 18229-1EnquiryAI trustworthiness framework, part 1: loggingthe log event set that records an override, a reversal, a stop or an intervention, giving a test of Art. 14(4)(d) and (e) an observable record of each oversight action

Verified on kla.digital, JTC 21 Standards Tracker (updated 29 June 2026)

Procedures

Each protocol is versioned; its page states the derivation from the standards above. PR-14-OVR v1.0 covers the seven testable elements, from the interface check to the two-person verification workflow for biometric identification.

What an assessor asks for

  • Human oversight measures description (Annex IV section 2(e))
  • Deployer-implementable oversight measures in instructions for use (Art. 13(3)(d))
  • Oversight measure rationale record linking each measure to risk, level of autonomy and context of use (Art. 14(3))
  • Override, reversal and stop verification report (PR-14-OVR output)
  • Safe-state definition and post-stop state record (Art. 14(4)(e))
  • Automation bias measure description and verification record (PR-14-OVR output)
  • Oversight action log extract showing override and stop events (Art. 14(4)(d) and (e), read with Art. 12)
  • Two-person verification workflow record for biometric identification systems (Art. 14(5))

Common findings

  • The stop function halts the model call but leaves downstream automation running, so the system does not come to a halt in a safe state.
  • An override changes the displayed result, but the recorded decision still carries the system output.
  • Capacities and limitations are stated in general terms, without the operating conditions under which the assigned person should distrust the output.
  • The interface presents the output as a pre-filled decision, and no measure counters automation bias.
  • Oversight measures are listed for the provider side only; the measures the deployer is expected to implement are not identified.
  • For a biometric identification system, the second confirmation can be given by the same account that gave the first.

Questions

What are the Article 14 human oversight requirements?

Art. 14(1) requires the provider to design the high-risk AI system so that natural persons can oversee it effectively during use, with appropriate human-machine interface tools. Art. 14(3) requires the provider to identify the oversight measures before placing the system on the market, either built into the system or for the deployer to implement. Art. 14(4) lists five capabilities for the assigned persons: understand and monitor, stay aware of automation bias, interpret the output, decide not to use or override the output, and intervene or stop the system in a safe state. Art. 14(5) adds a separate verification by at least two natural persons for remote biometric identification systems in Annex III point 1(a).

What does Article 14 on human oversight say, in plain explanation?

Art. 14 has five paragraphs. Art. 14(1) states the design goal: effective oversight by natural persons during use. Art. 14(2) states the aim: prevent or minimise the risks to health, safety or fundamental rights that remain under intended use or reasonably foreseeable misuse. Art. 14(3) states the form: measures commensurate with the risks, the level of autonomy and the context of use, built in by the provider or handed to the deployer. Art. 14(4) states what the assigned person can do: understand, monitor, resist automation bias, interpret, override and stop. Art. 14(5) states the two-person rule for remote biometric identification.

Why is human oversight required for high-risk AI systems?

Art. 14(2) gives the reason: oversight aims to prevent or minimise the risks to health, safety or fundamental rights that persist despite the other requirements in Chapter III Section 2. Accuracy, robustness and data governance reduce risk but do not remove it. A natural person who can monitor, override and stop the system is the measure for the risk that remains. Art. 14(4)(b) names one specific risk: automation bias, the tendency to rely automatically on the output.

Who does EU AI Act Article 14 human oversight apply to, the provider or the deployer?

Art. 14 is a design requirement placed on the provider. The provider builds the oversight measures into the system under Art. 14(3)(a) and identifies the measures the deployer implements under Art. 14(3)(b). The deployer's duty to implement those measures and to assign oversight to natural persons with the necessary competence, training, authority and support sits in Art. 26(1) and 26(2). A verification of oversight therefore has two parts: what the provider built, and what the deployer operates.

Does AI Act Article 14 set a numeric threshold or a required number of overseers?

Art. 14 sets no numeric performance threshold. The one count in the article is in Art. 14(5): at least two natural persons separately verify and confirm a remote biometric identification before the deployer acts on it. No harmonised standard is cited in the Official Journal for Art. 14. The relevant JTC 21 draft, prEN 18229-3, is at drafting stage with no public text. The provider therefore justifies each oversight measure against the risks, the level of autonomy and the context of use, as Art. 14(3) requires, and documents the justification.

How we test this

We test the oversight measures against Art. 14(4): the assigned person monitors an injected anomaly, overrides the output and stops the system into the declared safe state, and we verify that the recorded decision carries the person's choice. We prepare the evidence an assessor asks for, including the oversight measure rationale under Art. 14(3); the scope limits are stated on what we cannot do.

What we cannot do

  • We do not perform conformity assessments where a notified body is required.
  • We do not issue CE marking or the EU Declaration of Conformity.
  • We are not a notified body.
  • We do not give legal opinions on classification or liability.
  • We test against requirements, prepare evidence, and structure documentation; compliance decisions remain with the provider or deployer, their notified body, and their counsel.

Read the full statement