AI incident response — what the playbook needs that IT playbooks miss

Three properties distinguish AI incidents from the IT incidents most response teams are organised around. Each property has direct implications for how the playbook needs to be written.

Non-deterministic reproduction.When a service fails because a database connection times out, you can reproduce the failure by replicating the conditions: same query, same load, same pool configuration. The same is not true of an AI failure. The user prompt that produced a harmful output yesterday may produce a benign output today. The same RAG query against the same retrieved chunks may produce different responses on the next call. The inability to reproduce reliably means the playbook cannot rely on a “reproduce, isolate, fix” loop. The investigation has to work from the logged evidence of what did happen, not from re-running the incident.

Model-level root cause.When the cause of an incident lives in training data, fine-tuning data, or model architecture, it is — for almost every organisation — inaccessible. You can examine the prompt, the retrieval pipeline, the tool layer, the system configuration. You cannot examine the weights. You cannot examine the training set the vendor used. You may not even be able to determine which model version was in use at the time of the incident if the vendor has rolled forward in the interim. A meaningful share of AI incidents have a root cause that you can characterise but not access, and the playbook must acknowledge that root-cause analysis sometimes ends with “the model produced this; we cannot determine why.”

Evidence that degrades over time. A standard IT incident can be investigated days or weeks after the fact, because the systems involved keep their logs. AI incidents have a much shorter window. Vendor model logs are often retained for 30 days or less. Model versions change without notice. Vendor configurations change without notice. Internal prompt templates can be edited. Memory contents can be overwritten. The clock on evidence preservation for an AI incident starts at the moment of detection, and it runs in hours, not days.

Standard IT incidents have a forensic window measured in months. AI incidents have a forensic window measured in hours. Build the playbook around that constraint or accept that root cause analysis will not be possible.

These three properties are not exotic — they are inherent to building on models you do not train. Any AI incident response playbook that does not account for them is going to miss the moments where preparation could have preserved the evidence or shortened the response.

The taxonomy matters because each type has a different detection path, a different containment option, and a different evidence requirement. The playbook should reference the type explicitly — “this is an AI-04 tool-misuse incident” — because the response paths diverge from that point.

Two categories deserve specific note. AI-02 prompt injection and AI-04 tool misuse are often related — the injection is the entry point, the tool misuse is the resulting action. They should be tracked separately because the detection signal and the containment response are different. An organisation that conflates them tends to miss the injection root cause and focus only on the tool action, which leaves the underlying vector unaddressed.

AI-08 vendor incidents are the category most organisations are least prepared for, because the response is largely out of your control. The vendor is investigating; the vendor is deciding what to disclose; the vendor is choosing the timeline. Your job in an AI-08 incident is to determine the scope of your own exposure, contain it where you can, and document what you do not know. The playbook should treat AI-08 as a first-class category and not as a sub-type of another category — the response shape is different enough to warrant separate handling.

Before mapping the gaps, it is worth being explicit about what existing IT playbooks already cover well — and what an AI playbook can therefore inherit rather than reinvent.

Infrastructure incidents. When the cause is a service outage, a network failure, a database problem — the standard playbook works. The AI feature is sitting on top of infrastructure, and the infrastructure has its own incidents. The detection, response, and recovery patterns for these are well-established.

Availability incidents. When the AI feature is unavailable because the underlying service is unavailable, the response is to restore the service. Standard runbook. The AI-specific question — “is the model itself behaving correctly?” — comes after availability is restored.

Intrusion response. When an attacker has compromised infrastructure that the AI feature runs on, the response is the same as for any other workload on that infrastructure. Isolate, investigate, restore. The AI-specific question — “what did the AI feature do during the compromise window?” — is layered on top.

Forensics through logs. The discipline of preserving logs, building timelines, and reconstructing what happened is well-established. The AI playbook inherits this discipline. What it has to add is the specific fields and sources that matter for AI — which the standard log preservation process is not necessarily configured to capture.

The standard playbook also handles the meta-process well: incident declaration, severity assignment, comms cadence, retrospective. None of that needs to change for AI. What changes is the technical content of each stage.

Where standard playbooks fall short is in the AI-specific content of each stage. They miss the detection signals that matter for AI, the containment options that exist only for AI, the evidence that degrades faster than IT evidence, and — most importantly — the root cause discipline that has to accept that not all root causes are accessible.

