AIG-053 Serious Incident Reporting to the AI Office
Description
For each general-purpose AI model designated as carrying systemic risk, a record exists of every serious incident in which the model was involved, directly or through a system built on it, gathered from the organisation's own monitoring, from downstream providers and users through a published reporting channel and from public sources reviewed at defined intervals. Each record holds the incident, the model's involvement as established or suspected, its causes as established, the corrective measures taken or planned and their dates, and is reported to the AI Office and to the national competent authorities concerned within the period the applicable law and code of practice set for that category of incident, measured from the point the organisation became aware of the model's involvement, with an initial report followed by updates until the incident is closed. Incident records and the information gathered for them are retained for at least the period the code of practice sets.
Rationale
The counterparty and the trigger are what separate this from AIG-021: the AI Office rather than a national market surveillance authority, and a designated model's involvement rather than a system the organisation operates. The Code sets the initial report at two days for critical infrastructure disruption and cybersecurity breaches including weight exfiltration, five days for death and ten days for serious harm, then intermediate and final reports; the periods live in the evidence and the register of obligations rather than the text. The public-source review is the item an incident process built for operated systems never has, because the model is involved in incidents the organisation does not see. Boundary with AIG-021: that control reports a system's serious incident to the competent authority of the jurisdiction; where one event is both, both reports are made and each record cites the other. Boundary with AIG-038: that control receives feedback and adverse impact reports from users and affected people; the channel here receives incident reports about the model from downstream providers and users. gpai-provider seat (ADR-031).
Applicability (9 profiles)
Reporting to the AI Office about a designated model is the gpai-provider seat (ADR-046). A SaaS provider reports a systems serious incident to the competent authority under AIG-021.
A general-purpose model providers duty (gpai-model-provider, ADR-046). The deployer takes the model documentation and the published training summary the provider issues into its AIG-032 assessment.
Condition: ai_risk_class in gpai-systemic
Art.55(1)(c) binds the provider of a model designated as carrying systemic risk.
Reporting to the AI Office about a designated model is the gpai-provider seat (ADR-046). A SaaS provider reports a systems serious incident to the competent authority under AIG-021.
A general-purpose model providers duty (gpai-model-provider, ADR-046). The deployer takes the model documentation and the published training summary the provider issues into its AIG-032 assessment.
Reporting to the AI Office about a designated model is the gpai-provider seat (ADR-046). A SaaS provider reports a systems serious incident to the competent authority under AIG-021.
Reporting to the AI Office about a designated model is the gpai-provider seat (ADR-046). A SaaS provider reports a systems serious incident to the competent authority under AIG-021.
Reporting to the AI Office about a designated model is the gpai-provider seat (ADR-046). A SaaS provider reports a systems serious incident to the competent authority under AIG-021.
Reporting to the AI Office about a designated model is the gpai-provider seat (ADR-046). A SaaS provider reports a systems serious incident to the competent authority under AIG-021.
Framework Mappings (7)
| EU-AI-Art.55.3 | Systemic Risk Obligations — Serious Incident Reporting | full |
| COP-S-3.5 | Post-market monitoring | informative |
| COP-S-9 | Serious incident reporting | full |
| COP-S-9.1 | Methods for serious incident identification | full |
| COP-S-9.2 | Relevant information for serious incident tracking, documentation, and reporting | full |
| COP-S-9.3 | Reporting timelines | full |
| COP-S-9.4 | Retention period | informative |
Evidence (2)
The serious incident register for a designated model, with each record's sources, contents, report dates against the period for its category and the retention marker.
Example: Aurora-2 serious incident register 2026, three records, exported 1 September 2026; SI-2026-02 initial report to the AI Office on 14 July 2026, final report 29 August 2026.
Test: Verify: (1) each record names the incident, the model's involvement as established or suspected, the source it was learned from, the causes and the corrective measures with dates, (2) the initial report to the AI Office and to any national authority concerned falls within the period for the category, measured from the recorded awareness date, (3) updates follow until the record is closed with a final report, (4) a record that also fell under the system incident process cites the AIG-021 record and its authority report, (5) the register and its supporting information carry a retention marker of at least the period the code sets, (6) where no incident occurred in the period, the public-source reviews are recorded at the defined interval.
The published reporting channel for downstream providers and users, exercised by submitting a test report and following it to the register.
Example: Walkthrough of the model incident reporting page and intake queue on 8 September 2026, test report MI-T-0031.
Test: Verify: (1) the channel is published where the model is offered and states what it is for, (2) a test report submitted through it reaches the register with a timestamp, (3) the intake owner is named and the test report was triaged within the period the process states, (4) the channel tells the reporter that their own Art.73 obligations are unaffected.
Questions (3)
Is a serious incident register kept for each designated model, covering incidents the model was involved in through systems built on it?
Answer for the model, wherever the incident happened. An incident process limited to systems the organisation operates is AIG-021 and does not answer this question.
Which of the following does the process include?
Options follow the incident from discovery to retention. The public-source review is the one a process inherited from operated systems will be missing.
From what point is the reporting period measured?
Options run from the earliest trigger to none. Awareness includes a credible report from a downstream provider or a public source, not only an internal finding.