Art. 73 EU AI Act: incident reporting to supervisory authorities

Updated: June 2026

Introduction: the incident reporting framework

Art. 73 of the EU AI ActEU AI ActRegulation (EU) 2024/1689, the European Union's law on artificial intelligence. It takes a risk-based approach: prohibited practices, requirements for high-risk AI systems, transparency obligations for specific uses, and a separate regime for general-purpose AI models. Obligations are divided between providers and deployers. See general-purpose AI, conformity assessment.Open full entry → creates a serious-incident reporting obligation. The primary duty falls on the providerproviderThe actor who develops an AI system (or has it developed) and places it on the market or into service under its own name. It carries manufacturer-style duties: design controls, documentation, conformity.Open full entry → of the high-risk AI systemhigh-risk AI systemAn AI system that falls under the EU AI Act's strictest requirements, following Article 6. There are two routes in: a system that is a product or safety component covered by the Union harmonization legislation in Annex I and subject to third-party conformity assessment, or a system used in one of the areas listed in Annex III, such as employment, education, or access to essential services. Article 6(3) contains a filter: an Annex III system is not high-risk if it does not pose a significant risk of harm to health, safety, or fundamental rights, although a system that profiles natural persons is always high-risk. See EU AI Act, Annex III, conformity assessment.Open full entry →; a deployerdeployerAn organization using an AI system under its own authority in its activities. It carries the operator duties: use per instructions, oversight, input relevance, monitoring, notices.Open full entry → that becomes aware of a serious incidentserious incidentAn AI incident causing (or nearly causing) death, serious harm to health, property, fundamental rights or infrastructure. It triggers regulatory reporting duties for high-risk systems.Open full entry → notifies the provider first under Art. 26(5), and reports to the market surveillance authoritymarket surveillance authorityThe national body that enforces the AI Act in a member state, with powers to investigate, order corrective action and apply penalties.Open full entry → itself only where the provider cannot be reached. This connects the EU AI Act's incident regime to the existing product-safety reporting framework, adapted to the AI context.

What is a "serious incident"?

Art. 3.49 defines a serious incident as any incident or malfunction of a high-riskriskIn the EU AI Act's terms, the combination of the likelihood that a harm occurs and the severity of it if it does. The link between a principle (via the harm that would breach it) and a control (the measure that reduces it). Naming the harm and assessing its risk is required by Art. 9 before any mitigation measure is chosen. See harm, control, residual risk.Open full entry → AI systemAI systemA machine-based system that, for explicit or implicit objectives, infers from input how to generate outputs (predictions, content, recommendations or decisions) that can influence physical or virtual environments. The OECD-style definition followed by the EU AI Act.Open full entry → that directly or indirectly leads, or might reasonably be expected to lead, to:

1. The death of a person or serious damage to their health
2. A serious and irreversible disruption of the management and operation of critical infrastructure
3. The infringement of obligations under Union law intended to protect fundamental rights
4. Serious damage to property or the environment

The phrase "might reasonably be expected to lead" is significant, this is a prospective standard. Deployers must report not only incidents where harmharmHarm is the concrete damage an AI system causes or can cause: to a person, a group, an organization, or society. A risk is that same damage seen in advance, weighed by likelihood and severity; a harm that has occurred is remedied rather than managed.Open full entry → has occurred, but also near-misses where serious harm was a reasonably foreseeable consequence of the AI system's behavior.

Reporting timelines

Unlike the GDPRGDPRRegulation (EU) 2016/679, the General Data Protection Regulation, the EU's law on the processing of personal data. It applies to AI wherever personal data enters training, inputs, outputs, or logs, and it operates alongside the EU AI Act rather than being replaced by it. See controller, processor, lawful basis, DPIA.Open full entry →'s single 72-hour breach rule, Art. 73 sets tiered deadlines, and they run in calendar days, not business days: immediately after the causal link is established and at the latest 15 days after becoming aware (Art. 73(2)); no later than 2 days for a widespread infringement or a serious and irreversible disruption of critical infrastructure (Art. 73(3)); and no later than 10 days in the event of a death (Art. 73(4)).

The reporting process

Step 1: incident detection

Incidents may be detected through: post-market monitoringpost-market monitoringProvider-side duty to systematically collect and act on experience from systems in use, the product-regulation half of continuous monitoring.Open full entry → systems (Art. 26.5), user complaints, staff reports, or external notifications from affected individuals. Your incident detection capability is only as good as your monitoring program.

Step 2: preliminary assessment

Assess whether the incident meets the "serious incident" threshold under Art. 3.49. Document this assessment with the reasoning. Conservative classification is advisable, if in doubt, report.

Step 3: notification to provider

Before or simultaneously with regulatory reporting, notify the AI system provider. The provider has obligations under Art. 73.4 to cooperate in the investigation and may need to take corrective action. Document your notification.

Step 4: regulatory reporting

In the Netherlands no market surveillance authority has been formally designated yet; the draft Uitvoeringswet AI-verordening (UAIV) proposes the AP for much of Annex IIIAnnex IIIThe EU AI Act's list of high-risk use-case areas: biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration, justice.Open full entry → and the AFM and DNB for financial institutions. Report to the competent authority through its designated incident channel once designation is in force. Required content: incident description, system identification, population affected, immediate measures taken, and provider notification status.

Step 5: post-incident review

Conduct a structured post-incident reviewpost-incident reviewThe structured learning step after containment: root cause, corrective actions with owners, and updates flowing back into assessments, registers, training and contracts.Open full entry → to identify root cause and implement preventive measures. Document the review and update your risk assessment.

Compliance checklist

1. Does your incident management policy explicitly cover AI incidentsAI incidentAny event where an AI system's outputs, actions or data handling caused or plausibly could cause harm, or materially deviated from validated behavior, including harmful outputs from a system that is technically working.Open full entry → under Art. 73?
2. Is there a documented procedure for assessing whether an AI incident meets the "serious incident" threshold?
3. Is the competent authority's incident reporting channel known to your AI governance team?
4. Is there a notification procedure for informing AI providers of incidents?
5. Are AI incidents logged, reviewed, and actioned post-incident?
6. Is incident reporting responsibility assigned to a named person or function?