Organizations Need AI Rollback Plans Before They Need Them
A support team I spoke with had an AI assistant drafting first-pass replies to customer emails. It had been running for most of a year, and people liked it. Then one Tuesday it started citing a refund window the company had quietly retired months earlier, and a couple of customers acted on the wrong answer before anyone caught it. The mistake itself was small and fixable. What stayed with the team was a different question: nobody was sure who could actually turn the thing off, or what “off” even meant once the assistant had become part of how everyone worked.
That gap is more common than the tidy case studies suggest. Organizations put real effort into deciding whether to adopt a tool, and almost none into deciding how they would step back from one. Adoption gets a launch plan. Reversal gets a shrug and a vague sense that it would be fine.
A rollback plan sounds, at first, like planning to fail. In practice it tends to be the opposite. The teams that move quickest with AI are often the ones who already know how they would unwind a deployment, because that knowledge is exactly what lets them say yes without quietly bracing for the day it goes wrong.
A rollback plan isn’t a sign you expect the tool to fail. It’s what lets you adopt it without holding your breath.
What “rollback” actually means here
It is rarely a single red button. Most real rollbacks are partial, and naming the levels in advance is half the work. You might revert to a previous model version that behaved more predictably. You might pause one automated step while leaving the rest of the workflow running. You might route a class of decisions back to a person for a while. Or you might retire a tool entirely. These are different moves with different costs, and a team that has never distinguished them ends up treating every wobble as all-or-nothing.
Notice that none of this requires you to predict the specific failure. You are not forecasting what will break. You are deciding, while calm, what your options are when something does.
What changes once the tool is load-bearing
Early on, switching off an AI tool is easy, because nothing depends on it yet. The harder moment arrives later and arrives quietly. At some point enough of the work has reshaped itself around the tool that removing it is its own disruption. People have stopped doing the manual version. The old spreadsheet macro got deleted. The person who knew the by-hand process moved teams. The tool didn’t just speed up the work; it became the work.
This is the stage most maturing organizations are actually in, even if their paperwork still describes a pilot. The assistant is no longer an experiment running alongside the real process. It is the real process. And a fallback that nobody has used in eight months is not a fallback. It is a memory.
Building the plan before you need it
The useful version of this work is unglamorous and mostly happens on a quiet afternoon when nothing is on fire. A few moves tend to hold up:
• For each AI system that matters, write down what “off” means in concrete terms, and name the person who has the authority to call it. Authority that lives nowhere lives with no one.
• Keep one recent known-good state you can return to: a previous model version, or a manual process documented well enough that a competent colleague could resume it without archaeology.
• Decide the trigger in advance. What level of error, drift, or complaint means you pause, rather than “we’ll know it when we see it”? A threshold set under pressure is usually set too late.
• Rehearse it once while everything is fine. A rollback nobody has ever practiced is a theory, and theories tend to discover their gaps at the worst possible moment.
None of these are dramatic. That is rather the point. The whole aim is to make stepping back an ordinary operational move instead of an emergency.
Why leadership tends to care about this
Framed well, reversibility is not a vote of no confidence in the tool. It is a statement about the organization: that it can adopt quickly and still stay in control of what it adopted. Boards and risk committees have started asking some version of this question, and the teams that can answer it plainly tend to get more room to move, not less. The ones who answer with a long pause tend to get a new layer of approvals instead.
It is also cheaper to design reversibility in early than to retrofit it during an incident, when the options are fewer and everyone is tired. Like our piece on AI Policies Fail When Nobody Owns Enforcement argues for clear ownership of policy, the same logic applies to rollback: a safeguard with no name attached to it is a safeguard that quietly fails when you finally reach for it.
This is why AI governance becomes achievable when you treat it as an operating practice rather than a one-time approval. The first rollback plan you write will be imperfect. The point is that it exists, gets used, and gets a little better each time the tool’s role changes.
Worth sitting with
If our most-used AI tool produced confidently wrong output tomorrow, how long would it take us to notice, and who would decide what to do next?
Which of our AI deployments could we genuinely step back from today, and which have we already grown dependent on without ever deciding to?
What is our known-good state to return to, and when did we last confirm it still works?
Are we treating governance here as a signature on a launch, or as something we revisit as the tool quietly takes on more?
If you only do one thing, pick the AI system you would least want to lose and write down how you would turn it off. If that proves harder to answer than it should be, that is the finding. Working through it with someone who has built operational safeguards before tends to be faster than discovering the gaps live, and the experts in Compass are a reasonable place to start that conversation when you are ready.
