To run a root cause analysis with AI, use the model to organize evidence, expose gaps, generate competing system-level hypotheses, and design checks that could disprove them. Do not let AI declare the cause: qualified people must preserve evidence, assess causality, choose corrective actions, and verify that those actions actually prevent recurrence.

Key Takeaways

Define the problem with a measurable gap, scope, and time boundary.

Freeze source evidence before interpretation and preserve its provenance.

Label observations, interpretations, assumptions, and hypotheses separately.

Use Five Whys or a Fishbone diagram to expand candidates, not to prove one.

Prefer checks that distinguish competing explanations.

Look for interacting system conditions rather than a person to blame.

Validate corrective actions with outcomes and unintended-risk checks.

Important safety boundary: Safety-critical, regulated, legal-hold, accident, security, clinical, environmental, or professional investigations must use organization-approved procedures and qualified investigators. This general workflow does not replace emergency response, statutory reporting, evidence preservation, labor protections, legal advice, or specialist judgment.

This article covers operational and process analysis. For a software defect, use the separate AI-assisted code debugging workflow. The general guide to using AI provides the input-minimization and review foundation used here.

What role should AI play in root cause analysis?

AI can act as a structured second reader. It can normalize timestamps, map statements to evidence IDs, identify contradictions, generate questions, group causal factors, and compare hypotheses against a checklist. Those are useful acceleration tasks when the source package is controlled.

AI should not decide what happened, assess witness credibility, assign fault, alter originals, or approve corrective actions. It lacks access to the full environment and may produce a coherent story from incomplete evidence. NIST’s AI Risk Management Framework emphasizes governing, mapping, measuring, and managing risks across use, including validity, reliability, transparency, privacy, and accountability.［1］

OSHA recommends investigating underlying system causes rather than stopping at carelessness or failure to follow a procedure. It notes that equipment, procedures, training, management, design, and other program conditions often interact.［2］ That systems boundary matters even in non-safety operational work: “Alex entered the wrong value” describes an event, not why the process allowed one entry to create the loss.

What records keep the analysis honest?

Maintain three linked artifacts.

Evidence ledger

Evidence ID	Source	Time captured	What it directly shows	Reliability limits	Custodian
E-01	approved order export	14:05 UTC	duplicate order IDs entered the queue	export excludes deleted rows	operations owner

Hypothesis register

Hypothesis ID	Candidate cause	Supporting evidence	Contrary evidence	Distinguishing check	Status
H-01	retry created duplicate	E-01, E-04	no retry log for two cases	reproduce with logging enabled	open

Corrective-action register

Action ID	Factor addressed	Control	Owner	Due date	Success measure	New-risk check	Approval
A-01	duplicate acceptance	reject repeated order ID	process owner	agreed date	zero accepted duplicates in test set	legitimate resubmission still works	pending

The registers prevent polished narrative from outrunning evidence. They also allow a later reviewer to see why one candidate was rejected and whether an action addressed a proven factor or merely a symptom.

How do you run a root cause analysis with AI in nine steps?

Step 1: Define the problem precisely

Describe the expected state, observed state, measurable gap, start and end time, affected process, and impact. Use neutral language. “Shipment confirmation exceeded the approved two-hour target for 18 orders between 10:00 and 14:00 UTC” is better than “the fulfillment team failed again.”

Record what is out of scope and who authorized the analysis. Separate impact containment from causal investigation. You may need to stop ongoing harm immediately while preserving the question of why it occurred.

List the decisions the analysis must support: restore service, change a control, revise training, notify an authority, or open a specialist investigation. Do not imply that one RCA can satisfy every purpose.

Step 2: Freeze and inventory evidence

Preserve originals before cleaning, combining, or summarizing them. Give each record a stable ID and capture source, custodian, time basis, timezone, retention requirement, access restriction, and known gaps. Examples include logs, work records, change approvals, equipment status, interviews, photos, policies, and prior near-miss reports.

OSHA’s employer guide begins with preserving and documenting the scene, then collecting information before determining causes and implementing corrective actions.［3］ For ordinary process work, the “scene” may be a frozen export, configuration snapshot, queue state, or approved document set.

