Incident Response for AI Features

AI-specific steps

AI incidents include harmful or offensive outputs, data leakage, large cost spikes, mass misinformation from a bad prompt change, or abuse at scale. The response follows the usual pattern with AI-specific steps: contain quickly (kill switch or revert the config version), preserve evidence (requests, outputs, config versions), assess scope (how many users, which outputs), communicate with affected users and stakeholders, fix and add regression tests, and run a blameless review. Some incidents carry legal reporting duties, so involve the right teams.

An AI incident runbook

Keep it with the rollout plan.

1 contain: flip kill switch or roll back config version; confirm traffic on fallback
2 preserve: export affected request ids, outputs, config versions, timestamps
3 assess: count affected users / outputs; any personal data exposed?
4 communicate: status update to stakeholders; user notice if needed; legal / privacy if data involved
5 fix: patch prompt / checks; add failing cases to eval + red-team suites; re-run gates
6 review: blameless write-up; update rollout plan and triggers

Keep request ids and config versions

Without them you cannot tell which users saw the problem or which change caused it.

Quick check: What is the first step when an AI feature produces harmful outputs at scale?

• Wait for the weekly meeting
• Start a long investigation while it keeps running
• Delete all logs
• Contain it with the kill switch or a config rollback