It is 6:40 on a Tuesday evening when the message reaches your phone: a hospitalist has just discovered that an AI-drafted discharge summary listed a medication the patient was never prescribed, the patient went home on it two days ago, and the covering nurse is on the line asking what to do. In that moment, the quality of your program is not decided by your governance charter or your validation binder. It is decided by whether anyone in your organization knows who to call, what to preserve, and how to care for that patient in the next fifteen minutes. This lesson is about building the answer to those questions before the phone rings, because an incident response you invent during the incident is not a response, it is a scramble with a patient in the middle of it.

Why AI Needs Its Own Incident Response Muscle

Every hospital already has a patient-safety event system. You have an incident reporting tool, a risk-management team, a process for serious safety events, and a rhythm of morbidity-and-mortality review. The instinct, a good one, is to route AI events straight into that existing machinery rather than building a parallel bureaucracy. That instinct is correct as far as it goes, and this lesson will insist on the connection. But an AI-related event has features your existing system was not designed to capture, and if you do not add those features deliberately, the event will be logged as an ordinary error and the AI-specific evidence will evaporate before anyone thinks to look for it.

Consider what makes an AI event different. When a clinician makes a manual error, the record captures what happened: the wrong order, the missed value, the note. When an AI contributes to an event, there is a second layer that ordinary reporting ignores. There was an AI output, a specific draft or score or suggestion. That output was produced from a prompt and a context, the recorded conversation, the chart data the tool ingested, the question asked. It came from a specific model version, which may be silently updated next week. And a human took an action in response, accepting, editing, or overriding it. None of those four things lives in the standard incident form, and all four are exactly what you will need to understand what went wrong, defend the organization, and stop it recurring. A program that cannot reconstruct the AI output, its inputs, its version, and the human's action is a program that will investigate every AI event blind.

This is the strategist's job at the end of Level 4. You have built the board-ready strategy, the vendor rubric, the governance charter, and the validation and monitoring plan. Incident response is the machinery that catches what all of that prevention misses, because prevention is never perfect and the mature question is not whether an AI event will happen but whether you are ready when it does. An organization is not judged by whether it had an incident. It is judged by how it responded.

Care for the Patient First, Always

Before anything else in this lesson, the first rule: the patient comes before the investigation. When an AI output may have harmed a patient, the immediate obligation is clinical, not forensic. Stabilize, correct, and disclose to the degree your policies and the clinical situation require, exactly as you would for any safety event. The medication the patient should not be taking gets stopped and the patient gets contacted; the missed abnormal value gets acted on; the wrong-laterality plan gets corrected. Nothing about the AI involvement changes the primacy of the patient in front of you, and any incident-response design that puts evidence preservation ahead of patient care has its priorities inverted and will fail a surveyor, a family, and its own conscience.

Here is the tension you must design around: caring for the patient and preserving the evidence can pull against each other, because fixing the record is exactly what destroys the forensic trail. The nurse who deletes the wrong medication from the active list to protect the patient has also, without meaning to, altered the evidence of what the AI produced. The resolution is not to slow down patient care. It is to build preservation into the workflow so that it happens automatically alongside the correction, not instead of it. Your incident process should let a clinician fix the patient's chart while the system quietly captures a snapshot of what the AI output said before the fix. Care first, and let the structure preserve the evidence so the human does not have to choose.

An incident response you invent during the incident is not a response. It is a scramble with a patient in the middle of it. The time to decide who is called and what is preserved is before the phone rings.

What You Preserve, and Why Each Piece Matters

The heart of AI incident response is preservation, because the AI-specific evidence is fragile in a way ordinary evidence is not. Notes get signed and locked; AI drafts and model versions do not, and a routine update or a cleared cache can erase the only record of what the tool actually did. Teach your responders to preserve five things, and teach them why each one matters, because a responder who understands the why will preserve well under pressure and a responder following a checklist blindly will not.

The AI output. The exact text, score, or suggestion the tool produced, captured before anyone edits it. This is the primary artifact. Without it you are investigating a rumor of what the AI said, and a rumor will not survive an M&M review or a deposition. If the fabricated medication was corrected in the chart, you still need the original draft that contained it.

