Many organisations are deploying AI into important workflows without knowing how quickly they could stop it during an incident. Research from digital-governance association ISACA finds that 59% of surveyed digital-trust professionals do not understand their organisation’s interruption time for a compromised or malfunctioning AI system.
Only 21% say they could intervene meaningfully within 30 minutes. Just 42% express confidence that their organisation could analyse and explain a serious AI incident afterward.
These gaps turn a model failure into a management crisis. If nobody can pause the system, preserve evidence or identify accountable leadership, small errors can continue long enough to cause financial, legal and reputational damage.
Every AI system needs a tested stop path
An emergency control must do more than disable a user interface. Teams need to know which agents, models, integrations and scheduled processes will stop, what happens to partially completed actions and how the service can be restored safely.
The stopping method should reflect the system’s authority. An assistant generating drafts may need a simple access suspension. An agent changing customer records or infrastructure requires immediate revocation of credentials and isolation from connected tools.
Organisations should rehearse these controls under realistic conditions. A written procedure is not enough if the responsible person lacks access or if dependent systems continue acting after the primary model is paused.
Logs must remain available when the system stops. Investigators need prompts, retrieved data, tool calls, outputs and model versions to reconstruct the event. Without evidence, remediation becomes guesswork and the same failure is likely to recur.
Accountability must be assigned before failure
ISACA finds that 20% of respondents do not know who would be responsible if AI caused damage. Only 38% identify the board or an executive as ultimately accountable.
Technical teams can operate controls, but business leadership owns the decision to deploy AI and the risks attached to it. Each system needs a named executive owner, an operational responder and clear escalation thresholds.
Kovant chief executive Ali Sarrafi suggests treating agents like digital employees: define ownership, permissions, supervision and an instant override. The analogy is useful because it turns an abstract model into an actor with a role and manager.
Human review alone is insufficient. Forty percent say people approve almost all AI actions and another 26% evaluate outcomes, yet reviewers cannot reliably catch rapid or hidden activity without supporting infrastructure. More than a third of organisations do not require employees to disclose AI use in work products, creating further blind spots.
Incident preparation enables safer scale
A practical response plan begins with an inventory of AI systems, owners, data access and connected actions. Teams can classify impact, define stop-time objectives and establish whom to notify internally and externally.
During an incident, the priority is containment: pause authority, isolate affected integrations and preserve evidence. Analysis then determines what occurred, which data or customers were affected and whether regulators must be informed. Recovery should use a known model, configuration and data state rather than simply restarting the same system.
Afterward, organisations need a documented review that changes controls, tests or permissions. Transparent reporting to leadership builds institutional knowledge and helps prevent a local mistake from remaining hidden until it repeats elsewhere.
Slowing all AI adoption is not the answer. Systems can deliver significant value, but governance must be part of the architecture rather than added after a crisis. Visibility, halt mechanisms and accountability make experimentation more confident because consequences can be contained.
ISACA’s figures reveal that many businesses are not yet in control of their deployed AI. The warning is operational, not theoretical: a system that cannot be stopped or explained is not ready for consequential autonomy.
Organisations should be able to answer three questions before launch: who owns this AI, how quickly can we halt it and what evidence will explain its behaviour? If any answer is uncertain, incident preparation should begin before capability expands.
