AI Incident Runbook: A Plain Guide to Writing One.

An AI incident runbook is a short, written plan for when your AI does something wrong. It says who acts, what they do first, and when they call for help. Write it before you need it. This guide shows you how, step by step.

TL;DR

• An AI incident is any event where your AI causes harm or raises risk. That covers bugs, attacks and misuse.
• Your runbook is your normal incident plan, adapted for AI. You do not need a whole new discipline.
• Use six steps: detect, contain, keep evidence, investigate, recover, learn.
• Name owners and escalation paths now. Keep AI logs now. You cannot add them after the fact.
• Test the runbook with a practice drill. Update it after every real incident.

What counts as an AI incident?

The OWASP GenAI Incident Response Guide gives a clear definition. An AI incident is any event where an AI system's behaviour or misbehaviour leads to unintended, harmful or risk-elevating outcomes. That includes technical failures, security breaches, misuse and wider harm to people.

Here are some plain examples:

• Your support bot tells a client something false, and they act on it.
• Someone tricks your AI agent into leaking private data.
• An agent with too much access deletes or changes files it should not touch.
• A model update makes answers worse, and nobody notices for a week.
• Your AI starts sending messages to clients in the wrong tone, or the wrong voice.

None of these is a normal server outage. The system is up. It is just wrong, and it is wrong in a way that looks fine on a dashboard.

That is why you need an AI-specific runbook.

Why an AI runbook is not a brand new thing

You are not starting from zero. According to a speaker abstract from a 2026 NIST session, responding to AI incidents is the existing incident response cycle adapted to new assets, stakeholders and failure modes, not a separate field.

Think of a restaurant kitchen. You already have a fire plan. Now you add a new fryer. You do not write a new kitchen. You add a page to the fire plan: where the new fryer is, what can go wrong with it, and where the shut-off is.

Your AI runbook works the same way. It sits next to your current plan. It adds the AI parts.

What is different about AI?

• It is probabilistic. (That means it gives different answers to the same question.) You cannot always repeat the fault.
• Harm can be quiet. Nothing crashes. A client just gets bad advice.
• Causes hide in many places. The model, the prompt, the data, the tools it can use, or a person typing something tricky.

What to prepare before anything goes wrong

Most of the work happens before the incident. NIST experts in 2026 stressed that planning is the main difference: knowing which AI assets you have and which logs you need.

Make a list of your AI

Write down every AI tool, agent and model your business uses. For each one, note:

• What it does.
• What data it can see.
• What actions it can take.
• Who owns it.

You cannot protect what you have not listed. A founder with five tools and no list will lose an hour just working out what broke.

Name the roles

The OWASP guide points to key roles: incident response managers, ML engineers and data scientists. Small team? One person can wear two hats. But write down the name.

A 2026 NIST session abstract adds that the people who own model lineage (which version came from where) should join incident response and practice drills before an incident. Do not meet them for the first time at 2am.

At minimum, name:

1. Incident lead. Makes the calls.
2. Technical owner. Can switch things off and look inside.
3. Communications owner. Talks to clients and staff.
4. Legal or compliance contact. Checks what you must report.

Agree who can decide what

The UK's National Cyber Security Centre advises teams to pre-agree decision-making principles and delegation in a playbook. The aim: high-impact actions, like shutting a system down, can happen fast even if senior leaders are away.

That is guidance from a UK body, but the idea works anywhere. Put it in writing. "If the founder is unreachable for 15 minutes, the technical owner may pause any agent."

Set up the emergency switch

Some incidents need special access. OWASP covers "break-glass" emergency credentials. Think of the red box on the wall with a hammer. You can use it in a crisis, but you must log it, and you must check it afterwards. Control who holds those keys. Our guide to role-based access for AI systems shows how to keep access tight day to day.

Keep the right logs

Normal server logs are not enough. The OWASP guide lists AI-specific evidence: prompt logs, model drift baselines and agent execution records. The CD Foundation adds AI application telemetry, agent execution logs, model version history, configuration records and deployment evidence.

In plain words: keep a record of what was asked, what the AI answered, what it did, and which version did it.

Watch out for private data in those logs. Read our piece on PII in AI and how to stop it leaking before you store everything forever.

Set severity levels and clocks

OWASP recommends severity-based SLAs (agreed time limits). Set maximum times for first containment, for removing the cause, for recovery, and for how often you update people.

A simple version:

Severity	Example	First containment	Update stakeholders
High	Agent leaks client data or acts without approval	Immediately	Every hour
Medium	Bot gives wrong advice to several clients	Same day	Daily
Low	One odd answer, no harm	Within the week	At the review

These numbers are examples. Set your own to fit your size and risk.

The six steps of the runbook

Copy this structure. Fill in your own names and tools.

Step 1: Detect and classify

You cannot fix what you do not see. OWASP suggests streaming inputs, outputs, prompts and system metrics into one central log stack. Then use checks like prompt-based anomaly detection, confidence monitoring and pattern matching.

The guide also names prompt-related signals to track: prompt injections, prompt leakage, unusual submission rates and shifts in prompt patterns. A prompt injection is when someone hides instructions in their message to trick the AI. It is like a stranger slipping a fake note into your assistant's inbox.

Once you spot something, classify it. OWASP says to triage by severity, blast radius and likely impact on business functions or affected people. Not just by how many records are involved.

Ask three questions:

• How bad is the harm?
• How far has it spread?
• Who is affected?

Write the answers in the incident log. Add the time.

Step 2: Contain

Stop the spread first. Fix it later.

The OWASP guide describes isolating affected parts: disabling a compromised API, suspending a specific agent, or taking a model offline. Pick the smallest switch that works. Turning off one agent beats turning off the business.

