Who Has the Authority to Stop an AI System?

Consider a hypothetical customer service assistant that begins promising refunds outside company policy. A supervisor notices the pattern. The technical team controls the integration, the business owner is unavailable, and the vendor has opened a support ticket. Meanwhile, the assistant continues responding. The organization needs a decision that takes effect immediately, with an understood process for handling the customers already affected.

Assign the decisions before deployment

Wingward recommends documenting three decisions for each consequential AI workflow: who may pause it, who directs the response, and who may authorize its return. Name an accountable owner and a backup for each decision. In a small organization, one person may hold several responsibilities. The important test is whether staff can use the arrangement during an ordinary workday, including when the usual owner is absent.

There is a strong foundation for this approach. The National Institute of Standards and Technology’s voluntary AI Risk Management Framework calls for clear responsibilities, executive accountability for AI risk decisions, and assigned responsibility for overriding or deactivating systems whose performance or outcomes depart from intended use. Those expectations appear in GOVERN 2.1, GOVERN 2.3, and MANAGE 2.4 (Tabassi, 2023). The operating arrangements proposed here translate that guidance into decisions a leadership team can make.

Make a pause work in practice

Start by defining what a pause accomplishes. The appropriate response could suspend automatic customer replies, remove an agent’s ability to change records, hold transactions for review, or stop a particular integration. Choose the smallest intervention that reliably contains the problem, while allowing broader action when the scope is uncertain. A workflow can remain useful in a more restricted mode if that mode has been tested and can be supervised adequately.

Write triggers in terms that operators can recognize. For the customer service example, an unauthorized financial commitment might trigger immediate suspension of automated replies. A decline in answer quality might trigger closer review under a specified deadline. State which signals require action, how quickly action must occur, and who receives the escalation. Allow trained responders to act on credible evidence of serious harm while an investigation establishes the full facts.

Make permission and capability agree. Someone authorized to pause a workflow needs the relevant access, an available control, and enough knowledge to confirm that it worked. Someone with administrator access needs clear limits on its use. Check what happens to queued messages, scheduled jobs, and connected applications after the control is activated. A successful pause should have an observable result that the responder can verify.

The NIST AI RMF Playbook addresses these practical concerns through guidance on bypass and deactivation thresholds, backup arrangements, downstream consequences, preservation of evidence, and criteria for redeployment (National Institute of Standards and Technology, n.d., MANAGE 2.4). Stopping a component is one part of managing the effects of a failure. The response must also account for work already completed and people already affected.

For our hypothetical assistant, that means identifying the messages containing unauthorized promises, assigning someone to review the affected customer cases, and preparing an approved response. Staff also need a workable way to handle new requests. Estimate how much demand the fallback can absorb and who will manage delays. Where pausing a system could itself interrupt an essential service, evaluate that consequence in advance and rehearse the safest available transition.

Connect vendors and incident response

Give vendors a defined place in this arrangement. Establish which controls your organization can operate directly, which actions require the provider, and how an urgent request reaches someone empowered to act. Ask for evidence that the proposed restrictions work in your deployment. A vendor’s ability to disable its service does not establish how your organization will contain a problem in a connected business process.

Existing incident response practices provide useful structure. NIST’s 2025 cybersecurity incident response guidance specifically addresses authority to disconnect or shut down technology assets and recommends testing documented procedures. Its scope is cybersecurity; applying those operating disciplines to other AI failures is a management recommendation (Nelson et al., 2025, Section 2.3). Use established response channels where they fit, with additional expertise for the people and decisions an AI workflow affects.

Define the conditions for return

Set return-to-service conditions before the pressure to resume builds. Specify the evidence the accountable owner must review: what caused the problem, what changed, how the correction was evaluated, which affected cases need remediation, and what uncertainty remains. For consequential uses, Wingward recommends review by someone able to challenge the deployment team’s assessment. A limited restart with closer monitoring may be appropriate when its boundaries and stopping conditions are explicit.

Rehearse the decisions together. Give the supervisor, technical operator, business owner, and relevant risk specialists the same short scenario. Have them locate the control, identify the backup decision maker, explain the fallback, and determine what would permit a restart. Record uncertainties as changes to make before relying on the process. Repeat the exercise when responsibilities or integrations change materially. Leaders should also support reasonable pauses made in good faith within the agreed rules, so employees can exercise the authority they have been given.

Five questions for your next review

Use these five questions in your next AI deployment or operating review:

1. Who can pause this specific workflow immediately, and who acts when that person is unavailable?

2. What observable conditions trigger a pause, a restriction, or escalation, and how quickly must someone respond?

3. Which tested control stops the relevant activity, including queued work and connected systems?

4. How will we continue essential work, preserve evidence, and address people or transactions already affected?

5. Who can authorize a restart, and what evidence must they review before accepting the remaining risk?

References

National Institute of Standards and Technology. (n.d.). AI RMF Playbook: Manage. Retrieved September 16, 2026, from NIST AI Resource Center.

Nelson, A., Rekhi, S., Souppaya, M., & Scarfone, K. (2025). Incident response recommendations and considerations for cybersecurity risk management: A CSF 2.0 community profile (NIST Special Publication 800-61 Rev. 3). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-61r3

Tabassi, E. (2023). Artificial intelligence risk management framework (AI RMF 1.0) (NIST AI 100-1). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.AI.100-1