Safeguard
AI Security•

When to pause, roll back or retire an AI system

Criteria for stopping an AI system: unacceptable risk, drift, vendor change or lost purpose. What the NIST AI RMF says about disengaging and retiring.

Safeguard Security Team
3 min read

Pause an AI system when harm is occurring or imminent, when it behaves outside its intended use, or when residual risk exceeds your tolerance. Retire it when its purpose is gone, a safer option exists, or you can no longer support it. Decide the triggers before launch.

What NIST says

The framework states that where a system presents unacceptable negative risk, such as imminent significant impacts, severe harm occurring, or catastrophic risk, development and deployment should cease safely until risks are sufficiently managed. MANAGE 1.1 asks for a determination of whether the system achieves its intended purposes and whether deployment should proceed. MANAGE 2.4 covers mechanisms to supersede, disengage or deactivate. GOVERN 1.7 asks for processes to decommission and phase out systems safely without increasing risk or reducing trustworthiness.

Pause triggers worth writing down

  • A confirmed incident causing harm to users or exposure of sensitive data.
  • Measured quality drops below a threshold you set at launch.
  • The model or data source changes materially without re-testing.
  • A vendor discloses a breach or a serious defect.
  • A legal or regulatory change affects the use case.
  • Evidence the system is being used for something it was not approved for.

Roll back versus switch off

Rollback fits when the previous version was safe: pin the prior model or prompt set and redeploy. Switch off fits when no safe version exists. Pre-plan both and name who can pull each lever.

Retirement triggers

  • Business purpose no longer exists.
  • A cheaper, simpler or non-AI method does the job. NIST's MANAGE 2.1 explicitly asks you to weigh viable non-AI alternatives.
  • The vendor is retiring the model, or support has ended.
  • Cost of risk controls exceeds the value.

A decommission checklist

  1. Announce and set a date.
  2. Remove access and credentials, including API keys and agent tokens.
  3. Export or delete data according to retention rules and contracts.
  4. Preserve documentation, test results and decisions for audit.
  5. Update the inventory entry with status and date.
  6. Tell downstream users and dependent systems.
  7. Review for lessons.

Document the decision

When you pause or retire a system, write down who decided, the trigger, the evidence, and the conditions to restart. A restart should need the same approvals as a new launch if the risk was serious. Keep the record with the inventory entry so a later owner understands why the system stopped.

Pre-agree thresholds

Pick numbers before launch, while nobody is under pressure. For example: pause if the error rate on the weekly regression set rises above an agreed level, if user complaints about harmful output pass a set count in a week, or if a critical vendor issue stays unresolved past a stated window. The exact values depend on your tolerance. What matters is that the trigger is written down, so the pause is a routine decision and not a debate.

Quick check

Who has authority to pause?

Name the system owner and the on-call security lead. Make it clear they will not be penalized for a good faith pause.

How do we avoid forgotten systems?

Give each inventory entry a review date and a status. Anything past its review date without an owner confirmation goes to the retirement queue.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.