Issue #75

Rehearse the AI Off-Switch Before You Need It

sent to 25 subscribers

Every AI feature launch comes with a rollout plan. Fewer come with a rollback plan that anyone has actually tested — and there's a specific gap worth naming: the difference between a general feature flag and a dedicated, rehearsed "AI off" path.

A feature flag that hides a UI element is not the same thing as a fallback that keeps the underlying task working once the model is out of the loop. If your AI feature summarizes tickets, drafts replies, or routes requests, turning it off shouldn't mean the surrounding workflow stops functioning — it should mean falling back to whatever a human did before the feature existed, and that fallback path needs to still exist in your codebase, your docs, and your team's muscle memory.

The reason this matters isn't just outages. Teams turn off AI features for reasons that have nothing to do with the provider going down: a quality regression nobody caught in eval, a cost spike, a policy or compliance concern, a bad news cycle. Those are business decisions, not infrastructure failures, and they can come with no warning and no time to build a fallback from scratch under pressure.

Treat the off-switch like a fire drill, not a hypothetical. Once a quarter, actually flip it in staging — or during a quiet window in production — and watch what breaks. Does the support queue still route? Does anyone remember the manual process? Is the fallback path still wired up, or did it bit-rot the moment everyone trusted the AI version? The features that get the off-switch flipped and drilled ahead of time are the ones that survive a bad week without becoming an incident.

← Back to archive