EU AI Act Serious Incident Reporting Under Article 73
This page explains what Article 73 of the EU AI Act requires when a high-risk AI system causes a serious incident: what counts as one, how fast you have to report it, which authority receives the report, and the internal process that has to be running before anything goes wrong. It is written for the people who will actually be paged at 2am, not for the people who will read the file afterwards.
What Article 73 says
Article 73 places the reporting duty on the provider of a high-risk AI system placed on the Union market. The provider must report any serious incident to the market surveillance authority of the Member State where the incident occurred. If the incident occurred in several Member States, that means several authorities.
The clock starts at a specific point. The report is due immediately after the provider has established a causal link between the AI system and the serious incident, or the reasonable likelihood of such a link, and in any event no later than the outer deadlines set out below. The Act expressly allows an incomplete initial report followed by a complete one, so there is no excuse for sitting on a notification while you finish the root cause analysis.
After reporting, the provider must carry out the necessary investigations without delay, including a risk assessment of the incident and corrective action. Article 73 also imposes a preservation duty that engineering teams routinely breach by instinct: you must not perform any investigation that alters the AI system in a way that may affect a subsequent evaluation of the causes, before informing the competent authority that you intend to do so. Rolling back a model version or wiping an inference log to "fix it fast" can itself become the compliance failure.
What counts as a serious incident
The definition sits in Article 3(49). A serious incident is an incident or malfunctioning of an AI system that directly or indirectly leads to any of the following:
- the death of a person, or serious harm to a person's health;
- a serious and irreversible disruption of the management or operation of critical infrastructure;
- the infringement of obligations under Union law intended to protect fundamental rights;
- serious harm to property or the environment.
The third limb is the one that catches software companies off guard. It does not require anyone to be physically hurt. A credit scoring model that systematically disadvantages a protected group, a CV screening tool that filters on a proxy for age, an exam proctoring system that fails one demographic at a materially higher rate: each of these can constitute a serious incident under Article 3(49)(c) even though the only visible symptom is a metric drift in a dashboard. If your product sits in Annex III, fundamental rights incidents are the category you are most likely to have to report.
Note also what is not in scope. A pure availability outage with no harm, a billing bug, a degraded latency SLA: none of these are serious incidents under Article 3(49) unless they produce one of the four listed consequences.
Provider or deployer: who reports what
The Article 73 notification to the authority is the provider's duty. The deployer has a separate and earlier duty under Article 26: a deployer that identifies a serious incident must immediately inform the provider first, then the importer or distributor, and the relevant market surveillance authority. Deployers must also monitor operation in line with the instructions for use, and suspend use and inform the provider where a system presents a risk.
In practice this creates a chain that only works if you have built it. Your deployer customers will not know how to reach your incident channel unless your instructions for use under Article 13 tell them, with a named address and an expected response time. If you are a provider and your first notice of a harmful output is a customer support ticket routed to tier one, you will miss the clock.
Two carve-outs matter. Where providers of Annex III high-risk systems are already subject to Union law laying down equivalent reporting obligations, the Article 73 notification is limited to fundamental rights incidents. Separate arrangements apply to high-risk systems that are, or are safety components of, products covered by the EU medical device regulations. Financial institutions subject to Union financial services law report through the supervisory framework that already applies to them.
The reporting clock
| Incident type | Outer deadline | Starting point |
|---|---|---|
| Serious and irreversible disruption of critical infrastructure | 2 days | Awareness of the incident |
| Death of a person | 10 days | Awareness of the incident, reporting immediately once a causal link is established or suspected |
| All other serious incidents | 15 days | Awareness of the incident |
These are outer limits, not targets. The operative wording is "immediately" once causation or a reasonable likelihood of causation is established. Market surveillance authorities are required to act on a notification within a short window of receiving it, so a late report compresses everyone's timeline, not just yours.
What the authority will expect in the file
Article 73 does not prescribe a form, and the Commission is required to issue dedicated guidance on these obligations. Build your template so you can produce, within hours:
- system identity: name, version or model hash, intended purpose, registration details, the notified body if one was involved;
- the deployer and the Member State where the incident occurred;
- a timeline with timestamps: first harmful output, first internal detection, escalation, causal assessment;
- the harm category under Article 3(49) and the number of people affected;
- the automatically generated logs required by Article 12, preserved and hashed;
- preliminary causal analysis, the corrective action taken or planned, and whether other deployers of the same version are exposed.
Providers must retain system logs for a period appropriate to the intended purpose and in any event at least six months. Deployers must retain the logs under their control on the same minimum. If your retention policy deletes inference logs at 30 days to save storage, you will be unable to investigate an incident reported on day 40 and unable to meet the retention obligation.
The dates that bind
Enforcement powers under the Act are live now and national market surveillance authorities are designated and operating. Prohibited practices have applied since 2 February 2025, and general purpose AI and transparency obligations have been enforceable since 2 August 2026. Providers of general purpose AI models with systemic risk already have a standing duty to track, document and report serious incidents and corrective measures to the AI Office without undue delay.
For high-risk systems, Article 73 bites with the rest of the high-risk regime. Annex III standalone obligations apply from 2 December 2027, a date set by the Digital Omnibus provisional agreement of May 2026 that is still pending formal adoption. Annex I embedded high-risk obligations apply from 2 August 2028. The next hard date is 2 December 2027, 418 days away. That is roughly one product cycle to build and test an incident pipeline that you will be judged on under a two day clock.
Actions to take now
- Write the Article 3(49) classification rule into your triage runbook. Give on-call engineers a one page decision tree with the four harm categories and worked examples from your own product. The person deciding whether a clock has started should not need to read the Regulation at 2am.
- Fix log retention at a minimum of six months and make logs immutable on incident declaration. Add a freeze command that snapshots inference logs, model version, config and feature store state before anyone rolls back. Test that the freeze survives a redeploy.
- Publish a named incident contact to every deployer and put it in the instructions for use. Include an expected acknowledgement time and the information you need from them. Deployers have their own Article 26 duty to inform you immediately, and they will only do so if the route is obvious.
- Pre-map the market surveillance authority for every Member State you operate in. Record the contact route and the notification format per country in a table your legal and engineering leads can both reach. You will not have time to research this during a two day window.
- Run a tabletop exercise against the 2 day clock, not the 15 day one. Simulate a fundamental rights incident surfaced by a deployer, and measure the elapsed time from report to a submittable initial notification. Feed the result into your post-market monitoring plan.
Incident reporting is the obligation where the gap between documented process and real capability shows up fastest, because the deadline is counted in days from awareness rather than from a decision you control. If you want a quick read on whether your systems fall into the high-risk scope that triggers Article 73 at all, and which of the 2027 or 2028 dates applies to you, the free screener at https://www.getactcomply.com/check walks through the classification in a few minutes.