The morbidity-and-mortality conference has reached the AI-related case, and the first slide says everything wrong with how most organizations investigate these events. It reads, in effect, "The AI generated an incorrect summary." The room nods, someone notes that the vendor has been informed, and the case is closed as a technology problem. But sitting in that room is the uncomfortable truth: the AI being wrong is not the root cause of anything. The model was going to be wrong sometimes; that is a known, permanent feature of the technology. The real question, the one that slide skips, is how a wrong output traveled all the way to a patient without a single human or system catching it. Answer that, and you find the failure you can actually fix. Stop at "the AI was wrong," and you will investigate the same event again next quarter.

Why "The AI Was Wrong" Is Not a Root Cause

Root-cause analysis exists to find the systemic conditions that let a bad thing happen, so you can change them and prevent recurrence. Applied to AI, the discipline runs immediately into a seductive dead end: the model produced a wrong output, therefore the model is the cause, therefore the fix is to tell the vendor and wait for a better model. This feels like a root cause because it names a concrete thing that went wrong. But it fails the only test that matters, which is whether acting on it prevents recurrence. You do not control the model's error rate. You did not write it, you cannot audit its weights, and even a genuinely improved version will still be wrong sometimes, because being sometimes wrong is intrinsic to how these systems work. An investigation that terminates at the model has identified something true and something useless at the same time.

There is a second reason the model-blaming reflex is so tempting, and it is worth naming so you can resist it in your own committees. Blaming the model feels like it protects your people: it is nobody's fault, the machine erred, the humans were let down by a tool. That instinct is generous but corrosive, because it quietly concludes that nothing in your control needed to change, which is the same as concluding that the next patient is equally exposed. A finding that comforts everyone in the room and changes nothing in the workflow is not a kind finding; it is an abdication dressed as compassion. The genuinely humane analysis is the one that spares the next patient, and that always requires locating something you can actually change.

The mature reframe is to treat the model's error not as the root cause but as the triggering hazard, the equivalent of a look-alike drug label or a confusing pump interface. In classical patient safety we long ago stopped accepting "the nurse made a mistake" as a root cause, because it does not prevent the next nurse from making the same mistake under the same conditions. We learned to ask what in the system allowed a normal human error to reach the patient. AI demands exactly the same maturity. The model's error is the normal, expected hazard. The root cause is whatever let that expected hazard travel unchecked into a patient's care. If your analysis names the model and stops, you have simply relabeled "the nurse made a mistake" for the machine age, and you will get the same non-result.

A disciplined RCA follows a fixed sequence, and it helps to name the steps so a committee cannot skip to blame. First, assemble a factual timeline of the event from source data, not memory. Second, classify the error into one of the four failure families. Third, walk all three layers and name the hole in each. Fourth, write a corrective action for each layer, each with an owner, a due date, and a verification method. Fifth, set an effectiveness-check date on which you will re-measure whether the fix worked. Sixth, route each finding back into the governance structure it belongs to. Any analysis that stops before step four has described the event without changing the system, which is exactly the failure this lesson exists to prevent. Note that any error rate a vendor quotes for its model is a starting hypothesis, not a fact: verify it on your own representative data, and never repeat a marketing statistic blindly into an RCA record.

The Three-Part Anatomy of AI Harm

Here is the single most useful frame in this lesson, and it is worth memorizing: an AI event that reaches a patient is almost never one failure. It is three, stacked. The harm is the model error, plus a missing human check, plus a workflow or governance gap that allowed the first two to line up. Remove any one of the three and the patient is unharmed. This is the AI-era version of the Swiss-cheese model of accident causation: harm occurs only when the holes in several layers of defense align, and a competent root-cause analysis finds all the holes, not just the first one it trips over.