The deepest gap is around root cause analysis. Standard playbooks treat root cause as a required output of every incident: the investigation concludes when the root cause is identified, the fix is applied, and the fix is verified. For AI incidents, the root cause may sit in training data you did not collect, fine-tuning runs you did not perform, or model behaviour you cannot inspect. The investigation cannot conclude with a classical root cause for every incident.

The right discipline is to distinguish between contributing factorsyou can identify and address, and the terminal root causewhich may be inaccessible. A prompt injection incident, for example, may have a terminal root cause in “the model is susceptible to certain phrasings of override instructions” — which you cannot fix because you do not control the model. But it has contributing factors you can address: the untrusted content reached the prompt without sanitisation; the agent had too broad a tool surface; the output was not validated. The playbook should require identification of contributing factors and acknowledge when the terminal root cause is inaccessible — rather than treat an inaccessible root cause as an open incident.

The detection signals for AI incidents are mostly different from the ones your monitoring is currently watching for. A standard SOC is set up to detect anomalies in infrastructure metrics — latency, error rate, login failures, network volume. None of those will catch a hallucination, a prompt injection success, or a data leakage in output.

The signals worth instrumenting for AI:

• Output anomalies. Sudden changes in output length, frequency of refusal responses, frequency of safety filter triggers, rate of tool invocation. A shift in any of these can indicate a behavioural problem before it surfaces as a user complaint.
• User reports. User feedback is often the first signal for hallucination harm and bias incidents. The reporting channel should be one click from the AI output, and the volume should be a first-class metric. Spikes in reports are signals.
• Cost spikes. Token usage that rises without a corresponding rise in legitimate usage is a signal of abuse, runaway loops, or denial-of-service. Watch the cost per user, the cost per request, and the rate of change over short windows.
• Behavioural drift. The same evaluation set, run regularly against the live system, should produce roughly the same results. When eval results shift materially, something has changed — the model version, a prompt, a retrieval source, an upstream configuration. Behavioural drift detection requires investment in the eval set itself.
• Audit log anomalies. Patterns in tool calls that deviate from baseline — same tool called from many sessions in sequence, unusual parameter values, off-hours invocation patterns. These are the agentic equivalent of intrusion detection signals.
• Vendor advisories.The vendor disclosing a model change, a security incident, or a sub-processor change is itself a detection signal. Subscribe to the vendor's security and changelog feeds and treat them as inputs to your monitoring.

The user-report channel deserves additional emphasis. For two of the incident categories — hallucination harm and bias — the user is almost always the first detector. A reporting flow that is buried, slow, or requires re-authentication will under-detect these categories. A flow that is one click, sends to a queue with named ownership, and triggers a response SLA is the difference between catching the incident at first occurrence versus at the hundredth.

AI incidents have a set of containment options that do not exist for standard IT incidents. The playbook should pre-define which option applies to which incident type, with the decision threshold made explicit.

The most important pre-decision is the kill-switch threshold. There should be a documented criterion that, when met, triggers a feature-disable decision without waiting for further investigation. Common criteria: confirmed data leakage of regulated data; confirmed unauthorised actions taken under any user identity; confirmed prompt injection succeeding with measurable user impact. When the criterion is met, the AI feature goes off while investigation continues. The kill-switch should be code-level — a feature flag with a clear default-off path, not a configuration setting that requires a deployment to change.

Evidence preservation is where AI incident response most diverges from IT incident response. The window is short, the sources are not all under your control, and the formats are not all standard. The first action upon detection — before containment, before triage — should be evidence capture, because every minute of delay reduces what you can recover.

The evidence checklist for an AI incident:

• Snapshot all logs in the affected time window.Application logs, tool call logs, model invocation logs, retrieval logs, audit logs. Copy them out of your normal log infrastructure into an incident archive. Logs that are normally retained for 30 days are often the only forensic source you have, and incident investigation can take longer than 30 days.
• Capture the model version and configuration. Which model? Which version? Which provider deployment? Which fine-tuning adapter, if any? What were the temperature, top-p, max-tokens, and other generation parameters? These can change without notice; capture them while you still know what they were.
• Capture the system prompt and any prompt templates.The exact text in use at the time of the incident. If prompts are version-controlled, record the git SHA. If not, save the literal text. Future prompt edits will erase the evidence of what was in use during the incident.
• Preserve the involved user inputs and outputs. The exact prompts and the exact outputs involved in the incident, with their timestamps and user attribution. If the user can edit or delete the conversation, copy it out of the user-facing system into the incident archive.
• Document user-facing impact. How many users were affected? What did they see? What did they do with what they saw? Was there secondary action — did the harmful output reach an external recipient, a customer system, a regulator?
• Record what the vendor is providing. If the vendor is involved, document their version of events, their timeline, the artefacts they have provided, and any commitments they have made about further disclosure.

