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 counts as an AI incident, covering at minimum systematic bias, unsafe output at scale, suspected model or data poisoning and loss of control of an AI-driven action. Within that it defines what counts as a serious incident, by reference to death or serious harm to a person's health, serious and irreversible disruption of critical infrastructure, infringement of obligations protecting fundamental rights and serious harm to property or the environment. Each incident record carries a severity, the escalation path followed, the investigation, the root cause, the communication to affected users, a post-incident review and a closure date. A serious incident is reported to the competent authority for each jurisdiction in which it occurred, within the deadline applicable law sets for that category of incident, measured from the point at which the organisation or an operator of the system becomes aware of it. The system is not altered in a way that would prevent the incident being evaluated before that report is made.
Rationale
An AI incident differs from a security incident in causality, in the size of the affected population and in who has to be told. A generic IT incident process handles none of those: it has no category for a model that has been quietly wrong for six weeks and no clock to report it on. Under the EU AI Act the serious incident definition is Article 3(49) and the deadlines are Article 73: 15 days by default, two days for a widespread infringement or a serious and irreversible disruption of critical infrastructure and 10 days where a person has died, each running from awareness, including a deployer's awareness. The bar on altering the system before reporting, also Article 73, cuts against the engineering instinct to patch first. The serious incident reporting a general-purpose AI model provider owes to the AI Office is a duty of that role and belongs to the GPAI provider bundle rather than here. Corrective action on a finding of non-conformity, the duty to inform the distribution chain and cooperation on a reasoned authority request moved to AIG-043 in S5; an incident and a non-conformity finding can both be open on the same system at the same time. Neither starts the other. INC-001 holds the general incident response plan, INC-005 the personal data breach notification and INC-010 the authority contacts; AIG-020 holds the logs AIG-043 gives an authority access to. A serious incident involving a designated general-purpose model is reported to the AI Office under AIG-053; where one event is both a system incident and a model incident, both reports are made and each record cites the other.
Applicability (9 profiles)
The deployer detects incidents in its use, informs the provider and, where the provider cannot be reached, the market surveillance authority (Art.26.4). The serious incident report under Art.73 is the provider's.
Art.73 supplies the counterparty and the deadlines this control leaves to applicable law. A serious incident goes to the market surveillance authorities of the Member States where it occurred, immediately once the provider has established a causal link with the system or the reasonable likelihood of one and in any event within 15 days of the provider or the deployer becoming aware, cut to two days for a widespread infringement or a serious incident in the Art.3(49)(b) sense and to 10 days where a person has died. An incomplete initial report followed by a complete one is allowed where that is what makes the deadline. The clause barring an investigation that alters the system before the authority is informed is Art.73 as well and the investigation, its risk assessment and the corrective action are owed without delay after the report, with the notified body brought in where relevant.
Art.26(5) binds both seats. A serious incident is notified to the provider immediately. Where the deployer cannot reach the provider, the Art.73 route to the market surveillance authority applies to the deployer instead. That is the one place this seat files a report the library otherwise treats as the provider's, so the process names who makes the call that the provider is unreachable and what evidences it. AIG-018 carries the monitoring and suspension limb.
Framework Mappings (22)
| EU-AI-Art.26.4 | Deployer Obligations — Operational Monitoring and Incident Notification | full |
| EU-AI-Art.73 | Serious Incidents — Reporting to Market Surveillance Authorities | full |
| COP-S-9 | Serious incident reporting | informative |
| COP-S-9.2 | Relevant information for serious incident tracking, documentation, and reporting | informative |
| COP-S-9.3 | Reporting timelines | informative |
| A.3.3 | Reporting of concerns | partial |
| A.8.4 | Communication of incidents | full |
| GV-1.5-001 | Risk Management Monitoring and Review | GV-1.5-001 | informative |
| GV-1.5-002 | Risk Management Monitoring and Review | GV-1.5-002 | informative |
| GV-2.1-001 | AI Risk Roles and Responsibilities | GV-2.1-001 | partial |
| GV-2.1-002 | AI Risk Roles and Responsibilities | GV-2.1-002 | informative |
| GV-4.3-002 | AI Testing and Information Sharing Practices | GV-4.3-002 | partial |
| GV-6.2-002 | Third-Party Failure Contingency Processes | GV-6.2-002 | full |
| MG-2.3-001 | Unknown Risk Response and Recovery | MG-2.3-001 | partial |
| MG-2.4-002 | AI System Deactivation and Override Mechanisms | MG-2.4-002 | full |
| MG-2.4-003 | AI System Deactivation and Override Mechanisms | MG-2.4-003 | partial |
| MG-4.3-001 | Incident and Error Communication | MG-4.3-001 | informative |
| MG-4.3-002 | Incident and Error Communication | MG-4.3-002 | partial |
| MG-4.3-003 | Incident and Error Communication | MG-4.3-003 | full |
| GOVERN 4.3 | AI Testing and Information Sharing Practices | partial |
| MANAGE 2.3 | Unknown Risk Response and Recovery | full |
| MANAGE 4.3 | Incident and Error Communication | full |
Evidence (3)
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 categories are enumerated rather than inherited from an IT incident taxonomy, (2) what counts as a serious incident is defined and covers harm to health, disruption of critical infrastructure, infringement of obligations protecting fundamental rights and harm to property or the environment, (3) severity tiers are defined with worked examples, (4) the escalation path reaches legal and compliance, (5) the reporting deadline for each category of serious incident is stated together with the point from which it runs, (6) the process bars altering the system in a way that would prevent evaluation before the report is made, (7) communication to affected users and a post-incident review are required within a defined timeframe.
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 most recent full reporting year. Verify: (1) each incident is classified against the defined severity model, (2) each record carries the root cause, the remediation and a closure date, (3) the post-incident review was completed within the defined timeframe, (4) any incident meeting the serious incident definition shows the report to the competent authority, its date and the awareness date it was measured from, (5) any incident where the system was changed during an open serious incident shows that the competent authority was informed of the change before it was made.
Alert rule configuration for the AI incident categories the process defines, showing the route each alert takes.
Example: Alerting configuration export, 2026-08-20: rules for bias drift, unsafe output rate, poisoning indicators and loss of control of an AI-driven action, each routed to the AI on-call rota
Test: Read the alert rule configuration for the systems in the AI system inventory. Verify: (1) a rule exists for each AI incident category the incident process names, (2) each rule routes to a rota or team rather than to an individual mailbox, (3) each rule carries a threshold or condition rather than being informational only, (4) the rules are enabled in production rather than staged, (5) a category named in the process with no rule behind it is reported as a gap.
Questions (2)
Does a documented process exist for detecting, investigating and responding to AI system incidents?
A generic IT incident process does not meet the control. The AI process has to define AI-specific incident categories and the notification obligations that attach to a serious incident; Q2 captures which parts are present.
Which of the following are covered in your AI incident response process?
The serious incident definition, the reporting deadlines and the bar on altering the system are the three a process inherited from IT incident management will be missing. The deadline runs from the moment the organisation or an operator becomes aware of the incident, not from the moment the investigation concludes. AIG-043 asks about corrective action on a system found not to conform and about what an authority can ask for afterwards.