Two rules:

1. Keep the evidence. Do not wipe prompt history or logs while you shut things down. Copy them first.
2. Keep a human in the loop. For big containment calls, a person decides. OWASP says human oversight balances smaller blast radius against keeping things running.

Have a fallback ready. If you switch off the AI, what happens to the work? A person, a simple script, or a holding message. We cover this in AI fallback strategies.

Step 3: Preserve evidence

Before you change anything, save what you have. Think of a crime scene. Nobody cleans the room first.

Save:

• Raw prompts and responses from the time window.
• Agent action records.
• The model version and settings in use.
• Recent changes to prompts, tools or data.
• Who had access.

The CD Foundation says this evidence helps investigate compromised software or manipulated model behaviour. Store it somewhere the AI itself cannot edit.

Collecting evidence is only half of it. You also need to retain what you learn, so the findings stay findable and not just the files.

Step 4: Investigate

Now ask why. OWASP says to analyse agent execution records, model lineage and telemetry. You are working out which of three things happened:

• Misuse. Someone used the system in a way you did not intend.
• Security compromise. Someone broke in or tampered with it.
• Unintended model behaviour. The AI just got it wrong.

Check whether knowledge bases, training data or guardrails (the rules that limit what the AI does) were changed. Check whether bad inputs got past your filters.

Carnegie Mellon's Violet Turri, in a 2026 NIST workshop paper, notes that AI systems are tightly bound to their deployment context. So look across the whole life of the system, including data updates and retraining points.

Security layers matter here. If the AI could do too much, that is part of the cause. See why AI agent security needs layers.

Step 5: Remove the cause and recover

Fix the root cause, not only the symptom. Then bring the system back in a controlled way.

OWASP describes recovery as restoring approved model versions, configurations and data, then validating services within your security boundaries before normal operation resumes.

A safe order:

1. Roll back to the last known good version.
2. Remove or patch the cause.
3. Test in a safe space with the same kind of input that caused the problem.
4. Restore access in stages.
5. Watch closely for a set period.

Edge cases cause many repeat failures. Read how AI systems handle edge cases in production when you write your test cases.

Step 6: Report and learn

Decide who needs to know. In the United States, the OWASP guide says to talk to legal counsel about reporting duties. Rules depend on your industry, your contracts and the data involved. So your runbook should name your lawyer, not guess.

You can also share information voluntarily. CISA's 2025 JCDC AI Cybersecurity Collaboration Playbook encourages partners to share actionable information on AI cybersecurity incidents and vulnerabilities through CISA's cyber incident reporting portal. That helps others defend themselves too.

Then hold a review. OWASP says to record:

• The trigger.
• The containment steps.
• The triage decisions.
• The final resolution.

Keep it blameless. You are fixing the system, not hunting for a person to blame. Feed findings into your threat model and monitoring rules.

A one-page template to start from

Copy this into a document and fill it in.

1. Scope. Which AI systems this covers.
2. Contacts. Incident lead, technical owner, comms owner, legal contact. Phone numbers, not just emails.
3. Severity table. High, medium, low, with clocks.
4. Detect. Which alerts, which logs, who watches.
5. Contain. The switch for each system, and who may use it.
6. Preserve. Where evidence is copied, and who has access.
7. Investigate. The three questions: misuse, compromise or model behaviour.
8. Recover. Rollback steps and test checks.
9. Report. Who is told, by whom, and by when.
10. Review. Meeting within a set number of days. Owner for each fix.

One page is enough to start. A short plan people use beats a long plan nobody reads.

Test it before it counts

A runbook you have never tried is a guess. OWASP recommends regular tabletop exercises with cross-functional teams. A tabletop is a talk-through drill. Someone reads out a made-up incident. The team says what they would do.

Try these scenarios:

• A client says your AI shared another client's data.
• An agent sends 200 emails you never approved.
• A new model version changes answers overnight.

After each drill, ask:

• Did everyone know their job?
• Could we find the logs?
• Could we switch the agent off in minutes?
• Who was missing from the room?

Fix the gaps. Run it again in a few months. Update the runbook after every real incident as well.

Our view: build the runbook into the system

Most incident plans are a document in a folder. When something breaks, nobody opens the folder. The runbook should live inside the system.

That means every agent has an owner. Every agent has a switch. Every action leaves a record. And a human approves anything that matters before it goes out.

Many founders are the bottleneck, and they hold back from handing work to AI because they cannot see what it is doing. The answer is not less AI. It is AI you can see, stop and explain.

Our approach is to capture how you make decisions, then build agents that follow your standard. A good runbook is part of that standard. It tells the agents, and your team, what to do when the standard is not met.

If you want to scale without being in every decision, plan for the bad day first.

James Killick

Where we can help

If you run a business with $1M+ in revenue and lean on your own expertise, we can build this with you. Our 90-day program is done-with-you. We set up your AI agents, the access rules and the safety checks, so your team can deliver without you in every loop. It is $18,500 as a one-off. A Foundation Month is $3,500 if you want to start smaller.

Prefer to build on your own? Our platform is $90 per month or $900 per year. For governance help, see our 90-day AI agent governance playbook and our AI system governance plan for NIST and ISO.

Next step

Pick one AI tool you use today. Write down its owner, its off switch and its logs. That is your first runbook page. When you want help building the rest, talk to us about the 90-day program.

Sources

• OWASP GenAI Incident Response Guide
• NIST AI incident speakers, panelists and abstracts, 2026
• NCSC: Preparing for a highly disruptive cyber incident
• CD Foundation: AI Incident Response and Recovery
• NIST: Exploring the AI Incident Documentation Practice
• CISA: JCDC AI Cybersecurity Collaboration Playbook