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

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. It carries manufacturer-style duties: design controls, documentation, conformity.Open full entry → obligation under the EU AI ActEU AI ActRegulation (EU) 2024/1689, the European Union's law on artificial intelligence. It takes a risk-based approach: prohibited practices, requirements for high-risk AI systems, transparency obligations for specific uses, and a separate regime for general-purpose AI models. Obligations are divided between providers and deployers. See general-purpose AI, conformity assessment.Open full entry →. The provider must design the oversight features in; deployersdeployerAn organization using an AI system under its own authority in its activities. It carries the operator duties: use per instructions, oversight, input relevance, monitoring, notices.Open full entry → 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. It is meaningful only when the human has authority, information and time to act. One of the seven pillars of responsible AI, and under the EU AI Act a requirement for high-risk AI systems: Article 14 requires that those systems are designed so natural persons can effectively oversee them. Oversight that exists on paper but amounts to confirming in practice does not meet that bar. See override rate, automation bias, high-risk AI system, fairness, safety and reliability, privacy, security and robustness, transparency and explainability, accountability, responsible AI. In the IAPP AIGP body of knowledge, this principle appears as human-centricity, with human oversight as one of its elements.Open full entry → has two articles, and the difference between them is the difference between building and using. Art. 26.2 is the deployer obligation: ensure that the people assigned to oversee the system are competent, trained, and authorized. 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 systemshigh-risk AI systemAn AI system that falls under the EU AI Act's strictest requirements, following Article 6. There are two routes in: a system that is a product or safety component covered by the Union harmonization legislation in Annex I and subject to third-party conformity assessment, or a system used in one of the areas listed in Annex III, such as employment, education, or access to essential services. Article 6(3) contains a filter: an Annex III system is not high-risk if it does not pose a significant risk of harm to health, safety, or fundamental rights, although a system that profiles natural persons is always high-risk. See EU AI Act, Annex III, conformity assessment.Open full entry → are designed so that natural personsnatural personA living human individual, as distinct from a legal person such as a company; the holder of data-protection and AI-Act rights.Open full entry → overseeing them can do the following, to the extent appropriate to the riskriskIn the EU AI Act's terms, the combination of the likelihood that a harm occurs and the severity of it if it does. The link between a principle (via the harm that would breach it) and a control (the measure that reduces it). Naming the harm and assessing its risk is required by Art. 9 before any mitigation measure is chosen. See harm, control, residual risk.Open full entry →:

• 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 controlcontrolThe concrete, testable measure that reduces a specific risk, and through that risk protects the principle behind it. Also called a risk management measure, risk response, or risk treatment. Always traceable to the risk it addresses: under EU AI Act Art. 9 every control must map back to a specific risk, and controls recorded separately from their risks is a recognized compliance failure. It works in one of three types: preventive, detective, or corrective. See risk, control types, evidence.Open full entry →: 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 governancegovernanceThe system through which an organization steers itself: corporate governance, risk management, compliance, lines of accountability, risk appetite, and the operating model. It exists across everything the organization does, before and beyond AI. AI governance is this same system extended for AI. See AI governance, governance design, execution level.Open full entry → document can assert that the organization maintains human control over its AI. Art. 14(4)(e) requires that control to be real and immediate: a stop button or comparable procedure that brings the system to a halt in a safe state, available to the overseer. It does not itself mandate a single-action control or require the intervention to be logged; logging overrides is sound control design you anchor to your oversight log. An organization 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 biasbiasA systematic skew in data, model behavior, or outcomes that treats one group differently from another without justification. Bias usually enters through training data that reflects historical patterns. For high-risk AI systems, Article 10 of the EU AI Act requires examination of datasets for possible biases and measures to detect, prevent, and mitigate them. See fairness, proxy discrimination.Open full entry →?
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?