← All posts

Turning it on was the easy part. Can you turn it off?

A glowing blue illuminated power switch on a pedestal on a dark slate desk, beside an identical switch housing standing empty and unlit with a thin amber cable running into shadow, ringed by power, undo, stopwatch, warning, chain-link and clipboard icons, with an unlit black lever, ledger and plug in the foreground.

Every AI deployment I have been part of had a go-live plan. Dates, owners, a checklist, someone watching a dashboard on the morning it went out. Not one of them had a serious plan for the opposite direction — what happens on the day the thing has to come back out again.

There is usually a line in the risk assessment that covers it: in the event of failure, revert to the manual process. I have written that line myself. It is one sentence describing a process nobody has run for a year, staffed by people who have moved on, at a volume it was never sized for.

Going live is a decision you make. Coming off is usually a decision that gets made for you.

“Revert to manual” is not a plan

Put that same sentence in a continuity plan for a payments system and it would not survive the first review. Someone would ask who does it, how many an hour, when it was last tested. Nobody accepts a one-line fallback for infrastructure.

AI systems get the exemption because of how they arrive. They come in as a productivity tool, on a pilot, with a champion and a small scope — and then the workflow reorganises around them and they quietly become infrastructure. Nothing ever reclassified them, so the continuity thinking never caught up.

Regulators have noticed the shape of this, if not the AI version. Under DORA, financial entities in the EU must hold exit strategies for ICT services supporting critical or important functions, with transition plans they can actually execute. The useful part is not the rule but the discipline it assumes: someone has thought about coming off, and checked that it works.

You will be switched off, and rarely by choice

The stop is not hypothetical, and it usually arrives from outside.

The model underneath you gets retired. Providers deprecate versions on their own schedule, not yours. The replacement is not the thing you validated, and the migration window is set by someone who has never heard of your use case.

The supplier changes or withdraws the feature. The exposure I described in why most of your AI risk arrived through procurement, seen from the other end: a capability you now depend on can be repriced, reworked or dropped.

An incident forces a stop. A bad batch of outputs, a data question you cannot immediately answer, a complaint that escalates. The first control anyone reaches for is to switch it off — and they are right to. The question is what the next hour looks like.

Someone with the authority to stop you does. The EU AI Act writes this into the oversight duties for high-risk systems: whoever is overseeing must be able to intervene, or interrupt the system through a stop button or similar procedure that brings it to a halt in a safe state. Sit with that phrase. A stop that leaves your operation halted alongside the model is not a safe state.

The fallback rots while you are not watching

Your ability to run without the system decays from the day you switch it on, and nothing on any dashboard tracks it.

The people who knew the manual route move on. Not made redundant — promoted, reassigned, retired. The written procedure was never the real process. The real process lived in what four experienced people knew about the exceptions, and two of them have left.

The capacity was spent the day the business case was approved. The saving gets booked in advance and the headcount goes somewhere else. The manual path still exists in the runbook. It does not exist in the roster.

The volume grew because the machine made it cheap. Automate a process and throughput rises to meet the new cost — more documents summarised, more alerts triaged. The manual route was sized for the old river and you have widened it. Going back is not a return to how things were; it is doing the new volume by hand.

The output became someone else’s input. A year of AI-drafted summaries sits in the case files, and three teams downstream now start their work by reading one. Switch the system off and their process breaks too — because the dependency was never on the tool. It was on the artefact the tool produced.

Reversible actions are not a reversible deployment

I have argued that the most useful line in agent design is between reversible and irreversible actions — draft and stage freely, keep the irreversible things on a human’s desk. That still holds, and it is a question about a single action.

The deployment asks its own version of it. An agent whose every action is perfectly reversible can still be an irreversible arrangement, because what became irreversible was nothing the agent did. It was the way the work reorganised itself around the assumption that the agent would be there.

What a real exit has in it

None of this is an argument against deploying. It is an argument for four things that take an afternoon each and almost never get done.

A trigger written down in advance. What conditions mean stop — quality below an agreed line, a supplier notice, an incident of a defined category. Decide it while everyone is calm, or the call gets made at speed by whoever is in the room, with the person who owns the savings target arguing the other way.

A capacity number, not a paragraph. How many cases a day can the manual route absorb, with the staff you have now, at the volume you have now? One number. If nobody can produce it, you do not have a fallback, you have a sentence.

A rehearsal on an ordinary Tuesday. Turn it off deliberately, at low stakes, for a day. Everything else is preparation for this. A drill is how you find out that the service account expired, the old report was decommissioned, and three exception types were only ever handled by the model — none of which appear in any document.

A floor you keep on purpose. The boring deterministic version — the rules-based screen, the checklist, the standard template — kept alive even though it is worse. It is slower and it catches less. It is also much cheaper than a week of processing nothing at all.

The question I would ask this quarter

Pick the AI system your operation is most quietly dependent on. Not the flagship with the steering group — the useful one everybody now assumes is there. Then ask one question: if it stopped at nine on Monday morning and did not come back, what does Friday look like?

Not whether you could cope in principle. Who does the work, how much of it does not get done, who has to be told. If that answer takes more than a minute to assemble, the difficulty is the finding.

An AI system is not finished when it works. It is finished when you have shown you can run without it — and then chosen to run with it anyway.

Sources: DORA (Regulation (EU) 2022/2554), Article 28, EU AI Act, Article 14 — Human oversight.

If your team is working out what it would actually take to run without the AI it now depends on, that is the kind of thing we work through with teams. Talk to us if it’s useful, or see how we run it in-house.

Prefer plain text? Read the Markdown version — a clean copy for LLMs and AI tools.

Want this for your team?

If a topic here matches something your team is wrestling with, we can turn it into a session built around your business.

Enquire