It happens on a Tuesday afternoon. A patient has been harmed, and an AI tool was somewhere in the chain: an ambient note that carried a wrong medication, a summary that hid an abnormal value, a risk score that steered a decision the wrong way. In the first minutes, none of that matters, because there is a patient who needs care right now. But in the minutes after that, a second clock starts, and most clinicians have no training for it. The evidence of how the AI actually contributed, the output, the prompt, the version, the record, is fragile and disappearing, and the reflexes that serve you well in a conventional adverse event can quietly destroy it. This lesson is about both clocks: caring for the patient first, and then preserving the truth of what happened before it evaporates.

The Patient Comes First, Always

Let there be no ambiguity about the order of operations, because it is the one part of this that is not new. When AI has contributed to harm, the first and overriding priority is the patient, exactly as in any adverse event. Stabilize, treat, escalate, mobilize the team, do everything clinical judgment demands. Nothing about the AI dimension changes this. The tool's involvement does not create a special category of emergency that competes with the patient's needs; the patient's needs come first, full stop, and any framework that suggests otherwise has lost the plot. Everything else in this lesson happens in the space that opens up after the patient is safe, and it must never be allowed to intrude on the care itself.

It is worth naming this plainly because the rest of the lesson is about evidence, and a discussion of evidence can subtly imply that documentation competes with care. It does not. The evidence work is a second-order task that begins once the immediate clinical situation is controlled. A clinician who delays a needed intervention to screenshot an AI output has misunderstood the priority entirely. First the patient. Then, and only then, the record of what happened.

Hold onto that image of two clocks, because it is the organizing idea of the whole lesson. The first clock is the one you already know how to read: it is the clinical clock, and it runs the way it always has when a patient is in trouble. The second clock is the one this lesson exists to teach, because almost no one has been trained to hear it ticking. It is the evidence clock, and in an AI-related event it runs fast and it does not wait. The skill is not to run both clocks at once, which would be dangerous, but to know that the second one exists, to let the first one finish, and then to move on the second one before it runs out. Most clinicians default to the reflexes of a conventional adverse event, where the evidence sits patiently until the paperwork gets done. That default is exactly what quietly destroys the AI evidence, and knowing that in advance is most of the fix.

The Second Clock: Preserve the Evidence

Here is what makes an AI-related event different from a conventional one, and why it demands a reflex most clinicians have never built. In a traditional adverse event, the relevant evidence, the orders, the notes, the medication record, the monitor strips, is relatively stable and lives in systems designed to retain it. In an AI-related event, a crucial part of the evidence is unusually fragile. The AI's raw output may be overwritten the moment it is edited. The prompt and the context that produced it may not be stored at all, or may be purged on a short cycle. The specific version of the model that generated the output may be updated next week, so that the tool you could examine tomorrow is not the tool that erred today. This evidence has a short half-life, and once it is gone, the ability to understand what actually happened goes with it.

So the second-order priority, after the patient, is preservation. Four things are worth preserving, and it helps to hold them as a short mental list. First, the AI output itself, in as close to its original form as you can capture: the note as drafted, the summary as generated, the score as displayed, before any editing overwrites it. A screenshot or a copy into a preserved location can save what an edit would otherwise erase. Second, the prompt and the context: what was asked, what information the tool was given, what it was working from, because the same tool produces different output from different input, and the input is half the story. Third, the version: which tool, which model version, which configuration was in use at the moment of the event, because that identifies the specific thing that must be examined. Fourth, the record of the human interaction: what the clinician saw, did, accepted, or overrode, which is the audit trail this chapter has been building, now doing its most important job. Preserve these, through your institution's actual mechanism, and the event remains understandable. Fail to, and it becomes an argument between faded memories.

It helps to see the four items laid out together, because each answers a different question and each disappears in a different way. The table below is not a checklist you complete yourself; it is a map of what the institution's process needs to secure once you flag that AI was involved.

A caution belongs here. Preservation does not mean freelance evidence-collection or copying protected health information into unsecured personal locations; that would create a new privacy problem on top of the safety one. It means invoking your institution's incident and evidence-preservation process, promptly and knowingly, and flagging that AI was involved so the people who can properly secure the fragile pieces do so before they expire. Your job is to recognize that AI evidence is perishable and to trigger the right mechanism fast, not to become an amateur investigator.

