Summary: Mandatory reporting of serious incidents by providers of high-risk AI systems, on a tiered clock from 2 to 15 days. The Code of Practice runs a parallel, faster regime for GPAI with systemic risk.
Sources: raw/AI-regulations/Regulation - EU - 2024_1689.md (Article 73); raw/Laws/Overview of the Code of Practice...md (Commitment 9)
Last updated: 2026-07-28
Who reports, to whom
Art 73(1) — “Providers of high-risk AI systems placed on the Union market shall report any serious incident to the market surveillance authorities of the Member States where that incident occurred” (source: Regulation - EU - 2024_1689.md).
The clock
The trigger is establishing “a causal link between the AI system and the serious incident or the reasonable likelihood of such a link” (Art 73(2)). Suspicion starts the clock, not confirmation.
| Incident type | Deadline |
|---|---|
| Widespread infringement or serious incident per Art 3(49)(b) | 2 days from awareness (Art 73(3)) |
| Death of a person | 10 days — “immediately after the provider or the deployer has established, or as soon as it suspects, a causal relationship” (Art 73(4)) |
| General case | 15 days from awareness (Art 73(2)) |
Art 73(2) adds that the period “shall take account of the severity of the serious incident” — the 15 days is a ceiling, not an allowance.
Art 73(5) — incomplete initial reports are explicitly permitted “where necessary to ensure timely reporting,” followed by a complete report. Speed over completeness.
The evidence-preservation rule
Art 73(6) is the provision security teams need to internalise. The provider must investigate without delay, including risk assessment and corrective action, and:
“shall not perform any investigation which involves altering the AI system concerned in a way which may affect any subsequent evaluation of the causes of the incident, prior to informing the competent authorities of such action.”
This directly constrains incident response. The instinct to hotfix, roll back the model, or purge a poisoned memory store is exactly the kind of alteration this covers. Notification comes first.
That sits in tension with the containment guidance in the IR sources — Microsoft’s staged model wants “at least one containment action… executable within 60 minutes of incident declaration, without waiting for root-cause determination” (source: raw/AI-incident-response/Incident response for AI systems.md), and CoSAI asks whether to “roll back to a previous model version? Purge poisoned memory? Rebuild your vector database?” (source: raw/AI-incident-response/Defending AI Systems...md). Under Art 73(6) those actions are permitted, but the authorities must be informed of them first. Playbooks need that notification step baked in, not bolted on. See AI incident response.
Downstream timing
Art 73(8) — the market surveillance authority must take Regulation (EU) 2019/1020 Art 19 measures “within seven days from the date it received the notification.”
Art 73(11) — national competent authorities “shall immediately notify the Commission of any serious incident, whether or not they have taken action on it.”
Avoiding double reporting
Art 73(9) — for Annex III high-risk systems whose providers are already subject to equivalent EU reporting obligations, notification is limited to Art 3(49)(c) incidents.
Art 73(10) — for systems that are medical devices under Regulations (EU) 2017/745 or 2017/746, likewise limited to Art 3(49)(c), reported to the national competent authority chosen for that purpose.
Guidance
Art 73(7) — the Commission “shall develop dedicated guidance to facilitate compliance,” issued by 2 August 2025 and assessed regularly.
The GPAI parallel regime
Art 55(1)(c) requires GPAI systemic-risk providers to report serious incidents to the AI Office “without undue delay.” The Code of Practice Commitment 9 makes that concrete, and it is faster and more prescriptive than Art 73 (source: raw/Laws/Overview of the Code of Practice...md):
| Incident type | Initial report deadline |
|---|---|
| Disruption to critical infrastructure | ≤ 2 days |
| Serious cybersecurity breach (e.g. exfiltration, cyberattack) | ≤ 5 days |
| Death of a person | ≤ 10 days |
| Serious harm to health, fundamental rights, property, environment | ≤ 15 days |
“Awareness includes both established and reasonably suspected involvement.”
Also required: intermediate reports at least every 4 weeks while unresolved; a final report within 60 days of resolution; 5-year retention.
The 5-day cybersecurity-breach tier is the one with no Article 73 equivalent — Art 73’s tiers are keyed to harm type, not to attack. For a GPAI systemic-risk provider, a weight exfiltration is a 5-day reportable event.
What must be in a GPAI report
Commitment 9 Measure 9.2 requires start/end dates, harm description and affected groups, the causal chain, model identification, evidence of involvement, measures taken, recommendations for authorities, and a root cause analysis covering “the model outputs that caused or contributed to the incident,” inputs used, and “systemic mitigation failures or circumventions” — plus post-market monitoring patterns “reasonably linked to the incident (e.g. near misses, anomaly trends).”
“If certain information is unavailable at the time of reporting, the report must record this explicitly.”
That root-cause schema is a useful IR template regardless of jurisdiction. It also presumes you have per-incident input/output capture — which is the Art 12 record-keeping obligation and the telemetry gap Microsoft flags. See high-risk-requirements.
Detection sources
Measure 9.1 requires consulting “external sources, including police and media reports, social media content, academic research, and incident databases” and enabling third-party reporting to the signatory or directly to the AI Office.
The incident-database point connects to the AI Incident Database — see AIID incident responses.