Why incident reporting deserves attention now
Most AI compliance programmes are built around the moment a system goes to market: the risk assessment, the technical file, the conformity assessment, the CE mark. Far fewer are built around the moment something goes wrong. Yet that is where regulatory exposure tends to become visible, and where the timelines are unforgiving.
Article 73 of the EU AI Act requires providers of high-risk AI systems to report serious incidents to market surveillance authorities within deadlines measured in days, not months. The obligation was not amended by the Digital Omnibus on AI in July 2026 – the deadlines and the definition stand exactly as enacted. What did change is when the high-risk regime as a whole starts to apply, which gives businesses time to build the process properly rather than improvise it under pressure.
What counts as a serious incident
Article 3(49) defines a serious incident as an incident or malfunctioning of an AI system that directly or indirectly leads to any of four outcomes: 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; or serious harm to property or the environment.
Two features of that definition drive most of the practical difficulty. The first is “indirectly”. An AI output that feeds a human decision, or flows into a downstream process, can still be the cause of a serious incident. The second is the fundamental rights limb. Discriminatory outputs, unlawful automated decisions and privacy infringements sit inside the definition of a serious incident, and they are considerably harder to detect than a physical failure. A system can be causing reportable incidents for months without anyone in the business noticing.
Who reports, and to whom
The primary duty sits with providers of high-risk AI systems placed on the Union market. Reports go to the market surveillance authorities of the Member State where the incident occurred – so an incident affecting users in three countries can mean three notifications.
Deployers are not exempt. Article 26(5) requires a deployer that identifies a serious incident to immediately inform first the provider, then the importer or distributor, and then the relevant market surveillance authorities. The same paragraph requires a deployer to suspend use and inform the provider without undue delay where use of the system may present a risk within the meaning of Article 79(1).
That sequencing matters operationally. The provider’s clock can start running from the moment the deployer becomes aware – so a deployer that sits on an incident for a week has consumed a large share of the provider’s reporting window before the provider even knows.
The three clocks
Fifteen days: the general rule
Article 73(2) requires the report 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 not later than 15 days after the provider or deployer becomes aware of it. The period must take account of the severity of the incident, so 15 days is an outer limit rather than a default.
Note the trigger: reasonable likelihood of a causal link, not proof of one. Waiting for certainty before starting the clock is a misreading.
Two days: widespread infringement or critical infrastructure
Article 73(3) shortens the deadline to not later than two days after becoming aware, in the case of a widespread infringement or a serious and irreversible disruption of the management or operation of critical infrastructure. Two days is not enough time to design a process. It is only enough time to execute one that already exists.
Ten days: death of a person
Article 73(4) sets a deadline of not later than ten days after becoming aware where a person has died. The clock here starts immediately after the provider has established, or as soon as it suspects, a causal relationship – a deliberately low threshold.
Reporting before you have all the answers
Article 73(5) allows an initial incomplete report where necessary to ensure timely reporting, followed by a complete report. This is the provision that resolves the tension between speed and accuracy. You are not expected to have finished the investigation before you notify.
What you must do after reporting
Article 73(6) requires the provider, without delay, to perform the necessary investigations into the incident and the AI system, to include a risk assessment of the incident, to take corrective action, and to cooperate with the competent authorities and, where relevant, the notified body.
One duty in that paragraph is regularly missed and creates real difficulty. The provider must not perform any investigation that involves altering the AI system in a way that may affect the subsequent evaluation of the causes, before informing the competent authorities. The engineering instinct after a serious failure is to patch it immediately. Article 73(6) requires you to tell the authority first.
On the authority’s side, Article 73(8) requires market surveillance authorities to take appropriate measures within seven days of receiving the notification.
Where Article 73 gives way to other regimes
The AI Act does not stack incident reporting on top of every other regime without limit. Article 73(9) provides that where providers of Annex III high-risk systems are already subject to Union legislative instruments laying down equivalent reporting obligations, the Article 73 notification is limited to serious incidents falling under the fundamental rights limb of Article 3(49). This is the hook for regimes such as NIS2 and DORA.
Article 73(10) applies a similar limitation to high-risk systems that are, or are safety components of, devices covered by the Medical Devices Regulation or the In Vitro Diagnostic Regulation, with notification going to the national competent authority designated for that purpose.
The GDPR is different. Article 73 contains no GDPR carve-out. Personal data breach notification under Article 33 GDPR – 72 hours to the supervisory authority – runs in parallel and cumulatively. A single incident involving an AI system and personal data can trigger both regimes on different clocks to different authorities. Building one process that recognises both is considerably easier than reconciling two after the fact.
Praktiskt exempel
A Nordic lender uses an AI creditworthiness system. An internal review finds the model has been systematically declining applicants from certain postcodes at a materially higher rate, for reasons unrelated to their financial position, over several months.
This is not a crash and nobody was hurt, but it sits squarely within the fundamental rights limb of Article 3(49). It is a serious incident. Because the pattern affects consumers in more than one Member State, the widespread infringement analysis and its two-day deadline come into play. Separately, if personal data has been processed unlawfully, GDPR notification obligations may run in parallel. And under Article 26(5) the lender, as deployer, must inform the provider immediately.
The lesson is that the incidents most likely to be reportable under Article 73 look like analytics findings, not outages – which is precisely why they are missed.
Vanliga misstag som företag gör
The first is treating AI incident reporting as an extension of the IT security incident process. Security processes are tuned to detect breaches and outages. They are not tuned to detect discriminatory outputs, and the fundamental rights limb is where much of the Article 73 exposure sits.
The second is starting the clock when causation is proven. Article 73(2) starts it at reasonable likelihood, and Article 73(4) starts it at suspicion.
The third is patching first and notifying second, which risks breaching Article 73(6) and destroying the evidence an authority will want to see.
The fourth is assuming a sectoral regime displaces Article 73 entirely. Where the equivalence limitation applies, the fundamental rights limb survives – so a NIS2 report does not close the file.
The fifth is leaving deployers out of the process. If your customers do not know they must tell you immediately, you will learn about incidents far too late to meet your own deadlines.
Rekommenderade åtgärder
Write an AI incident procedure that is distinct from, but connected to, your security incident and personal data breach procedures, with a single intake point and a triage step that tests an event against all four limbs of Article 3(49) rather than only the safety limb.
Define internally what “becoming aware” means and who has authority to declare an incident, because the clocks run from that moment. Build monitoring capable of surfacing fundamental rights harms – disparity testing, outcome monitoring by protected characteristic, complaint pattern analysis – not merely uptime and error rates.
Put deployer notification duties into your customer contracts and instructions for use, with a defined channel and an explicit expectation of immediate notice. Add a hold step to your engineering runbook so that no remedial change is deployed to an implicated system before the authority has been informed. Then rehearse it. A two-day deadline is met by muscle memory, not by procedure documents.
Vanliga frågor
When does the Article 73 duty actually start?
Article 73 sits in Chapter IX, which applies from 2 August 2026. But it operates on high-risk AI systems, and the obligations that create that population were deferred by the Digital Omnibus on AI to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems. In practical terms the reporting regime becomes operative alongside those dates – which is time to build the process, not a reason to skip it.
Do general-purpose AI model providers have to report incidents?
Providers of general-purpose AI models with systemic risk have a separate duty under Article 55(1)(c) to track, document and report relevant information about serious incidents and corrective measures to the AI Office and, as appropriate, national competent authorities, without undue delay. There is no fixed day count in the Act. Those obligations have applied since 2 August 2025, and the Commission has published a reporting template to support them.
What if we are not sure the AI system caused the harm?
Report anyway if there is a reasonable likelihood of a causal link, and use the initial incomplete report route in Article 73(5). Under-reporting where a link is reasonably likely is a compliance failure; reporting an incident that later proves unrelated is not.
Slutsats
Article 73 turns a bad day into a regulatory deadline measured in days. Fifteen days as a general rule, ten where someone has died, two for widespread infringements and critical infrastructure disruption – with a definition of “serious incident” broad enough to capture discriminatory outputs as readily as physical failures. The businesses that handle this well are the ones that built the detection, triage and escalation path before they needed it, and that tell their deployers exactly what to do. Lawgent helps businesses design AI incident reporting processes that work alongside their GDPR, NIS2 and DORA obligations, and that hold up when the clock is running.
