AI incident response plan

Your chatbot invents a returns policy, your scoring system denies credit because of an undetected bias, or a prompt injection extracts customer data. Do you have a plan? We explain how to build an AI-specific incident plan with six phases, key roles, and an operational runbook.

IT incident plans have existed for decades. Every reasonably serious company has a procedure for responding to a server outage, a security breach, or data loss. But AI incidents are different.

An AI system can fail in ways that no traditional incident plan covers: hallucinations that generate false information in customer communications, bias that systematically discriminates against a group without anyone noticing, prompt injections that extract confidential data, or gradual performance degradation that goes unnoticed for weeks.

The AI Act explicitly requires deployers of high-risk AI systems to have incident management procedures. But even for limited- or minimal-risk systems, an AI incident plan is not a luxury: it is an operational necessity. Because when your AI fails —and at some point it will— the difference between a minor incident and a crisis lies in the speed and quality of your response.

In this article, we explain the types of AI-specific incidents, the six phases of a response plan, the roles you need to define, and how to build an operational runbook that your team can execute when things fail.

Types of AI incidents (and why they are different)

An AI incident is not the same as a classic IT incident. The fundamental difference is that many AI failures are silent, progressive, and difficult to detect with traditional monitoring tools.

Privacy/PII: Unauthorized access to personal data through the AI system, data leakage in model responses, or use that is incompatible with the stated purpose. Example: a chatbot including one customer’s data in its response to another.
Security: Prompt injection (manipulating the model through malicious inputs), data exfiltration, an outage of the AI provider’s API, or compromised credentials for accessing the model.
Ethical/Content: Systematic bias detected in model decisions, generation of offensive content or disinformation, or reputational damage caused by inappropriate output.
Operational: Critical hallucinations (false data in external communications), mass batch errors, gradual degradation of model quality, or service unavailability.

Each type of incident requires a different response. A privacy incident activates legal obligations (notification to the authority within 72 hours under the GDPR). An ethical incident may require immediate system deactivation. An operational incident may be resolved by rolling back to a previous version.

Severity levels

High: Impact on customers, personal data compromised, legal non-compliance, or reputational damage. Immediate action: containment within 2 hours.
Medium: Significant internal impact, substantial quality degradation, or risk of escalation if no action is taken. Action: classification and containment within 8 hours.
Low: Limited incident, no external impact, detected during a pilot or in a controlled environment. Action: record and correct in the next cycle.

The greatest risk of AI incidents is not that they happen. It is that nobody finds out until it is too late.

The six phases of an AI incident response plan

Detection. The first step is knowing that something is wrong. For AI systems, this requires automatic alerts (latency, error rates, anomalous access), monitoring of quality metrics (hallucination rate, faithfulness if you use RAG, bias metrics), a reporting channel for internal and external users (email, Teams, ticket), and active logging of all interactions with a minimum retention period of 90 days.
Containment. Once the incident is detected, the priority is to limit the damage. Typical actions include disabling the AI system integration (degraded mode), limiting its scope (restricting it to internal users, blocking public channels), activating human fallback (redirecting queries to agents), and preserving evidence (logs, screenshots, and the configuration at the time of the incident).
Notification. Legal obligations may be activated depending on the type of incident. For privacy incidents involving compromised personal data: notify the data protection authority within 72 hours (GDPR), assess the obligation to notify affected individuals, and inform the DPO and the AI committee. For high-risk AI Act incidents: record the incident in the technical documentation and communicate it to the interested parties.
Eradication. Identify and eliminate the root cause. This may involve correcting the system prompt, updating the knowledge base (if using RAG), retraining or reconfiguring the model, patching a security vulnerability, or modifying the system’s guardrails.
Recovery. Restore the service in a controlled way: verify system integrity before reactivation, deploy gradually (internal first, external later), monitor intensively during the first 24–48 hours after restoration, and confirm that quality metrics return to the thresholds defined in the technical documentation.
Lessons learned. The most overlooked and most valuable phase. It includes an incident report (root cause, impact, response time, and measures), a post-mortem with the teams involved, an update of preventive controls, and a review of the incident plan itself if shortcomings have been identified.

Traffic light: In the AI governance framework, a high-severity incident automatically activates the Red light (KILL) for that system. It is not reactivated until phases 4 and 5 are complete, and reactivation requires approval from the AI Steering Committee.

Key roles: who does what when AI fails

An incident plan without clear roles is a useless document. Define these responsibilities before you need them:

