AI Post-Incident Review
Conduct a structured review after every significant AI incident to identify root causes, contributing factors, and systemic improvements.
Objective
Learn from AI incidents to prevent recurrence and continuously improve AI governance controls through disciplined post-incident analysis.
Maturity Levels
Initial
Post-incident reviews are not conducted; the same issues recur.
Developing
Reviews happen informally for major incidents but findings are not systematically tracked.
Defined
A documented post-incident review process is conducted for all incidents above a defined severity threshold.
Managed
Review findings are tracked to resolution; recurring themes inform governance policy updates.
Optimizing
Review methodology is refined based on the quality of insights produced; systemic findings are escalated to executive governance.
Evidence Requirements
What an auditor or assessor would expect to see for this control.
- —Post-incident review reports for all incidents above a defined severity threshold, including timeline, root cause, and contributing factors
- —Action item tracking records showing review findings were assigned to owners with due dates
- —Closure records confirming action items were completed and verified effective
- —Trend analysis records showing recurring root causes across multiple incidents
- —Review cadence records confirming reviews were conducted within the required timeframe after each qualifying incident
Implementation Notes
Key steps
- Use a blameless review format: the goal is systemic improvement, not individual accountability — blameful reviews suppress honest disclosure of contributing factors.
- Require a five-why root cause analysis for Severity 1 and 2 incidents: surface-level causes usually mask systemic governance gaps.
- Track action items to closure with owners and deadlines — reviews that produce untracked recommendations provide false assurance.
- Share sanitized review findings across AI teams: incidents affecting one system often reveal vulnerabilities that exist in others.
Example Implementation
AI engineering team conducting a post-incident review after a P2 hallucination incident in a financial report tool
Post-Incident Review — IRC-INC-0038 (Hallucination in Earnings Summary)
Incident summary: AI earnings report summarizer cited a specific revenue figure ($42.3M) not present in the source document; the figure was used in an internal presentation before being caught by a finance analyst
Timeline reconstruction: AI output generated 09:15; included in presentation by 10:00; analyst identified discrepancy at 11:40; output removed and corrected by 12:15
Five-why root cause analysis:
- Why did the model hallucinate a specific figure? — No grounding instruction required citation of source for numerical claims
- Why was there no citation requirement? — Output validation rules only checked format, not factual grounding
- Why was factual grounding not in the validation rules? — Hallucination risk assessment was not performed for this use case at deployment
- Why was no hallucination assessment done? — Deployment gate checklist did not include factual grounding check for numeric outputs
- Why not? — Deployment checklist was not updated when use case expanded from text summarization to numerical summarization
Root cause: Deployment gate checklist gap — no factual grounding check for numerical claims
Corrective actions:
- Add numerical claim grounding check to deployment gate checklist — Owner: AI Lead · Due: 2026-05-01
- Add citation requirement to summarization system prompt — Owner: ML Engineer · Due: 2026-04-25
- Add post-delivery analyst spot-check step to report workflow — Owner: Finance Process Lead · Due: 2026-05-15
Control Details
- Control ID
- IRC-004
- Domain
- Incident Response
- Typical owner
- AI Governance Team / AI Engineering
- Implementation effort
- Low effort
- Agent-relevant
- Yes