The idea behind it
Most incident response plans were written for outages and security breaches. AI systems add incidents those plans do not describe: an answer that was wrong and someone acted on it, text hidden in an email that redirected an agent, a provider's model update that changed behavior overnight, or an agent loop that ran up a bill. OWASP lists prompt injection first among its risks for LLM applications, and distinguishes direct injection from indirect injection that arrives in outside content such as a web page or a file. The playbook adds these types to the plan you already run, with the same incident record, on-call and severity scale.
The AI-specific work is mostly evidence and notification. The facts that explain an AI incident live in places a standard plan does not list: the conversation, the output as delivered, the model version, the system prompt, the retrieved documents and the agent's tool calls with the credential each used. Some of them sit in vendor systems with short retention. Notification deadlines run from when the company became aware: 72 hours where feasible under GDPR Article 33, 24 and 72 hours under NIS2, and 15, 10 or 2 days for serious incidents with high-risk systems under the EU AI Act, whose high-risk rules apply from December 2, 2027 for Annex III systems.
What's inside
- Six incident types, each with what it looks like, the first containment step and the lead: wrong output acted on, sensitive data in prompts or outputs, prompt injection, an agent's wrong action, a model or vendor change, and a cost spike.
- Four severity levels with their criteria and response times, and a first-hour table of steps and owners.
- Nine roles with a name and backup for each, and a table of the evidence to keep: prompts, outputs, model version, configuration, agent actions, approvals, logs and billing.
- Communication to staff, affected users, the vendor, regulators and the press, with a first message to adapt.
- A notification table citing GDPR Articles 33 and 34, NIS2 Article 23 and EU AI Act Articles 73 and 26(5), checked against the Official Journal text, with the AI Act's high-risk dates after the Digital Omnibus.
- Post-incident review questions, and a 90-minute tabletop scenario with four injects on prompt injection at a fictional service desk agent.
Format: PDF (6 pages) and Word document.
A look inside
Pages 1 and 2 of 6 of the PDF. Select an image to enlarge it.
Who uses it
- CISOs and security operations leads, to extend the incident response plan to AI systems and agents.
- Owners of AI systems and agents, to know what to stop, what to preserve and what to roll back.
- Privacy leads, DPOs and legal counsel, to decide quickly whether a notification duty applies.
- Incident managers and IT leaders, to run the tabletop and test the plan before a real incident.
When to use it
- The company puts an AI assistant or agent into production for the first time.
- An agent gets write access to systems that affect customers, money or access rights.
- Staff report that an AI tool gave them another user's data, or that confidential data went into a tool not approved for it.
- A provider announces a model update or retirement for a model you depend on.
- The annual incident response exercise is due and has never covered AI.
How to use it
Fill in the names, contacts and thresholds, link it from your incident response plan, and run the tabletop with the people it names.
- Fill in the brackets: the systems in scope, the names and backups for each role, contacts and severity thresholds.
- Link the playbook from your incident response plan so AI incidents use the same record, on-call and scale.
- Check with each AI system's owner that the evidence in section 6 is logged, where, and for how long.
- Have legal and privacy confirm the notification table for your countries and sectors, and add your own rows.
- Run the 90-minute tabletop with the people named in the roles table.
- Fix what the tabletop exposed, and review the playbook every six months and after every SEV1 or SEV2.
You leave with: An AI incident playbook with named roles, severity levels, a first-hour checklist, an evidence list, cited notification duties and a tested tabletop scenario.
Where it goes wrong
- Restarting or fixing the system before copying the logs, prompts and configuration that explain what happened.
- Not recording when the company became aware, which is when the GDPR, NIS2 and AI Act deadlines start.
- Treating a prompt injection only as a security event, without reviewing every action the agent took after the first suspect input.
- Leaving the vendor out until late. Model versions, logs and retention often sit with the provider.
Get the playbook
It is free. Enter your work email and we send the download link.
Questions
What is an AI incident?
An event in which an AI system, or an agent acting through one, causes or could cause harm to people, data, money, operations or the company's obligations. The playbook covers six types and logs near misses caught before harm at the lowest severity.
Does the EU AI Act require AI incidents to be reported?
Article 73 requires providers of high-risk AI systems to report serious incidents to market surveillance authorities, within 15 days of becoming aware, 10 days after a death and 2 days for a widespread infringement or critical infrastructure. Under Article 26(5), deployers that identify one inform the provider first. The high-risk rules apply from December 2, 2027 for Annex III systems and August 2, 2028 for Annex I.
Is personal data in a prompt a GDPR breach?
It can be. A personal data breach is a breach of security leading to unauthorized disclosure of, or access to, personal data. If one occurred, the controller notifies the supervisory authority within 72 hours of becoming aware where feasible, unless it is unlikely to result in a risk to people. The privacy lead or DPO decides.