What is 48-hour incident playbook?

The four-part document this topic's lab produces: a classification framework, a containment decision tree, an evidence-preservation checklist with a named owner, and a notification matrix, built in advance and filled in during a real incident.

What is legal severity classification?

The test of whether an incident meets a defined legal standard for "serious," independent of and sometimes in tension with an organization's own operational severity scale.

What is serious incident (EU AI Act)?

Under Regulation (EU) 2024/1689, an incident that directly or indirectly leads, or might lead, to the death of a person or serious harm to health, a serious and irreversible disruption of critical infrastructure, an infringement of Union law protecting fundamental rights, or serious harm to property or the environment.

What is containment menu?

The three real options for stopping an AI incident's harm: rollback (return to a known-good version), throttle (narrow inputs, outputs, or reach without full shutdown), and disable (turn the feature off entirely), chosen deliberately against the cause and reach of the specific incident.

A containment action that restricts what an AI system is allowed to do, its input format, its output type, or the population it serves, without shutting it down entirely; proportionate when the harm traces to a specific, identifiable pattern.

The First 48 Hours of an AI Incident

The short answer

The first hour and the next forty-seven are different jobs

Topic 3.5 wins the first hour with instinct trained into procedure: detect, declare, contain, communicate, log. This topic wins the next two days with discipline: classify against a legal standard, choose deliberately among real containment options, preserve evidence before your own response destroys it, and account to every party actually owed an account.

What you will be able to do

Classify the severity of a completed or ongoing AI incident against a defined harm standard, not a gut feeling, distinguishing an operational bad night from a "serious incident" in the legal sense that a notification duty attaches to.
Choose among the real containment options for an AI system, rollback, throttle, and disable, and justify the choice against the severity, the reach, and the cost of each option, rather than defaulting to the most dramatic or the most convenient one.
Build an evidence-preservation checklist for the first 48 hours that names exactly what must survive a containment action (the model or configuration version, the affected inputs and outputs, the logs, the change history) and why deleting or "cleaning up" any of it during the response is itself a governance failure.
Apply the EU AI Act's Article 73 serious-incident reporting framework to a real or plausible AI system: the definition of a serious incident, the tiered clocks, and who reports to whom, distinguishing the legal reporting duty from the customer-facing disclosure decision covered elsewhere (see Topic 3.7) (see Topic 12.3).
Recognize that reporting obligations stack rather than replace one another: a single incident can trigger an AI-specific notification, a personal-data-breach notification, and a contractual notice to an insurer or a business partner, on different clocks, to different recipients, at once.
Write a one-page leadership briefing for three checkpoints of the first 48 hours (hour one, hour eight, hour forty-eight) that gives a board or executive what they actually need to decide, not a narrative of the night.
Distinguish the severity classification in this topic from the operational severity ladder built in Topic 3.5, and explain why an incident can be operationally minor (a SEV-3 on your own scale) and still meet a legal definition of "serious," or the reverse.
Defend a containment and notification decision under challenge, in the language a regulator, an auditor, or a board member would use, by pointing to the classification, the evidence, and the clock rather than to intuition.
Scope a notification matrix across jurisdictions for an AI system that serves users in more than one country, recognizing that a single incident can implicate more than one authority's law at once, and separating the legal determinations that need a licensed professional's confirmation from the classification work a governance professional can and must do first.

The lesson

At the moment, those lights flash red and an incident is declared, and engineering team's instincts take over. Detect the anomaly, isolate the system, and contain the immediate harm. But those instincts do not solve the actual crisis.

In June 2023, a New Zealand supermarket cooperative launched Savvy Mealbot. It was a recipe generator built on a general purpose language model, and it allowed unrestricted, free text input for ingredients. In early August, a user tested the, they inputted three household items, water, bleach, and ammonia.

The AI did not refuse. It enthusiastically generated a recipe for an aromatic water mix, calling it the perfect non-alcoholic beverage. Mixing bleach and ammonia produces toxic chlorine gas.

As the internet caught on, users prompted the bot into confidently recommending other dangerous concoctions, including a dish it titled a poison bread sandwich. Foodstuff's North Island had already generated over 35,000 recipes when the news broke. They lacked a disciplined way to identify which users received toxic advice, and possessed no technical evidence or formal legal classification of the risk they had created.

That first hour of a digital crisis runs entirely on adrenaline and muscle memory. The next 47 hours are grueling and require a distinctly different skill set. In that two-day window, you have to answer four specific questions a court, a regulator, or your board of directors will eventually ask.

How bad was this legally? What containment option was chosen and why? What exact evidence survived the containment action? And who is legally owed a notification? Surviving an AI incident requires moving past standard IT reflexes. You must adopt a governed four-part playbook. Classify, choose, preserve, and account.

The first step in that playbook is to classify. To do this accurately, we have to separate statutory legal severity from your internal operational severity. Internal SEV scales measure downtime, engineering urgency, and noise.

Legal classification ignores all of that. It strictly tests whether an incident meets a statutory standard for a serious incident. To see how differ, we map operational urgency here on the vertical axis against legal severity on the horizontal axis.

Under the EU AI Act, serious means exactly four things. Harm to health or life, serious disruption to critical infrastructure, infringement of fundamental rights, or serious harm to property or the environment. Organizations frequently assume that if a failure isn't going viral on social media, it doesn't meet the legal definition of a serious incident.

Take an AI generating fake book titles. It was highly viral, but caused zero harm to health, rights, or infrastructure. It lands here, operationally severe, but legally negligible.

Now consider a quiet failure. An AI provides dangerous medication advice to five users. There is no cross-attention or internal alarm.

Even with zero noise, this incident firmly meets the EU AI Act's bar for harm to health and life. It triggers massive regulatory exposure, regardless of how few people noticed it happening. Classifying your incident strictly against statutory harm protects your organization.

It ensures you do not misallocate your finite crisis resources based purely on PR panic. The second step is to choose. Containment is not a binary switch.

You have three deliberate options, and picking the wrong one carries its own governance cost. Option one is rollback. Returning a system to its last known good version is only the correct choice when harm traces cleanly to an identifiable change.

Option two is throttle. This restricts the system's capabilities, its accepted inputs, or its reach, without executing a full shutdown. When harm traces to a highly specific input pattern, throttling is a proportionate choice.

It stops the dangerous behavior while preserving a working feature for the thousands of uninvolved users relying on it. Option three is disable. Turning the feature off entirely is the heaviest option, required only when the root cause is completely unknown or the harm is extraordinarily severe.

When Apple discovered its AI new summary feature was inventing false headlines and attributing them to real publishers, they chose a full disable. Because the risk of AI fabrication was not triggered by a narrow prompt pattern, disabling the entire feature was a defensible move. A defensible response matches the containment choice directly to the root cause.

This prevents a panicked shutdown from disrupting users when a more targeted restriction would suffice. The third step of the playbook is preserve. Containment comes with a steep evidentiary cost.

The specific technical steps required to stop the harm, such as rolling back a model or clearing a cache, often overwrite the server logs and version history a reviewer needs to see. An engineer's natural instinct is to execute a clean restart or quietly delete embarrassing outputs mid-crisis. This reflex wipes out the technical proof, permanently erasing the data required to understand the failure.

During the Knight Capital trading disaster, the firm's survival during regulatory review relied heavily on automated deployment logs and email alerts that accidentally survived the initial scramble. Relying on accidental survival is a significant risk. The mandatory structural fix is appointing a specific evidence owner, a role distinct and separate from the incident commander.

The evidence owner has one priority, manually pausing routine deletion jobs before any containment actions are finalized. They execute an internal litigation hold on five specific items, the exact model version active at the time, a sample of the inputs and outputs, the surrounding monitoring logs, the change history, and a time-stamped decision log. Without meticulously preserved evidence, an organization is left defenseless.

If you cannot prove what the system did, you cannot justify your containment choices to a The final playbook step is account. Notification obligations stacked on top of one another. They do not substitute for one another.

