Risk · R-135 · Operational Resilience
Inability to stop or roll back AI
A misbehaving system cannot be disabled, reverted to a known good version, or have its actions reversed quickly enough to limit harm.
- Severity
- High
- Audience
- Heads-of · Practitioner
- Frameworks
- Article 14 · Article 20 · MANAGE 4
- Responsible AI domain
- Lifecycle stage
- Reviewed
- 2026-11-11
What it is
Stopping an AI system should be simple and often is not. There may be no switch, or nobody with authority to use it out of hours. The previous version may not have been kept, or may no longer be compatible. A hosted model cannot be rolled back by the customer at all. An agent may already have taken actions, such as payments sent or records changed, that stopping it does not undo. The EU AI Act requires high-risk systems to be designed so that a person can intervene or interrupt them. The risk is that when the moment comes, the means do not exist.
How it happens
- No stop mechanism was designed, or it was never tested.
- Authority to stop the system is unclear, and people hesitate.
- Earlier model and prompt versions were not retained.
- The system's actions in other systems are not reversible.
Why it matters
The scale of harm from a faulty system is set largely by how long it runs after the fault is noticed. Minutes matter for an agent that is acting, and days for a model that is deciding.
Warning signs
- Nobody can say how the system would be switched off, or who decides.
- Rollback has never been rehearsed.
- Previous versions are not archived in a deployable form.
- No record links the system's actions to a means of reversing them.
Who owns it
The system owner is accountable for being able to stop it. Engineering builds and tests the mechanism. The incident manager has authority to invoke it.
In practice
A pricing agent begins applying a discount to every order after a configuration change. The on-call engineer can see it happening. Disabling the agent needs a change approval that takes two hours out of hours, and the earlier configuration was overwritten. The same pattern generalises to any system that was easy to switch on and never designed to be switched off.
Mitigating controls
Primary controls
- AI incident response and rollback Corrective
- Maintains the ability to revert to a known good version. When an AI system fails or produces harmful output, a defined procedure contains it, restores a known good state, preserves the evidence and manages the consequences.
- Human override and stop mechanism Corrective
- Provides a tested way to pause or shut the system down. A designated person can pause, override or shut down an AI system at any time through a tested mechanism, with the authority to do so settled in advance.
Supporting controls
- AI change management Preventive
- Versioning preserves the state to return to. Changes to models, prompts, data sources, tools and configuration are assessed, tested, approved and versioned before they reach production.
- Staged rollout Preventive
- Limits exposure so a rollback affects fewer people. New AI systems and material changes are released first to a limited population under close monitoring, and extended only when defined criteria are met.
Framework and clause references
| Framework | Clause | Title |
|---|---|---|
| EU AI Act | Article 14 | Human oversight Names the ability to interrupt the system. |
| EU AI Act | Article 20 | Corrective actions and duty of information Corrective action and withdrawal. |
| NIST AI Risk Management Framework (AI RMF 1.0) | MANAGE 4 | Risk response, recovery and communication plans are documented and monitored Mechanisms to supersede or deactivate. |
Sources
- EU AI Act: Regulation (EU) 2024/1689 European Union (EUR-Lex) · official text
- NIST AI Risk Management Framework (AI RMF 1.0) NIST · framework
Related terms
How to cite
Axiom Verity (2026). Inability to stop or roll back AI. Reference Library, R-135. https://axiom-verity.com/risks/inability-to-stop-or-roll-back-ai. Reviewed 2026-11-11.
Found an error or a better source? Report a correction.