The reason speed matters so much is worth making concrete, because it changes how you act in the hour after an event. Ordinary incident reporting often tolerates a delay; a report filed the next morning is usually fine, because the underlying evidence is not going anywhere. AI evidence inverts that assumption. The pre-edit draft may be gone the moment the note is finalized. The prompt and the retrieved context may be held only in a short-lived cache. The model version in production may roll forward on the vendor's schedule, not yours. So the instinct to "write it up properly tomorrow when things calm down" can be the very delay that loses the evidence, and losing it is not recoverable. This does not mean abandoning the patient to file paperwork; it means that once the patient is stable, the AI-evidence preservation step moves up your list, ahead of the parts of documentation that can safely wait. Knowing in advance that this evidence is the perishable part is what lets you act on it in time rather than discovering, weeks later, that the one thing everyone needs was quietly overwritten on the afternoon it happened.

This is also a strong argument for knowing your institution's AI-incident pathway before you ever need it, because you will not have the bandwidth to learn it in the moment. Many organizations are still building these pathways, and in some places the honest answer is that the process is immature or unclear. That gap is itself worth surfacing through your safety and governance channels now, in the calm, rather than discovering it during a crisis. Part of being a safe operator of clinical AI is asking, before an incident, a simple question: if an AI tool contributed to harm on my unit tomorrow, who would I call, and what would get preserved. If you cannot answer that, you have found a gap that belongs in front of your leadership today.

In a conventional adverse event the evidence waits for you. In an AI-related one it evaporates. First care for the patient. Then, before it disappears, preserve what the AI produced, what it was given, which version produced it, and what the human did with it.

How an AI Event Is Genuinely Different

Beyond the fragility of evidence, an AI-related event differs from a conventional one in what actually needs to be understood, and this reshapes the analysis that follows. In a conventional adverse event, the investigation centers on human actions and system conditions. In an AI-related event, there are three interacting elements, and a sound analysis has to hold all three at once. There is the tool: what the AI produced and why it was wrong, whether it fabricated, dropped a fact, drifted, or was biased. There is the human check: what verification did or did not happen, and why the erroneous output was not caught before it reached the patient. And there is the workflow gap: the conditions that allowed an unverified or wrongly-verified AI output to travel all the way to harm, the missing gate, the time pressure, the unclear ownership of the verification step.

Missing any of the three produces a shallow and dangerous conclusion. Blame only the tool, and you learn nothing about why your safety net did not catch it, so the next tool's error sails through the same gap. Blame only the human, and you ignore both the tool's failure and the workflow that set the human up to fail, which is both unjust and useless for prevention. The mature analysis asks all three questions together: the tool produced a wrong output, yes, and the human check did not catch it, and the workflow allowed the uncaught output to reach the patient. Each is a distinct point of failure and a distinct opportunity to prevent the next one. This three-part view is what separates a real root-cause analysis of an AI event from a superficial one.

Root Cause Beyond "The AI Was Wrong"

The single most important intellectual discipline in analyzing an AI-related event is refusing to stop at "the AI was wrong." That phrase feels like an explanation, and it is a trap, because it is almost never the actual root cause. "The AI was wrong" describes the triggering error; it does not explain the harm. The harm required more than a wrong output; it required a wrong output that was not caught and that reached a patient. So the wrongness of the AI is the beginning of the analysis, not the end of it.

The questions that go deeper are the ones that actually prevent recurrence. Why was the output wrong, in a way specific enough to matter: was it a hallucination, a dropped fact, drift, bias? Why did the human check fail to catch it: was there no verification step, was the clinician under a load that made the check impossible, did automation bias lead to an authoritative output being accepted without scrutiny? Why did the workflow permit an unverified output to reach the patient: was the verification gate missing for this class of decision, was ownership of the check ambiguous across the team, had a drifting tool eroded trust so that a real signal was ignored? Notice that these questions reach back through the entire level. Automation bias, verification gates by risk, team-based ownership of the check, drift, the audit trail, each earlier lesson turns out to be a place where this event could have been prevented, and the root-cause analysis is where they all come due. "The AI was wrong" hides all of that. The disciplined analysis surfaces it, and in surfacing it, finds the changes that stop the next event.

Sit for a moment on the middle question, the human check, because automation bias is the mechanism that turns a model error into a patient harm, and it deserves to be named as the mechanism rather than treated as carelessness. Automation bias is the human tendency to accept an authoritative-looking output without applying the scrutiny you would apply to a colleague's uncertain suggestion. An AI output is fluent, confident, and well-formatted; it does not hedge, it does not look tired, and it arrives precisely when the clinician is under the most time pressure. Those are exactly the conditions under which a person waves something through. This is why the iron rule of the program applies with full force at the moment of the check: verify, do not repeat blindly. "The AI said so" is not verification, and an authoritative output is not a verified one. When an incident analysis finds that the human check failed, the honest and useful finding is usually not that the clinician was negligent but that automation bias did what automation bias does, and that points to a structural countermeasure rather than a reprimand.