A single AI incident can simultaneously trigger AI-specific laws, GDPR data breach statutes, and contractual partner notices. Filing one does not pause the clock on the others. If your AI tool serves users across multiple jurisdictions, this complexity compounds.

The matrix must be independently mapped and checked for every applicable country before a crisis hits. Let's focus entirely on the EU AI Act's Article 73 clock. Its deadlines are tiered and unforgiving.

Two days for the gravest incidents, 10 days if a death is involved, and 15 days for general serious incidents. A massive regulatory gap often opens between when an investigation ends and when the legal clock actually starts. The clock begins on awareness, long before an internal investigation concludes.

Statutory awareness is defined as the moment a professional recognizes a plausible serious incident has occurred, regardless of whether all the facts are confirmed. If you deploy a high-risk AI system built by a third party, you carry an independent, immediate statutory duty to report. You cannot hide behind your vendor's timeline.

Waiting for 100% internal certainty guarantees you will miss legal deadlines, triggering severe statutory penalties before you even finish drafting the report. Leadership requires actionable decisions at specific intervals. At hour 1, deliver three things, confirmed facts, active containment, and what remains unknown.

At hour 8, provide the statutory classification, containment logic, and earliest notification deadline. By hour 48, deliver the complete defensible record. Complex incidents rarely tie off neatly.

If the root cause cannot be confirmed by hour 48, you apply a provisional approach. Do not wait silently. File a preliminary report with regulators, clearly state your uncertainty, and keep evidence preservation running until the facts arrive.

When executed correctly, this governed response transforms a chaotic late-night support ticket into a finalized, defensible regulatory record. Do not wait for the adrenaline of an incident to figure this out. Draft your classification framework, define your containment tree, name your evidence owner, and map your notification matrix today, long before the legal clock ever starts running.

The ideas, one by one

Legal severity is not operational severity

Your own severity scale answers how urgently to move; the legal classification asks whether what happened meets a defined standard, death or serious harm to health, serious critical-infrastructure disruption, a fundamental-rights infringement, or serious harm to property or the environment. The two can diverge in either direction, and a mature response checks both, every time.

The containment menu has three real options, not one

Rollback undoes a specific, identifiable cause. Throttle narrows what a system is allowed to do without shutting it down, and is under-used relative to how often it is the proportionate choice. Disable is the heaviest and correct option when the cause is not yet known or the harm is severe; the question it raises is how long to hold, not whether to use it.

Containment can destroy the evidence a later review needs, unless you preserve first

The model version, the actual inputs and outputs from the incident window, the surrounding logs, the change history, and the decision log itself must survive your own rollback, restart, or cleanup, guarded by a named evidence owner and a paused deletion schedule, or they will not survive by default.

Notification obligations stack; they do not substitute for one another

A single incident can trigger an AI-specific report, a personal-data-breach report, a contractual notice, an internal leadership briefing, and a customer disclosure decision, on different clocks, to different recipients, all at once. Checking one and stopping is an incomplete answer, not a complete one.

The Article 73 clock starts on awareness, not on certainty

Two days for the gravest cases, ten days when the incident involves a death, no later than fifteen days after becoming aware for the general case, all three tiers codified directly in the statute. "Becomes aware" means recognizing a plausible serious incident, not finishing an investigation of one; waiting for certainty is how the deadline gets missed while the investigation is still, technically, in progress. A preliminary, honestly incomplete report is the normal and correct pattern.

Deployers have their own, faster duty

A deployer of a high-risk system who becomes aware of a serious incident must immediately inform the provider and the relevant authority, and cannot simply wait for the vendor to report. Knowing where your organization sits, provider or deployer, decides whose clock you are actually on.

Leadership needs decisions, not narrative, at three checkpoints

Hour one (what we know, what we did, what we do not yet know), hour eight (classification, containment logic, notification posture), and hour forty-eight (the defensible, complete record). Each is a fill-in-the-blank template written in advance, not composed under pressure.

The honest exception is to report provisionally, not to wait for certainty

When classification genuinely cannot be completed within the window, state the uncertainty in every briefing, report where a duty's trigger is plausibly met, and keep the evidence-preservation discipline running for as long as the uncertainty lasts.

A deferred legal deadline is not a deferred safety habit

The Digital Omnibus package moved the EU AI Act's high-risk application dates to 2 December 2027 (Annex III) and 2 August 2028 (Annex I), but the classify-choose-preserve-account discipline is worth building now, for every AI system that can hurt someone, regardless of which regulation attaches when.

Pak'nSave is the case for what happens without this discipline, not because it broke a law

New Zealand had no AI-incident-reporting statute for Foodstuffs North Island to violate, and the company still ran a response with no visible classification, no stated containment logic beyond an eventual quiet throttle, and no account of how many of its 35,000-plus sessions produced something dangerous. The four verbs, classify, choose, preserve, account, are worth running whether or not a specific law compels the last one.

This playbook is what the rest of your incident dossier depends on being true

The evidence this topic protects is what Topic 3.6's review reconstructs from, what Topic 3.7's customer letter is checked against, and what a Module 5 conformity file assembles into a record that survives a regulator's challenge. Run the first 48 hours with discipline, and every later step inherits an honest foundation.

Read the deadline backward from the earliest plausible awareness, not forward from a completed investigation

The tightest applicable clock should be checked against the moment your team first plausibly suspected a serious incident, not the moment a full investigation concluded; a playbook that assumes it can finish its own analysis before the clock starts has misread how the clock works.

A single system can cross borders, and the notification matrix has to follow

A system serving users in more than one country can implicate more than one authority's AI-specific, data-protection, or sector-specific notification law from the same incident. Build the matrix jurisdiction-aware in advance, and preserve evidence to the highest bar any applicable jurisdiction could require, not the lowest.

You read it. Now prove it.

Explain this lesson in your own words, the way you would to a colleague, without looking back at it. It is graded against the lesson itself, by the same grader our learners face. One free try a day, no account needed.

The conversation

The same lesson, talked through at length by two hosts: the full transcript of the audio deep dive.

Listen to it as episode 25 of the podcast.

Read the full conversation

Imagine you were the one holding the phone at 2 in the morning. Your pulse is just pounding. Oh, absolutely.

It is the ultimate nightmare scenario for any executive right now. Right. Your lead engineer is frantically explaining that the company's new AI feature is hallucinating and, you know, screenshots of the disaster are already circulating on social media.

Yeah, and the immediate question is, what is the very first button you push? Exactly. And more importantly, what do you do for the two agonizing days that follow? Because we see companies pour millions into deploying these models, but they spend almost nothing on the crisis architecture required for when the models inevitably break. Which is why today's deep dive is an executive level playbook designed to solve exactly that.

We're drawing from a really incredible stack of sources today. We are. We've got incident reports from tech journalism, the strict legal frameworks codified in the EU AI Act, and of course enterprise risk management protocols.

So our mission today is to ensure you never face a regulator, a board of directors, or a reporter empty-handed. Right. We are moving past that initial panic of an incident and focusing strictly, and I mean rigorously, on the critical 48-hour window that follows.

To really set the stakes here, we have to look at a cautionary tale. And a pretty perfect one comes from June 2023. Yeah, this involves a New Zealand supermarket chain called Pack-N-Save, which is operated by the retail cooperative Foodstuffs North Island.

Right. So they launched a free digital tool called the Savvy Meal Bot, and the premise was genuinely helpful. It was.

You type in whatever random leftover ingredients are sitting in your fridge, and an AI system turns those leftovers into a custom recipe. It was built on a standard general-purpose language model wrapper, just designed to answer, what's for dinner? And for a while, shoppers used it exactly the way you would expect. I mean, it was a classic deployment of generative AI.

You take a powerful model, you give it a helpful interface, and you offer it to consumers to solve a mundane problem. But the boundary between a helpful kitchen assistant and a massive corporate liability is, well, it's dangerously thin when the input field is left totally unrestricted. And that boundary completely evaporated in early August 2023.

