The first serious AI incident arrives on a Friday afternoon, and the org discovers nobody defined what counts as one, who may pull the kill switch, or that DPDP's 72-hour breach clock started at discovery. This playbook designs that machinery in advance: incident classes, a severity ladder, decision authority, customer remediation, and the regulatory triggers.
Workflow area: AI Rollout & Governance · Tier: Advanced · Hands-on time: ~40 minutes
IT incident management exists everywhere; AI incident management almost nowhere — and the gap is business-shaped. When a model starts fabricating policy clauses, the servers are green: no alert fires, no SLA breaches, and the "outage" is a quality collapse only humans can recognize. Worse, the response decisions are business decisions — stop a revenue-carrying process or keep it running degraded, notify customers or quietly fix, does this trigger a legal clock — made under time pressure by whoever is present unless someone designed the process first. That someone is the analyst, and the design work reuses everything this track built: the failure catalog says what can go wrong, the kill switch exists, the audit trail can reconstruct — this playbook assembles them into a runbook.
Define the incident classes from the failure-mode catalog. Each high-impact row of pb-44 maps to a class; typical set: harmful or legally exposing output reached a customer; fabrication above threshold (single fabrications are exceptions — a pattern is an incident; set the number); personal-data leakage in outputs or logs (simultaneously a breach — see step 4); discriminatory-pattern detection from fairness monitoring (pb-47); prompt-injection exploitation; runaway cost or volume; and silent-degradation discovery — sampled review or a scheduled eval run (pb-50) finding quality below the acceptance floor. The last class is the one every draft misses: no single event, no timestamp, still an incident.
Build the severity ladder with response times and stop rules. Severity is impact-based and pre-decided:
SEV-1 Customer harm occurring or legal exposure live
(leakage, harmful output sent, discriminatory pattern).
Response: immediate. Default: STOP the AI path, switch
to degraded-mode manual process (pb-46). Bridge opens;
business owner + privacy officer paged.
SEV-2 Quality below acceptance floor, harm contained inside
review/exception queues. Response: same business day.
Options: constrain autonomy tier, tighten sampling,
targeted stop for affected case types.
SEV-3 Elevated exception/override rates outside bands (pb-49),
single contained failures. Response: 3 working days,
via governance triage — watch, fix, or escalate.
Rule: when severity is disputed, the higher classification
holds until evidence lowers it.
The Sev-1 "default stop" line is the cultural keystone: stopping is the pre-authorized safe action, not a heroic call someone must defend later.
Assign decision authority by name and rehearse the switch. Three authorities, held by roles not committees: who declares an incident and severity (any trained responder declares; the on-call owner confirms); who orders stop and resume (business process owner for Sev-1 stop — resume additionally requires the eval evidence per pb-50's change gate, because resuming without proof of fix is how incidents recur); and who approves external communications (comms plus legal above a defined exposure line). Then rehearse: a quarterly tabletop — pick a failure-catalog scenario, walk the ladder, pull the kill switch in staging, run a case through degraded mode — because an unrehearsed runbook is a document, not a capability.
Wire the regulatory clocks and customer remediation in advance. For personal-data incidents, the DPDP Rules require notifying affected data principals and the Data Protection Board on discovery — with the detailed report due within 72 hours — and GDPR's 72-hour supervisory-authority clock applies where it reaches; both clocks start at awareness, not at root-cause confirmation, so the process routes any suspected leakage to the privacy officer within hours, with counsel owning the notification decision. Pre-draft the remediation pack with legal review now, not during the incident: customer notification templates per incident class (what happened, what it means for you, what we are doing, your recourse), the correction workflow for AI-caused wrong outcomes (found via the audit trail's reconstruction capability, pb-45), and the appeal-path fast lane (pb-50) for affected customers.
Close every incident into the learning loop. The post-incident review asks the AI-specific questions: which failure mode was it, and was it in the catalog (if not, the catalog grows — pb-44); why didn't detection fire earlier; and then the mandatory conversions — incident cases become golden-set cases (pb-48) so regression runs forever test this exact failure, thresholds and sampling rates adjust (pb-50), and requirements gaps become change requests. An incident that produces no new eval cases and no control change was handled, not learned from. Track the metric that proves the loop works: median time from failure occurring to failure detected, falling quarter over quarter.
Incident records are among the most sensitive artifacts in the whole system — they combine customer harm details, personal data, and admissions of failure; restrict access hard, route all external statements through legal, apply DPDP/GDPR retention discipline to the incident store itself, and never paste live incident material into unapproved AI tools while investigating.
AI incidents are quality collapses on green infrastructure, and the response decisions are business decisions — pre-defined classes, an impact-based ladder with a pre-authorized stop, the 72-hour breach machinery wired to the privacy officer, and a loop that turns every incident into eval cases are what make the Friday-afternoon discovery a procedure instead of a panic.