Design the AI workflow's off switch before you need it

Imagine a support team runs a summarization agent on incoming tickets for months. It is useful, so nobody thinks about it. Then the vendor deprecates the model behind it, quality drops, and a customer complaint traces back to a hallucinated refund promise in an agent-written summary. The team wants to turn it off. The shutdown drags on: no one owns the decision, the agent’s output is quietly feeding a reporting dashboard and a routing rule, and turning it off breaks both.

That delay was not a tooling problem. It was a design gap. The team had an intake review, a pilot check, and a rollout plan. It had never decided how the workflow gets turned off.

The stage most programs skip

There is a standard shape to how an AI system lives and dies. ISO/IEC 22989, the AI terminology standard, lays it out as inception, design and development, verification, deployment, operation and monitoring, and finally retirement. Retirement is not an afterthought in that model. It is a named stage, and the standard defines it as decommissioning the system while addressing long-term data and access risks.

Most internal programs implement every stage except the last. They fund the build, gate the launch, and monitor the running system. Retirement stays undefined until something forces it, and by then it is an incident instead of a procedure.

The fix is cheap if you do it before launch and expensive if you do it after: write down how the workflow ends before you decide it can start.

Two different shutoffs

“Turning it off” hides two situations that need different plans.

The first is planned retirement. The workflow is being replaced, the project ended, the model is reaching end of support, or a review concluded the AI step is not worth its cost. You have time. You can migrate consumers, archive data, and communicate a date.

The second is emergency deactivation. Output quality collapsed, the system is producing harmful or non-compliant results, a data exposure is suspected, or a cost runaway is burning budget by the hour. You have minutes, and the decision to stop cannot wait for a meeting.

These fail in opposite ways. Planned retirement fails slowly and quietly: a “decommissioned” system that is still receiving traffic because one dependency was missed. Emergency deactivation fails fast and loudly: nobody is sure they are allowed to hit the switch, so the harm continues while people look for approval.

The NIST AI Risk Management Framework treats the emergency case as a control you build in advance. Its playbook expects an organization to have assigned owners and applied mechanisms to supersede, disengage, or deactivate a system whose behavior is inconsistent with its intended use. In plain terms: a working kill path with a named owner and a defined trigger, not an ad-hoc scramble.

	Planned retirement	Emergency deactivation
Time available	Weeks	Minutes
Decision maker	Program owner, on schedule	On-call owner, on a defined trigger
Main risk	A missed consumer keeps the dead system alive	Nobody is sure they are allowed to stop it
First move	Inventory who depends on the output	Cut the workflow, then investigate

The reason it is hard is not the switch

The mechanical off switch is easy. The hard part is knowing what breaks when you flip it.

A 2015 paper from Google researchers on technical debt in machine learning systems named the trap directly: undeclared consumers. A model produces an output, and over time other systems start reading that output without telling anyone. The same paper describes entanglement, summarized as “changing anything changes everything” — pull one thread and unrelated behavior shifts. AI workflows accrue this debt faster than ordinary software because their output is easy to consume and easy to depend on informally.

That is why the support team’s shutdown broke a dashboard and a routing rule. Nobody had declared those consumers. They had grown around a useful output.

So the first real artifact of a shutoff plan is not the switch. It is a consumer inventory: what reads this workflow’s output, whether each reader is a human or another system, and what each one does if the output stops. You cannot maintain this list perfectly, but writing it once at launch and reviewing it when the workflow changes turns an unknown blast radius into a known one. If you already keep an evidence trail for the workflow, the log of who queried its output is the cheapest place to discover consumers you forgot about.

Keep the records after you kill the system

Turning a workflow off is not the same as making its history disappear, and in a regulated setting the two are explicitly separated.

Under the EU AI Act, a high-risk AI system has to keep automatic logs over its lifetime, and lifetime is defined to run from deployment through decommissioning — not just the current release. Deployers of high-risk systems have to retain those logs for at least six months from when each log is created, and sector or data-protection law can push that longer. NIST’s guidance points the same way for any serious system: when you deactivate, preserve the materials needed for forensic, regulatory, and legal review, and run a root cause analysis on the event.

This creates a genuine tension with data minimization. The retirement stage in ISO/IEC 22989 is partly about disposing of data and revoking access so a dead system is not a standing liability. The regulatory logging rules pull the other way. The resolution is to separate the two: dispose of live operational data and revoke credentials on shutdown, but move the audit logs into cold, access-controlled retention with an explicit expiry. Deleting everything the moment you turn a system off is a mistake in exactly the cases where someone will later ask what it did.

If your workflow is not high-risk under any regulation, treat six months of retained logs as a reasonable default rather than a requirement, and shorten it deliberately if privacy pressure warrants.

Have somewhere to fall back to

An off switch with nothing behind it is a service outage. The NIST playbook is explicit that deactivation planning includes redundant or backup systems so operational and business functions continue.

For an AI workflow the fallback is usually one of three things, in rough order of cost: revert to the manual process the AI replaced, degrade to a simpler non-AI rule, or fail over to a second model or vendor. The one you choose should be decided before launch, because each has a standing cost. Keeping the manual process warm means people have to retain the skill and the access. A rule-based fallback has to be maintained even while the AI is doing the work. A second vendor doubles part of your integration surface.

This is where a fair number of teams should conclude they are not ready to depend on the workflow at all. If turning it off means the work simply stops and there is no acceptable degraded mode, the workflow is load-bearing without a backup, and that is a risk you took without naming it.

What this costs, and who can skip it

A shutoff plan is not free. The consumer inventory needs maintaining, the fallback needs to stay usable, and the retention policy needs an owner. For a serious, long-lived workflow that touches customers, money, or regulated data, that cost is small next to a two-day scramble during an incident.

For a genuine throwaway — a one-off analysis, a personal-productivity experiment, a pilot explicitly scoped to be discarded — a full shutoff plan is overhead you do not need. The honest test is whether anything downstream would notice if the workflow vanished tonight. If the answer is nothing, skip the plan. If you are not sure, that uncertainty is itself the signal that undeclared consumers may already exist.

The failure mode to avoid is the middle: a workflow that started as an experiment, quietly became infrastructure, and never got the retirement design that its new status requires. Reviewing the workflow when it changes scope is the moment to add one.

The retirement note you write on day one

You do not need a checklist product for this. You need a short note, attached to the workflow at launch, that answers a handful of questions the eight-month-later version of you will not be able to reconstruct in a hurry:

• Who owns the decision to retire this, and who is allowed to trigger an emergency stop without asking?
• What specific conditions trigger each — a quality threshold, a cost ceiling, a vendor end-of-support date, a compliance finding?
• What reads the output today, and what does each consumer do when it stops?
• What is the fallback, and is it currently usable?
• What data and logs are deleted on shutdown, and what is retained, for how long, and where?

Write it in a paragraph or a table, whatever your team will actually keep current. The value is not the format. It is that the answers exist before the day you need them.

Revisit the note whenever the workflow’s inputs, model, vendor, or regulatory status changes — those are exactly the events that add undeclared consumers, invalidate a fallback, or move a workflow across a compliance threshold. An off switch you designed for last year’s system is not guaranteed to work on this year’s.