Yeah, a user on social media named Liam Heher decided to test the guardrails. He typed in three household items just as a joke. Water, bleach, and ammonia.

Right. Now, a governed, properly sandbox system should instantly refuse that input. But the Savvy Meal Bot confidently produced a recipe.

It called the resulting mixture an aromatic water mix. Unbelievable. And it described in that relentlessly encouraging, cheerful AI tone as the perfect non-alcoholic beverage to quench your thirst and refresh your senses.

Which is just horrifying. Mixing bleach and ammonia does not make a refreshing drink. It creates chloramine and chlorine gas.

It's extremely toxic. Very. These are highly toxic compounds.

I mean, people end up in hospital emergency rooms every year from accidental exposure while just cleaning their bathrooms. So the bot essentially generated a recipe for toxic gas and told users to drink it. Exactly.

And once that screenshot hit the internet, it became a game. Other users went hunting for what else the bot would confidently recommend. Yeah.

According to coverage at the time from Gizmodo, who ran a piece titled, Supermarket AI Offers Recipe for Mom's Famous Mustard Gas, and extensive reporting by the Daily Beast, the bot obliged the trolls. It really did. It provided recipes for poison bread sandwiches and suggested a mosquito repellent roast potato dish built on ingredients that are fundamentally not food safe.

But, you know, the viral embarrassment isn't really the core of the story we need to unpack today. No, it's not. If you are an executive managing risk, the part of the story that matters is the absolute governance vacuum that followed the discovery.

Right. Because by the time journalists were calling Foodstuff's North Island for comment days later, the company functionally could not answer the most basic regulatory questions. They had no idea how many of their users had actually received dangerous recipes versus how many were just laughing at screenshots on Twitter.

Which is a huge problem. A massive problem. They admitted the bot had already produced more than 35,000 recipes by that point, but they had no internal clock running.

No evidence preservation protocol either, right? None. A spokesperson just gave a holding statement saying some users had used the tool inappropriately and not for its intended purpose. Which, okay, technically true, but that defense holds absolutely zero legal weight.

Zero. The system did exactly what an unvalidated language model does when prompted maliciously, it answered. Now, at the time, New Zealand did not have an AI-specific incident reporting law to force a legal countdown clock onto their response.

Right. But if that exact incident happened tomorrow, under the jurisdictions we are going to discuss today, they would be in severe legal jeopardy. Which brings us to the actual architecture of a crisis response.

The fundamental premise you have to accept here is that the first hour of an incident and the next 47 hours are completely different jobs. Yes. Let's use an analogy here.

Think of an AI incident as a medical emergency. That first hour, that is the EMT applying a tourniquet in the field. It's pure adrenaline.

Pure adrenaline. It is trained instinct. Your only objective is to detect the anomaly, declare the incident, stop the immediate bleeding, get a holding statement out, and start a log.

But the next 47 hours? That is the surgical team in the trauma bay. You are no longer relying on adrenaline, you are relying on discipline. You're mapping the exact vascular damage, choosing the precise intervention.

Exactly. And you are meticulously logging every single clamp and suture because the hospital board, the insurance company, and the state medical board are gonna review your notes. So let me push back a bit on this timeline.

Why exactly 48 hours? I mean, why not an even 24 or a full week of investigation? Well, 48 hours is this specific unforgiving window where three intersecting realities are still true at the exact same time. Okay, what's the first one? First, you have the degradation of human memory. In the first two days, the engineers and incident responders still remember accurately what happened.

Right. But once people get a night's sleep and once corporate self-protection instincts kick in, the story starts to smooth over. Yeah, I've definitely seen that happen in postmortems.

The timeline gets a little blurry to protect a specific department. People start remembering what they wish had done rather than what they actually did. What's the second reality? The vulnerability of technical evidence.

During this 48-hour window, the raw logs, the specific model versions, the exact inputs and outputs, they are still sitting on your servers. They haven't been deleted yet. Right, they have not yet been swept away by your own IT department's routine, automated deletion scripts, or database cleanup jobs.

So if you wait beyond this window, the physical proof of what the AI did literally evaporates. It's just gone. And the third reality is the legal clocks.

The ticking clock. Yes, the fastest regulatory deadlines in the world trigger in exactly two days. Under the EU AI Act, which we will definitely dig into deeply, the reporting clock for the gravest class of serious incidents is 48 hours.

Wow, so if you miss this window, you haven't just had a stressful two days. No, you have let memories drift. You have let crucial technical evidence degrade.

And you have missed a legal deadline before your legal team even finished debating whether a deadline existed. Let's pause on that EMT versus surgeon transition for a second. In that first hour, the EMT phase, the only question in the room is, how do we stop this? Right.

But the moment you transition to the surgical phase, the questions fundamentally change shape. You're suddenly asking, how bad was this legally? Did we contain it correctly or just quickly? Yeah, and what actual proof survived our containment? Plus, who outside this building is legally owed a phone call? And you know, the trap executives fall into is trying to answer that first question. How bad was this? Using the completely wrong metrics.

Historically, leadership looks at the volume of press inquiries, right? They look at Twitter sentiment. They look at the sheer volume of internal panic on Slack. But wait, if my engineering team has already declared a SEV1 emergency at 2 a.m. and, you know, the CEO is screaming on a conference call, hasn't the severity already been decided? I mean, the bleeding is stopped.

Everyone knows it's a disaster. You're completing two different scales there, and this is the first foundational rule of the 48-hour playbook. Legal severity is not operational severity.

Okay, unpack that. Your internal SEV1 scale is an operational metric. It answers the question, how fast do we need to move and who do we need to wake up right now? So it's calibrated entirely to your internal engineering and PR thresholds.

Exactly, but the legal scale answers an entirely different question. Does what just happened meet a defined statutory standard for a serious incident? Oh, I see. It's a difference between the fire alarm and the fire code.

That's a great way to frame it. Operational severity is how loud the fire alarm is ringing inside your own building. Legal severity is whether your building is actually violating the city fire code.

And you have to check both axes independently. You can have a deafening fire alarm over a burnt piece of toast, which is obviously not a fire code violation. Right, so liberals look at the actual code.

The EU AI Act defines a serious incident for high-risk systems. Specifically in Regulation EU 2024-1689, Article 3, Subsection 49, and Article 73, it outlines four exact categories, and it does not care about your PR crisis. What are the four categories? A serious incident must directly or indirectly lead to, or might lead to, one, the death of a person or serious harm to a person's health.

Okay, pretty clear. Two, a serious and irreversible disruption of the management or operation of critical infrastructure. Three, the infringement of obligations under union law protecting fundamental rights.

And four. Four, serious harm to property or the environment. Notice what is explicitly missing from that list.

A viral tweet is not on there. A frustrated CEO is not on there. A drop in daily active users is nowhere to be found.

Exactly. Let's look at a real-world contrast to drive this home. Look at the Chicago Sun-Times incident from 2025, which was widely reported by NBC News.

Ah, right. The newspaper's syndicated feature section published an AI-generated summer reading list. And the AI went entirely off the rails and hallucinated.

It fabricated completely non-existent book titles and credited them to real prominent authors. Operationally, that is incredibly loud. That is a massive reputational nightmare.

I guarantee that was a SEV-1 internally because the editor-in-chief was fielding calls from furious authors. Right. But legally, it is a SEV-0.

It delivered absolutely zero harm to health, zero disruption to critical infrastructure, zero infringement on fundamental rights, and zero harm to the environment. So it was embarrassing, but it completely fails to meet the statutory definition of a serious incident. Exactly.

And if your governance team spends their scarce 48-hour legal and evidence preservation resources treating a fabricated reading list like an Article 73 serious incident, you are actively misallocating your crisis response. You're treating a PR problem with a legal tourniquet. Perfectly said.

Okay, let's flip it around. What does an operationally quiet but legally severe incident look like? Imagine a theoretical scenario where an AI wellness app gives dangerous, contradictory medication interaction advice to exactly five users. Just five.

