Lesson 5 · AI Governance Basics
Incident recognition and escalation
- Length
- 27 minutes across 7 sections
- You will be able to apply
- Recognise, Contain, Preserve, Escalate
- You will produce
- Commit Statement
- You will work
- 3 gated questions
Personalize the practice
Apply this to your environment
These details adapt the application prompts and coach questions. They do not affect your score.
The incident you handled quietly is the one you will have again.
Core question
branching
Choose the first incident path you would actually take
Required practiceA dispatcher at OmniCorp Logistics corrected an AI-drafted delivery window yesterday before the customer saw it. Nothing external went wrong, and this is the only case anyone has mentioned. What is your first move?
AI incidents rarely announce themselves. There is no alarm, no outage page, no red banner. There is a person noticing that an output is wrong, fixing it, and moving on with their afternoon. By the time an AI incident looks like an incident, it has usually been happening for weeks.
So the hard part is not the response. Most organisations respond competently once they know. The hard part is recognition, and the reason recognition fails is almost never technical.
The pathology: Quiet Recovery
Someone spots a fabricated figure in a draft before it goes out. They correct it. It took ninety seconds. They do not report it, because nothing happened: the control worked, the output was fine, and reporting it would mean a form, a conversation, and the implication that their team's AI use is a problem. Multiply that by every competent person in the organisation.
The counter is to make the near miss the primary reportable event rather than a lesser category of one.
The evidence is destroyed, the class is never named, and the log contains only failures nobody caught.
- Quiet Recovery
- The evidence is destroyed, the class is never named, and the log contains only failures nobody caught.
- Reported near miss
- The pattern becomes visible before harm occurs, and containment can address the class rather than the instance.
Recognise, Contain, Preserve, Escalate
Definition
Four steps in fixed order. Recognise: name what class of failure this is, before deciding whether it matters. Contain: stop the flow, which means stopping further outputs of the same class, not merely correcting this one. Preserve: capture the prompt, the output, the timestamp, the account and the version, before anything is regenerated or cleared. Escalate: tell the named owner and the reporting path, including when you have already fixed it.
The order is not a suggestion. Preserve before escalate, because the first thing escalation triggers is somebody trying to reproduce the problem, and reproduction destroys the evidence of what actually happened. Contain before preserve, because containment is time-critical and preservation is not.
When to Use It
Use it for every near miss, not only for events with consequences. A fabricated citation caught in review is the same event as one that reached a customer, differing only in whether a person happened to be looking. Treat them identically and the near miss becomes your early warning system.
Use it also when the failure was your own: your prompt, your data, your oversight. Self-reported near misses are the highest-value entries in any log, and an organisation that punishes them will not receive a second one.
How to Apply It
- Name the failure class before assessing severity: fabrication, disclosure, bias, drift, misuse, or unavailability.
- Contain the class rather than the instance, and accept that this may mean pausing a workflow that is mostly working.
- Preserve prompt, output, timestamp, account, tool version and who was in the loop, before anyone regenerates anything.
- Escalate within a stated window even when the issue is already resolved, and record it as a near miss if no harm reached anyone.
| Failure class | What it looks like | Contain by |
|---|---|---|
| Fabrication | A confident statement with no source behind it | Pausing the output class until the evidence check is reinstated |
| Disclosure | Sensitive content reaching an unapproved destination | Cutting the route and identifying every prior instance |
| Bias | Systematically worse outcomes for one group | Suspending the affected decision path, not the whole system |
| Drift | Quality degrading gradually after a model or prompt change | Reverting to the prior version while you compare |
| Misuse | The system used for a task it was never gated for | Withdrawing access for that task and reopening the request lane |
Worked example 1 of 3
A drafting assistant at OmniCorp Financial produced a customer letter citing a regulatory reference that does not exist. A servicing agent noticed, deleted the sentence, and sent the letter. Two weeks later a colleague found the same fabricated reference in a different letter. Marisa Delgado walked the four steps with them.
- Marisa Delgado
- Recognise. What class is this?
- Servicing agent
- Fabrication. It invented a rule reference.
- Marisa Delgado
- Contain. What stops the class, not the sentence?
- Servicing agent
- Pausing any letter that cites a regulatory reference until we check them all.
- Marisa Delgado
- Do that now. Preserve. Have you still got the original output from a fortnight ago?
- Servicing agent
- No. I edited it in place.
- Marisa Delgado
- Then we have lost the first instance, and that is the cost of the quiet fix. Escalate anyway, and log it as a near miss with what you remember.
The review found the fabricated reference in nine sent letters over five weeks. Every one had passed a human reader. Nobody had reported the first.
Why This Works
Naming the class before assessing severity is what makes containment possible. Severity-first thinking evaluates the instance, concludes correctly that this instance was minor, and stops. Class-first thinking asks what else has this shape, which is the only question that finds the other eight letters.
Preserving before escalating works because AI failures are frequently unreproducible. Regenerate the same prompt and you may get a clean answer, at which point the incident is quietly reclassified as a misunderstanding and the underlying pattern survives. The artifact is the only durable evidence that it happened at all.
Worked example 2 of 3Optional depth
Trevor Okafor at OmniCorp Retail received a near-miss report about product descriptions containing a certification the supplier had never claimed. Recognise: fabrication. Contain: he paused generated descriptions for the whole category, not just the flagged product, which took eleven hundred items offline for two days and was unpopular. The category-wide check found the same fabricated certification on nineteen items. Containing the instance would have found one, felt proportionate, and left eighteen live.
Worked example 3 of 3Optional depth
Jo Halvorsen at OmniCorp Studio had no incident process and did not want one. What she built took a morning: a channel where anyone posts what happened, the prompt, and the output, before fixing anything, and a standing five minutes in the Monday meeting to read the week's entries. In four months it captured eleven near misses, two of which were the same failure class from different people, which is the pattern nobody would have seen otherwise. An incident process is a place to put it and a habit of reading it. Everything beyond that is refinement.
Edge Cases and NuancesOptional depth
Some incidents are the absence of an event: a system that stops flagging anything is failing loudly and silently at once. Some are legally sensitive, where preservation must be handled so it does not compromise privilege or a notification duty, so escalate early rather than investigating alone. Vendor-side incidents may be invisible to you entirely, which is an argument for contractual notification obligations rather than for monitoring you cannot perform. And a near miss caught by a control is evidence the control works and evidence the failure occurred: recording only the first half is how organisations reassure themselves into the next incident.
Name the failure class before assessing severity, so containment can address the pattern.
- Recognise
- Name the failure class before assessing severity, so containment can address the pattern.
- Contain
- Stop further outputs of the same class, not merely the single instance you found.
- Preserve
- Capture prompt, output, timestamp, account and version before anything is regenerated.
- Escalate
- Tell the named owner and the reporting path, even when you have already fixed it.
Knowledge check
Why does the framework require you to contain the class rather than the instance?
Common Failure Modes
The response end to end
Dr. Naomi Ellery was told, informally and in a corridor, that a clinical summarisation tool had twice omitted an allergy from a discharge summary. Both had been caught at signature. Neither had been reported.
Recognise: not fabrication but omission, a distinct class, and one that no evidence check for invented content would ever catch. Contain: she suspended the summarisation of any note containing an allergy field, which affected roughly a third of throughput and generated immediate pushback about the burden that placed on clinicians. She held it, because the class was omission of safety-critical fields and the containment had to match the class rather than the two known instances.
Preserve: the two known cases had been edited in place and were unrecoverable, so she preserved what existed, the signed versions and the underlying notes, and required raw capture from that point on. Escalate: to the clinical governance lead within the day, and to the supplier, whose response was that the model was not designed to guarantee field completeness. That sentence was the finding. The tool had never promised what everyone had assumed it did.
The retrospective review across four months found eleven further omissions, none reported, all caught at signature by clinicians who had assumed they were the only one. Eleven separate acts of competence, each individually correct, together forming a blind spot that had lasted a third of a year.
Decision point
Priya Raghunathan at OmniCorp Logistics is told by a dispatcher that an AI-drafted customer notification stated a delivery window that did not match the dispatch system. The dispatcher noticed, corrected it, and sent the right window. This happened yesterday. Nothing reached the customer incorrectly, the dispatcher is experienced and reliable, and it is the only case anyone has mentioned. What do you do?
Self-check
Mark the level that describes you today. Nothing is submitted.
| Behaviour | Ready | Developing | Not yet |
|---|---|---|---|
| Recognising the class | |||
| Containing | |||
| Preserving and escalating |
Commit
Commit Statement
Complete every line in your own words, then sign and date it. Attach the near miss you did not report.
| Window | Field application |
|---|---|
| Days 1 to 7 | Capture before you correct, every time, and log one near miss you would previously have fixed quietly. |
| Days 8 to 21 | Ask three colleagues what they have quietly corrected in the last month, and count how many are the same class. |
| Days 22 to 30 | Take one logged near miss and run the containment question properly: what else has this shape. |
Four steps and an honest near-miss log will let a team see its own failure patterns before they become incidents. They will not tell you when a regulator must be notified and within what window, how to preserve evidence without compromising privilege, or how to run a post-incident review that produces a change rather than a document. Building incident management that stands up to external scrutiny is the capability the paid programs develop next.
Learner feedback