How Must Serious Incidents Be Reported Under Article 73?

What is a serious incident?

A serious incident is defined in the Act by reference to its consequences, and the definition should be checked in the consolidated text before any classification is made. In outline, it covers incidents or malfunctions that directly or indirectly lead to, or might lead to, the death of a person or serious harm to health, a serious and irreversible disruption of the management and operation of critical infrastructure, an infringement of obligations under Union law intended to protect fundamental rights, or serious harm to property or the environment. The breadth of that outline is deliberate: it captures harm to people, to infrastructure, to rights and to property, and it includes malfunctions that might lead to such consequences, not only events where harm has already occurred. A provider and deployer should therefore define, for each system, what kinds of events could meet the definition in their deployment context, and should treat borderline events as reportable for internal escalation until the classification is confirmed.

Who reports, and to whom?

The reporting duty in Article 73 falls on providers of high-risk AI systems placed on the Union market, who report to the market surveillance authority of the Member State where the serious incident occurred. Deployers have a related role: where a deployer becomes aware of a serious incident, the deployer should inform the provider, and the provider's report is triggered by awareness of the provider or, where applicable, the deployer. That allocation means the deployer-to-provider channel is part of the reporting system, not an optional courtesy. A deployer that identifies a possible serious incident should escalate it to the provider promptly, with the facts, the system version, the deployment context and the evidence available, and should record that it did so. A provider that receives deployer information should treat the deployer's awareness as part of its own clock, and should not wait for its own independent confirmation before starting the reporting assessment.

For the broader regulatory framework, see EU database, registration and post-market monitoring.

What are the reporting periods?

The general outer period is no later than 15 days after the provider or, where applicable, the deployer becomes aware of the serious incident, with the report due immediately once a causal link, or the reasonable likelihood of such a link, has been established. Shorter periods apply in specified cases: reporting must be immediate and no later than 2 days after awareness for a widespread infringement or for a serious incident of a specified kind, and no later than 10 days after awareness where a death is involved, subject to the exact wording of Article 73. Those periods are outer limits, not targets: a report should be made as soon as the trigger is met, and an incomplete report made in time is preferable to a complete report made late, since the provision allows an initial incomplete report to be followed by a complete report. A provider should therefore have a pre-agreed incident clock, a named reporting owner and a template ready before any incident occurs, because the periods leave no room to design the process after the event.

What should a report contain, and what follows it?

A report should contain the information Article 73 requires for the incident, including identification of the system and provider, a description of the incident and its consequences, and the corrective action taken or planned, together with any information the authority requests in follow-up. The provider should also take appropriate corrective action, and should cooperate with the market surveillance authority's investigation, providing information and access as the Act requires. After reporting, the provider should feed the incident into post-market monitoring and risk management, reassess whether other systems or deployments are affected, and decide whether a wider corrective action, withdrawal or recall is needed. The incident record should preserve the timeline: when awareness arose, when the causal link was assessed, when the report was made, what was reported, and what action followed. That timeline is the evidence that the reporting periods were met, and it should be kept with the system's technical documentation.

How should an organisation prepare for reporting?

Preparation should be done before deployment, not after an incident. The provider should define serious-incident criteria for each system, train the people who operate and support it to recognise and escalate possible incidents, agree the deployer-to-provider channel and its timescales, and maintain a reporting template and a contact route for each relevant market surveillance authority. A tabletop exercise, in which a simulated incident is escalated and reported within the Article 73 periods, is a practical way to test whether the process works under time pressure and to find gaps in ownership or information. The exercise should include a deployer report, a causal-link assessment, a draft report and a corrective-action decision, and its findings should be recorded and acted on. An untested reporting process is a plan on paper only, and the first real incident is the wrong time to discover that it does not work.

Continue with post-market monitoring under Article 72.

What does this guide not decide?

This guide does not decide whether a particular event is a serious incident, which reporting period applies to it, or what corrective action is required. Those questions depend on the facts of the event, the system's intended purpose and deployment, and the exact wording of Articles 73 and 3, and they require the consolidated text and, where available, Commission guidance and any reporting template to be checked for the specific case. The guide also does not cover reporting duties under other law, such as data protection breach notification or sector vigilance, which can run in parallel with different clocks and recipients. Where an event may be a serious incident, escalate it immediately, seek qualified advice where the classification is contested, and do not delay reporting while other assessments are completed.

Frequently asked questions

Continue through this AI Act cluster

• EU database, registration and post-market monitoring
• post-market monitoring under Article 72
• enforcement and market surveillance
• record-keeping and registration links
• deployer responsibilities
• provider responsibilities