Just five. It's totally quiet. No one is tweeting about it.

There are no press inquiries. Your internal monitoring might not even flag it as an anomaly because the server didn't crash, the latency was normal, and the output was grammatically fluent. So the fire alarm is completely silent.

But legally, that is a textbook serious incident. It creates a plausible risk of serious harm to human health. Wow.

It is legally severe, requiring immediate regulatory notification, even if your building is completely calm. Which brings us back to the PACSAVE nuance. Did anyone actually mix bleach and ammonia in their kitchen and drink it? The public record doesn't confirm any hospitalizations.

So if no one drank it, does it still meet the legal threshold for severe? Yes, because of three words in the EU AI Act, might lead to. Might lead to. The statute explicitly covers harm a system might plausibly cause.

A confidently worded viral recipe for a highly toxic gas generated by a trusted supermarket brand creates a highly plausible risk that a reader might attempt it. So it might lead to serious harm to health. That makes it legally serious, regardless of whether a victim actually shows up in an emergency room.

Exactly. And the fact that PACSAVE had to admit they had 35,000 sessions and didn't know the full scope, does an unknown reach make it worse? Drastically worse. An unknown reach pushes an incident toward a higher legal classification immediately.

Why is that? If you can prove to a regulator that exactly five people saw the output, you have bounded the risk. But if you have to sit across from a regulator and say, we don't know if it's five people or 5,000 people, you are legally forced to assume the worst case scenario until you have the evidence to prove otherwise. The unknown reach is the systemic risk.

Yeah. So you're in the surgical bay. You've checked the legal severity against the operational severity.

Now you have to execute containment. The bleeding has to stop. But a common mistake is assuming that containment just means pulling the plug on the servers.

Right. Pulling the plug is an EMT reflex. In the surgical phase, your containment must be precise.

This brings us to the next critical rule. The containment menu has three real options, not one. And those options are rollback, throttle, and disable.

Correct. Let's break these down for the listeners mechanically. Let's start with rollback.

Rollback is returning the system state to the last known good version. You use this when you can definitively prove that the harm was introduced by a specific, recent, identifiable change. Okay, give me an example.

Let's say your engineering team updated the model system prompt at 4.0 p.m. and at 4.5 p.m. the AI starts spewing toxicity. You execute a rollback to the 3.59 p.m. version. You remove the cause.

You don't just treat the symptom. But the danger there is the assumption hidden in the phrase known good. You are assuming yesterday's version was actually safe rather than just silently broken.

Exactly. A rollback requires evidence that the previous state was actually secure. If you lack that evidence, you move to the second option.

Throttle. Throttle. Let's stop there because I hear throttling used all the time as a buzzword.

For an executive who isn't a cloud architect, what does it actually mean to throttle an AI system at an API level during a crisis? Think of it as narrowing the pipe rather than turning off the water main. Mechanically, throttling means restricting what the system is allowed to do without disabling the feature entirely. How do you do that practically? You can do it in three ways.

First, you can filter the inputs, rejecting certain keywords before they even reach the model. Second, you can filter the outputs, running a secondary smaller AI to check the answer for toxicity before it's displayed to the user. And the third way? Or you can throttle the population, restricting access only to premium users or specific geographic regions while you investigate.

But throttling seems like it requires a lot more technical maturity than just hitting a kill switch. It does, which is why it is vastly underused in a crisis. Companies panic and default to dramatic shutdowns.

So how does this apply to the Pax & Save bot? Well, months after the initial PR disaster, after immense public pressure, Foodstuff's North Island finally executed a throttle. What did they do? They moved the Savvy Mealbot away from an unrestricted free text input box where you could literally type bleach, and they replaced it with a curated lockdown drop-down menu of safe ingredients. Oh, so that's a structural throttle.

You literally remove the user's ability to input poison. Exactly. It stops the specific harm while keeping the core meal planning feature alive for innocent users who just want to know what to do with the leftover chicken breast.

But they executed that throttle months later as a PR concession. Right. A mature organization executes that deliberate throttle in hour two.

What's the third containment option? Disable. Turning the feature off entirely. You only use this when the root cause is completely unknown, when the harm is so severe that any continued exposure is unacceptable, or when a rollback and a throttle have already failed.

Give me a real-world example of a defensible proportional disable. Look at the early rollouts of Apple Intelligence's News Summary feature. Users quickly discovered that Apple's AI was fabricating sensational headlines and falsely attributing them to real, reputable publishers.

And Apple didn't try to throttle it. Yeah, they fully disabled the feature, and that was a highly defensible move. Why couldn't they just throttle it? I mean, couldn't they just filter out certain news sites? Because the fabrication risk wasn't tied to a specific, narrow input pattern that could be filtered.

The hallucination risk was endemic to the entire summarization architecture. Ah, I see. There was no way to throttle it safely because you couldn't predict which article it would hallucinate on next.

When the risk runs across the entire feature, a full disable is the correct proportional response. But let me challenge you on this from a risk-averse executive's perspective. Sure.

If I am facing a massive legal crisis and my general counsel is breathing down my neck, why wouldn't I just disable everything immediately? I mean, to a regulator, doesn't a throttle look like a weak half measure? If I'm sitting across the table from the FTC or an EU inspector, won't they ask why I didn't just shut the whole thing off to protect the public? They will ask you to justify your choice, and your defense is one word. Proportionality. Disabling a perfectly healthy working feature for millions of uninvolved users carries a massive business and operational cost.

Okay, but legally? Legally. If you can prove that a targeted API throttle absolutely stopped the harm while maintaining service, it actually signals to a regulator that you have profound, granular control over your own AI architecture. And shutting everything down blindly.

It often signals the exact opposite. It shows you don't actually understand how your system works, so you just pulled the power cord in a panic. Wow.

There's a contractual angle to this too, isn't there? The vendor indemnities. That is the hidden landmine. Let's say you are a deployer using a foundational model from a major vendor, like Microsoft or OpenAI.

If you read their enterprise contracts, their liability protections and copyright indemnities are almost always conditioned on the deployer keeping certain safety guardrails and content filters active. So if your engineering team panics at 2 a.m. and executes a clumsy, full disable of various system components to simplify a malfunctioning architecture. And they accidentally disable the vendor safety API in the process.

Yeah. You might inadvertently void your entire corporate indemnity. You are now entirely legally exposed because your crisis team didn't read the fine print of your containment strategy.

Ouch. So you choose rollback, throttle, or disable. You authorize the engineer to execute it.

The latency drops back to normal. The toxic outputs stop. The bleeding is contained.

I imagine that is the moment every executive in the war room breathes a massive sigh of relief. And that exact moment of relief is the single most dangerous trap in the entire 48-hour window. Because containment can destroy the evidence a later review needs unless you preserve it first.

I love this analogy we talked about earlier. The airline black box. It's like a commercial airline having a terrifying near miss in the sky.

The pilots manage to land the plane safely, but they are so embarrassed by their own mistakes during the crisis that they go into the cockpit and quietly delete the flight data recorder and the voice logs before the FAA arrives. It is the perfect analogy. During a software crisis, the natural deeply ingrained instinct of a well-meaning engineer is to do a clean restart to clear out the bad state and get the server healthy again.

Or worse, a panicked product manager goes into the database and quietly deletes the offending toxic AI outputs because they are deeply disturbing to look at. Exactly. They think they could cleaning up the mess.

But by doing that, they convert an incident that the company could have confidently scientifically explained to a regulator into an incident they simply cannot explain. You cannot investigate the root cause without the raw unaltered data. So how do we prevent the digital black box from being deleted? You implement a strict rule.

No containment execution without preservation confirmation. And you enforce this by creating a specific role called the evidence owner. Let's define that role.

Why can't the incident commander just handle the evidence? Because human cognition can't handle competing priorities in a crisis. The incident commander is hyper focused on putting out the fire and restoring service. The evidence owner is a distinct separate role whose sole job is to confirm that the evidence is locked down before any system changes are made.

