EU AI Act Human Oversight: Stop and Override Control Requirements for High-Risk AI

What Article 14 says about stopping and overriding

Article 14 requires high-risk AI systems to be designed and developed, including with appropriate human-machine interface tools, so that natural persons can effectively oversee them while they are in use. The purpose of oversight is to prevent or minimise risks to health, safety or fundamental rights that may emerge under intended purpose or reasonably foreseeable misuse, including risks that persist despite the other requirements in the same section. Measures must be commensurate with the risks, the level of autonomy and the context of use.

Among the listed oversight capabilities is the ability to intervene in the operation of the system or interrupt it through a 'stop' button or a similar procedure that allows the system to come to a halt in a safe state. Two points follow from the wording. First, the form is open: a button is one option, and 'a similar procedure' is another. The required outcome is a halt in a safe state. Second, the text speaks of intervening and interrupting, which are actions taken during operation. A review process that only examines outputs after the fact does not, on its face, match that language. That is an interpretation, but it is the safer reading for an audit.

The recitals add context. Appropriate oversight measures should be identified by the provider before the system is placed on the market or put into service. Where appropriate, systems should have in-built operational constraints that cannot be overridden by the system itself and that respond to the human operator. Systems should also include mechanisms that guide and inform the overseer on if, when and how to intervene, or to stop the system if it does not perform as intended. Recitals explain the text and carry 'where appropriate' qualifiers, so treat them as guidance on intent rather than as separate mandates.

Timing matters for planning. As of November 2026, the Commission states that rules for systems used in certain high-risk areas, including biometrics, critical infrastructure, education, employment, migration, asylum and border control, apply from 2 December 2027. The Digital Omnibus on AI, proposed in November 2025, reached provisional agreement between the Council and Parliament in May 2026.

Provider design duties and deployer operating duties

Stop and override capability is split across two roles. Confusing them is a common reason teams build the wrong control or assume someone else has built it. The provider decides what oversight features exist. The deployer decides who uses them, under what authority, and how their use is monitored. Before adding deployer-side controls, confirm what the provider has built and obtain its documentation of the stop or interrupt mechanism and its safe-state behavior.

• Identify oversight measures: Provider: identifies appropriate measures before market placement or putting into service. Deployer: uses the system in line with those measures.
• Build the stop or interrupt mechanism: Provider: designs the system and its human-machine interface so overseers can intervene or interrupt and reach a safe halt. Deployer: operates and tests the mechanism in its own environment.
• Assign overseers: Provider: supplies information that lets overseers decide if, when and how to intervene. Deployer: assigns oversight to people with competence, training, authority and support.
• Monitor in use: Provider: maintains a post-market monitoring system. Deployer: ensures oversight and monitoring during use.
• Logs: Provider: keeps the automatically generated Article 12(1) logs to the extent they are under its control. Deployer: should establish which logs it controls and keep evidence of its own interventions.

The evidence an auditor or regulator would expect

The recitals describe comprehensible information on how systems were developed and perform over their lifetime as essential for traceability, verifying compliance and monitoring. In practice, that means evidence of three kinds.

First, evidence of design and assignment: provider documentation of the stop mechanism and its safe-state behavior, a mapping of each oversight capability to a named control, owner and test, and records of overseer assignment, training and authority to halt the system. Second, evidence of testing: results of periodic production tests of the stop and override path, not only design-time review, including measured response times and the outcome of failure-mode tests. Third, evidence of operation: decision records showing the control acted on real interactions, and approval records showing who decided what and when.

The third category is where many programs are thin. A policy that says a human can intervene is not evidence that interventions worked. Records generated at the moment of enforcement are stronger than records reconstructed afterward. Also establish which logs you control as deployer and which sit with the provider, since the Act's provider log obligation applies to logs under the provider's control. Agree internally who retains each record and for how long, using your own retention policy and applicable legal advice.

Where execution-path enforcement helps, and where it does not

A runtime control placed in the execution path can act on individual interactions and tool calls: allow, redact, block, or escalate for human approval. For traffic that passes through it, this supports the intervene and interrupt expectation, because the decision is enforced at runtime, not reviewed after the fact. Because the decision is made outside the model, it also addresses the expectation of constraints the system cannot override itself.

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, at the level of individual interactions and tool calls. It produces audit-ready evidence from that enforcement, mapped to the EU AI Act among other frameworks, and can be deployed self-managed in the customer cloud with configurable retention and data residency. It has run in continuous production in a regulated enterprise for more than 18 months.

The limits are as important. Runtime enforcement covers only the traffic it sees. It does not replace the provider's design of the system's own stop mechanism, define a safe state for you, or establish overseer competence and training. Risk management and post-market monitoring remain organizational processes and need other tooling. Use enforcement evidence as one part of the file, alongside provider documentation, assignment records and test results.