A Worked Example: Two Investigations of the Same Event

Consider a real-shaped scenario. An AI-drafted note carried forward a medication the patient was no longer taking; the error was not caught; the patient received a harmful duplicate therapy. Two institutions investigate the same class of event and reach very different depths.

The first investigation concludes: the AI documentation tool made an error and generated an incorrect medication; the tool is unreliable; clinicians are reminded to be careful. This feels like closure. It is nearly worthless. It has not asked why the clinician did not catch the error, so it has learned nothing about the verification step. It has not asked why the wrong medication traveled from note to order to administration without a gate stopping it, so the workflow that let it through is untouched. It has blamed the tool and exhorted the humans, and it has left every condition that produced the harm exactly in place, ready to produce it again with a different medication next month.

The second investigation preserves the evidence first, the original AI draft showing the erroneous medication, the version of the tool, the record of what the clinician did, and then asks the three questions. On the tool: the scribe carried forward a medication from an outdated part of the record, a known failure pattern. On the human check: the clinician signed the note during a high-volume block without comparing the medication list to the reconciliation source, a verification gap under load. On the workflow: there was no required verification gate for medication changes in AI-drafted notes, and no clear owner for that check across the team. Each finding yields a specific fix: a source-comparison step for medications, a verification gate tied to the stakes, an explicit owner for the check. Same event, same harm. One investigation produced a shrug and a reminder; the other produced changes that prevent the next patient's harm. The difference was entirely in the refusal to stop at "the AI was wrong."

Two features of the deep investigation are worth drawing out, because they generalize. First, notice that its conclusions were fair to the clinician without being soft. It did not excuse the missed check, but it located that miss inside a workflow that made the miss likely, a high-volume block, no required gate, no clear owner, and it fixed those conditions rather than merely instructing the clinician to try harder. This is the just-culture stance that adverse-event analysis has long taught, now applied to AI: the goal is to understand how a competent professional came to make an understandable error under the conditions they faced, not to find someone to blame. An analysis that blames the human produces defensiveness and silence; the next near-miss goes unreported, and the system learns nothing. An analysis that fixes conditions produces a safer system and a workforce willing to surface the next problem. Second, notice that every fix the deep investigation reached for was a structural change, not an exhortation. "Be careful" is not a fix; a required source-comparison step is. The reliable output of a good AI incident analysis is a change to the tool, the check, or the workflow that would have caught this error without depending on anyone being more vigilant than humans reliably are.

Why "Be Careful" Is Not a Fix

The gap between the two investigations comes down to a single distinction that is worth stating on its own, because it governs almost every AI incident you will ever analyze: the difference between a structural change and an exhortation. An exhortation is an instruction to the people involved to behave better next time: be careful, pay closer attention, double-check the medication list, remember that the AI can be wrong. A structural change alters the tool, the check, or the workflow itself so that the error is caught even when no one is more vigilant than usual. "Be careful" is an exhortation. A required source-comparison step that will not let the note be signed until the medication list has been reconciled is a structural change. The first depends on a human being reliably more attentive than humans reliably are, especially under load, at hour ten, on a short-staffed unit. The second does not. Only the second actually prevents the next event, because the next event will happen to a competent, well-meaning clinician who is exactly as tired and busy as the one before.

This is why an incident analysis that ends in a reminder has, in a real sense, produced nothing. It has converted a harm into an admonition and left every condition that caused the harm in place. A useful test for any proposed fix is to ask: does this change what a person has to remember, or does it change what the system will allow? If the answer is the former, you have an exhortation dressed up as a corrective action, and it will fail the same way the last one did. If the answer is the latter, you have a fix. The reliable output of a good AI incident analysis is a change to the tool, the check, or the workflow that would have caught this specific error without depending on heightened vigilance, and if the analysis cannot name such a change, it is not finished.

Disclosure: Telling the Patient and Family

There is a dimension of a mature response that the mechanics of care and evidence can crowd out, and it deserves to be named directly: disclosure. When AI has contributed to a patient's harm, a complete response includes being transparent with the patient or the family that AI was involved, as part of the honest account of what happened. This is not a separate ethical flourish bolted onto the clinical work; it is continuous with the disclosure obligations that already govern adverse events, and it is increasingly continuous with the law. The same just-culture stance that refuses to scapegoat the clinician also refuses to hide the machine. An account that quietly omits the AI's role is not a neutral simplification; it is a material omission, and patients and families notice when the story does not add up.