The prompt and context. What the tool was given to work with: the recorded encounter audio or transcript, the chart data it ingested, the specific question a clinician asked it, the retrieved documents it drew on. An output is only interpretable against its inputs. A summary that dropped an abnormal lab is one kind of failure if the lab was in the source and another kind entirely if it was not, and you cannot tell which without the context.

The model version. The specific version, build, or configuration of the tool in use at the moment of the event. This matters more than it sounds. Vendors update models continuously, and the behavior you are investigating may not exist in next week's version, or a new version may have introduced it. Without the version stamp you cannot tell the vendor what to reproduce, cannot know whether a fix landed, and cannot tell whether your validation still applies. This is also where your vendor rubric and contract pay off: you should have negotiated the right to know the version and to be notified of changes.

The record. The state of the chart at the time, including what was ordered, signed, and acted upon. This anchors the AI output to real clinical consequence. It tells you whether the bad output reached the patient or was caught, and it is the difference between a near-miss to learn from and a harm event to disclose.

The human actions. What the clinician did with the output: accepted it verbatim, edited it, overrode it, or never saw it. This is the most important piece for root-cause work, and the easiest to lose because it lives in memory and in audit logs that may not be retained. Whether the human verified and was defeated by a plausible fabrication, or never verified at all, points to entirely different fixes. Capture it while it is fresh, ideally through the audit trail rather than recollection alone.

The Five Artifacts, How to Capture Them, and How They Are Lost

Preservation is a mechanics problem, not a slogan. For each artifact, your responders need to know exactly how to capture it and exactly how it disappears if they do not. Put this on the serious-event checklist so it is not left to memory at 6:40 on a Tuesday.

Chain of Custody and Audit-Trail Retention

Preserving the five artifacts is only half the job; the other half is being able to prove that what you preserved is what actually happened, unaltered. This is chain of custody, the same discipline a laboratory or a pharmacy applies to a controlled specimen, translated to digital evidence. When you snapshot the original AI draft, capture who captured it, when, and from where, and store it somewhere the responders cannot quietly edit. Timestamp everything. A preserved artifact with no provenance is weaker in an M&M review and far weaker in a deposition than one you can trace end to end.

Audit-trail retention is where many programs quietly fail. The EHR audit log that shows a physician signed a draft at 2:14 and never opened the medication section is exactly the human-action evidence you need, but default retention windows are often short and the log may be pruned before an investigation begins. Decide in advance how long AI-relevant audit trails and preserved artifacts are retained, align it to your record-retention policy and any litigation-hold requirements, and confirm your informatics team can actually produce the log for a given encounter on demand. If you cannot retrieve the audit trail six weeks later, you do not have the human-action artifact, whatever your checklist says.

Triaging the Event and Setting Severity

Once the patient is cared for and the evidence is preserved, the event must be triaged, and triage in AI incidents answers two questions at once: how bad was the outcome, and how systemic is the cause. An ordinary safety severity scale handles the first. AI events need a second axis for the second, because a single fabricated medication in one note and a summarization model that has been silently dropping abnormal values across thousands of charts are wildly different problems that can produce identical individual outcomes. The first is a discrete event; the second is a latent hazard affecting a population, and it may be quietly harming patients who have not been discovered yet.

Practically, define severity along the familiar patient-harm dimension first: no harm and caught before reaching the patient (a near-miss, still worth reporting), reached the patient with no harm, reached the patient with temporary harm, reached the patient with serious or permanent harm, or contributed to death. This is the language your existing safety system already speaks, and mapping AI events onto it is what connects the two systems. Then add the systemic question: is this a one-off, or is the underlying AI behavior likely to be affecting other patients right now through the same tool? A high answer on the second axis triggers something an ordinary event does not: consideration of whether to pause or restrict the tool while you investigate, a decision that belongs to your governance structure and that you should have pre-authorized someone to make on an emergency basis.