Product Owner (PO): Ultimately responsible for the system. Accountable (A) in the RACI matrix. Approves containment and restoration. Communicates with business stakeholders.
Security/CISO: Responsible (R) for security and privacy incidents. Leads containment, manages forensics, and coordinates technical notification.
IT/Platform (on-call): Responsible (R) for continuity and availability. Executes degraded mode, manages rollback, and monitors recovery.
Legal/DPO: Consulted (C). Assesses notification obligations (72 hours under GDPR, AI Act), manages legal communications, and documents them for the technical documentation.
Data Owner/Steward: Consulted (C). Verifies data integrity and assesses whether the root cause lies in the training data or the knowledge base.

The runbook: from theory to executable action

The incident plan defines what and who. The runbook defines how. It is the operational document that your on-call team can follow step by step at 3 a.m. when the alert sounds.

An AI incident runbook must include:

Covered cases: An explicit list of scenarios (API outage, RAG index degradation, credential leak, prompt injection, critical hallucination, detected bias).
Step-by-step procedure: For each scenario, the concrete steps: which command to run, which system to disable, whom to call, and which channel to use.
Escalation criteria: When to move from low to medium severity, and from medium to high. Which thresholds trigger escalation. Who has the authority to escalate.
Evidence to capture: Log excerpts, screenshots, configuration at the time, tickets, and communications. Everything with a timestamp.
Emergency contacts: Names, email addresses, and phone numbers. Not only internal contacts: also the AI provider’s contact, the DPO, and the supervisory authority’s contact if necessary.

The runbook must be practical, not theoretical. If your team cannot follow it without needing additional explanations, it is not finished. The best test is a drill. Present a fictional scenario and measure how long your team takes to follow the runbook. If it takes longer than expected, revise the document.

Regulatory obligations: AI Act, GDPR, and NIS2

An AI incident plan is not just good practice. Three European regulations require or imply it:

AI Act: Deployers of high-risk systems must notify serious incidents to the authorities and document all incidents in the technical documentation. Article 26 establishes post-market monitoring obligations that include incident management.
GDPR: If an AI incident compromises personal data, the obligation is triggered to notify the data protection authority within 72 hours (Article 33) and, if there is a high risk to the data subjects, to notify the affected individuals (Article 34).
NIS2: For essential and important entities, the NIS2 Directive requires security incident response plans with notification within 24 hours and a detailed report within 72 hours. If your AI system is part of critical infrastructure, NIS2 applies.

Advice: Integrate your AI incident plan with your existing security incident plan. You do not need two separate plans: you need one unified plan that covers AI-specific scenarios with the same SLAs and escalation chain.

Drills: proof that your plan works

An incident plan that has not been tested is a theory, not a plan. Drills are the only way to verify that your team knows what to do, that contacts are up to date, that procedures are executable, and that response times are realistic.

We recommend at least two drills per year:

Critical hallucination drill: Scenario: your ecommerce chatbot has been generating false information about returns policies for the last four hours. How long does your team take to detect, contain, and communicate it?
Data breach drill: Scenario: a prompt injection is found to have caused the model to expose customer data in its responses. Is the GDPR notification triggered within 72 hours? Is the evidence preserved?

After each drill, document the findings and update the plan. Drills are not an exam: they are an opportunity to improve.

The incident plan within the AI governance framework

The incident plan is not an isolated document. It integrates into your organization’s governance ecosystem:

Technical documentation: Section 14 of the technical documentation records all incidents and post-mortems. Each closed incident adds evidence and lessons to the documentation.
Gate system: At Gate 2 (pre-deployment), verify that the incident plan is defined and the runbook is executable. Without an incident plan, the gate does not open.
GO/FIX/KILL traffic light: A high-severity incident automatically activates Red (KILL). Reactivation requires completing phases 4–5 and approval from the AI Steering Committee.
FRIA: If an incident reveals a risk not identified in the FRIA, it triggers a review of the impact assessment. Incidents trigger recategorization.
AI Lite Policy: The principle of reversibility is embodied in the incident plan’s degraded mode. The principle of observability is embodied in logging and detection.

Conclusion: prepare the response before you need it

An AI incident plan is one of those documents you hope never to need. But when you do need it, you are grateful that you prepared it. The difference between a company that manages an AI incident professionally and one that improvises lies in prior preparation.

You do not need a perfect plan. You need a plan that exists, that your team knows, that has been tested at least once, and that is updated when things change. With six phases, clear roles, and an executable runbook, you have the foundation.

If you need help designing your AI incident plan, building the operational runbook, or running drills with your team, Impulsa3 can support you throughout the process.

impulsa3.com · Digital Transformation and AI for SMEs and ecommerce · servicios@impulsa3.com

The operational response is completed with human oversight in AI.