Article 14(4)(e) of the EU AI Act requires that operators be able to interrupt a high-risk AI system through a stop button or similar procedure. This page covers the practical implementation of break-glass procedures, from authorisation and technical mechanisms to notification chains and annual testing.
Every high-risk AI system must have a documented break-glass procedure that allows authorised personnel to halt the system immediately when they believe it is causing or about to cause harm.
Every high-risk AI system must have a documented break-glass procedure that allows authorised personnel to halt the system immediately when they believe it is causing or about to cause harm. This requirement is the operational expression of Article 14's "stop button" mandate: Article 14(4)(e) requires that operators be able to "interrupt the operation of the high-risk AI system through a 'stop' button or a similar procedure." The regulation demands a real, tested, functional mechanism, not a theoretical capability documented only in policy.
The break-glass procedure bridges the gap between Operational Oversight governance structures and the practical reality of stopping a system in production. Without a tested halt mechanism, all other oversight controls lose their effectiveness because they cannot prevent ongoing harm once it is detected.
The procedure must define which personnel are authorised to stop the system, and the authorisation should be deliberately broad.
The procedure must define which personnel are authorised to stop the system, and the authorisation should be deliberately broad. For high risk ai system deployments, any person at Level 2 or above in the oversight pyramid should be able to trigger a break-glass action. The rationale is practical: requiring senior management approval before halting a potentially harmful system introduces delay that may increase harm.
Broad authorisation reflects a design principle that prioritises safety over hierarchy. When an operator or manager identifies potential harm, the organisational response must enable immediate action rather than routing through approval chains that consume critical time.
A compliant break-glass procedure must specify four distinct elements.
A compliant break-glass procedure must specify four distinct elements. First, a technical mechanism: a clearly marked emergency stop function in the operator interface, a dedicated API endpoint, or a documented process for contacting the engineering team outside business hours. Second, immediate actions: halting system processing, holding pending decisions, and notifying affected deployers. Third, a notification chain that specifies who is informed immediately and who within defined timeframes. Fourth, resumption criteria that specify what conditions must be met before the system is restarted.
These four elements ensure that activating break-glass is not simply pressing a button but triggers a coordinated response. The technical mechanism provides the means, the immediate actions define the scope, the notification chain ensures accountability, and the resumption criteria prevent premature restart.
The implementation architecture should provide two independent halt mechanisms to ensure reliability.
The implementation architecture should provide two independent halt mechanisms to ensure reliability. The first is an in-application stop button: a prominent, clearly labelled control in the operator's review interface that, when activated, immediately halts all inference processing. Activation triggers an API call to the inference service that suspends request processing, drains any in-flight requests (completing them rather than dropping them, to avoid data loss), and returns a "service suspended" response to subsequent requests.
The second mechanism is an infrastructure-level kill switch: a dedicated API endpoint hosted separately from the main application that scales the inference service to zero replicas on container orchestration platforms or disables the inference endpoint on managed ML services. This second mechanism exists as a failsafe in case the application itself is compromised or unresponsive. Maintaining two independent paths to halt the system ensures that no single point of failure can prevent an emergency stop.
Feature flag services such as LaunchDarkly, Unleash, or Flagsmith provide a clean implementation pattern for break-glass controls.
Feature flag services such as LaunchDarkly, Unleash, or Flagsmith provide a clean implementation pattern for break-glass controls. A feature flag named "system-active" defaults to true, and the inference service checks this flag before processing each request. When break-glass is activated, the flag is set to false and all subsequent inference requests return a suspension notice.
Feature flags propagate globally within seconds, making them suitable for emergency use. The flag change is logged with the identity of the person who changed it and the timestamp, providing Audit Trail evidence of who triggered the halt and when. This approach separates the break-glass control from the application's own code paths, reducing the risk that a software defect could prevent the halt from taking effect.
The notification chain ensures that the right people are informed when a break-glass is activated.
The notification chain ensures that the right people are informed when a break-glass is activated. The activation event should trigger alerts to four groups: the on-call engineering team to investigate and resolve the root cause, the AI Governance Lead to assess compliance implications, the DPO Liaison if personal data processing is affected, and senior management if the incident has business continuity implications.
Incident management platforms such as PagerDuty or Opsgenie automate this routing based on severity and time-of-day rules. Automated routing removes the burden of manual notification from the person who triggered the break-glass, allowing them to focus on the immediate situation. The notification chain should be documented and tested alongside the technical halt mechanism.
The organisation's AI governance policy must explicitly protect any individual who triggers a break-glass action in good faith from negative consequences.
The organisation's AI governance policy must explicitly protect any individual who triggers a break-glass action in good faith from negative consequences. A culture in which operators or managers hesitate to stop a system because they fear career repercussions is a culture in which harmful AI systems continue to operate.
The non-retaliation commitment should specifically cover good-faith activations that turn out to have been unnecessary. False positives are the expected cost of an effective safety mechanism; penalising them discourages future legitimate activations. If personnel learn that triggering break-glass when harm was not ultimately confirmed leads to disciplinary action, they will delay activation in ambiguous situations, which is precisely when the mechanism is most needed.
The Technical Owner must test the break-glass procedure at least annually through a simulated exercise conducted under controlled conditions.
The Technical Owner must test the break-glass procedure at least annually through a simulated exercise conducted under controlled conditions. During a maintenance window, the break-glass is activated and the team verifies that inference processing halts within the declared timeframe. The notification chain is verified to confirm all recipients receive the alert. The system is then brought back online through the documented resumption process.
Separately, the AI Governance Lead defines the Incident Response resumption process: who authorises resumption, what checks are performed before resuming, and how the suspension period is documented. The exercise should confirm that the technical stop mechanism works correctly, that affected deployers receive timely communication, and that the system can be restarted once resumption criteria are satisfied. The Technical Owner documents exercise results and any deficiencies remediated, retaining the results as compliance evidence.
In-flight requests should be drained (completed, not dropped) to avoid data loss, while all subsequent requests receive a service suspended response.
The infrastructure-level kill switch serves as a failsafe in case the main application is compromised or unresponsive, ensuring no single point of failure can prevent an emergency stop.
No. The organisation must explicitly protect good-faith activations, including those that prove unnecessary. Penalising false positives discourages future legitimate activations when the mechanism is most needed.
Article 14(4)(e) requires operators to be able to interrupt a high-risk AI system through a stop button or similar procedure, making a tested halt mechanism mandatory.
Any person at Level 2 or above in the oversight pyramid should be authorised, because requiring senior approval before stopping a harmful system introduces dangerous delay.
A technical halt mechanism, immediate actions upon activation, a notification chain, and resumption criteria that must be met before the system restarts.
Two independent mechanisms: an in-application stop button that drains in-flight requests gracefully, and an infrastructure-level kill switch hosted separately from the main application.
A feature flag checked before each inference request can be set to false on activation, propagating globally within seconds and providing audit evidence of who triggered the halt.
The Technical Owner conducts at least annual simulated exercises that verify the halt mechanism, notification chain, and resumption process under controlled conditions.
