An AI incident response plan sets out how an organisation detects, rates, contains, investigates and reports failures of its AI systems: harmful or wrong output, data exposure, agents acting beyond their permissions, prompt injection and model drift. The template below gives severity levels, roles, containment options for models and agents, a legal notification matrix, an incident report form and a worked example.
What counts as an AI incident
Classic incident plans start from a security breach. Many AI incidents are not breaches at all: a correct login receives a confident but false answer, a retrieval index shows a document to the wrong team, or an agent sends an email nobody approved. The OECD separates an AI incident, where harm has occurred, from an AI hazard, where harm could plausibly occur; record both, because hazards are cheaper to fix.
The EU AI Act uses a narrower term. Under Article 3(49), a serious incident is one that directly or indirectly leads to death or serious harm to health, a serious and irreversible disruption of critical infrastructure, an infringement of Union-law obligations that protect fundamental rights, or serious harm to property or the environment.
| Incident type | Example | Usual first lever |
|---|---|---|
| Harmful or false output | Assistant invents a policy clause that reaches a customer | Pull the output, add a review step |
| Data exposure | Retrieval returns HR files to staff without access | Withdraw the index, fix permissions |
| Prompt injection | Instructions hidden in an email make an agent forward files | Disable the tool, quarantine the source |
| Excessive agency | Agent changes records outside its task | Revoke the tool grant, require approval |
| Bias or discrimination | Ranking model scores one group consistently lower | Suspend automated use, revert to manual |
| Drift or regression | New model version drops answer accuracy | Roll back the version |
| Supplier change | Vendor swaps the underlying model without notice | Pin a version or switch route |
AI incident severity levels
| Level | Criteria (any one is enough) | Respond within | Who is told | Suspension |
|---|---|---|---|---|
| Severity 1 | Harm to a person’s health, safety or fundamental rights; possible EU AI Act serious incident; large-scale or special-category data exposure; external publication of harmful output | 1 hour, around the clock | Committee chair, DPO, legal, executive sponsor | Incident commander suspends at once |
| Severity 2 | Confidential data seen by unauthorised people; agent acting outside its permissions; wrong output used in a decision about a person | 4 business hours | Governance lead, DPO, security | System owner decides within 4 hours |
| Severity 3 | Wrong or harmful output caught before use; failed control without exposure; repeated injection attempts | 1 business day | System owner, technical owner | Partial: disable the affected feature |
| Severity 4 | Quality drift within tolerance; near miss; single user complaint | Next review cycle | Technical owner | None |
Rate on the highest criterion that fits and re-rate as facts emerge. A level can go down after investigation, but the original rating stays in the record.
The AI incident response plan template
Attach the plan to your existing incident management policy so that security, privacy and IT teams use one queue. Replace the bracketed text and remove anything that does not apply.
1. Scope and definitions
1. SCOPE AND DEFINITIONS
1.1 This plan covers every AI system in the AI inventory, and
any AI use discovered outside it.
1.2 AI incident: an event in which an AI system causes harm, or
nearly does, to people, property, operations, data or legal
obligations. AI hazard: a condition that could plausibly
lead to one.
1.3 Serious incident: as defined in EU AI Act Art. 3(49).
1.4 Related: Incident Management Policy; Personal Data Breach
Procedure; AI Governance Policy; Business Continuity Plan.2. Roles
2. ROLES
2.1 Incident commander [on-call role]: runs the response,
sets severity, owns the timeline.
2.2 AI technical lead [technical owner of the system]: executes
containment, preserves evidence, leads root-cause work.
2.3 System owner: decides on business impact, customer contact
and restart.
2.4 Security: investigates attacks such as prompt injection,
credential misuse or poisoned data.
2.5 Data protection officer: decides whether a personal data
breach occurred and whether to notify.
2.6 Legal and compliance: decides on regulatory reports,
including EU AI Act Art. 73 and sector rules.
2.7 Communications: approves any statement to customers or the
public.
2.8 Suspension authority: the incident commander, the system
owner and the chair of the AI governance committee may each
suspend an AI system without further approval.3. Detection and reporting
3. DETECTION AND REPORTING
3.1 Sources: user reports, monitoring alerts on quality,
refusals, cost or latency thresholds, security alerts,
reviewer overrides, complaints, vendor notices.
3.2 Anyone can report to [queue / address / phone] at any
time. Reports are accepted without blame.
3.3 The first responder opens a record (Annex A), assigns a
provisional severity and pages the incident commander for
Severity 1 or 2.4. Containment
4. CONTAINMENT (choose the narrowest option that stops harm)
4.1 Disable a single tool or connector for the agent.
4.2 Switch the system to read-only or draft-only mode, so a
person must approve every action.
4.3 Roll back the model, system prompt or configuration to the
last approved version.
4.4 Withdraw or re-permission a retrieval index or data source.
4.5 Route traffic to an approved fallback model.
4.6 Suspend the system and show users the manual procedure.
4.7 Revoke credentials or tokens the system used.
Record the time and the person for every step.5. Evidence preservation
5. EVIDENCE
5.1 Before changing anything that is not containment, export
the logs for the affected period: prompts, retrieved
sources, tool calls, outputs, approvals, model and
configuration versions, user identities.
5.2 Store evidence in [restricted location] with a hash and
access record.
5.3 For a possible serious incident, do not alter the system
in a way that could affect later evaluation of the cause
before informing the competent authority (Art. 73(6)).6. Investigation, recovery and closure
6. INVESTIGATION, RECOVERY AND CLOSURE
6.1 Establish the root cause: model behaviour, data, retrieval
permissions, prompt or configuration, tool design, attack,
human process or supplier change.
6.2 Fix the cause, then re-run the acceptance tests in the
model card plus a test that reproduces the incident.
6.3 Restart only with system owner approval; for Severity 1,
with the committee chair's approval as well.
6.4 Watch the system closely for [14] days after restart.
6.5 Hold a blameless review within [10] business days for
Severity 1 and 2. Update the risk register, the model card
and this plan with what was learned.7. Notification matrix
| Duty | Applies when | Deadline | Owner |
|---|---|---|---|
| EU AI Act Art. 73, provider | Serious incident involving a high-risk AI system you provide | Immediately after a causal link is established or reasonably likely, at most 15 days; 10 days if a person died; 2 days for a widespread infringement or critical infrastructure disruption | Legal |
| EU AI Act Art. 26(5), deployer | You use a high-risk system and identify a serious incident | Inform the provider immediately, then importer or distributor and the market surveillance authority | System owner |
| GDPR Art. 33 | Personal data breach likely to result in risk to people | Supervisory authority without undue delay, where feasible within 72 hours | DPO |
| GDPR Art. 34 | High risk to people’s rights and freedoms | Affected people without undue delay | DPO |
| NIS2 Art. 23 | Significant incident at an essential or important entity | Early warning within 24 hours, notification within 72 hours, final report within one month | Security |
| Contracts | Customer, supplier or insurer terms | As the contract says | Legal |
Article 73 concerns high-risk AI systems, so for Annex III systems it bites in practice once those rules apply on 2 December 2027, the date set by the Digital Omnibus on AI, Regulation (EU) 2026/1744, which left the Article 73 deadlines as they were. The Commission published draft guidance and a draft reporting template for Article 73 on 26 September 2025. Financial entities should add their DORA major ICT incident reporting to the matrix. If you are unsure whether a system is high-risk, run it through the EU AI Act compliance checker now rather than during an incident.
AI incident report template
This is Annex A of the plan. One record per incident, opened by the first responder and completed by the incident commander.
ANNEX A: AI INCIDENT REPORT
Incident ID: [AI-INC-YYYY-NNN]
Opened by / at: [name] / [date, time, time zone]
AI system: [inventory ID, name, version]
System owner: [name] Technical owner: [name]
Severity: initial [1-4], final [1-4], reason
Type: [harmful output / data exposure /
prompt injection / excessive agency /
bias / drift / supplier change / other]
What happened: [plain description, 3-5 sentences]
People affected: [who, how many, any vulnerable groups]
Data involved: [classes, personal data yes/no]
Detected by: [user / monitor / reviewer / vendor]
Timeline: detected [ ] contained [ ] resolved [ ]
Containment taken: [steps from section 4, time, person]
Evidence stored at: [location, hash]
Root cause: [category and description]
Serious incident under EU AI Act Art. 3(49)? [no / yes / open]
Personal data breach? [no / yes; DPO decision date]
Notifications made: [authority, date, reference]
Corrective actions: [action, owner, due date]
Register entries: [risk IDs added or re-scored]
Closed by / at: [name] / [date]How to fill it in, and who owns it
The AI governance lead owns the plan and keeps it consistent with the AI governance policy, which sets the suspension authority and the duty to report to the committee. The security incident manager usually acts as incident commander, because the on-call rota already exists. Each technical owner adds a one-page annex per Tier 1 or Tier 2 system listing its containment levers, where its logs live and who can execute a rollback.
Staff reporting duties belong in the employee AI use rules, which should point to the same queue. Rehearse the plan twice a year with a tabletop exercise built on a realistic scenario, such as an injected instruction in a supplier invoice that an agent acts on. If the exercise shows that nobody owns the inventory or the audit trail, the AI readiness assessment scores those gaps alongside four other areas.
The editable DOCX version of this plan and the report form sits in the AI Governance Template Pack, together with the other five templates.
Worked example: an HR assistant shows salary data
The organisation and figures below are fictional.
| Time | Event | Plan section |
|---|---|---|
| Day 1, 09:12 | An employee reports that the HR policy assistant quoted a colleague’s salary band | 3.2 |
| 09:20 | First responder opens AI-INC-2026-014, provisional Severity 2: confidential personal data shown to an unauthorised person | 3.3 |
| 09:41 | Technical lead withdraws the compensation folder from the retrieval index; the assistant keeps answering policy questions | 4.4 |
| 10:05 | Logs for the previous 30 days exported and hashed | 5.1, 5.2 |
| 11:30 | Root cause found: a folder permission sync failed after a migration, so the index treated the folder as open to all staff | 6.1 |
| 14:00 | Logs show three users saw salary information; DPO assesses risk to those employees | 7 (GDPR) |
| Day 2 | DPO decides the breach is notifiable on the facts and notifies the supervisory authority within 72 hours; the three employees are informed | 7 (GDPR Art. 33) |
| Day 3 | Permission sync fixed, a test added that checks restricted folders before each re-index, folder restored | 6.2, 6.3 |
| Day 12 | Review: register risk R-11 re-scored, model card updated with the new test | 6.5 |
The assistant answers HR policy questions and makes no decisions on recruitment, promotion or termination, so it is not an Annex III employment system and Article 73 did not apply. The GDPR route did.
Agent-specific operations
Agents add authority to the picture: they hold credentials, call tools and chain steps, so containment has to remove authority before it removes the model. Our playbook for incidents involving private AI agents covers reconstructing an execution graph and preserving state in detail, and the agent governance and security handbook lists the tool-permission and approval controls that make section 4 possible. When an AI incident is also an IT outage, the IT incident coordination agent keeps the timeline and stakeholder updates current.
How VDF AI fits
Containment is only fast if the levers exist before the incident. In VDF AI, which runs on your own servers or in an air-gapped environment, administrators grant tools to roles through the MCP tool registry and can withdraw a grant, consequential agent actions can be held at a human approval gate, and agent configurations are versioned so a rollback restores the last approved state.
For evidence, each execution is written to an immutable audit record covering the user, agent, model version, retrieved sources, tool calls and response, which can be exported to your SIEM. VDF AI Router can keep a workload on approved local models, which gives section 4.5 a fallback route that never leaves your network. Investigation, decisions and any regulatory report stay with your teams.
Sources
- AI Act, Regulation (EU) 2024/1689, on EUR-Lex
- Digital Omnibus on AI, Regulation (EU) 2026/1744
- European Commission, draft guidance and reporting template for serious AI incidents (26 September 2025)
- GDPR, Regulation (EU) 2016/679
- NIS2, Directive (EU) 2022/2555
- NIST SP 800-61 Rev. 3, incident response recommendations (April 2025)
- NIST AI 600-1, Generative AI Profile
- OECD, Defining AI incidents and related terms
- CISA, JCDC AI Cybersecurity Collaboration Playbook (January 2025)
- NCSC and CISA, Guidelines for secure AI system development