The Two-Axis Triage Matrix

The value of two axes is that they can disagree, and their disagreement is exactly the information a single severity score would hide. Read the matrix by finding the outcome in a row and the systemic reach in a column; the cell tells you the disposition. Note that a low-harm, high-reach cell can demand more urgent action than a high-harm, isolated one, because the low-harm event is a warning shot from a hazard still live across the population.

Containment: Stopping the Bleed Without Pulling the Whole EHR

When triage flags a high systemic risk, the natural fear is a false choice between doing nothing and shutting everything down. Neither is acceptable. Pulling the whole EHR or disabling an entire ambient platform to stop one misbehaving function creates its own patient-safety event, because clinicians lose the documentation and decision support they depend on across every patient. Mature containment is surgical: you restrict or pause the one AI function implicated while leaving everything else running.

Work these containment mechanics out with your vendor and informatics team before you need them, so the options exist as switches rather than emergency engineering. Common containment moves, from lightest to heaviest, include the following.

• Mandatory line-by-line review. The function keeps generating output, but the workflow forces the clinician to review and attest to each section before it can be signed, removing the fast accept-verbatim path that let a fabrication through.
• Shadow or read-only mode. The AI still produces output for evaluation and monitoring, but it cannot write to the chart or drive an order, so you can watch its behavior without letting it reach a patient.
• Feature-level pause. The specific function, say the discharge-summary generator, is switched off while the rest of the ambient documentation tool continues, so clinicians fall back to the prior manual workflow for that one task only.
• Full tool suspension. Reserved for a broad, unbounded hazard where you cannot isolate the failing function, and taken with eyes open to the workflow harm it causes.

Notice that each of these is a fallback to a known-safe state, not a leap into the unknown. The clinician who loses the discharge-summary generator still knows how to write a discharge summary. That is the point of designing containment around graceful degradation: the safe fallback already exists in the workforce's muscle memory. Containment only works if someone is empowered to trigger it fast, and the single most common containment failure is not a missing switch but a missing decision-maker: the hazard is real at 6:40 on a Tuesday, and no one is sure who has the authority to pause the function, so nothing happens until a committee can be assembled in the morning while patients keep flowing through the same defect. Fix this in advance. Your governance structure should name, by role, who may authorize an emergency pause or restriction, define the narrow criteria that justify it, and pre-authorize that person to act ahead of a full committee review with a required prompt debrief afterward. Pre-authorizing the decision is not abandoning governance; it is governance deciding, calmly and in advance, how it wants to act under time pressure.

Roles and Escalation: Who Is Called

The phone call that opened this lesson has to reach the right people, and in the right order, without the clinician on the unit having to figure out an org chart at 6:40 on a Tuesday. Pre-define the roles and the escalation path so that reporting an AI event is one action, not a research project. At minimum your response involves the frontline clinician who found it, a clinical supervisor or charge nurse who can act immediately on the patient, risk management and patient safety who own the formal event, and a designated AI or informatics contact who understands the tool and can preserve the technical evidence. For serious or systemic events, the escalation climbs to your AI governance structure, the CMIO or equivalent, compliance and legal, and, when the cause points at the tool itself, the vendor under the terms you negotiated. Patients and families are informed per your disclosure policy, and, where an AI use must be disclosed under state law, that obligation does not disappear because an error occurred.

Sequence and timing matter. The chain is not a group text sent to everyone at once; it is an ordered notification where each link owns a specific action and triggers the next. The table below is a template to adapt to your own structure, not a mandate, but the ordering principle holds: care and containment first, formal ownership next, then the governance and external links that most organizations mishandle by calling them too late.

The single most common failure here is not having a designated AI contact at all, so the event lands in the general safety queue, gets triaged as a documentation error, and the model version and prompt context are gone by the time anyone realizes AI was involved. Name that role in advance. Give the frontline the one number to call. Make the AI-involvement flag a required field on your event report so the event routes itself. The difference between a program that learns from its incidents and one that repeats them is usually just whether the AI-specific evidence survived the first hour, and that survival is a design decision you make now, not a heroic act you hope for later.

