Your on-call knows what to do when the API is down — nobody trained for when it's up and confidently lying. This playbook defines AI-specific incident classes — mass hallucination, injection exploit, cost runaway, viral bad output — with a severity ladder, pre-written comms, and a rollback drill you run once before you need it.
Workflow area: Agents & Responsible AI · Tier: Advanced · Hands-on time: ~40 minutes
AI incidents break the standard playbook in three ways. Detection: nothing is "down" — dashboards are green while the model tells customers a refund policy you don't have. Diagnosis: the trigger might be a model-provider change you didn't deploy. And blast radius: a single bad output can be a screenshot with a million views before your first responder finishes coffee. The teams that handle these well didn't improvise better; they had classes, severities, owners, and one rehearsal. This playbook is that preparation, sized for a product team rather than a security org.
Define the AI incident classes with detection signals. Draft with Claude:
Define AI-specific incident classes for a product team runbook.
Feature: [WHAT IT DOES, WHAT TOOLS/DATA IT TOUCHES, USER BASE]
Existing monitoring: [GUARDRAIL METRICS FROM OUR ROLLOUT PLAN,
COST ALERTS, FEEDBACK PIPELINE]
For each class, give: definition, 2-3 realistic detection
signals (which alert or human report catches it FIRST), initial
containment action, and the diagnosis question that splits
"our change" from "provider change" from "attack".
Classes: 1. MASS HALLUCINATION (systematic confident wrong
answers — policy, price, medical/legal); 2. INJECTION EXPLOIT
(user-driven behavior override, data exfiltration, tool misuse);
3. COST RUNAWAY (usage or token spike breaking spend forecasts);
4. VIRAL BAD OUTPUT (single harmful/embarrassing output
spreading publicly); 5. QUALITY REGRESSION (gradual metric
decay after a model/prompt change). Add any class my feature's
tool access makes possible, e.g. WRONGFUL ACTIONS for agents.
Sample output fragment:
CLASS 3 — COST RUNAWAY
Detect: spend/day > 3× forecast (billing alert) · p99 tokens/
request jumps without deploy · one account >20% of total usage.
Contain: rate-limit the top accounts, flag-off the expensive
path, switch router default to cheap tier.
Split diagnosis: our deploy? (check prompt/config changelog) →
provider pricing/behavior change? (check announcement, token
counts per identical request) → abuse? (account concentration,
scripted patterns).
Map classes to a severity ladder with pre-authorized actions. Reuse your org's SEV levels, adding the AI mapping: SEV1 — active harm at scale or data leaking (injection exfiltrating PII, agent taking wrongful actions): kill switch now, no meeting; SEV2 — systematic wrong answers on consequential topics, or viral output verified: feature-flag off or degrade to pb-48's T0 suggest-mode within 30 minutes; SEV3 — contained quality regression or cost breach: rollback via pb-43's procedure inside business hours. The load-bearing part: each severity lists its pre-authorized actions and the single role that triggers them — mid-incident is not when to seek approval for turning off a revenue feature.
Pre-write the four comms templates. In-product notice ("this feature is temporarily unavailable while we improve it"), support macro with the honest FAQ (what happened, what we did, whether users should re-check outputs they received), status-page/customer email for SEV1-2 (drafted with legal now, at leisure, not at 2 a.m.), and internal exec brief format (class, severity, blast radius, containment, next update time). The AI-specific rule: state clearly whether outputs users already received and acted on are affected — that's the question every customer actually has, and the one generic templates omit.
Write the one-page runbook per class. For each class: detection signals → containment ladder (mildest first: rate-limit → degrade to lower autonomy/cheaper path → flag off → full kill), the diagnosis split from step 1, evidence to preserve (trace IDs, prompt/model versions from pb-51's changelog, affected-output samples — you'll need them for the postmortem and possibly for disclosure), and the comms trigger points. Keep each to one page in incident.io or wherever runbooks live; a runbook nobody can read in 90 seconds is documentation, not response.
Run the drill — once, for real. Ninety minutes, whole feature team. Scenario: "screenshots circulating — the assistant is quoting a returns policy that doesn't exist." Inject it via a planted staging output. Measure: time to detect (did anyone notice before being told?), time to classify and severity-assign, time to actual containment — really pull the flag in staging, really execute the prompt rollback from pb-43's rehearsal, really post the comms template to a test channel. Then the honest debrief: which signal fired, which was silent, which authority was ambiguous. Fix the runbook the same day. A plan without its drill is a document; the drill is what you actually bought with this playbook.
Injection and data-leak incidents may trigger breach-notification obligations on statutory clocks — loop in security and legal at SEV1-2 immediately, preserve evidence before remediation where safe, and never let a product-side rollback quietly delete the logs that determine whether disclosure is required.
AI incidents are product incidents whose dashboards stay green — so buy your response in advance: five classes with real detection signals, pre-authorized kill authority per severity, comms that answer "are my past outputs wrong?", and one honest drill. The drill converts the plan from paper to muscle.