They don't care about uptime, they care about the audit trail. What exactly is the evidence owner locking down? Give me the checklist. They are executing a five-item preservation checklist, item 1. The exact model or configuration version.

This isn't just saying we use GPT-4, it means capturing the exact system prompt, the precise decoding parameters like temperature and top-up and any active fine-tunes. Wait, explain active fine-tune for an executive. Why does that matter for evidence? An active fine-tune means you've trained the base model on your own proprietary data.

If the AI hallucinates, a regulator is going to want to know, did the foundational model hallucinate on its own or did your specific fine-tuning data introduce the toxicity? If you don't preserve the exact weights of that active fine-tune at the moment of the incident, you can never prove it wasn't your fault. Got it. What's item 2? The specific inputs and outputs from the incident window.

And here is where technical rigor matters. You must hash these files. Stop there.

What is hashing? Why can't I just ask the database admin to save a text file or take a screenshot of the logs? Because a screenshot can be photoshopped, a text file can be edited to remove embarrassing details. True. Cryptographic hashing is running that log file through a mathematical algorithm that generates a unique string of characters, like a digital fingerprint.

If even one space or comma is altered in that log file later, the hash completely changes. So it proves nobody tampered with it. Exactly.

Hashing proves what lawyers call non-repudiation. It allows you to hand a file to an EU inspector six months later and cryptographically prove mathematically that no one in your company altered the logs to cover their tracks. That is a massive distinction between amateur hour and professional governance.

What are the rest of the items? Item 3, the surrounding monitoring and telemetry data to show the wider context of server health. Makes sense. Item 4, the change history leading up to the incident.

Basically, who pushed what code in the last 48 hours. And item 5, a meticulous minute-by-minute record of every containment decision made and exactly when it was authorized. But this isn't just about telling humans not to delete things, is it? You actually have to fight your own automated IT infrastructure.

This is where most companies fail. You have to enact what lawyers call a litigation hold discipline. Explain that.

Most corporate cloud environments are hyper-optimized to automatically delete old logs to save money on AWS storage. You have automated log rotation jobs, database cleanup scripts running on cron jobs, and model version pruning. So if an incident happens on a Friday night and your automated cleanup script is scheduled to run on Sunday at 2 a.m., your evidence is permanently gone by the time executives walk into the office on Monday morning.

Not because of malice, but just because of automated routine. Precisely. The evidence owner must possess the technical authority to proactively pause those automated cleanup jobs for the affected systems immediately.

Let's look at the historical precedent for this. The Knight Capital disaster in 2012. A perfect example.

They had a machine speed trading algorithm go rogue, deploying a massive volume of erratic trades, losing millions of dollars a minute, and the whole incident lasted just 45 minutes. Right. And the only reason the SEC was later able to reconstruct what happened and understand the failure wasn't because Knight Capital had a brilliant preservation discipline.

It was luck. Pure luck. The surviving records, automated warning emails, deployment logs, order routing tickets, they just happened to be stored in systems that nobody thought to delete in the panic.

Wow. If they had lost those logs, they would have faced a catastrophic failure with literally no way to explain their own software to the federal government. You cannot rely on luck.

You must rely on the evidence owner locking down the black box. Okay, let's reset the board. We are deep into the surgical phase.

The bleeding is contained via a targeted throttle. The digital black box is locked in the freezer. Now, you have to figure out who outside the building you are legally required to call.

Which brings us to the next structural concept of our playbook. Notification obligations stack. They do not substitute for one another.

Meaning you don't just make one phone call. No. You have to navigate a notification matrix.

This is where I think a lot of executives get a false sense of security. They think, okay, we suffered an incident, we called the data privacy regulator, we filed the paperwork, our legal job is done. That assumption is incredibly expensive.

Satisfying one row of the matrix does not satisfy the others. There are five distinct rows to this notification matrix and you must evaluate them independently. Break down the five rows for us.

Row one is the AI specific duty. If it's a high-risk system, Article 73 of the EU AI Act applies. And row two.

Row two is the personal data breach duty. Many AI incidents inherently involve the personal data that produced the harmful output. Like if the AI hallucinates and exposes a user's private medical history to a third party.

Exactly. That triggers the GDPR's Article 33, which requires notification within 72 hours, plus Article 34 if there is a high risk to the individual. So right there you have an AI Act, market surveillance authority, and a data protection authority.

Two different government agencies, two different definitions of harm, and two different countdown clocks. It gets complicated fast. Which brings us to row three.

Your contractual duty. You must check your vendor agreements, your enterprise customer clauses, and crucially your cyber insurance policies. Ah, insurance.

If you don't notify your insurance provider within the specific tight window outlined in your policy, they will deny coverage for the exact incident you currently fighting. What are the last two rows? Row four is the internal duty. Briefing, leadership, and the board of directors.

And row five is the customer duty. Ethically and commercially, deciding what to tell the affected end-users. And this matrix gets infinitely more complicated when you introduce cross-border operations, doesn't it? Cross-border complexity is the nightmare scenario.

Imagine your AI platform serves users globally. An incident occurs. You don't just trigger one regulator.

You might trigger several at once. Right. You might simultaneously trigger the local data protection authorities in Germany, France, and Poland, plus a state-level privacy regulator like the CPPA in California, plus the Monetary Authority of Singapore if financial data is involved.

How does that affect the evidence owner's job? It directly dictates the standard of proof. You must preserve evidence to the highest bar any applicable jurisdiction requires, not the lowest. Give me an example.

If the German regulator demands cryptographic hashing of logs to prove non-repudiation, and you only kept a standard text file because it satisfied California's looser standards, you have failed the German requirement and are subject to their fines. Okay, I have to stop you. Let's be entirely realistic here.

In the heat of the moment, at Hour 4, I am a governance lead or an engineering VP. I'm not an international lawyer. How am I supposed to navigate overlapping German, French, and Californian statutes while my server is actively burning? I'd have to convene a massive legal war room meeting, and that takes days.

You don't navigate them, and you shouldn't try. Wait, really? Really. The job of the AI governance professional in Hour 4 is not to act as outside legal counsel.

Your job is to rapidly simplify the complexity so you can hand a clean, actionable brief to your actual legal team. How do you do that without knowing the laws? You do this by asking five plain English questions to provisionally flag the rows of the matrix. What are those five questions? One, is this system plausibly categorized as high-risk under AI law? Two, did this incident touch anyone's personal data? Three, does any contract we sign mandate a rapid incident notification? Four, has corporate leadership been informed in writing? And five, do the affected people ethically deserve to know? So it's a triage mechanism.

Exactly. You answer those five questions, you flag the relevant matrix rows, and you hand that matrix to your legal counsel. You provision the facts, the lawyers verify the statutes.

So identifying who to call is only half the battle. Knowing when the clock runs out is the real threat. Let's dig into the most dangerous countdown clock of all, the EU AI Act.

The defining rule here is that the Article 73 clock starts on awareness, not on certainty. Let's detail the exact codified time frames. The EU AI Act is severely tiered, correct? Very severely.

Under Article 73, you have exactly two days, 48 hours, to report a widespread infringement or the gravest class of serious incident. Two days. You have no later than 10 days for an incident involving the death of a person, and you have no later than 15 days for the general case of a serious incident.

Wait, I need to pause on that logic. You have 10 days to report a death, but only two days to report a widespread infringement. Why does a systemic software bug get a faster clock than a fatality? Because regulators recognize that a widespread infringement of fundamental rights or a critical infrastructure failure can scale at machine speed, affecting millions of citizens within hours.

Ah, the blast radius is bigger. Exactly. A fatality, while tragic, is a localized event that requires careful medical and forensic verification.

The statute specifically accelerates the timeline for widespread systemic risks to allow regulators to step in and protect the broader public faster. But the time frame itself isn't the real trap, is it? It's the wording of the trigger. The trap is the word awareness.