From the Preserved Record to a Structured Root-Cause Analysis

Preservation is not the goal; it is the fuel. The reason you fight to keep the five artifacts alive through the first hour is that they are precisely what a structured root-cause analysis needs to reach a real answer rather than a comfortable one. An RCA that has only the corrected chart and a clinician's recollection will conclude something bland, a documentation error, and change nothing. An RCA holding the original output, the context that produced it, the version, the record, and the human action can reconstruct the timeline, locate the true failure point, and prescribe a fix that fits.

Timeline Reconstruction and Classifying the Human Action

The first move in the RCA is to lay the artifacts on a timeline: the encounter and its context, the moment the model produced the output, the point the human accepted or edited it, the moment it entered the record, and the moment the consequence reached the patient. That timeline is what turns five separate artifacts into a story of causation. It also forces the single most important distinction in AI root cause, the classification of the human action.

Ask whether the clinician verified and was defeated by a plausible fabrication, or never verified at all. These are different failures with different fixes. A clinician who checked the medication list against the source and still missed a fabrication that looked entirely reasonable points to a tool defect, a presentation problem, or a verification aid that is needed but absent; the fix is technical and design-level. A clinician who signed a beautiful draft without checking points to automation bias and a workflow that made the fast unverified path too easy; the fix is a forcing function, training, or a mandatory-review containment step. Blaming the individual in either case is the wrong move, but so is treating both as the same event. The audit trail is what lets you tell them apart, which is why you fought to preserve it.

Discrete Event Versus Latent Population Hazard

The RCA must also answer the systemic-axis question with evidence, not intuition: is this a discrete event that happened to one patient, or the visible tip of a latent hazard affecting a population? The preserved version and context let you query whether the same model build and the same conditions could be producing the same failure elsewhere, and a targeted look-back across recent charts produced by that function can confirm or rule out a cluster. This distinction changes everything downstream. A discrete event closes with a local fix and a lesson; a latent population hazard triggers containment, a broader look-back for patients already affected, and a materially different conversation with the vendor and the board.

Feeding Findings Back Into Monitoring, Governance, and the Board

A root-cause analysis that ends in a binder has failed. The findings must flow back into the machinery you built across Level 4. A verification-gap finding becomes a monitoring metric, a new alert, or a forcing function in the workflow. A tool-defect finding becomes an item in vendor management, a contract-performance conversation, and a re-validation requirement before the fixed build is trusted. A pattern across several incidents becomes a governance agenda item and, if the risk is material, a line in the board report where the dual-axis metrics, value on one axis and risk on the other, are fed by exactly this pipeline. Each preserved artifact you insisted on has a downstream home, and the loop only closes when it lands there.

A Worked Example: The Phantom Medication

Return to the discharge summary. Walk it two ways, because the contrast is the whole lesson. In the unprepared organization, the covering nurse calls a general help line, is told to correct the chart and file an incident report, and does exactly that: she removes the medication from the active list, contacts the patient to stop it, and writes up a documentation error. The report enters the safety queue as a medication-list discrepancy. Three weeks later, quality notices a cluster of similar discrepancies and asks informatics whether the ambient tool could be involved. Informatics cannot answer, because the original AI drafts were overwritten when the notes were finalized, the tool was updated eleven days ago, and no one recorded which version produced the summaries. The organization cannot tell whether it has a solved problem or an active hazard still generating phantom medications tonight. It cannot tell the vendor what to fix. It cannot show a surveyor what it learned. The patient was cared for, which is what matters most, but the institution learned almost nothing and remains exposed.

In the prepared organization, the same nurse calls the one number, states that an AI output may have harmed a patient, and the flow fires. The patient is cared for first: the medication is stopped, the patient contacted, the chart corrected. As she corrects it, the system captures a snapshot of the original AI-drafted summary, its source encounter transcript, and the model version stamp, because preservation was built into the incident action rather than left to her memory. The designated informatics contact confirms which model build produced the note and pulls the audit trail showing the physician signed the draft without editing that section, a human-action detail that will matter enormously for root cause. Triage rates the outcome as reached-the-patient, no lasting harm, and flags the systemic axis as high because the same model and workflow are in use across the service. Governance, pre-authorized for emergency action, restricts the tool's discharge-summary function to mandatory line-by-line review pending investigation, and the vendor is engaged with a reproducible version and prompt. Same patient, same error, entirely different institutional outcome, because the response existed before the incident did.