Walk the three layers. The model error is the fabrication, the omission, the biased score, the wrong laterality: the raw defect in the output. It is real, but by itself inert, an error on a screen that has harmed no one yet. The missing human check is the verification step that should have caught the model error and did not, either because it was skipped under automation bias, or because it was never designed into the workflow at all, or because it was designed but was impossible to actually perform in the time allotted. The workflow or governance gap is the systemic condition that made the missing check likely: a workflow that presented the output as authoritative, a sign-off gate that did not exist, a training program that never taught this failure mode, a monitoring plan that would never have surfaced the pattern, a tool deployed for a use it was never validated for. When you can name all three for a given event, you have a real root-cause analysis. When you can name only the first, you have a press release.

An AI event that reaches a patient is the model error plus a missing human check plus a workflow or governance gap. Remove any one and the patient is unharmed. If your analysis names only the model, you have a press release, not a root-cause analysis.

Using the Four Failure Families to Find the Missing Check

The three-part anatomy tells you what to look for. The four failure families tell you where to look, because they map to distinct verification steps, and the missing check is almost always the one that matches the family of error. You learned these families earlier in the program: fabrication (the model invented something that was not there), omission (the model dropped something that was there), bias (the model performed worse for a particular population), and automation bias (the human over-trusted the output and skipped checking). For any AI event, ask which family the error belongs to, then ask which verification step corresponding to that family was missing. That single move turns a vague "we should be more careful" into a specific, fixable defect.

Each family points at a different check. A fabrication reaching the patient means the missing step was source verification: no one confirmed the invented finding, dose, or citation against a ground truth. The fix lives in a workflow that forces a source check for the categories of output where fabrication is dangerous. An omission reaching the patient means the missing step was completeness verification: no one cross-checked the summary or note against the source for what was dropped, and the fix is a completeness check on exactly the values (abnormal labs, pertinent negatives) that matter. A bias event reaching the patient means the missing step was subgroup validation and monitoring: the tool was never tested, or is not being monitored, for disparate performance across the populations you serve, and the fix lives in your validation and monitoring plan, not at the bedside. An automation-bias event means the check existed on paper but the human did not perform it, which points not at more exhortation but at forcing functions, workload, and culture. Naming the family names the fix.

The mapping from family to check to corrective action to the place the fix lives is stable enough to tabulate, and a mature program keeps this table on the wall of the RCA room so no one has to reinvent it under the pressure of a bad case.

Notice how much precision this discipline adds compared to the vague resolutions that AI events usually attract. A committee that concludes "we need to be more careful with AI summaries" has said nothing a fix can be built from, because carefulness is not a control you can install, audit, or measure. A committee that concludes "this was an omission, the completeness verification step was absent, and the fix is a required confirmation that recent abnormal diagnostics are reflected before a summary drives a decision" has produced something an informatics team can build, a governance body can mandate, and a surveyor can inspect. The four-family lens is not academic taxonomy; it is the tool that converts a fog of good intentions into a specific defect with a specific owner. And it prevents the classic error of applying the wrong fix to the wrong family, such as responding to a systematic bias problem with clinician reminders, which is like responding to a look-alike-drug error by telling nurses to read more carefully. The family tells you which layer of the system to reach for.

Fix the System, Not the Individual

The gravitational pull of every AI root-cause analysis is toward blaming the clinician who accepted the output. It is the easiest hole to see, the human at the end of the chain, and blaming them feels like accountability. It is the opposite. Blaming the individual is what lets the system off the hook, because it implies the fix is "that clinician should have been more careful," which changes nothing structural and guarantees the next clinician, under the same conditions, does the same thing. The whole point of root-cause analysis, inherited from decades of patient-safety science, is that safe systems are built to be resilient to normal human error, not to depend on humans never erring. A clinician who skipped a verification step under time pressure on a short-staffed shift is not the root cause; they are the last visible symptom of a workflow that made the skip likely and a system that had no catch behind them.

