The AI Incident Response Playbook Nobody Has Written
The EU AI Act gives enterprises 2 days to report a serious AI incident. Three frameworks shipped in the last 12 months. This piece merges them into a single playbook with roles, timelines, and triggers.
The AI Incident Response Playbook Nobody Has Written
The EU AI Act's Article 73 gives enterprises 2 days to report a serious AI incident that disrupts critical infrastructure. Three enterprise-grade incident response frameworks shipped in the last 12 months. CoSAI's AI Incident Response Framework. OWASP's GenAI IR Guide. NIST's IR 8596. Adoption is near zero.
The August 2, 2026 deadline is four days away. The frameworks exist. The AI incident response playbook that merges them into roles, timelines, and triggers does not. This piece builds it.
Subscribe to the weekly brief so you can have the frameworks and governance questions your AI roadmap needs, delivered every week.
Key Takeaways
- EU AI Act Article 73 imposes a 2-day reporting window starting August 2
- CoSAI, OWASP, and NIST converge on one five-phase lifecycle
- Microsoft and MAST identify 14+ agent failure modes to plan for
- Every playbook needs a named AI Incident Commander before day one
- Silent model drift can erase 30% accuracy before anyone notices
Contents
- What Counts as an AI Incident
- The Lifecycle Every Framework Agrees On
- Agent Failure Modes Your AI Incident Response Playbook Must Cover
- Who Owns What When an AI Agent Fails
- The EU AI Act Reporting Triggers and Timelines
- Detection Before the Clock Starts
- FAQ
What Counts as an AI Incident
Your existing cyber incident playbook covers ransomware, phishing, and data exfiltration. It does not cover an autonomous agent that rewrites its own tool calls, a model whose accuracy degrades silently for weeks, or a chatbot that leaks PII through a crafted prompt injection.
OWASP's GenAI Incident Response Guide defines the boundary clearly:
"An AI incident is any event where the development, use, or malfunction of an AI system directly or indirectly leads to specific harms."
That definition is deliberately broad. It covers output-level failures (hallucinated advice that triggers a compliance breach), system-level failures (a sandbox escape that reaches the corporate network), and drift-level failures (a scoring model that shifts approval rates by 12 points over a quarter without an alert).
The key distinction: a cyber incident targets your systems from outside. An AI incident often originates from inside your own model, running with your own permissions. The containment logic, escalation paths, and reporting obligations are all different.
The recent sandbox escape analysis showed what happens when this boundary is undefined. The team that discovers the anomaly does not know whether to file a security ticket or invoke a dedicated AI response path. That ambiguity costs hours. Under Article 73, those hours count.
The Lifecycle Every Framework Agrees On
The good news: you do not need to pick one framework. CoSAI, OWASP, and NIST IR 8596 all anchor on the same backbone, NIST SP 800-61r3's incident response lifecycle, and extend it with AI-specific guidance.
The merged lifecycle has five phases:
- Preparation. Inventory your AI assets (models, agents, data pipelines). Define trigger criteria. Assign roles. Run tabletop exercises.
- Detection and Analysis. Monitoring catches the anomaly. Triage determines: is this an AI incident or a standard infra issue? The answer dictates the response path.
- Containment. Isolate the affected model or agent. For agentic systems, this means revoking tool-call permissions and freezing the agent's execution context, not just pulling network access.
- Eradication and Recovery. Root-cause the failure. Retrain, rollback, or replace the model. Validate the fix against the original failure mode before restoring production traffic.
- Post-Incident Activity. Document lessons. Update the playbook. Feed the failure mode into your monitoring rules so detection catches it earlier next time.
The CoSAI framework's March 2026 revision adds the most detailed AI-specific guidance at each phase, including the regulatory notification checkpoints that Article 73 requires. If your organization already runs NIST 800-61 for cyber, you are not starting from zero. You are adding an AI chapter to an existing book. The enterprise agent control plane maps to the same lifecycle at the infrastructure layer.
Agent Failure Modes Your AI Incident Response Playbook Must Cover
A playbook without scenario cards is a policy document, not a response tool. I used to believe a strong model was most of the battle. Production taught me otherwise. Your team needs to know what can go wrong, specifically, before it happens.
Two taxonomies published in the last year cover the landscape. Microsoft's June 2026 update extends its agentic AI failure taxonomy after a year of red-teaming. It adds MCP/plugin abuse, session context contamination, inter-agent trust escalation, and agentic supply chain compromise to the existing set of prompt injection, data poisoning, and model theft.
The MAST multi-agent failure taxonomy takes a structural approach, organizing 14 failure modes into three categories:
| Category | What it covers | Example failure modes |
|---|---|---|
| Specification and system design | Failures baked into the agent's goals, constraints, or architecture | Misaligned objectives, insufficient constraints, reward hacking |
| Inter-agent misalignment | Failures in how agents coordinate, communicate, or defer | Conflicting sub-goals, deceptive communication, trust escalation between agents |
| Verification and termination | Failures in knowing when to stop, escalate, or hand off to a human | Unstoppable loops, insufficient human oversight, verification spoofing |
Each category maps to a different containment strategy. A specification failure means the model itself needs correction. An inter-agent misalignment failure means the orchestration layer is broken. A termination failure means your kill switches are not working.
Pillar Security's "Week of Sandbox Escapes" documented what happens when containment layers are not independently enforced: a successful inner escape reaches the corporate network and control plane. Your playbook should have a scenario card for each of the three MAST categories, with the specific containment actions your infrastructure supports.
When agents succeed only 56.6% of the time in production, these failure modes are not edge cases. They are operating conditions.
Who Owns What When an AI Agent Fails
The CoSAI framework specifies the roles your AI incident response team needs. The structure extends your existing CSIRT, it does not replace it.
- AI Incident Commander. Owns the response from detection through post-mortem. This is not the CISO (who is busy with the broader security posture) and not the ML team lead (who is too close to the model). It is a dedicated role with pre-negotiated authority to freeze model deployments and redirect engineering resources.
- Model Owners. The engineers who built and maintain the affected model. They diagnose root cause and execute the fix.
- Data Protection and Privacy. Engaged immediately when the incident involves personal data, training data contamination, or output that may violate data-subject rights.
- Legal and Compliance. Owns the regulatory notification. Under Article 73, the clock starts at detection. Legal needs to be in the room at triage, not called in at hour 36.
The CSA Agentic AI NIST RMF Profile adds a mapping layer: each role maps to the NIST AI RMF's Govern, Map, Measure, and Manage functions, so your compliance documentation stays aligned.
Get the full analysis. The frameworks, the deadlines, and the governance questions behind your AI roadmap land in one weekly brief. Subscribe so you can have the playbook-level detail before the next deadline hits.
If your RACI matrix does not have an AI Incident Commander, your first real AI incident will create the role under fire. The person who fills it will have no playbook, no pre-negotiated authority, and a 2-day reporting clock already running.
The board's first question should be: who is the AI Incident Commander?
The EU AI Act Reporting Triggers and Timelines
Article 73 of the EU AI Act creates a tiered reporting system for serious incidents involving high-risk AI systems. The deadlines are hard. The European Commission published a draft reporting template with these rules becoming applicable from August 2, 2026.
| Trigger condition | Reporting window | What to file |
|---|---|---|
| Serious or irreversible disruption of critical infrastructure | 2 days | Initial notification with incident description, affected systems, containment status |
| Death or serious health harm may have been caused | 10 days | Detailed report including root cause analysis and corrective measures taken |
| Other serious incidents involving high-risk AI (fundamental rights, property, environment) | 15 days | Full incident report with root cause, impact assessment, and preventive measures |
The definition of "serious incident" is specific: an incident or malfunction that directly or indirectly results in death, serious harm, critical infrastructure disruption, fundamental-rights violations, or serious property or environmental damage.
Two details matter for your playbook. First, the clock starts at detection, not at root-cause determination. If monitoring catches an anomaly on Monday and the team confirms it Wednesday, the clock started Monday. Second, GPAI model providers have separate obligations. If your incident involves a third-party foundation model, both you and the provider may have reporting duties.
Your playbook needs a decision tree at the triage phase: does this incident meet the Article 73 threshold? If yes, which tier? That decision determines whether Legal has 2 days or 15 days to file. The broader August 2026 compliance landscape extends well beyond incident reporting.
Detection Before the Clock Starts
The reporting clock starts at detection. That makes your mean time to detect (MTTD) the most consequential metric in the entire playbook. If your team takes 30 days to notice a model has drifted, you have already consumed your entire response window before anyone knew there was a problem.
A data-science consultancy cited in industry monitoring guidance reports that unmonitored AI models can lose up to approximately 30% of predictive accuracy within six months of deployment, even on ostensibly stable datasets. The degradation is silent. No outage alert fires. The model simply gets worse until someone checks.
This is why enterprise AI observability practice emphasizes continuous monitoring over periodic audits:
- Output distribution drift. Track the statistical distribution of model outputs over time. A shift in the distribution often precedes a visible accuracy drop.
- Canary tests. Run a known-good input set through the model on a schedule. When canary accuracy drops below threshold, the alert fires before users notice.
- Confidence score anomalies. If the model's own confidence scores cluster differently than during validation, something has changed in the input distribution or the model weights.
- Automated regression alerts. Compare production performance against your validation baseline daily, not quarterly.
NVIDIA's sandboxing guidance adds the infrastructure layer: Firecracker microVMs for maximum isolation, gVisor or Kata Containers for GPU-capable container isolation, and cgroup-based resource limits (cpu.max, memory.max, pids.max) to cap blast radius.
The pattern is the same across detection and containment: instrument the system before the incident, not during it. Honestly, this is the part that bothers me most. The frameworks are published. The tooling exists. The drift just happens quietly while everyone is watching the dashboards that were built for a different kind of failure. RSAC 2026 surfaced the same ownership question at the detection layer.
FAQ
What is an AI incident response playbook?
A structured plan that extends your existing cyber incident response process with AI-specific triggers, failure modes, roles, and regulatory reporting steps. It tells your team exactly what to do when an AI system causes harm, who owns each step, and which regulatory deadlines apply.
What are the EU AI Act incident reporting deadlines?
Article 73 sets three tiers: 2 days for serious or irreversible disruption of critical infrastructure, 10 days where death or serious health harm may be involved, and 15 days for other serious incidents involving high-risk AI systems. These deadlines start at detection, not at root-cause confirmation.
How do you detect an AI model failure in production?
Through continuous monitoring: track output distribution drift, run canary tests on a known-good input set, watch for anomalies in model confidence scores, and compare production performance against your validation baseline daily. Silent drift is the most dangerous failure mode because no outage alert fires.
What roles belong on an AI incident response team?
At minimum: an AI Incident Commander (dedicated role with authority to freeze deployments), model owners (the engineers who built the system), data protection and privacy lead, and legal and compliance (who own regulatory notification under Article 73). This extends, not replaces, your existing CSIRT.
How does NIST AI RMF handle incident response?
NIST IR 8596 maps AI incident handling to the Cybersecurity Framework's Respond and Recover functions, linking to SP 800-61r3 for the lifecycle. The CSA Agentic AI profile further maps agentic controls to the RMF's Govern, Map, Measure, and Manage functions.
What to Do This Week
The three frameworks converge. The deadline is live. The playbook void is a choice, not a constraint.
Three actions before August 2:
- Name your AI Incident Commander. Not the CISO. Not the ML lead. A dedicated role with pre-negotiated authority.
- Map the three reporting tiers to your AI asset inventory. Which of your models are high-risk under the EU AI Act? Which outputs could trigger the 2-day window?
- Run one tabletop exercise. Pick a scenario from the MAST taxonomy (an inter-agent trust escalation is a good first drill), walk through detection, containment, and notification. Time it. If triage alone takes longer than two days, you know the problem.
The frameworks are published. The template is mapped. The role is defined. What remains is execution.
Subscribe to the weekly brief so you can get the AI governance frameworks, sourced data, and practitioner playbooks that land before the next deadline. Read the full sandbox escape analysis for the incident that exposed this void.