Then the RCA runs on real fuel. The timeline shows the fabrication entered at model generation and survived because the physician signed without opening the medication section, a never-verified action pointing at automation bias and a too-easy accept path. A look-back across the version and context confirms three more summaries from the same build carried plausible but unordered medications, turning a discrete event into a confirmed latent hazard. The findings feed back: a mandatory-review forcing function on discharge summaries, a monitoring signal for unsupported medication lines, a vendor re-validation requirement on the next build, and a line in the quarterly board report. The patient was cared for in the first fifteen minutes, and the institution came out of the event safer than it went in. That is the entire point.

Connecting to the Systems You Already Have

The final design principle is the one that keeps this from becoming shelfware: AI incident response is not a new empire, it is an extension of the patient-safety machinery you already run. Do not build a separate reporting tool, a separate committee, or a separate culture. Add an AI-involvement flag to your existing event report. Add the five preservation items to your existing serious-event checklist. Give your existing risk-management and patient-safety teams a designated AI contact to pull in. Route AI events into your existing M&M and safety-committee rhythm, with the AI-specific evidence attached so the review is real. The reason to connect rather than build parallel is not tidiness; it is that a parallel system will be bypassed under pressure, while an extension of the system clinicians already use on their worst days will actually fire.

This is also where incident response feeds back into everything else in Level 4. Every AI event, investigated properly, is data for your monitoring plan, evidence for your governance structure, a test of your vendor relationship, and a line item in what you report to the board. The dual-axis metrics you learned to build, value on one axis and risk on the other, are fed by exactly this pipeline: an organization that surfaces, preserves, and investigates its AI events honestly is the one that can report risk credibly, because it actually knows what its risk is. An organization that buries them under generic error codes is flying blind and reporting a comforting fiction. Incident response is where the strategist's prevention meets reality, and where the record you have insisted on all along, the record that proves a human decided, becomes the record that proves your program can be trusted.

Key Takeaways

• An incident response invented during the incident is a scramble with a patient in the middle of it. Decide who is called, what is preserved, how the event is triaged, and who may pause the tool before the phone rings, because prevention is never perfect and maturity is measured by the response.
• Care for the patient first, always. Stabilize, correct, and disclose exactly as for any safety event; never let evidence preservation come ahead of patient care, and design the workflow so preservation happens automatically alongside the correction.
• Preserve five fragile things that ordinary reporting misses: the AI output itself, the prompt and context that produced it, the model version, the state of the record, and the human actions taken in response, and protect them with chain of custody and defined audit-trail retention.
• Contain surgically: restrict or pause the one implicated AI function through mandatory review, shadow or read-only mode, or a feature-level pause, rather than pulling the whole EHR, and pre-authorize by role who may trigger an emergency pause.
• Triage on two axes: the familiar patient-harm severity, and a second systemic axis asking whether the same AI behavior is affecting other patients right now, because a low-harm, high-reach event can demand more urgent action than an isolated serious one.
• Pre-define an ordered notification chain, from frontline to charge to risk and patient safety to a designated AI contact to governance, compliance, and vendor, so the AI-specific evidence survives the first hour instead of being lost in the general queue.
• Feed the five preserved artifacts into a structured RCA that reconstructs the timeline, classifies the human action as verified-and-defeated versus never-verified, distinguishes a discrete event from a latent population hazard, and prescribes a fix that fits.
• Do not build a parallel bureaucracy. Extend the patient-safety event system you already run, and feed every RCA finding back into monitoring, governance, vendor management, and board reporting, because the institution that surfaces and preserves its events honestly is the only one that can report its risk credibly.