Launch plans are common. Exit plans are rare.

Most AI workflow projects produce a runbook, an owner, and a go-live checklist before the first case runs. Very few produce the equivalent document for the day the workflow is replaced, consolidated, or simply no longer earns its keep.

That asymmetry creates a specific kind of risk. A workflow that quietly stops being maintained does not stop holding permissions, storing data, or appearing as a trusted step in some other system's integration. It just stops being watched.

Decommissioning is a governance requirement, not housekeeping

NIST's AI Risk Management Framework (AI RMF 1.0) includes decommissioning directly in its core governance function. Subcategory GOVERN 1.7 states the expectation plainly: processes and procedures must be in place for decommissioning and phasing out AI systems "safely and in a manner that does not increase risks or decrease the organization's trustworthiness."

That framing matters because it puts the burden of proof on the shutdown, not just the launch. An AI workflow that reached production under a reviewed set of permissions, data access, and human oversight should leave production under an equally reviewed process, not a deployment that was simply stopped being funded.

What an AI workflow decommission plan should cover

Traditional IT decommissioning guidance, like the U.S. Department of Housing and Urban Development's published decommission project guide, lays out a sequence that applies almost unchanged to an AI workflow: decide and document why the system is being retired, notify users and stakeholders, determine how the data will be disposed of or retained, archive the data and software components, remove system access, and conduct a post-decommission review.

For an AI workflow specifically, the data-and-access steps need extra care, because the footprint is wider than a single application. A workflow built for agentic orchestration typically touches a model provider, one or more retrieval sources, several destination systems, and a human review queue. Each of those needs its own closure step.

  • Revoke model and tool API keys, not just the orchestration layer's own login.
  • Decide the retention period for prompts, decision evidence, and review logs before deleting anything, and check it against the retention rule the workflow was already operating under.
  • Remove the workflow from monitoring, alerting, and the service inventory so a stale dashboard does not look like a live system.
  • Confirm no other workflow or integration still calls this one as a dependency before access is cut.

What should trigger the decommission conversation

A workflow is a decommission candidate when its cost or risk of continued operation has clearly overtaken its business value: the case volume it was built for has shrunk, a newer workflow now covers the same decision with better evidence or controls, the model or vendor it depends on is being sunset, or a policy change has made the original scope obsolete.

None of these are emergencies, which is the point. A planned retirement, scheduled with notice to the people whose work depends on it, is a very different event from an unannounced shutdown discovered when someone's queue stops filling.

Close the loop with a short review

The last step in a decommission plan should be a short written review: why the workflow was retired, what it cost to operate in its final period, what broke or needed cleanup that the original build did not anticipate, and what should be different in the next workflow's design.

That review is cheap to produce and is usually the only record that tells the next build team what the last one would have done differently. Treating it as optional is how the same integration mistakes get rebuilt into the next workflow.