AIG-021 AI Incident Response and Error Communication
Description
A documented process exists for detecting, investigating, and responding to AI system incidents and errors. The process defines: what constitutes an AI incident (e.g. systematic bias detected, unsafe output at scale, model poisoning suspected), severity classification, escalation paths, communication obligations to affected users and regulators, and post-incident review requirements. For GPAI models posing systemic risk, serious incidents are reported to the AI Office without undue delay. Incident records are retained.
Rationale
AI incidents differ from security incidents in causality, affected population scale, and regulatory notification obligations; a generic incident process does not adequately cover them.
Framework Mappings (6)
| EU-AI-Art.26.4 | Deployer Obligations — Operational Monitoring and Incident Notification | partial |
| EU-AI-Art.55.3 | Systemic Risk Obligations — Serious Incident Reporting | full |
| A.3.3 | Reporting of concerns | full |
| A.8.4 | Communication of incidents | full |
| MANAGE 2.3 | Unknown Risk Response and Recovery | full |
| MANAGE 4.3 | Incident and Error Communication | full |
Evidence (2)
AI incident response process defining what constitutes an AI incident, severity classification criteria, escalation paths, communication obligations, and post-incident review requirements.
Example: AI Incident Response Runbook v1.2 (Confluence), defining 3-tier severity model, AI-specific incident categories (systematic bias, unsafe output, model poisoning, data leakage), 24-hour regulatory notification SLA, and post-incident review obligation within 14 days
Test: Request the AI incident response process documentation. Verify: (1) AI-specific incident types are enumerated (not limited to generic IT incidents), (2) severity tiers are defined with examples, (3) escalation path includes legal/compliance and regulator notification obligations, (4) communication obligations to affected users are specified, (5) post-incident review is required with a defined timeframe, (6) GPAI systemic risk model serious incident reporting obligation is addressed if applicable.
Completed AI incident records for the last 12 months demonstrating that incidents were documented, investigated, and resolved per the defined process.
Example: AI Incident Record AI-INC-2025-003 (Jira): systematic gender bias detected in job-ranking model, severity P2, root cause analysis completed, model retrained, post-incident review completed 2025-09-20, affected users notified, no regulatory notification required (below threshold)
Test: Request all AI incident records for the last 12 months. Verify: (1) incidents are classified using the defined severity model, (2) each record contains root cause, remediation action, and closure date, (3) post-incident review was completed within the defined timeframe, (4) any incidents exceeding notification thresholds show evidence of communication to affected parties and/or regulators.
Questions (2)
Does your organisation have a documented process for detecting, investigating, and responding to AI system incidents?
A generic IT incident process is not sufficient. The AI incident process must define AI-specific incident types (systematic bias, unsafe outputs, model poisoning), regulatory notification obligations, and post-incident review requirements.
Which of the following are covered in your AI incident response process?
All six areas indicate a mature AI incident response capability. Missing regulatory notification timelines or AI-specific incident categories suggest the organisation is applying a generic IT incident model that will not satisfy EU AI Act Art. 26.4 or Art. 55.3 obligations.