GovCompass
Knowledge base
ReferenceHuman oversightSafety & reliability

Art. 14 EU AI Act: designing high-risk AI for human oversight

By Michel Venniker· · Aligned with the consolidated EU AI Act, including the 2026 Omnibus amendments.

Art. 14 requires providers to design and build high-risk AI systems so that they can be effectively overseen by humans during use. The system must let an overseer understand its capabilities and limits, watch for anomalies, resist automation bias, correctly interpret outputs, decide not to use the system, and intervene or stop it through a kill switch (Art. 14(4)(e)). It is the design obligation that makes the deployer oversight duty of Art. 26.2 possible.

Updated: June 2026

This is an explicit providerproviderThe actor who develops an AI system (or has it developed) and places it on the market or into service under its own name — carrying manufacturer-style duties: design controls, documentation, conformity.Open full entry → obligation under the EU AI Act. The provider must design the oversight features in; deployers operate them under Art. 26.2.

Introduction: oversight begins in the design

Human oversighthuman oversightDesigned-in human ability to monitor, intervene in, override or shut down an AI system — meaningful only when the human has authority, information and time to act.Open full entry → has two articles, and the difference between them is the difference between building and using. Art. 26.2 is the deployerdeployerAn organization using an AI system under its own authority in its activities — carrying operator duties: use per instructions, oversight, input relevance, monitoring, notices.Open full entry → obligation: ensure that the people assigned to oversee the system are competent, trained, and authorised. Art. 14 comes earlier in the chain: it requires the provider to design and build the system so that effective human oversight is possible in the first place. A deployer cannot oversee a system that gives them no way to understand, question, or stop it, no matter how competent the overseer. Art. 14 is what makes Art. 26.2 achievable.

The article frames oversight as a property the system must be engineered to support. The provider must build in the technical means for oversight, or identify the measures the deployer must implement, before the system is placed on the market. Oversight is therefore a design requirement, evaluated at conformity assessmentconformity assessmentThe pre-market process demonstrating a high-risk AI system meets the EU AI Act's requirements, leading to CE marking and registration.Open full entry →, not an operational afterthought.

What the system must enable

Art. 14 requires that high-risk AI systems are designed so that natural persons overseeing them can do the following, to the extent appropriate to the risk:

  • Understand the capacities and limitations of the system and monitor its operation, including detecting and addressing anomalies and unexpected performance.
  • Remain aware of automation biasautomation biasThe human tendency to over-trust automated outputs — accepting a system's recommendation without genuinely weighing the case, which hollows out human oversight.Open full entry →, the tendency to over-rely on the output of an automated system, and guard against it.
  • Correctly interpret the output, taking into account the tools and methods available for interpretation.
  • Decide not to use the system in a particular situation, or to disregard, override, or reverse its output.
  • Intervene in or interrupt the operation of the system through a stop mechanism that brings it to a safe state.

That last point is Art. 14(4)(e), the kill switchkill switchThe designed-in, rehearsed ability to suspend or deactivate an AI system quickly when containment requires it.Open full entry →. The system must allow a human to halt it, in one action, to a safe state, and the act of intervening must itself be part of the record. This is the concrete, engineered expression of human control: not a policy that says a human is in charge, but a button that proves it.

The kill switch as an instrumented control

The stop mechanism is worth dwelling on because it is where the difference between policy and instrumentation is sharpest. A governance document can assert that the organisation maintains human control over its AI. Art. 14(4)(e) requires that control to be real and immediate: a means to bring the system to a safe state in a single action, available to the overseer, with the intervention logged. An organisation that can demonstrate the stop mechanism, and produce the log of when it was used, has human oversight as an instrumented control. One that points to a paragraph in a policy has an aspiration.

The relationship to Art. 26.2 and Art. 13

Art. 14 connects to two articles on either side of it. Toward the deployer, it links to Art. 26.2: the oversight measures the provider builds in are the measures the deployer operates, and the instructions for use must explain how. Toward information, it links to Art. 13: the provider must give the deployer the information needed to exercise oversight, including the system's limits, the conditions under which it may behave unreliably, and how to interpret its outputs. Oversight that is designed in under Art. 14 but not explained under Art. 13 leaves the deployer unable to use it.

