AI Incident Log and Tracking
Added May 2026
Maintain a centralized, structured log of all AI incidents, near-misses, and governance concerns, accessible to the AI governance function.
Objective
Enable trend analysis, governance reporting, and regulatory audit responses by maintaining a complete and accessible AI incident record.
Maturity Levels
Initial
AI incidents are not centrally logged; records exist only in individual email threads or chat channels.
Developing
Incidents are logged in a shared document or ticketing system but without a consistent structure.
Defined
A defined incident log schema (a standard set of required fields) is consistently used; all incidents above a threshold are logged with key fields completed.
Managed
Incident trends are analyzed quarterly and reported to governance bodies; the log informs risk assessments.
Optimizing
The incident log feeds automated risk dashboards; log completeness is audited periodically.
Get the free AI Governance Control Tracker
Get the free Excel tracker for all 136 governance controls. Score your maturity on AI Incident Log and Tracking and every other control, assign owners, and set deadlines.
- 136 controls in Excel
- Score maturity and assign owners
- Track deadlines and regulation coverage
Includes AI Governance Weekly every Thursday. Unsubscribe anytime.
Evidence Requirements
What an auditor or assessor would expect to see for this control.
- —Centralized incident log with all required fields populated for every recorded incident and near-miss
- —Near-miss reporting records demonstrating the logging process captures events below the reporting threshold, not just confirmed incidents
- —Governance committee reporting records showing the incident log is reviewed on a defined cadence
- —Log completeness audit records confirming all incidents above the reporting threshold are present in the log
- —Retention records confirming the incident log is maintained for the required period
Implementation Notes
Key steps
- Define the minimum fields for every incident record: date, system, incident type, severity, timeline of events, resolution, and post-incident review status.
- Log near-misses with the same rigor as incidents, they are your cheapest source of governance intelligence.
- Restrict write access (the ability to edit) to incident records after they are closed to preserve their integrity as audit evidence.
- Review the incident log as a standing agenda item at AI governance committee meetings.
Example Implementation
AI governance team maintaining a centralized incident register across five production AI systems
AI Incident Log Schema
Required fields for every incident entry:
| Field | Type | Description |
|---|---|---|
| incident_id | String | IRC-YYYY-NNNN format |
| system | String | AI system affected |
| incident_type | Enum | MODEL_FAILURE, DISCRIMINATORY_OUTPUT, DATA_EXPOSURE, ADVERSARIAL_ATTACK, AGENTIC_SCOPE_VIOLATION, HALLUCINATION_HARM, NEAR_MISS |
| severity | Enum | P1, P2, P3, P4 |
| detected_at | ISO-8601 | When incident was first detected |
| detected_by | String | Person/system that detected it |
| resolution_at | ISO-8601 | When incident was resolved |
| root_cause_summary | Text | Brief root cause (required for P1/P2) |
| pir_status | Enum | NOT_REQUIRED, SCHEDULED, COMPLETED |
| notification_required | Boolean | Whether regulatory/user notification was assessed |
| notification_status | Text | Outcome of notification assessment |
Quarterly trend report (standing AI Governance Committee agenda item):
- Incident count by type and severity
- Mean time to resolution by severity
- Open action items from post-incident reviews
- Near-miss analysis: were there precursors we should have caught earlier?