Root-cause analysis and lessons learned

What it does

It stops the same failure recurring. After a significant incident or near miss, a structured review establishes what happened, why the system behaved as it did, why controls did not prevent or detect it sooner, and what should change. The review looks past the immediate technical cause to the decisions and gaps behind it. Actions are assigned, tracked and reported, and what was learned is shared with other system owners. The system owner is accountable for the review; governance tracks the actions. It operates after each qualifying event.

How to implement it

• Define which incidents and near misses require a review.
• Hold the review promptly, with people who were not responsible for the system as well as those who were.
• Trace causes through data, model, prompt, integration, process and governance.
• Record which controls failed, and whether each was missing, badly designed or not operated.
• Turn findings into owned, dated actions, and add the failure to test suites and scenario libraries.
• Share findings across teams, and report themes to the governance forum.

Evidence it operates

Design: a post-incident review procedure and template. Operation: review reports for qualifying incidents; an action log with completion evidence; test cases and scenarios added as a result; themes reported to governance.

Where it fits

After incident response has closed. It supports AI incident response gap and serious incident reporting failure, and it feeds AI failure scenario testing, the evaluation suite and AI risk reporting to the board.

Limits

For a complex model the technical cause may not be discoverable, and the review has to settle for the conditions that allowed harm. Reviews that look for someone to blame learn little. Actions tend to be closed on paper. Lessons recorded in one team's report rarely reach the others unless someone carries them.