Why it matters

For the provider, Art. 14 is assessed at conformity: a high-risk system that cannot be meaningfully overseen, or that lacks a stop mechanism, does not conform and cannot carry the CE markingCE markingThe mark affixed to products (including high-risk AI systems) indicating conformity with applicable EU requirements.Open full entry →. For the deployer, Art. 14 determines whether the system they buy can be governed in practice. A deployer evaluating a high-risk system should treat the absence of real oversight features, especially a working stop mechanism, as a conformity defect to raise with the provider, not a limitation to work around.

Governing oversight by design

For providers, the controls ensure oversight is engineered and evidenced: the system surfaces its confidence and limits, flags anomalies, makes the override and the stop mechanism available and usable, and logs interventions. These features are tested before market placement and documented in the technical file.

For deployers, the controls are about verification at procurement: confirm that the system provides the Art. 14 oversight features, that the stop mechanism works and reaches a safe state, and that the instructions explain how to interpret outputs and when the system is unreliable. A high-risk system that cannot be stopped by its overseer is not one a deployer can lawfully operate.

Compliance checklist

  1. Does the high-risk system let an overseer understand its capabilities and limitations and monitor its operation?
  2. Does it help the overseer detect anomalies and resist automation bias?
  3. Can the overseer correctly interpret the output, with the tools the provider supplies?
  4. Can the overseer decide not to use the system, or override or reverse its output?
  5. Is there a stop mechanism (Art. 14(4)(e)) that brings the system to a safe state in one action, with the intervention logged?
  6. Do the instructions for use (Art. 13) explain how to exercise these oversight features?
Legal referencesArt. 14Art. 26Art. 13

More on Human oversight

Art. 26.2 EU AI Act: human oversight of high-risk AI

Reference

Art. 26.2 requires deployers to ensure that the people assigned to oversee a high-risk AI system have the competence, training, and authority to do so effectively. Valid oversight is substantive, not formal: the overseer must understand the system, be trained on its limitations, and hold genuine authority to override its outputs.

Art. 27 EU AI Act: Fundamental Rights Impact Assessment (FRIA)

Reference

Art. 27 requires certain deployers, public bodies and private deployers in defined sectors such as credit and insurance, to conduct a Fundamental Rights Impact Assessment (FRIA) before deploying a high-risk AI system, examining the impact on fundamental rights and the mitigation measures.

Art. 4 EU AI Act: AI literacy obligations for organisations

Reference

Art. 4 has required organisations since 2 February 2025 to ensure a sufficient level of AI literacy among staff who operate or use AI systems, proportionate to the system and the role. It applies to all AI use, not only high-risk systems, and must be demonstrable.

AI in recruitment: risks, bias and what the EU AI Act already requires

Analysis

AI recruitment systems fall under Annex III of the EU AI Act as high-risk, which triggers the full deployer obligations of Article 26, human oversight, data quality, monitoring, log retention, and a Fundamental Rights Impact Assessment under Article 27. These duties cannot be transferred to the software vendor.

More on Safety & reliability

Art. 26.4 EU AI Act: input data quality for deployers

Reference

Art. 26.4 requires deployers of high-risk AI to ensure that input data is relevant and sufficiently representative for the system's intended purpose. The deployer is responsible for data quality in operation, even though the provider sets the specifications under Art. 10.

Art. 26.5 EU AI Act: post-market monitoring for deployers

Reference

Art. 26.5 requires deployers of high-risk AI to monitor the system's operation against the provider's instructions and to report risks and serious incidents. Monitoring is the early-warning mechanism that connects to incident reporting under Art. 73.

Art. 5 EU AI Act: all 8 prohibited AI practices explained

Reference

Art. 5 lists the eight prohibited AI practices, including subliminal manipulation, exploitation of vulnerable groups, social scoring, and untargeted facial-recognition scraping. These prohibitions are absolute, apply to every organisation regardless of size, and have been in force since 2 February 2025.

Art. 6 EU AI Act: how to classify a high-risk AI system

Reference

Art. 6 sets out how to classify a high-risk AI system: a system is high-risk if it is a safety component of a product under Annex I, or falls within one of the Annex III use cases. Misclassification is itself a violation, and the responsibility rests with the organisation, not the supplier.