This does not mean individuals are never accountable; reckless disregard for a known safety rule is a real thing. It means the default posture of the analysis is to assume a competent professional acting reasonably under the conditions the system created, and to ask what about those conditions made the error likely. The test is forward-looking: will your proposed fix prevent the next event, or does it merely assign fault for this one? "Counsel the physician" prevents nothing. "Add a forcing function that requires source confirmation before an AI-drafted discharge med list can be signed" prevents the next one. A blameless, systems-focused analysis is not softness; it is the only kind that actually reduces the recurrence rate, and reducing the recurrence rate is the entire job.

The single hardest judgment in an AI RCA is telling three overlapping causes apart: a genuine model error (the output was wrong), automation bias (the output was wrong and a human over-trusted it), and a process failure (a verification step was designed but never operated, or a tool was used outside its validated purpose). These are not mutually exclusive, and a serious event usually contains all three, but the analysis must separate them because each points at a different corrective-action class. The record itself carries the tells. Read it against this diagnostic table.

The distinction has real consequences. Misread automation bias as pure model error and you will chase a better model while leaving the interface that induced over-trust untouched, so the next clinician falls into the same trap. Misread a process failure as automation bias and you will build forcing functions on top of a workflow that had no gate to force, or worse, counsel a clinician for skipping a check that the system never made possible. The record must let a later reviewer, a surveyor, or opposing counsel see which of the three you found and why, because the corrective action only makes sense once the cause is named correctly.

A Worked Example: The Dropped Ejection Fraction

Take a concrete case through the full method. An AI chart-summarization tool produced a pre-visit summary for a cardiology follow-up. The summary described the patient as clinically stable and omitted a recent echocardiogram showing a newly reduced ejection fraction. The physician, running behind, read the tidy summary, did not open the underlying echo report, and reassured the patient without adjusting therapy. Three weeks later the patient presented in decompensated heart failure. The shallow analysis writes: "AI summary was incomplete; vendor notified." Now run the real one.

Family: this is an omission. The tool dropped a value that was present in the source. That immediately tells us the relevant verification step is completeness, cross-checking the summary against the source for dropped abnormal values. Layer one, the model error: the summarization model compressed away an abnormal echo result, a known, expected failure mode of summarization, not a shocking novelty. Layer two, the missing human check: the completeness verification that should have caught the omission did not happen; the physician trusted the summary and never opened the source echo. Layer three, the workflow and governance gap: now the real findings surface. The summarization tool presented its output as a complete clinical picture with no cue that it might have dropped something. There was no required step to confirm that recent diagnostic results were reflected before a summary drove a clinical decision. The tool had been deployed for pre-visit summarization without validation on how often it omitted abnormal values. And nothing in the monitoring plan would ever have surfaced a pattern of dropped abnormals across the cardiology service. Four systemic holes, any one of which, closed, saves this patient.

See what the real analysis buys you. The shallow version yields "be careful" and a vendor ticket, and the same event recurs. The deep version yields a specific, testable fix at each layer. Do not let those fixes float as good intentions: write each one into the record with an owner, a due date, and a verification method, so a governance body can track it to closure and a surveyor can inspect that it happened. Here is the corrective-action table this case should produce.

Notice that not one of these fixes is "counsel the physician." The physician's skipped check was real, but it was the symptom, and treating the symptom would have left every other clinician on that service exposed to the identical trap. Notice too that each action names a person, a deadline, and a way to prove it was done. An action with no owner is a wish, an action with no due date never closes, and an action with no verification method cannot be shown to a board or a surveyor as complete. The RCA is not finished when the meeting ends; it is finished when every row of this table is verified closed and the effectiveness check has re-measured the outcome.

From One Event to a Safer System

The final move separates a program that investigates from one that improves: each root-cause analysis must feed back into the very structures you spent Level 4 building. A finding of missing subgroup validation is a defect in your validation plan, and the fix updates that plan for every future tool, not just this one. A finding that a monitoring signal would never have surfaced the pattern is a defect in your monitoring plan, and the fix adds the metric. A finding that a tool was used for an unvalidated purpose is a defect in your governance intake and change-control process. A finding that clinicians were never taught this failure mode is a defect in your training program. A finding that a workflow presented AI output as authoritative with no verification gate is a defect in your workflow design. The root-cause analysis is not the end of the incident; it is the input that hardens the whole apparatus so the same class of event cannot recur across the organization.