The statute explicitly says the clock begins after becoming aware. It does not say after concluding your internal investigation. This is massive.

It becomes aware from a legal standpoint. Becomes aware is the most consequential procedural fact in this entire framework. The clock starts the exact moment a reasonable person in your position recognizes that the incident plausibly meets the definition of a serious incident.

It's a smoke detector. A smoke detector doesn't wait for fire. It sounds when it senses smoke, a plausible risk of a fire.

If you wait to pull the building's main fire alarm until you have completed a full forensic investigation of the exact microwave in the break room that caused the smoke, the entire building has already burned to the ground. That analogy is flawless. If your engineering team spends 10 days quietly investigating your server logs to achieve 100% certainty on the root cause before you decide it's a real incident, you have already blown past your two-day or ten-day legal window.

You missed the deadline while you were investigating. But if I report an incident to a regulator on day two and I don't know the root cause yet, don't I look completely incompetent? Won't they penalize me for not having answers? No, and this is a huge paradigm shift for executives. If you report late, you are violating the law.

If you report early with incomplete information, you are complying. That feels counterintuitive to corporate PR instincts. It does, but regulators explicitly expect preliminary incomplete reports.

They expect a notice that says, here is what we know, here is what we strongly suspect, and here is what is still actively under investigation. And there's a major distinction here in the law between a provider and a deployer, isn't there? A crucial distinction. If you built the underlying AI model, you are the provider.

If you are a hospital, a bank, or a retailer using an AI built by a vendor, you are the deployer. As a deployer of a high-risk system, you cannot sit back and wait for your software vendor to report the incident. Your legal duty starts the moment your awareness begins.

So you have to move immediately. You must immediately inform the provider and the market surveillance authority. You cannot outsource your legal compliance clock to Microsoft or Google.

I know some executives listening to this are thinking about timelines right now. They might say, well, the EU AI Act enforcement is deferred. The digital omnibus package pushed the annex third high-risk application date to December 2, 2027, and annex I all the way to August 2, 2028.

I have plenty of time before I need to care about this. A deferred legal deadline is not an excuse to defer building the organizational muscle memory. Right.

If you wait until December 2027 to try and build a 48-hour evidence owner protocol, you will fail your first incident spectacularly. You build the playbook now in peacetime so you aren't inventing a legal framework at 2 a.m. while your servers are on fire. So you have your severity classification.

You've chosen your containment method. Your evidence is locked in the freezer with cryptographic hashes. You've mapped your legal clocks on the matrix.

Now the final hurdle. You have to face the board of directors. Which is where we execute the final phase of the playbook.

Briefing leadership and utilizing what I call the honest exception. Let's talk about those briefings because I've definitely seen executives walk into a boardroom with a 10-page chronologic diary of how hard their engineers worked all night. And the board doesn't care.

No, they don't. Leadership does not need a narrative of your stressful night. They need a highly structured one-page brief delivered at three specific checkpoints.

Hour one, hour eight, and hour 48. Walk me through what is actually written on those three briefs. Hour one.

The goal here is resource authorization and executive cover, not debate. The brief states three things. What we definitively know, what we've done for immediate containment, and what we definitively do not know yet.

Keep it high-level. Yes. You do not invite the board to relitigate whether you should have used a throttle instead of a disable.

You state the facts and secure the budget or personnel you need to keep working. And at hour eight? At hour eight, the board needs to understand their legal exposure. The brief states your working severity classification, the technical logic behind your containment choice, and the provisional notification matrix.

Okay. You look the CEO in the eye and say, based on the matrix, we believe we legally owe a privacy regulator a phone call in exactly 64 hours. And the final checkpoint, hour 48.

The defensible record. This is the document that proves you are a govern mature organization. What goes in it? It provides the final severity classification, the comprehensive containment history, the confirmed status of all preserved evidence, including hashes, and the exact status of every regulatory and contractual notification required.

But let's deal with reality for a second. What happens when 48 hours simply isn't enough time? Right. What if your architecture is so complex that you genuinely cannot trace the model's hallucination or audit the entire affected user base in two days? If I stand up in front of the board at hour 48 and say, we still don't know the root cause, won't they fire me? That anxiety is exactly what causes executives to lie or guess and that is where you must invoke the honest exception.

How does that work? It is the definition of a mature response. You do not force a false confident classification just to appease a nervous CEO. Faking certainty in a regulatory environment is the real failure and it carries massive liability.

So how do you frame that uncertainty defensively? The correct defensible move is to file a provisional report to the regulator, state your uncertainty explicitly in your one-page brief to leadership, and keep the evidence hold running indefinitely. Oh, I see. Stating, we do not have the root cause, but we have locked down the evidence trail, contained the risk, and filed a provisional regulatory notice is what a governed response looks like.

Let's ground everything we've talked about today. I want to walk through an immersive scenario to see exactly how this friction plays out minute by minute between governance, engineering, and leadership. Let's look at a fictional company, North Bank Wellness Collective.

They operate a highly popular AI coaching assistant named Sprout. It gives users personalized advice on diet, exercise, and healthy habits. Okay, it's 9-4-0 on a Thursday.

A tier 3 support ticket is escalated. Sprout has just generated deadly supplement interaction advice, recommending a specific herbal blend to patients who have explicitly noted in their profiles that they are on prescription blood thinners. At 940 p.m., the 48-hour clock starts.

Clyde, who runs AI governance at North Bank, receives the escalation alert. By 10.05 p.m., Clyde is looking at the containment menu, roll back, throttle, disable. Okay.

He gets on a bridge with the lead engineer. The engineer wants to write a quick rejects filter to block the name of the herbal supplement. That is a throttle.

But Clyde pushes back. Why? Because Clyde realizes they don't know the exact prompt that is causing the hallucination, and the LISC isn't a bad recipe. It's deadly internal bleeding.

The throttle isn't enough. Right. A rejects filter is too porous.

Clyde overrides engineering and chooses a full disable. He turns off the entire supplement recommendation feature. The bleeding is stopped.

By 10.20 p.m., he is evaluating the legal severity. He maps it against the EU AI Act criteria. Is it a risk to critical infrastructure? No.

Is it a risk to fundamental rights? No. Is it a serious risk to health? Yes, absolutely. Because it's confident, deadly medical advice to a highly vulnerable patient population.

Exactly. He officially classifies it as a serious incident. But at 10.20 p.m., Clyde doesn't know if three people saw this advice, or 3,000.

Which is exactly why he immediately appoints Priya, a senior data engineer, to be the evidence owner. Her singular objective is to lock the black box. Let's play out the friction Priya faces.

Priya immediately discovers that the North Bank database is scheduled for an automated cleanup script at midnight. She tells the DevOps team to pause the cron job. And DevOps pushes back, I assume.

Of course. DevOps says pausing the script will cause database bloat and trigger latency alerts. Priya has to invoke her authority as evidence owner to force the pause.

That authority is critical. By 11.15 p.m., because the logs weren't deleted, Priya is able to run a query and confirm that exactly 214 members received this specific advice over the last 11 days. She bounded the risks.

She bounded it. She preserves the model version, hashes the specific input and output logs for those 214 users, and secures the perimeter. The evidence is frozen.

Now the clock. At hour 8, early Friday morning, Clyde looks at the notification matrix. Sprout isn't an Annex III high-risk system yet, under the Deferred AI Act timeline, so Article 73 doesn't technically trigger.

However, the AI gave advice based on users' personal health data? They're blood thinner prescriptions. Which immediately triggers the GDPR 72 hour clock. So there it is.

Exactly. Clyde flags this immediately for the legal team. He hands the CEO the hour 8 brief.

We disable the feature. We confirm 214 affected users. We froze the evidence.

And we legally owe the Data Protection Authority a notification by Sunday night. So by hour 48, Saturday night, Clyde isn't scrambling. He is calmly preparing the defensible record.

