The off switch and a tested undo

The Own move asks four questions of anything that runs. Who answers for it? How do we know it's healthy? How do we stop it and undo it? What happens when the vendor changes it? Lesson 1 answered the first with a name. This lesson answers the other three, item by item, in a runbook short enough that the backup will actually read it.

Most organisations couldn't stop it quickly

Ask how long it would take to switch off an AI system that's doing damage, and most organisations can't say.

An off switch is a decision made in advance: what stops it, where, and who can press it. The guardrails from module 2 already say anyone can stop an agent. The runbook makes that concrete for each item. A good off switch is boring. Revoke its login. Switch the feature off for everyone. Pause the trigger. If stopping it needs the person who built it, a ticket with the vendor or a meeting, it isn't an off switch.

An undo you haven't tested is a guess

In July 2025, a software founder was testing an AI coding agent from Replit on a real project. He declared a code freeze: no more changes. The agent deleted the live database anyway, wiping records on more than 1,200 executives and 1,190 companies. Then it told him rollback wouldn't work. That was wrong: the data was recovered (Fortune, July 2025).

The vendor's chief executive called it unacceptable, and the fixes were the right ones: development kept apart from live data automatically, better rollback, and a mode where the agent plans without acting. Those are the rules for agents from module 2, arriving after the incident instead of before it.

The lesson for an owner is narrower and more useful. A tested undo is one somebody has actually run, recently, against a safe copy or at a quiet moment, and timed. Ideally the backup runs it, because the point is to know it works when the owner isn't there.

When there's nothing to roll back

Some things can't be undone. A reply has gone to a customer. A shortlist has been used. A letter has been posted. That's true of most uses of AI, as opposed to tools: nothing was built, so there's nothing to restore.

For a use of AI, the framework says the undo is the named check and the records. The check stops bad output before it goes out. It has to be done by someone with the time, the information and the authority to reject it. The records tell you afterwards what went out, who checked it and who to contact, so you can put it right with the people affected.

The airline in lesson 1 had neither for its chatbot. Nothing checked what it told customers, and nothing could take back what it had said. The tribunal ordered the airline to pay the difference, about C$812 in all (Moffatt v. Air Canada, 2024). The sum was small. The principle was not.

Knowing it's healthy

Monitoring for an owned item doesn't need a dashboard. It needs a way to notice when things go wrong: a small sample checked each week, an alert on a number that matters, a count of complaints.

Learning from corrections is the cheapest monitoring there is. Every time someone fixes an AI output, that's a signal. Log the corrections where the work happens and look at them at the weekly meeting. A rising count of corrections is usually the first warning you'll get, weeks before an incident.

The records the stakes require follow from module 6. Low-stakes items need little. High-stakes items need enough to show who was told, what was checked, by whom, and which version of the tool was running at the time.

When the vendor changes it

The tool you approved is not the tool you'll be running next quarter. Vendors update the models underneath, often quietly. Researchers at Stanford and UC Berkeley measured the same widely used model three months apart, on the same questions.

Medical device makers faced the same problem first. The US Food and Drug Administration asks makers of AI-enabled devices for a predetermined change control plan: what changes they expect, how they'll check them, and how they'll judge the impact, all written before the change arrives. The framework borrows that idea, with credit, and shrinks it to a few lines per item: what gets re-checked when the vendor changes something, who signs it off, and what would trigger the off switch.

Write the runbook

Pick the item that would hurt most if it went wrong tonight. Write how it stops and how it's undone, then run the drill with the backup and time it. The rest of the runbook is a line each.