Why governance matters here
In an incident, people hesitate: "Am I allowed to switch off the customer assistant?" Every minute of hesitation is more harmful answers, more exposed data or more spend. Pre-agreed rules remove the hesitation.
Governance frameworks also expect it. The EU AI Act, for example, requires high-risk AI systems to be designed so humans can intervene and interrupt them (a "stop" button or similar procedure); check how the rules apply to your systems with your compliance team.
Decision rights matrix
| Switch level | Can pull without asking | Must inform | Can restore |
|---|---|---|---|
| Tool (agent) | On-call engineer | Agent owner | Agent owner after review |
| Feature / safe mode | On-call engineer, product owner | Product owner, support lead | Product owner |
| Tenant / user block | On-call, security | Account owner / support | Security + account owner |
| Model / prompt version | On-call, ML/LLMOps lead | Product owners using it | LLMOps lead |
| Platform (all AI) | Incident commander, CISO / security lead | Leadership, all product owners | Incident commander + security |
Rule of thumb: pulling is easy, restoring requires review.
When the switch must be pulled
Write triggers down so nobody has to argue during an incident:
- Confirmed exposure of restricted or personal data through AI answers.
- An agent took an irreversible action it was not authorised for.
- Harmful content (self-harm advice, illegal instructions, discriminatory output) confirmed in production responses.
- Credential for a model endpoint exposed publicly.
- Spend exceeding the agreed emergency threshold.
And when it may be pulled at the engineer's judgement: rising complaint rates, unexplained quality drop, suspicious traffic.
Communication templates
Prepare short messages in advance:
| Audience | Message |
|---|---|
| Users (in product) | "This AI feature is temporarily unavailable. [How to get help]." |
| Support teams | What is off, why (one line), workaround, expected next update |
| Stakeholders | Impact, what triggered it, next decision point and time |
| Status page (if public) | Plain description, no blame, next update time |
Restore criteria
Before restoring:
- Cause understood and fixed, or risk accepted in writing by the owner
- Fix tested against the incident's examples (add them to the evaluation set)
- Staged restore plan: read-only / canary / limited tenants first
- Monitoring for recurrence in place
Audit trail
Each flip should record:
| Field | Example |
|---|---|
| Switch and level | ff ai-chat (feature) |
| Action | Off → on |
| Who | user or automation identity |
| When | UTC timestamp |
| Why | Incident ID, one-line reason |
| Approval (for restore) | Who approved, evidence link |
Sources: flag store and gateway change logs (activity logs, diagnostic logs), plus the incident record. Keep them together for the retention period your governance policy requires.
Review cadence
- After each pull: short post-incident review. Was the switch fast enough, and were the right people informed?
- Quarterly: review decision rights, triggers and contacts; run a drill.
- When a new AI system goes live: its kill switches are part of the launch checklist, with an owner.
Tip
Put the decision matrix and triggers on the first page of the AI system's runbook. In an incident nobody reads page 7.
Checklist
- Decision rights per switch level agreed and published
- Mandatory triggers written down
- Communication templates ready
- Restore criteria and approvers defined
- Audit trail captured automatically
- Kill switches part of AI launch approval