In practice this does not mean a technical lecture at the bedside about model architecture. It means that when the harm is disclosed, the account is truthful about the chain of events, including that an AI tool produced an output that contributed, and that the institution is examining how it failed and what is being changed so it does not happen again. The tone is the same one that good adverse-event disclosure has always required: honest, plain, without defensiveness, without blaming the patient or the absent, and without pretending to certainty the investigation has not yet reached. Framed this way, disclosure of AI involvement strengthens trust rather than eroding it, because it demonstrates that the institution takes the tool as seriously as it takes the harm.

The legal ground here is shifting under everyone's feet, and the honest framing is that it is an evolving patchwork rather than a settled rule. State disclosure obligations around AI in care are live and expanding: some states now require that patients be told when AI is used in their diagnosis or treatment, in clear and plain language, and others require disclaimers on AI-generated patient communications. These laws are new, they vary by state, and HIPAA-covered entities are treated differently across them, so the specifics are something to verify for your own jurisdiction rather than to assume. The durable point for the practitioner is directional: the expectation of transparency about AI involvement is rising, not falling, and disclosing it as part of an honest account of harm is where both the ethics and the law are heading. Treat it as part of the mature response, not an optional add-on.

It is also worth being explicit about how the second, human-check question interacts with everything this level taught, because it is where automation bias re-enters the story. In many real AI incidents the honest answer to "why did the human check fail" is not that the clinician was careless but that the output was fluent and authoritative and arrived under load, and an authoritative output under load is exactly what automation bias is built to wave through. That is not an excuse; it is a diagnosis, and it points to a different class of fix than "remind clinicians." If automation bias is the mechanism, the countermeasures are structural: a forcing function that makes the verification unskippable for this category of decision, a design that surfaces the source alongside the AI claim so comparison takes seconds, a culture in which slowing to check is respected rather than treated as inefficiency. The incident analysis, done well, does not just find that the check failed; it asks why a reasonable human failed to check, and that question routinely leads back to the human-factors truths this program has been teaching from the very first level.

Closing the Level: Toward Governance and Leadership

This lesson closes the AI-Integrated Practitioner level, and it is the right place to end, because an incident is where everything the level taught is tested at once. The human-in-the-loop pattern, the verification gates, the audit trail, the drift monitoring, all of it exists to prevent this moment, and when the moment comes anyway, as it sometimes will, the same disciplines govern how you respond: care for the patient, preserve the fragile evidence, and analyze the tool, the check, and the workflow together rather than settling for blame. You now have the full practitioner-level toolkit for operating clinical AI safely and for responding when it fails.

But notice what the incident analysis kept reaching for, and could not itself supply. A required verification gate for a class of decision. A clear owner for a check across a team. An evidence-preservation process that fires reliably. A feedback loop that turns a caught drift into a remediation. These are not things an individual practitioner can build alone. They are structures, and structures are the domain of governance and leadership, which is exactly where Level 4 begins. The practitioner level ends at the edge of what one skilled clinician can do: verify their own output, document defensibly, notice drift, respond well to an incident. The next level is about building the institutional systems that make those individual disciplines reliable across a whole organization, the AI governance structure, the policies, the monitoring apparatus, the leadership that decides what tools are deployed and under what safeguards. You have learned to be a safe operator of clinical AI. The path ahead is learning to build the system that keeps everyone safe. That is the work of the AI leader, and it starts on the far side of this page.

Key Takeaways

• When AI contributes to harm, the patient comes first, always, exactly as in any adverse event; the tool's involvement never competes with immediate clinical care, and evidence work is a strictly second-order task.
• What makes an AI event different is that a crucial part of the evidence is fragile: the raw output can be overwritten on edit, the prompt and context may not be stored, and the model version may change, so the evidence has a short half-life.
• After the patient, preserve four things through your institution's process: the AI output in original form, the prompt and context, the version and configuration, and the record of what the human did.
• Preservation means triggering the institution's incident and evidence-preservation mechanism fast and flagging AI involvement, not freelance evidence-collection or copying PHI into unsecured personal locations.
• An AI event has three interacting elements that a sound analysis must hold together: the tool (what it produced and why it was wrong), the human check (what verification did or did not happen), and the workflow gap (what let the uncaught output reach the patient).
• The cardinal analytical discipline is refusing to stop at "the AI was wrong," which describes the trigger, not the root cause; the harm required a wrong output that was not caught and that reached a patient.
• Deep root-cause questions reach back through the whole level, automation bias, verification gates by risk, team ownership of the check, drift, the audit trail, and each earlier lesson is a place the event could have been prevented.
• The incident analysis keeps reaching for structures no individual can build alone, required gates, clear ownership, reliable preservation, feedback loops, which is precisely the governance and leadership work that Level 4 begins.