AI Incident Response: Building a Playbook Before Something Goes Wrong

An AI incident is any event where an AI system behaves in a way that causes or risks harm — biased outputs, data leakage, a prompt-injection attack, accuracy drift — not just a classic data breach. A playbook written in calm spells out what counts, who does what, how to contain it, when you have to notify regulators, and how to review it afterward. Build it before you need it, because you will need it.

Why Does AI Need Its Own Playbook?

Most organizations already have some kind of incident response plan, and it's usually built around a data breach: someone reads records they shouldn't, a laptop goes missing, a database gets exposed. Those plans are necessary, but they're incomplete, because AI systems fail in ways a classic breach plan never saw coming. An AI incident isn't always about data walking out the door. Sometimes it's the system quietly making biased decisions for weeks. Sometimes it's confidently telling customers something flat-out false. Sometimes it's a prompt-injection attack turning your helpful assistant into a leak.

The worst possible time to work out who's in charge and what to do is while the incident is unfolding. A playbook written in a calm moment turns a 2 a.m. scramble into a checklist. And with AI now stitched into hiring, service, and operations, the question isn't whether you'll have an AI incident anymore. It's whether you'll be ready when you do.

What Counts as an AI Incident

Stretch your definition past "personal data was exposed." An AI incident is any event where an AI system behaves in a way that causes, or risks causing, harm. In practice, they cluster into a handful of types:

• Harmful or biased outputs. The system produces discriminatory, defamatory, or dangerously wrong results — a screening tool systematically downranking a protected group, a chatbot giving unsafe advice.
• Data leakage. The system exposes personal or confidential information — regurgitating training data, or a misconfigured tool returning one user's data to another.
• Manipulation and security attacks. Prompt injection, jailbreaks, or poisoned inputs that hijack the system's behaviour.
• Loss of control or accuracy drift. The model's performance degrades over time, or it starts operating outside its intended scope without anyone noticing.
• Third-party failures. An AI vendor you depend on has an outage, a breach, or ships a model change that breaks your process.

Writing these categories down ahead of time matters, because the first hard part of any real incident is just recognizing that one is happening. A team that has never named "biased output" as an incident type will file it as a product bug and quietly route it away from the people who should be sizing up the legal exposure.

Roles: Decide Who Does What Now

An incident is the wrong moment to start debating who owns it. Assign these roles ahead of time, and make sure each person actually knows they hold it:

• Incident lead — coordinates the response and has authority to make calls, including taking the system offline.
• Technical owner — the person or team who can actually investigate and contain the AI system.
• Privacy or legal — assesses notification obligations and legal risk.
• Communications — handles what's said to customers, staff, and, if needed, the public.
• Executive sponsor — the accountable senior person who's kept informed and makes the big calls.

In a small company one person may wear several of these hats, and that's fine — what matters is that the hats are assigned, not that five separate bodies are in the room. Keep a short, current contact list, and make sure someone is genuinely reachable outside business hours, because incidents rarely have the courtesy to happen at 10 a.m. on a Tuesday.

Containment: Stop the Bleeding First

The urge to chase the root cause right away is understandable, but the first job is to limit the harm. Containment for AI often gives you options a classic breach plan doesn't have:

• Pause the system. Have a pre-agreed way to take the AI offline or switch to a safe fallback (a human process, a simpler rules-based system). Knowing the kill switch exists — and having tested it — is half the battle.
• Preserve evidence. Capture logs, the offending inputs and outputs, and the system's configuration and version before anything is changed. You'll need this for the assessment and the fix.
• Constrain the blast radius. Revoke a leaked key, restrict access, or roll back a bad model version to stop the incident from spreading while you investigate.

The organizations that bounce back fastest are the ones that decided, in advance, what "pause this system" concretely means for each AI tool they run — and tested that it works.

Notification: Know Your Triggers

This is where AI incidents run into hard legal deadlines, and where a playbook earns its keep. The triggers you're most likely to hit in Canada:

Under PIPEDA, a breach of security safeguards involving personal information has to be reported to the Office of the Privacy Commissioner of Canada, and affected individuals notified, when it creates a *real risk of significant harm* — and you have to keep records of all such breaches, even the ones below the reporting threshold. Report as soon as feasible once you've determined the breach happened.

Under Quebec's Law 25, a confidentiality incident presenting a *risk of serious injury* means notifying the Commission d'accès à l'information and the affected individuals, and a register of all incidents has to be kept regardless. That register is exactly what an incident log is built to hold.

A lot of AI incidents will also be privacy incidents, and these obligations land squarely. Beyond privacy, keep an eye on the AI-specific direction taking shape: the EU AI Act — Regulation (EU) 2024/1689 — brings in obligations to report serious incidents for certain high-risk systems, and Canada's proposed Artificial Intelligence and Data Act under Bill C-27 points toward similar duties for high-impact systems. Sector rules in finance and health may pile on their own reporting expectations. Your playbook should list every trigger that could apply to you, with who assesses it and the clock that starts ticking — so the decision is a lookup, not a debate at the worst possible moment.

The Post-Incident Review: Where the Value Is

The response isn't over when the system comes back up. The most valuable part comes after: a blameless review that asks what happened, why, whether the response actually worked, and what would keep it from happening again. Blameless is the operative word — if people are bracing for punishment, they'll bury the near-misses that are your best early warning. Feed the findings back into the model card, the monitoring, the ROPA, and the playbook itself. An incident you learn nothing from is a pure cost; an incident you dissect is the cheapest security consulting you'll ever get.

This article is general information, not legal advice; your specific notification obligations depend on the incident, the data, and the laws that apply to you, and they're worth confirming with a professional.

Canuckt built Valdra to keep the pieces an AI incident demands in one place — your AI system inventory, the notification triggers, the incident register, and the review trail — so that when something does go sideways, the response is a plan you've rehearsed rather than a page you're writing under pressure.