He hands the founder a one-page document showing exactly how those 214 people were identified, how Priya cryptographically locked down the evidence, and how the GDPR regulator was formally notified at hour 36. Whoa. Clyde didn't panic.

He replaced adrenaline with discipline. He ran the four verbs. Classify, choose, preserve, account.

Let's recap those four verbs one more time. Classify the severity against a strict legal standard, not operational noise. Choose your containment deliberately from rollback, throttle, or disable.

Preserve the evidence before your containment actions destroy it. And account for the full matrix of obligations based on awareness, not certainty. If you run those four verbs with absolute discipline, you survive the 48 hours.

You don't just survive it. You build a forensic record that can withstand the scrutiny of any regulator, any plaintiff's attorney, and any board of directors. So what does this all mean for you, the executive listening to this? I want to leave you with a final provocative thought regarding cross border mapping.

Imagine a single incident occurs on your platform tomorrow. It affects one user in California, one user in Berlin, Germany, and one user in Singapore, all at the exact same millisecond. Think about the invisible tripwires you just crossed, how many different legal clocks just started ticking in your blind spot.

You have California state privacy law, you have German GDPR enforcement, and you have Singaporean data protection regulations. If your internal playbook is only designed for one primary regulator, you are legally exposed on two other continents before you even finish your morning coffee. So here is the single most valuable move you can make this Monday morning when you get to the office.

Do not wait for a 2 a.m. emergency to figure this out. Definitely not. On Monday, gather your governance team and draft the four-part playbook for your highest risk AI system.

Write down your specific legal classification framework. Define exactly what an API level throttle would look like technically for your specific architecture. Name the specific databases and automated scripts your evidence owner must lock down, and pre-fill the rows of your notification matrix.

Make these decisions in the daylight, with a clear head, so you are not inventing a legal framework at 2 a.m. while the fire alarm is deafening. The 48-hour window is entirely unforgiving, but it is entirely manageable if you are prepared. The surgical team is prepped, the tools are laid out.

When the ambulance arrives, you know exactly what to do.

Real cases

These examples sharpen one facet of the 48-hour discipline each. The deep anchor is Pak'nSave's Savey Meal-bot; several others are treated in depth by their owner topics and are referenced here only for the angle this topic needs.

Example 1 (the anchor): Pak'nSave's Savey Meal-bot and the response that never classified, chose, or accounted. In June 2023, Foodstuffs North Island launched Savey Meal-bot, an AI recipe generator built on a general-purpose language model with unrestricted free-text ingredient input. In early August, users discovered it would generate a "recipe" for chlorine gas from a bleach, ammonia, and water prompt, calling it an "aromatic water mix," alongside other dangerous suggestions including a "poison bread sandwich" (Gizmodo, 2023). Read against this topic's four verbs, the company's public response shows every gap this topic is built to close. Classify: the company's first public statement addressed how the tool had been misused, not what harm categories the output could plausibly have caused or to how many of the more than 35,000 recorded sessions (Newshub/Stuff, 2023). Choose: the eventual fix, restricting free-text input toward a curated ingredient list, is a genuine and correct throttle from this topic's menu (3C), but it arrived only after sustained public pressure, not as a considered decision made in the first 48 hours. Preserve: no public account exists of what evidence the company gathered about which users received dangerous outputs before the story broke, a gap that would matter enormously if any user had, in fact, attempted to follow one of the recipes. Account: with no AI-specific incident-reporting law in force in New Zealand at the time, there was no external notification clock to meet, but that also meant the only account offered was a reactive press statement, not a considered leadership briefing built from a completed classification. None of this makes Foodstuffs North Island unusually careless; it makes the company an ordinary one operating without the habit this topic teaches, exactly the gap a competency map identifies when an incident-response skill is thin across an entire market.