Not every corrective action is equally strong, and a leader who does not know the difference will fill the record with the weakest ones because they are the easiest to write. Human-factors science ranks corrective actions by how much they depend on a human choosing to behave well: the less they depend on human vigilance, the stronger they are. Forcing functions and physical constraints that make the error impossible sit at the top; automation and reminders that catch the error most of the time sit in the middle; education and policy, which only work if a busy human remembers and complies, sit at the bottom. Prefer the strongest action the workflow can bear, and treat a stack of bottom-tier actions as a warning sign that the analysis stopped short.

The record itself must show its work, because an RCA that cannot be inspected did not really happen. A defensible AI-event record contains, at minimum, the artifacts below. Corrective actions are tracked to closure the way any patient-safety action is: an owner is accountable, the governance body reviews open items until each is verified done, and effectiveness is re-measured on a set date, for example by re-auditing a fresh sample of encounters ninety days after the fix to confirm the pattern actually fell. If the re-audit shows no improvement, the action failed and the analysis reopens rather than the file closing.

None of this stands alone. Post-deployment monitoring and structured governance are the foundational elements that RCA both depends on and repairs, and external frameworks now say so explicitly. The Joint Commission and the Coalition for Health AI published guidance on the responsible use of AI in healthcare (RUAIH) on September 17, 2025, describing governance structures and ongoing post-deployment monitoring as core expectations. Treat any date, edition, or specific requirement as something to verify against the current published version rather than repeat from memory, but the direction is stable: an RCA that surfaces a monitoring gap is feeding the exact structure these frameworks expect you to maintain, and a program without a monitoring plan has nowhere for its RCA findings to land. Each analysis is a deposit into that standing governance and monitoring apparatus.

This is why root-cause analysis belongs at the end of Level 4, alongside incident response. Everything you built at this level, the board-ready strategy, the vendor rubric, the governance charter, the validation and monitoring plan, the change program, the dual-axis metrics, is a hypothesis about how to make AI safe. Every AI event is an experiment that tests that hypothesis, and a real root-cause analysis is how you read the result and update the design. An organization that does this consistently converts its worst days into a steadily hardening system; the same failure genuinely cannot happen twice because the analysis closed the specific hole that let it through. An organization that stops at "the AI was wrong" learns nothing, hardens nothing, and rediscovers each failure family the hard way, on patient after patient. The difference between them is not the quality of their AI. It is the quality of their analysis.

Key Takeaways

• "The AI was wrong" is never the root cause. The model being sometimes wrong is a known, permanent hazard you do not control; the root cause is whatever let that expected error travel unchecked to the patient, which is what you can actually fix.
• Treat the model error as the triggering hazard, the AI-era equivalent of a look-alike label, and apply the same systems maturity that stopped patient safety from accepting "the nurse made a mistake" as a cause.
• An AI event that reaches a patient is almost always three failures stacked: the model error, plus a missing human check, plus a workflow or governance gap. Remove any one and the patient is unharmed; a real analysis names all three.
• Use the four failure families to locate the missing check: fabrication points at source verification, omission at completeness verification, bias at subgroup validation and monitoring, and automation bias at forcing functions, workload, and culture. Naming the family names the fix.
• Fix the system, not the individual. Blaming the clinician who accepted the output lets the system off the hook and guarantees recurrence; assume a competent professional acting reasonably under the conditions the system created.
• The test of a fix is forward-looking: "counsel the physician" prevents nothing, while a forcing function that requires source confirmation before sign-off prevents the next event.
• Each root-cause analysis must feed back into your validation plan, monitoring plan, governance intake, training program, and workflow design, so the fix protects the whole organization, not just this case.
• Every AI event is an experiment that tests the safety hypothesis you built at Level 4; a real analysis reads the result and hardens the system, so the same class of failure genuinely cannot happen twice.