AI Incident Reporting Requirements: Who to Notify

The reporting question almost never has one answer. A single AI failure can simultaneously be a serious incident under EU product law, a personal data breach under GDPR, a material event for a listed company, and a crash report owed to a transport regulator. Four regimes, four recipients, four clocks, and they start at different moments and run at different speeds.

The organizations that handle this badly are rarely the ones that decided not to report. They are the ones that spent the first week deciding whether this counted, and blew a 72-hour window while deciding. This is the map of who wants to hear from you, when, and what triggers each obligation. It is drawn from the published legal texts and regulator guidance cited at the end, and it is not legal advice.

Step zero: classify the event before you route it

Every routing decision downstream depends on what kind of event this is. A model producing harmful output, a vulnerability in an inference server, a coordinated disclosure from an outside researcher and an insider misusing a deployed system are four different events, and only some of them are reportable to any given body. Our working taxonomy of incident, vulnerability, disclosure and misuse exists precisely because this classification drives the response, and getting it wrong at hour one propagates into every notification you send.

Two questions do most of the work:

1. Was there harm, or the realistic prospect of harm, to a person, to property, to the environment, or to critical infrastructure? That is the trigger language most product-safety regimes use.
2. Was personal data exposed, altered or lost? That is a separate trigger with its own, faster clock, and it fires independently of whether anyone was harmed.

If both are yes, you have at least two reports to file, and they go to different authorities.

EU AI Act Article 73: the serious-incident report

Start with the date, because it moved six days before it was due to land. The high-risk obligations in Chapter III of Regulation (EU) 2024/1689 were scheduled to apply from 2 August 2026. Regulation (EU) 2026/1744, the Digital Omnibus on AI, was published in the Official Journal on 24 July 2026 and entered into force on 27 July, deferring them: Annex III standalone high-risk systems now come into scope on 2 December 2027, and Annex I systems embedded in products already covered by EU product-safety law on 2 August 2028.

What did take effect on 2 August 2026 is the Article 50 transparency set and the governance and enforcement machinery, not the high-risk regime. Any guidance still telling you that Article 73 went live for high-risk providers in August 2026 was written before the Omnibus and has not been updated.

The deferral changes the timing, not the content. Article 73 itself is unamended, and its obligation attaches to providers of systems classified as high-risk, so it starts biting as those classification dates arrive. Treat the deadlines below as the design target your reporting process has to hit, not as a clock already running against you, and check the consolidated text rather than any secondary summary of it, this page included.

Who reports. Providers of high-risk AI systems, to the market surveillance authorities of the Member States where the incident occurred. Deployers are pulled in too: a deployer that identifies a serious incident must inform the provider first, then the importer or distributor and the relevant market surveillance authority.

What counts as a serious incident. An incident or malfunctioning that directly or indirectly leads to any of: the death of a person or serious harm to a person’s health; a serious and irreversible disruption to the management or operation of critical infrastructure; an infringement of obligations under Union law intended to protect fundamental rights; or serious harm to property or the environment. Note the third limb. A discriminatory outcome with no physical harm is inside scope.

The clocks. Three of them, and they nest:

• 15 days is the outer limit for the ordinary case. The report is due immediately after you establish a causal link between the system and the incident, or the reasonable likelihood of one, and in any event no later than 15 days after becoming aware.
• 2 days where there is a widespread infringement, or where the incident is a serious and irreversible disruption of critical infrastructure.
• 10 days where a person has died. The report is due immediately once a causal relationship is established or suspected, and no later than 10 days after becoming aware.

Incomplete is allowed. Article 73 explicitly permits an initial incomplete report followed by a complete one where that is necessary to report in time. This is the single most useful provision in the article and the one most often missed. The deadline is on the notification, not on the investigation.

GDPR Article 33: the 72-hour breach clock

If the incident involved personal data, a second and faster clock is running. Notification to the supervisory authority is due without undue delay and, where feasible, no later than 72 hours after becoming aware of the breach. Where the breach is likely to result in a high risk to individuals, Article 34 adds a duty to communicate to the affected people without undue delay.

AI systems make this trigger easier to hit than teams expect. A retrieval-augmented assistant that surfaces one customer’s records to another customer is a personal data breach even though nothing was hacked and no perimeter was crossed. A model that memorized training data and reproduces it on request is arguably the same. There is no intrusion to find, which is exactly the gap our incident-response playbook for AI systems is built around: standard runbooks assume a breach, and AI incidents frequently are not one.

SEC Item 1.05: materiality, not severity

For US-listed registrants, a cybersecurity incident determined to be material triggers a Form 8-K under Item 1.05, generally due four business days after the materiality determination, describing the nature, scope and timing of the incident and its material impact or reasonably likely material impact. Disclosure can be delayed where the Attorney General determines that immediate disclosure poses a substantial risk to national security or public safety and notifies the Commission in writing.

The trap here is the trigger. The clock starts on the materiality determination, not on discovery, but the determination itself must be made without unreasonable delay. Deferring the determination is not a way to defer the filing.

CIRCIA: critical infrastructure, when the rule lands

