A classical service incident playbook is built to catch hard failures: a 5xx spike, a saturated queue, a bad deploy that trips the error budget. Route an AI feature through it and the playbook will declare the system healthy while the feature is quietly getting worse. The dominant AI failure modes produce no error, no latency breach and no obvious rollback target — which means the playbook’s first step, “confirm the alert”, has nothing to confirm.
That gap is not a monitoring bug. It is a taxonomy gap. A classical playbook enumerates failures of availability; an AI playbook has to enumerate failures of correctness, and those need their own detection signal, severity definition, triage owner and rollback path. Until the incident classes are named, nobody can check whether they are covered.
What changes in practice between the two playbooks?
The structure of an incident response process — declare, triage, mitigate, review — survives the move to AI intact. What breaks is every assumption underneath it.
A classical playbook assumes the failure announces itself. Something returns an error, a probe fails, a dashboard turns red, and the page fires within seconds. An AI feature that starts answering confidently and wrongly emits a 200 with a well-formed body. Nothing in the request path knows the answer was wrong. Time-to-detect is then set by how long it takes a customer to complain and for that complaint to reach someone who can connect it to a model change — often days, sometimes a full release cycle.
A classical playbook also assumes the last deploy is the prime suspect, because in deterministic software the code is the thing that changed. For an AI feature the code frequently did not change at all. What changed was the input distribution, a retrieval index rebuild, a provider swapping the model behind a stable API name, or a prompt edit shipped as a config value with no review. In our experience the single most common wasted hour in an AI incident is spent bisecting application commits when the causal artefact was never in the repository.
Third, a classical playbook assumes mitigation means reverting to the previous known-good build. For an AI feature the previous known-good state is a tuple — model version, prompt template, retrieval index snapshot, threshold set, feature-store version — and reverting one element without the others can produce a third, novel behaviour rather than the old one.
The four incident classes a classical playbook does not name
These are the classes we consistently find missing when we read an existing incident process against a deployed AI feature. Each one needs its own row in the playbook, not a shared “AI issues” catch-all.
| Incident class | What actually happens | Detection signal it needs | Sensible first responder | Rollback target |
|---|---|---|---|---|
| Silent quality regression | Output correctness degrades while availability, latency and error rate stay nominal | Sampled eval on live traffic, human-review queue rate, task-completion or acceptance rate | Model owner, with platform on-call as declarer | Pinned previous model + prompt version |
| Data and concept drift | Input distribution moves away from training coverage, or the input→output relationship decays | Input- and output-distribution monitors with named thresholds and an alert owner | Data or model owner | Often none — the fix is recalibration, guards or retrain, not revert |
| Prompt injection and retrieval poisoning | Untrusted content in the prompt or index redirects behaviour or exfiltrates context | Output policy checks, retrieval-provenance logging, anomaly rate on tool calls | Security on-call jointly with model owner | Index snapshot revert, tool disable, retrieval source quarantine |
| Upstream model or provider change | A hosted model changes behind an unchanged API name or version alias | Golden-set canary run on a schedule, provider changelog watch, output-distribution diff | Platform on-call | Pin to a dated model identifier or fail over to the fallback provider |
Two things about this table matter more than its contents. The first is that the detection column is where most playbooks fail — three of the four classes have no signal at all in a standard observability stack, which is why the production AI reliability audit scope checklist treats incident playbook and drift posture as separate surfaces. The second is that the rollback column is not uniform: drift is the class where “roll back” is usually the wrong instinct, because the world moved, not the artefact.
Severity without an error rate to anchor on
Classical severity ladders anchor on availability: percentage of requests failing, minutes of downtime, error budget consumed. An AI feature that is 100% available and 30% wrong does not register anywhere on that ladder.
The workable substitute is to anchor severity on blast radius and reversibility rather than on a rate. Three questions do most of the work:
- Is the wrong output acted on automatically, or does a human see it first? An incorrect answer inside an automated decision loop — approval, routing, pricing, actuation — is categorically more severe than the same error surfaced as a suggestion.
- Is the damage reversible? A wrong summary shown once is recoverable; a wrong write to a system of record, a sent email, or a persisted label in a training set is not, and it contaminates the next model.
- Is the fault contained to a segment? A regression affecting one language, one customer tier or one fleet segment behaves differently from one affecting all traffic, and it should page differently.
Severity defined this way is declarable at the moment of detection, before anyone knows the cause — which is the property a severity definition needs to have. Waiting for a root cause before assigning severity is how AI incidents spend their first two hours ungoverned.
Rollback is a versioning question before it is an incident question
The reason so many AI incident playbooks contain the word “rollback” and cannot execute it is that the artefacts were never versioned as a set. If the prompt lives in an environment variable, the retrieval index is rebuilt in place nightly, and the model is referenced by a moving alias, then there is no previous state to return to — only a previous intention. That whole design problem is worth treating separately, and we work through it in how to design a rollback path for an AI feature in production.
For the playbook itself, the minimum is narrower: every AI incident class in the table above must name the artefact its mitigation acts on, and that artefact must be addressable by a pinned identifier at the moment of the incident. A flag-gated fail-safe default — degrade to a rules-based path, a cached response, or a human queue — counts as a valid rollback target and is often faster than reverting a model.
Ownership and the handoff nobody wrote down
The most reliable predictor of a long AI incident is that its first responder was not defined in advance. Platform on-call can see the symptom but cannot judge whether the outputs are wrong. The model owner can judge that but is not on a rota. The product team hears the complaints first and has no access to either.
The written form we look for is short: for each incident class, one named declarer (who can open the incident), one named diagnostic owner (who can decide whether the model is implicated), and one named executor (who has permission to flip the flag or pin the version) — with the understanding that the same person may hold two of the three. The related question of when a feature has earned a formal rota at all is a separate judgement, covered in when AI deployments need explicit on-call ownership.
Post-incident review needs the same adjustment. A blameless postmortem template built around “what code change caused this and what test would have caught it” produces nothing useful when the root cause is a shifted input distribution or a poisoned document. The two questions that replace it: which monitor should have fired and did not, and which artefact version was not pinned. Track one more number alongside those — the share of AI incidents closed as operational (config, retrieval, provider change) versus genuinely model-owned. When that ratio skews operational and the team keeps retraining anyway, the playbook is misrouting incidents at the triage step, not the fix step.
Testing whether the playbook is real
A playbook document is a claim, not evidence. The check is mechanical: take each named incident class, and confirm it has a monitor that would fire, a severity definition that can be applied at declaration, a named owner, and a rollback target that has actually been executed at least once outside an incident. Any class missing one of the four is an aspiration. This is precisely what our reliability audit tests against a deployed feature — the ownership matrix and release-readiness checklist in the Production AI Monitoring Harness exist to turn that four-column check into an evidenced result rather than a self-assessment, and it is one of the surfaces we scope in our engagements.
The measurable outcomes worth tracking afterwards are unglamorous: time-to-detect a silent quality regression, time-to-rollback to a known-good model or prompt version, and the share of AI incidents that had a named owner at declaration rather than after escalation. If repeat incidents on the same failure class fall, the playbook improved. If only the individual fixes got faster, it did not.
Frequently Asked Questions
What does the difference between an AI incident playbook and a classical service incident playbook mean in practice?
On AI Incident Playbook Differs, the short answer is this. When applied to How an AI Incident Playbook Differs, in deployment, it means adding incident classes whose symptom is wrongness rather than unavailability, each with its own detection signal, severity rule, owner and rollback target. The process skeleton — declare, triage, mitigate, review — stays the same; the assumptions that the failure announces itself and that the last deploy is the suspect do not survive., four recur: silent quality regression, data or concept drift, prompt injection and retrieval poisoning, and upstream model or provider change behind a stable API name. None of them trip an availability, latency or error-rate alert, so a standard observability stack reports the system as healthy throughout.
How do you define severity for an AI incident when there is no error rate to anchor on? Anchor on blast radius and reversibility instead of rate: whether the wrong output is acted on automatically or reviewed by a human, whether the damage can be undone, and whether it is contained to a segment. Those three can be answered at detection time, before the cause is known, which is what a usable severity definition requires.
How should post-incident review change when the root cause is a data or prompt issue rather than a code change? Replace “what code change caused this and what test would have caught it” with two different questions: which monitor should have fired and did not, and which artefact version was not pinned. Also record whether the incident was operational or genuinely model-owned, because that ratio tells you whether retrains are being triggered for causes a retrain cannot fix.
The AI Incident Playbook Differs checklist
AI Incident Playbook Differs is rarely the hard part — knowing which of its failure modes you can live with is. That answer is workload-specific, and it is worth writing down before you build.