Use only authorized inputs. Remove unrelated personal data and secrets before AI processing. If evidence is subject to legal hold, privilege, safety rules, or formal chain-of-custody requirements, stop and use the designated procedure.

Step 3: Build a time-aligned event timeline

Normalize timestamps without overwriting originals. Record the source clock, timezone, clock skew, precision, and whether a time is observed or estimated. Put actions, state changes, alerts, decisions, and external conditions on one sequence.

Ask AI to identify gaps, impossible orderings, and conflicting accounts, but require evidence IDs for every event. A prompt can say: “Return only events directly supported by the ledger. Keep conflicting times as separate rows. Do not choose the more plausible account.”

Avoid treating sequence as causality. Event B following event A shows order, not that A caused B. Use the timeline to form questions and locate missing data.

Step 4: Separate observations from hypotheses

Label every statement as observation, interpretation, assumption, hypothesis, or decision. An observation should describe what a source directly supports. “The approval field was empty in E-07” is an observation; “the reviewer skipped approval because of workload” is a hypothesis.

Ask AI to flag causal verbs that lack an evidence reference. Replace premature conclusions with testable language. If a witness supplies an interpretation, preserve it as that person’s account rather than converting it into fact.

This classification is especially valuable when several teams use different terminology. Create a glossary and record disputed meanings instead of letting a model normalize them silently.

Step 5: Generate candidate causes with structured methods

Use Five Whys, a Fishbone diagram, barrier analysis, change analysis, or an event tree to broaden the candidate set. The method is a question generator, not a proof engine. Stop a Five Whys branch when the next answer lacks evidence, crosses outside scope, or becomes a vague label such as “culture.”

Organize Fishbone branches around relevant system dimensions: process, tools, information, environment, staffing, supervision, incentives, interfaces, and controls. Add a candidate only when you can state what evidence would support or weaken it.

OSHA’s root-cause fact sheet says successful analysis may identify more than one root cause and lists multiple tools, including brainstorming, checklists, timelines, sequence diagrams, causal-factor determination, and logic or event trees.［4］ Do not force one neat answer when interacting factors fit the evidence better.

Step 6: Design distinguishing checks

For each open hypothesis, ask: what result would be more likely if this explanation were true than if its strongest alternative were true? A useful check changes the relative support between candidates.

Examples include comparing affected and unaffected cases, reproducing a condition in a controlled environment, inspecting an independent log, reviewing a change boundary, or checking whether the factor existed before earlier near misses. Record the expected result under each candidate before running the check.

Avoid checks that merely collect more of the same evidence. If both H-01 and H-02 predict a delayed queue, another queue-delay chart will not distinguish them. Prioritize safe, reversible, authorized checks and involve specialists when testing could create harm.

Step 7: Record excluded and unresolved causes

Do not delete a rejected hypothesis. Record the check, result, reviewer, and reason for exclusion. A later evidence correction may make it relevant again.

Use statuses such as open, supported, weakened, excluded, unresolved, or outside scope. “Excluded” should mean a defined check contradicted the candidate, not that the team disliked it. “Unresolved” is an acceptable result when evidence is insufficient.

Ask a reviewer who was not invested in the leading explanation to inspect contrary evidence. If the group only searches for confirmation, AI can accelerate confirmation bias by generating ever more fluent support for the favored story.

Step 8: Form a multi-factor conclusion and corrective actions

State the conclusion as a causal chain with evidence and confidence boundaries. Separate immediate cause, contributing conditions, failed or missing controls, and deeper organizational factors. Do not use a person’s name as the terminal cause.

Corrective actions should address verified factors and favor stronger system controls over reminders alone. NIOSH’s hierarchy of controls prioritizes elimination, substitution, and engineering controls above administrative controls and personal protective equipment because higher-level controls depend less on repeated individual action.［5］ The exact hierarchy may not map to every office process, but the principle is useful: redesign the condition before relying only on “be more careful.”

For each action, name an owner, due date, approval authority, implementation evidence, success measure, and possible new risk. Link temporary containment separately from permanent correction.

Step 9: Verify that corrective actions work

