Quick answer: an AI incident response plan needs a severity tier assigned within the first hour, a named decision-maker who can authorize shutdown, and — for high-risk systems affecting the EU — regulatory notification within 15 business days under the EU AI Act. Most organizations don’t have this written down until they’re already living through the first incident.
Why AI Incidents Need a Different Playbook Than Security Incidents
Traditional incident response assumes a clear binary: the system is either compromised or it isn’t, and containment means isolating it. AI incidents are messier. A model can be “working as designed” and still be actively causing harm — producing biased credit decisions, hallucinating customer-facing information, or an agent taking an action nobody authorized — without triggering any traditional security alert at all. Nothing was breached. Nothing crashed. The system just did something wrong, at scale, and kept doing it until a human noticed. That’s why an AI incident response plan needs its own document, not a repurposed section of your existing security IR plan. It answers a different first question: not “were we attacked,” but “is this system still allowed to be making decisions right now.”
Severity Tiers: Classify Before You React
| Tier | Definition | Response time | Who’s notified |
|---|---|---|---|
| Tier 1 — Near miss | System approached a failure condition but a human caught it before any action was taken or output used | Logged within 48 hours | System owner |
| Tier 2 — Contained failure | Incorrect output or action occurred but was limited in scope and reversible | Escalated within 4 hours | System owner, governance lead |
| Tier 3 — Customer-facing failure | Incorrect output or action reached a customer, employee, or the public and caused measurable harm or exposure | Escalated within 1 hour | Named executive owner, legal, comms |
| Tier 4 — Regulatory/safety event | Failure affects a regulated decision (credit, hiring, health, safety) or triggers a legal notification obligation | Escalated immediately | Executive owner, legal, compliance, board if material |
Near-miss logging matters more than most teams assume. A model that produced a confidently wrong answer a human happened to catch is the same failure mode as a Tier 3 incident, minus luck. Organizations that log near misses systematically catch the pattern before it reaches a customer; organizations that only track confirmed incidents find out about the pattern the first time luck runs out.
The First 24 Hours
- Hour 0–1: Classify and contain. Assign a severity tier. For Tier 3 or 4, the named “who intervenes” owner from your governance register (see the Decision-Rights Audit) executes the shutdown or restriction — this is the moment that tests whether your shutdown procedure actually works, not just whether it’s documented.
- Hour 1–4: Establish scope. How many decisions, customers, or records were affected? This determines whether the incident stays internal or requires customer or regulatory notification, and it’s the number legal and comms will ask for first.
- Hour 4–12: Notify internally, decide externally. The named “who answers” owner briefs legal and executive leadership. A decision gets made on customer notification and, if applicable, regulatory notification timing.
- Hour 12–24: Draft the record. Document what happened, what data or decisions were affected, and what containment action was taken — this record is what you’ll need for both a regulator and your own post-incident review, and it’s far more accurate written same-day than reconstructed a week later.
The EU AI Act Changed the Clock This Year
Under Article 62 of the EU AI Act, which became effective for high-risk systems in August 2026, providers must notify the relevant national authority of a serious incident within 15 business days. “Serious” covers incidents causing death, serious injury, significant property damage, or violations of fundamental rights — a bar that a poorly governed AI system making consequential decisions at scale can clear faster than most teams expect. Fifteen business days sounds generous until you consider that most organizations, per Deloitte’s 2026 survey, don’t yet have a tested way to even confirm a system has been shut down, let alone produce a documented incident record inside three weeks. This is precisely why the severity classification has to happen in the first hour, not the first week. A Tier 4 event’s regulatory clock is running whether or not your organization has noticed it yet.
Where Incidents Usually Originate
Two categories account for a disproportionate share of AI incidents in practice: systems operating exactly as designed but on a decision boundary nobody reviewed carefully enough, and AI tools that were never formally governed in the first place. The second category is worth naming directly — if the system involved in an incident turns out to be an unsanctioned tool an employee adopted independently, you’re dealing with a shadow AI problem as much as an incident response problem. Our shadow AI guide covers how to find those tools before they’re the subject of an incident report instead of after.
Building the Plan Before You Need It
The plan above only works if the severity tiers, response times, and named owners are decided in advance and tied to your existing governance register — not improvised during the incident itself. If you haven’t built that register yet, start with the AI governance framework template; the “who intervenes” and “who answers” fields in that register are exactly the names this incident response plan calls on in hour one.
Also Read: BrandRank.AI Normalization Transformation Rules: The Complete 2026 Guide
FAQs
Do we need a separate AI incident response plan if we already have a cybersecurity IR plan?
Yes, at least as an addendum. AI failures often don’t involve a breach or intrusion at all — the system can be functioning exactly as built and still be the incident — so a plan built around detecting compromise won’t trigger on this failure mode.
What counts as a “serious” AI incident under the EU AI Act?
For high-risk systems, Article 62 defines serious incidents as those causing death, serious injury, significant property or environmental damage, or a violation of fundamental rights obligations — providers must notify the relevant national authority within 15 business days of becoming aware.
Should near misses really get logged the same as real incidents?
Yes, at a lighter tier. A near miss is the cheapest data you’ll ever get about a failure mode — it shows you the pattern before it reaches a customer, which is the entire point of catching it early.