The Cyber Incident Reporting for Critical Infrastructure Act of 2022 sets a 72-hour clock for covered entities to report a covered cyber incident to CISA, and a 24-hour clock for reporting a ransom payment. The implementing rulemaking has slipped repeatedly, so the operative compliance date is the thing to verify rather than assume. Check CISA’s CIRCIA page for the current status before relying on any date you read in secondary coverage, including this page.

Sector regulators: where AI incidents actually surface first

Sector rules frequently pre-date the AI-specific ones and bite harder.

Road vehicles. In the United States, NHTSA’s Standing General Order 2021-01 requires manufacturers and operators of automated driving systems and Level 2 driver-assistance systems to report crashes where the automation was engaged in the 30 seconds before impact. This is the most commonly mis-stated deadline in the field, because the order has been amended three times and the widely quoted version is not the one in force. The Third Amended order, effective 16 June 2025, removed the one-calendar-day timeline the 2023 version carried. An initial report is now due within five calendar days for a crash involving a fatality, a transport to hospital for treatment, or the strike of a vulnerable road user, the same five days for an airbag deployment or tow-away, and remaining ADS crashes go in monthly. If a source quotes you a one-day clock, it is citing the superseded second amendment. The resulting dataset is the best public evidence base in the field, and we work through what it shows in self-driving car accident causes.

Medical devices. Software as a medical device incorporating AI sits inside existing adverse-event reporting regimes. The AI component does not create an exemption, and it does not create a separate channel either.

Financial services, aviation, energy. Each has an established incident channel. The correct question is not “is there an AI reporting rule for us” but “does our existing sector rule already capture this event”, and the answer is usually yes.

The vendor path, which is not a regulator path

If the failing component came from a supplier, you also owe the supplier a report, and they owe the ecosystem an advisory. That is coordinated disclosure, and it runs on a different logic to regulatory notification: it is negotiated, it has no statutory clock, and its output is a public document written with an eye on how it will read. Knowing how those documents are shaped, and what routinely gets left out of them, is a skill in itself, covered in anatomy of a vendor advisory.

Who to notify, at a glance

Trigger	Recipient	Clock	Regime	Applies from
Serious incident, high-risk AI system on the EU market	Market surveillance authority of the Member State	15 days (ordinary)	EU AI Act Art. 73	2 Dec 2027 (Annex III) / 2 Aug 2028 (Annex I)
Death of a person	Market surveillance authority	10 days, immediately on suspected causal link	EU AI Act Art. 73(4)	as above
Critical-infrastructure disruption or widespread infringement	Market surveillance authority	2 days	EU AI Act Art. 73(3)	as above
Deployer identifies a serious incident	Provider first, then importer/distributor and authority	Immediately	EU AI Act Art. 26(5)	as above
Personal data breach	Supervisory authority (and data subjects if high risk)	72 hours	GDPR Art. 33/34	in force
Material cybersecurity incident, US-listed issuer	SEC, Form 8-K Item 1.05	4 business days after materiality determination	SEC Release 33-11216	in force
Covered cyber incident / ransom payment	CISA	72 hours / 24 hours	CIRCIA	on the final rule’s compliance date, verify current status
ADS or Level 2 ADAS crash	NHTSA	5 calendar days (severe categories), monthly otherwise	Standing General Order 2021-01, third amendment	in force since 16 Jun 2025
Voluntary research submission	AIID, AIAAIC, OECD AIM	None	Voluntary registries	in force

The EU rows are the ones people get wrong, in both directions. The obligations are real and the text is settled, but the Digital Omnibus moved when they attach; build for them now and diarise the classification dates rather than assuming either that nothing applies or that everything already does.

What to have ready before the clock starts

Every one of these notifications asks for the same underlying facts, and the reason organizations miss deadlines is that they cannot assemble those facts fast enough. Four artifacts do most of the work:

1. A dated event log covering model version, prompt or input, retrieval context, tool calls and output, retained long enough to be useful. The logging decisions that make this possible have to be made before the incident, and we set out the ones that matter in our incident logging methodology.
2. A defensible timeline separating when the harm occurred, when you became aware, and when the causal link was established. Those three dates are what the deadlines key off, and reconstructing them after the fact from mismatched sources is its own discipline, covered in reconstructing an incident timeline from primary sources.
3. A source-tiered evidence pack, so the report distinguishes what is established from what is currently believed. The five-tier verification ladder is the same one that should govern what you assert to a regulator.
4. A named owner for the determination. Materiality, causal link and severity are judgments. If nobody owns them, they do not get made, and the clock runs anyway.

Three failure modes worth naming

Waiting for certainty. Article 73 permits an incomplete initial report and GDPR permits phased notification. Both regimes prefer an early partial notice to a late complete one.

Reporting once and assuming it covers everything. A GDPR notification is not an AI Act report, and neither is an 8-K. They go to different bodies and answer different questions.

Naming a culprit in the first report. Attribution is the slowest and most consequential call in any incident, and early attribution in a regulatory filing is very hard to walk back. State what happened and what you know; leave the actor unknown until it is not. That policy is why our own catalog in the AI Incident Explorer carries an explicit actor-unknown class, and the reasoning is set out in why we do not do attribution speculation.

Once the mandatory notifications are out, the voluntary ones are worth making too. The public record of AI failures is thin precisely because most events are reported to a regulator and never written up anywhere else. Our comparison of the public AI incident databases covers which of them accept submissions and what each one will do with yours.