The evidence archive should be its own storage location — not a folder in the application's log system, which may be subject to the same retention policy that is closing the window on the incident. Mature organisations have a dedicated incident evidence vault with long retention, segregated from the systems being investigated, with chain-of- custody discipline.

When the incident originates on the vendor side, the response shape is different. You are not the investigator; you are the affected party. Your timing, your communications, and your remediation are all partially governed by the vendor's decisions. The playbook for vendor incidents needs separate handling.

The most common pattern: the vendor discloses an incident affecting their service. Your AI feature has been running on that service, so the vendor's incident is now also your incident — at a minimum, you need to determine whether your users were affected. You may need to issue your own notification regardless of what the vendor has chosen to disclose publicly.

The contractual posture matters enormously here. The vendor's contract should commit them to specific notification windows for security incidents that affect customer data, specific notification windows for model changes that materially alter behaviour, and specific post-incident artefacts you are entitled to receive. Without those commitments, you are dependent on the vendor's discretion — and their discretion is governed by their own legal and PR teams, not your timeline.

The questions to have answered before a vendor-AI incident, not during one:

• Within how many hours of detection will the vendor notify us of a security incident affecting our data?
• What is the threshold for vendor-side incidents that trigger notification — only confirmed compromises, or also incidents under investigation?
• What artefacts will the vendor provide post-incident — root cause analysis, scope of impact, remediation summary?
• Will the vendor commit to notifying us of model version changes that materially alter behaviour on our workload?
• Can we get a named point of contact for incident escalation, with response-time commitments?

These belong in the procurement conversation, not the incident-response conversation. A vendor that cannot commit to specific notification windows in advance is a vendor whose incidents will surprise you when they happen, and the playbook will be running on whatever scraps of information the vendor chooses to share.

The post-incident phase is where the AI playbook produces the artefacts that feed back into the governance cycle. The standard IT post-incident review produces an incident report and possibly a runbook update. The AI incident review produces more: a set of updates to the security model and governance documents that the AI committee needs to see.

The artefacts that should be produced from every AI incident:

• Incident report. Timeline, detection path, impact scope, contributing factors, terminal root cause (or explicit statement that it is inaccessible), remediation actions taken, evidence references. The report should be readable by someone who was not in the room during the incident.
• Control gap identified — or accepted residual risk.Every incident reveals either a missing control (which becomes a new control in the inventory, with an owner and a gate) or a residual risk that the organisation now formally accepts. The binary is important: an incident with neither outcome means the review did not extract its lesson.
• Updated risk register. The incident is itself a data point for the risk register. If the risk had been identified previously, its likelihood and impact estimates should be updated. If the risk was not previously registered, it now is.
• Updated re-assessment triggers. Did the incident reveal a class of change that should have triggered a re-review and did not? The trigger set should be updated to catch the next instance.
• Communication to affected users. If the incident affected users, they have a right to know. The communication should be specific about what happened, what was affected, what was done to contain it, and what users should do. Generic post-mortems are not acceptable for incidents involving user-facing harm.
• Regulator notification, if required. High-risk AI Act systems have notification obligations to relevant authorities. GDPR breach notification obligations apply if personal data was affected. Determine which regimes apply, with what timeline, before the incident — not during it.

The link to the broader governance system is the point. AI incidents are not standalone events to be triaged and forgotten. They are evidence about the security model. A clean post-incident artefact stream means the next review of the system in question — by the AI committee, by an auditor, by a regulator — has access to a documented learning trail. A weak stream means each incident is treated as new, and the same issues recur.

The point of the post-incident phase is not the report. The point is the update to the security model that comes out of the report. An incident that does not change a control inventory, a risk register, or a re-assessment trigger has not been learned from.

For the foundational context on what those structured artefacts look like, see the AI Risk Disposition piece and the disposition-for-regulator-review piece. The artefacts produced from an incident plug directly into both — the incident report becomes evidence for the next disposition, and the control gaps become new entries in the controls table.

Most organisations do not have an AI incident response playbook today. They have an IT playbook and a hope that AI incidents will look enough like IT incidents to be handled by it. The first AI incident teaches them otherwise. The cheap thing to do is to write the playbook before that first incident — when there is no pressure, no panic, and time to think about evidence preservation, kill-switch design, and vendor commitments while there is still time to put them in place.