Define a baseline, target, observation window, comparison method, and rollback or escalation trigger before implementation. Measure the outcome the action is meant to change, not merely whether the task was marked complete.

Check for recurrence, near misses, workarounds, burden shifted to another team, reduced reporting, new failure modes, and false positives. A control that suppresses the visible symptom while creating hidden manual work has not solved the system problem.

Schedule a named review and reopen the hypothesis register if results conflict with the conclusion. Version the analysis rather than silently rewriting it. Final closure belongs to the accountable owner under the approved procedure, never to the model.

What prompt keeps AI inside the evidence boundary?

Use a staged prompt:

Using only the supplied evidence ledger, create: (1) a neutral problem statement, (2) an evidence-linked timeline, (3) a list separating observations from hypotheses, and (4) competing system-level candidate causes. For every candidate, list supporting evidence, contrary evidence, missing evidence, and one check that could distinguish it from the strongest alternative. Do not select a root cause, assess personal blame, invent events, or recommend action without showing the factor it addresses.

Run each stage separately and review it before moving on. Use the AI fact-checking method to map claims to sources, and require human approval for the conclusion and actions. If a validated fix becomes a repeatable operating control, document it through the SOP and checklist workflow.

Summary

Frame a neutral, measurable problem before searching for causes.
Preserve evidence and provenance before asking AI to organize it.
Separate the timeline, observations, interpretations, and hypotheses.
Generate multiple system-level candidates and design checks that can distinguish them.
Keep rejected and unresolved explanations visible.
Build corrective actions against verified factors and test outcomes over time.
Use qualified investigators and approved procedures whenever consequences or regulation demand them.

FAQ

Can AI identify the root cause automatically?

No. It can organize evidence and propose candidates, but incomplete context and confabulation can produce a convincing wrong answer. Accountable investigators determine causal support and approve conclusions.

Is Five Whys enough for every problem?

No. It is a useful question structure for some cases, but complex events may require timelines, barrier analysis, change analysis, event trees, specialist testing, or several methods together.

What is the difference between an immediate cause and a root cause?

An immediate cause is close to the event, such as an invalid value entering a queue. A deeper cause explains which system condition or failed control allowed that event and recurrence risk to exist.

Should human error be listed as the root cause?

Usually not as the endpoint. Record the action accurately, then examine interface design, workload, procedures, training, supervision, incentives, safeguards, and recovery controls that shaped the conditions.

How many candidate causes should I keep?

Keep every plausible, testable candidate supported by the current scope, then prioritize distinguishing checks. Do not force a fixed number or discard alternatives merely to simplify the report.

What if the evidence cannot distinguish two explanations?

Record both as unresolved, state what evidence is missing, and decide whether the risk justifies further investigation or a control that addresses both. Do not manufacture certainty.

How do I know a corrective action worked?

Use a pre-defined outcome measure, baseline, observation window, and unintended-risk checks. Task completion alone proves implementation, not effectiveness.

When should I stop using this general workflow?

Stop when the matter involves safety-critical systems, injury, regulated reporting, legal hold, criminal or disciplinary allegations, clinical decisions, environmental harm, or another professional-investigation boundary. Follow the designated procedure and qualified investigator.

Disclaimer: Safety-critical, regulated, legal-hold, accident, security, clinical, environmental, or professional investigations require organization-approved procedures and qualified investigators. This article is general process guidance and does not replace statutory reporting, evidence preservation, legal advice, or professional judgment.

Sources:

NIST — AI Risk Management Framework — https://www.nist.gov/itl/ai-risk-management-framework
OSHA — Incident Investigation Overview — https://www.osha.gov/incident-investigation
OSHA — Incident Investigations: A Guide for Employers — https://www.osha.gov/sites/default/files/IncInvGuide4Empl_Dec2015.pdf
OSHA and EPA — The Importance of Root Cause Analysis During Incident Investigation — https://www.osha.gov/sites/default/files/publications/OSHA3895.pdf
CDC/NIOSH — Hierarchy of Controls — https://www.cdc.gov/niosh/hierarchy-of-controls/index.html

Sources checked 30 August 2026.

Related Articles:

How to Run a Root Cause Analysis with AI