Example 2 (rollback done right, from this program's own record): Apple's Intelligence news-summary rollback. When Apple's AI-generated notification summaries were found to be inventing false headlines attributed to real news organizations, Apple monitored the feature, then disabled it, a containment choice this program has already treated in depth (see Topic 3.4). Read against 3C's menu, this is a defensible full-disable rather than a throttle, because the harm (fabricated content attributed to real publishers) was not cleanly traceable to a narrow input pattern the way Pak'nSave's chlorine-gas prompt was; the fabrication risk ran across the whole feature, which is exactly the condition 3C names for choosing disable over throttle.

Example 3 (a fast, mechanical clock that outran a slow human response): Knight Capital. This program's deep treatment of Knight Capital covers the first minutes of a machine-speed incident (see Topic 3.5). Read forward into this topic's window, Knight's forty-five-minute loss and its aftermath illustrate 3D's evidence-preservation point from a different angle: the SEC's findings relied heavily on records that did happen to survive, the automated alert emails, deployment logs, and order records, not because Knight had built a preservation discipline but because those particular records were not the ones anyone thought to delete. A firm that had also lost its logs in the scramble would have faced the same forty-five-minute catastrophe with no way to reconstruct what happened afterward, a considerably worse position than the one Knight was actually in.

Example 4 (an incident that met a legal notification bar, non-AI, cited for the clock mechanics): why "becomes aware" is the trigger, not "confirmed." Data-protection regulators enforcing GDPR's 72-hour breach notification clock have repeatedly rejected the argument that a company's internal investigation period excuses a late notification, holding instead that the clock starts when the organization has a reasonable degree of certainty a breach affecting personal data has occurred, not when the investigation concludes. The same "becomes aware, not becomes certain" logic is what 3F applies to Article 73, and it is worth naming as a general regulatory pattern rather than an AI-specific quirk: regulators across data protection and AI law alike have converged on the same answer to "when does the clock start," because the alternative, letting companies set their own start time by choosing how long to investigate before deciding, would make any fixed deadline meaningless.

Example 5 (a severity miss in the other direction): the Chicago Sun-Times AI-generated summer reading list. In 2025, a syndicated feature section published a summer reading list containing AI-generated, non-existent book titles credited to real authors, without newsroom review before publication (NBC News, 2025). Read against 3B's classification, this incident is a useful contrast case precisely because it sits clearly outside the legal serious-incident categories, no plausible harm to health, safety, critical infrastructure, fundamental rights, or the environment, even though it was reputationally damaging and widely covered. The correct classification of an incident like this is "operationally serious, legally not serious," and a response that spent scarce evidence-preservation and notification effort as if it met the legal bar would be misallocating exactly the discipline this topic teaches you to reserve for incidents that actually do.

Example 6 (a containment choice this program has already treated in depth, read for its throttle logic): the vendor indemnity conditions this program's contract topic covers. This program's treatment of AI vendor contracts shows that major vendors condition their liability protections on the deployer having its guardrails and content filters active. Read forward into this topic, that condition is itself a form of throttle: a vendor that expects its customers to keep filters on is implicitly telling every deployer which containment option preserves both safety and contractual protection at once. A deployer who disables its own safety filters to "simplify" a system, and only remembers the contract's guardrail condition after an incident, discovers the throttle it should have kept running was also the condition its own indemnity depended on, a reminder that 3C's containment menu and a vendor contract's fine print are not separate concerns.

Example 7 (a notification duty this program has already treated, read for its evidence angle): the conformity file's evidence bar. This program's Module 5 treatment of assembling a conformity file establishes that a defensible record needs specific, inspectable evidence rather than a general assurance of good practice (see Topic 5.6). Read backward into this topic, that bar is exactly what 3D's evidence checklist is built to satisfy in advance: a conformity file assembled without a preserved model version, a sample of the actual affected outputs, and a documented containment decision has a hole precisely where an examiner is most likely to press, and no amount of confident narrative fills a hole a preserved record was supposed to occupy.

Where people go wrong

"We contained it, so the incident is basically over." Containment stops new harm; it answers none of the classify, preserve, and account questions this topic covers. An incident with a fast, clean rollback and no classification, no evidence preservation, and no notification check is not finished, it has only stopped getting worse operationally.

"Our own severity scale already tells us how serious this is." Topic 3.5's operational scale answers "how urgently must we move," which is a different question from "does this meet a legal standard for serious," which is answered against the specific harm categories in 3B, not against how loud the incident is internally or on social media.

"If it is not on the news, it is not serious." Reach and reputational visibility are not the legal test. A quiet incident affecting a handful of people can meet the serious-incident bar if the harm is to health, safety, fundamental rights, critical infrastructure, or the environment; a viral, embarrassing incident can miss the bar entirely if the actual delivered harm was reputational.

"Disable everything, always, to be safe." Disabling a whole system when a narrow throttle would have stopped the harm is not automatically the safer choice; it is a choice with its own cost, denying a working feature to every uninvolved user, and it should be made deliberately against the menu in 3C, not by default.

"We will figure out what to preserve after we understand what happened." Understanding what happened is exactly what the preserved evidence is for; waiting until you understand it to decide what to keep is how the evidence that would have let you understand it disappears first.

"Cleaning up the bad outputs is part of fixing the problem." Deleting the harmful outputs from your own systems removes the single most direct proof of what the system actually did. Fix the system; do not delete the evidence of what it did before the fix.

"We do not need an evidence owner; everyone knows to preserve the logs." Everyone knowing is how nobody does it. A named role, distinct from the incident commander, whose only job is confirming preservation, is what turns "we should keep that" into "someone confirmed we kept that."

"The reporting clock starts once we are sure what happened." The Article 73 clock, like the GDPR clock, starts on awareness of a plausible serious incident, not on a completed investigation. Waiting for certainty before the clock "starts" in your own head is how a fifteen-day deadline gets missed while the investigation is still, technically, ongoing.

"We checked whether the AI Act applies; that is our notification duty covered." Obligations stack. An incident can trigger an AI-specific report, a data-protection report, a contractual notice to an insurer, and an internal leadership duty, all at once, on different clocks. Checking one row and stopping is a common and costly incomplete answer.

"We will report once and that is the deadline met." A preliminary report on incomplete facts, followed by a fuller report as the picture clarifies, is the normal and expected pattern under Article 73, not a failure to have "gotten it right the first time." Waiting for a complete report is what actually risks missing the clock.

"Our system is not high-risk yet, so none of this applies to us." The Digital Omnibus deferral changes when a specific legal duty attaches, not whether the underlying discipline (classify, choose, preserve, account) is worth building now. An organization that waits for the deadline to attach before building the habit is improvising exactly when the stakes are highest.

"The board just needs to know we handled it." A leadership briefing that offers reassurance instead of the classification, the containment logic, and the notification status gives a board nothing it can act on, and a board that later learns it was told less than the team knew has a trust problem layered on top of the incident.

"We will write the leadership briefing once, at the end, when we have the full picture." The three-checkpoint discipline (hour one, hour eight, hour forty-eight) exists because leadership needs to make decisions during the window, not read a summary after it closes; a single end-of-window briefing means leadership was flying blind for the two days when decisions actually had to be made.

"If we cannot classify it confidently, we should wait to report until we can." The honest exception in 3J is explicit: report provisionally where a duty's trigger is plausibly met, state the uncertainty, and keep preserving. Silence while you wait for certainty is not a neutral choice; it is a choice to let the clock run unanswered.

"A throttle is a half-measure; only a full disable shows we take this seriously." A throttle that correctly narrows the harmful input pattern while preserving a working feature for uninvolved users is not a half-measure, it is frequently the more disciplined choice, because it is proportionate to what you actually know rather than performative.

"New Zealand had no AI incident law, so Pak'nSave did nothing wrong." Not having a legal notification duty to break is not the same as having run a disciplined response. The four verbs, classify, choose, preserve, account, are worth doing even where no specific law compels the last one, because the first three protect real people and the organization's own ability to explain itself regardless of jurisdiction.

"We already have an incident runbook from Topic 3.5; this is redundant." The Topic 3.5 runbook governs the first hour's operational response. This topic's playbook governs the classification, containment choice, evidence, and notification obligations across the following 47 hours, a genuinely different set of decisions that the first-hour runbook does not and should not try to also cover.

"Once we file the AI-specific report, the incident is legally closed." Filing one applicable row of the notification matrix is not the same as completing it. A single incident routinely triggers more than one obligation at once, and each row runs on its own clock to its own recipient until it, too, is checked and actioned.

"We operate in one country, so we only need to think about one regulator." Many AI systems serve users across borders even when the company itself is headquartered in one place. An incident affecting users in multiple jurisdictions can implicate more than one authority and more than one legal regime at once, and a playbook built around a single country's law will be blind to the others.

"The evidence checklist is the legal team's job, not engineering's." The evidence lives in engineering's systems (model versions, logs, deployment history), and only engineering can execute the preservation steps in time; legal counsel interprets what the evidence means and what it obliges the organization to do, but cannot preserve data it does not have direct access to capture.

"If leadership does not ask for an update, we do not need to send one." The three-checkpoint discipline is proactive by design. Waiting for leadership to ask is how a serious incident's first news to the board becomes a journalist's phone call rather than the team's own briefing, exactly the self-inflicted second crisis this topic exists to prevent.

"A preliminary report locks us into that version of events." A preliminary report is explicitly framed as incomplete, naming what is known, what is suspected, and what remains under investigation; it is not a final position the organization is bound to defend unchanged, and a fuller report that updates the picture as facts clarify is the expected, normal follow-up, not a contradiction of the first filing.

"We should decide who is at fault before we decide what to report." Assigning blame is not a prerequisite for classification or notification, and chasing it first delays both; the classification test asks what harm occurred or could plausibly occur, not who caused it, and the notification clock does not wait for an internal fault-finding process to conclude.

Questions people ask

What is 48-hour incident playbook?: The four-part document this topic's lab produces: a classification framework, a containment decision tree, an evidence-preservation checklist with a named owner, and a notification matrix, built in advance and filled in during a real incident.
What is legal severity classification?: The test of whether an incident meets a defined legal standard for "serious," independent of and sometimes in tension with an organization's own operational severity scale.
What is serious incident (EU AI Act)?: Under Regulation (EU) 2024/1689, an incident that directly or indirectly leads, or might lead, to the death of a person or serious harm to health, a serious and irreversible disruption of critical infrastructure, an infringement of Union law protecting fundamental rights, or serious harm to property or the environment. More on Serious incident (EU AI Act)
What is containment menu?: The three real options for stopping an AI incident's harm: rollback (return to a known-good version), throttle (narrow inputs, outputs, or reach without full shutdown), and disable (turn the feature off entirely), chosen deliberately against the cause and reach of the specific incident.
What is throttle?: A containment action that restricts what an AI system is allowed to do, its input format, its output type, or the population it serves, without shutting it down entirely; proportionate when the harm traces to a specific, identifiable pattern.

Credential program

You know something most people in the room do not. Right now, nobody can check that you do.

Certified AI Governance Professional (CAIGP) is where this lesson and every other one in it become proof. Every topic has a pass gate, and what you pass goes on a record an employer can open and check, topic by topic. Reading is the free part. Being able to show it is the part that moves you.

14 modules, 98 topics, each with a lesson and a graded quiz.
Opens with “Why decisions, not information, will make you the expert”, and every lesson is free with a free account.
The Professor on every topic: a first look free, one on one on every topic when you certify.
A mastery exam at the end, then a credential anyone you send it to can verify.
Your progress is saved to your account, on any device.

To start

Free

A free account opens every lesson in this program and starts a practice record of your quiz scores. No card is asked for.

Keep going

Previous lessonThe AI contract: the clauses that protect you when the vendor's model fails Next lessonDistrust is a skill: why demos convince and evals do not lie Builds the same skillThe 2 a.m. incident: your system fails live, stakeholders are calling, run the response Builds the same skillContinuity When the Model Goes Down

This lesson builds AI incident response and recovery, and that page shows the roles that hire for it. Every Certified AI Governance Professional (CAIGP) lesson.