Almost everything written about AI incident reporting assumes Article 73 of the EU AI Act is the live obligation. Article 73 does apply. The article sits in Chapter IX, which takes the Regulation’s general application date of 2 August 2026 and appears in none of the exceptions in Article 113.
Its subject is a different matter. Article 73(1) binds “providers of high-risk AI systems placed on the Union market”, and the term high-risk AI system is nowhere defined in Article 3. Classification happens at Article 6, which sits in Chapter III Section 1, and the Digital Omnibus deferred Chapter III Sections 1 to 3 to 2 December 2027 for systems classified under Article 6(2) and Annex III, and to 2 August 2028 for systems classified under Article 6(1) and Annex I.
An article can therefore be in force while the population it binds has not arrived. AI incident reporting sits in exactly that position today, which explains the three absences dominating the subject: no final Commission guidance, no settled list of authorities to report to, and no published count of reports.
What follows sorts the duties by the date each one starts to bind, names what each requires, and says what the fifteen months before the first large commencement are for.
Live today: Article 55(1)(c), and it carries no statutory deadline
AI incident reporting has exactly one duty binding right now. Chapter V has applied since 2 August 2025, and Article 55(1)(c) requires providers of general-purpose AI models with systemic risk to “keep track of, document, and report, without undue delay, to the AI Office and, as appropriate, to national competent authorities, relevant information about serious incidents and possible corrective measures to address them”.
A serious incident report under that article carries no number in the Regulation. The Commission published a reporting template for these incidents on 4 November 2025, and the template states no deadlines either.
The template asks for nine substantive items, among them the chain of events that directly or indirectly led to the incident, a description of the evidence establishing the model’s involvement, a root cause analysis covering the inputs used and “any failures or circumventions of systemic risk mitigations”, and any patterns from post-market monitoring “such as individual or aggregate data on near misses”.
Serious incident clocks for model providers live in the General-Purpose AI Code of Practice, which is voluntary. Its Safety and Security chapter sets four initial-report clocks. Two days after becoming aware of the model’s involvement in a serious and irreversible disruption of critical infrastructure. Ten days for a death. Fifteen days for serious harm to health, an infringement of fundamental-rights obligations or serious harm to property or the environment. Each limb bites where the signatory establishes “or suspect[s] with reasonable likelihood” the causal relationship.
Serious incident reporting under the Code adds a limb the AI Act has nowhere: not later than five days for “a serious cybersecurity breach, including the (self-)exfiltration of model weights and cyberattacks”. The Code then requires an intermediate report at least every four weeks while the incident is unresolved, a final report not later than sixty days after resolution, and retention of the documentation for at least five years.
Interpretation, and it is mine: a model provider that has not signed the Code still owes Article 55(1)(c), and “without undue delay” will be read against the only published benchmark in existence. The Code’s clocks are the safest working assumption for a non-signatory, not a set of obligations it escaped.
Why Article 73 applies but binds almost nobody yet
Commencement dates for every AI incident duty are fixed by Article 113. The Regulation “shall apply from 2 August 2026”, subject to exceptions. Point (b) pulls Chapter III Section 4, Chapter V, Chapter VII, Chapter XII and Article 78 forward to 2 August 2025. Point (c), as replaced by the omnibus, pushes Chapter III Sections 1, 2 and 3 back to 2 December 2027 and 2 August 2028. Chapter IX, where Article 73 lives, is in neither list, so it takes the general date.
The consequence is structural rather than a drafting accident. Article 111(2), as amended, now speaks of “the date of application of Chapter III referred to in Article 113”. Article 111(2) then applies the Regulation to operators of high-risk systems placed on the market before that date “only if, as from that date, those systems are subject to significant changes in their designs”. Providers and deployers of high-risk systems intended for use by public authorities are given until 2 August 2030.
Article 26 sits in the same deferred block, which matters because the deployer’s incident duty lives there. Article 26(5) requires a deployer who identifies a serious incident to inform the provider immediately, then the importer or distributor and the market surveillance authority. The deployer duty is not live today either.
Two duties inside Chapter III do run on the earlier date and are worth separating out. Chapter III Section 4, on notifying authorities and notified bodies, has applied since 2 August 2025. Article 6(5), the Commission’s duty to supply classification guidelines, is expressly carved out of the deferral, and those guidelines remain in draft after a targeted consultation that closed in July 2026.
The trigger is a harm, and no deferral changes that
A serious incident is defined in Article 3(49), which sits in Chapter I and has applied since 2 February 2025. 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; or serious harm to property or the environment.
Read what that definition does not say. The definition says nothing about availability, latency, error rate or service tier. The Commission’s draft guidance lists examples of qualifying incidents or malfunctions at paragraph 12, and the list is not a security list: misclassifications, significant drops in accuracy, temporary system downtime, unexpected system behaviour. Its worked examples are a credit-scoring system denying a loan and a recruitment system discarding candidates by gender or ethnicity.
AI incident response templates on the open web classify by response time, where P1 means fifteen minutes and P4 means the next business day. None of those matrices can detect the case the Regulation cares about most: a model that is healthy, fast and wrong, whose output entered a decision about a person. Availability monitoring will never raise that serious incident.
Interpretation, mine again: reportability turns on the decision the output entered, not on the system’s state, so a severity scheme needs a second axis asking what the output was used for and whether an identifiable person was affected. The second axis is worth building now, because it takes longest and it is indifferent to commencement dates.
The clocks Article 73 will impose, and why two days is the design constraint
Article 73(2) carries the default clock. The report “shall be made 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, where applicable, the deployer, becomes aware of the serious incident”. The paragraph adds that the period “shall take account of the severity of the serious incident”, making fifteen days a ceiling rather than an allowance.
Two shorter serious incident clocks displace it. Article 73(3) requires a report “immediately, and not later than two days” for a widespread infringement or a critical-infrastructure incident under Article 3(49)(b). Article 73(4) requires a report “immediately after the provider or the deployer has established, or as soon as it suspects, a causal relationship” where a person has died, and in any event “not later than 10 days”.
Note that the triggers differ inside one article. The fifteen-day and two-day limbs run their outer bound from awareness of the incident. The ten-day limb runs its outer bound from awareness but its reporting trigger from establishing or merely suspecting causation, which fires earlier. Any plan that treats all three as one clock from one timestamp will miss the one that matters most.
Article 73(5) removes the excuse that the facts are unclear: “Where necessary to ensure timely reporting, the provider or, where applicable, the deployer, may submit an initial report that is incomplete, followed by a complete report”. The answer to not yet knowing whether the model caused it is an incomplete report inside the deadline.
Two days is what an AI incident response plan has to be designed against, because two days accommodates no meeting, no external legal opinion and no executive decision cycle.
Article 73(6) is the provision that survives every deferral
One paragraph shapes AI incident practice long before it binds anyone, because the behaviour it prohibits is the behaviour a competent team performs by reflex.
Article 73(6) requires the provider, after reporting, to “perform the necessary investigations in relation to the serious incident and the AI system concerned”, including a risk assessment and corrective action. Then: the provider “shall not perform any investigation which involves altering the AI system concerned in a way which may affect any subsequent evaluation of the causes of the incident, prior to informing the competent authorities of such action.”
Rolling back the weights, patching the prompt, pinning the previous version and redeploying all alter the system in ways that affect a later evaluation of the AI incident’s causes. Performing any of them before informing the authority is the prohibited act. Across the search results reviewed for this page, exactly one published page mentions this provision at all.
Three things make that provision survivable, and none of them can be improvised. A containment action that does not alter the artefact under investigation, such as disabling the route rather than replacing the model. A preservation step that captures weights, prompts, configuration, inputs, outputs and logs at the moment of detection. And a named person authorised to tell the competent authority that an alteration is about to happen.
Log retention deserves its own line. Article 19 requires providers of high-risk systems, and Article 26(6) requires deployers, to keep automatically generated logs “for a period appropriate to the intended purpose of the high-risk AI system, of at least six months”. A thirty-day default in a logging platform destroys the evidence before a serious incident investigation finishes, and changing that default is a ticket, not a project.
The Commission is overdue on guidance it owed in August 2025
Serious incident guidance is itself an obligation, and it falls on the regulator under Article 73(7). The Commission “shall develop dedicated guidance to facilitate compliance with the obligations set out in paragraph 1 of this Article”, and that guidance “shall be issued by 2 August 2025, and shall be assessed regularly”.
What exists is a consultation draft published on 26 September 2025 and open until 7 November 2025, still the only version. The AI Act Service Desk resources list still carries it as a draft. No summary of consultation responses has been published. The enforcement framework page, last updated 24 August 2026, describes the complaint tool, the whistleblower tool and the downstream-provider channel, and mentions serious incident reporting nowhere.
The draft is visibly unfinished. Six paragraphs end in a literal placeholder, one of them inside the list defining when a deployer may treat the provider as unreachable, immediately after the single criterion the drafters did complete. Another sits inside the list of what cooperation with authorities requires. The section on the Commission’s own role is a one-line stub.
Where the draft is complete, it supplies figures the Regulation does not contain, and they should be treated as direction rather than law. “Immediately” in Article 26(5) “should be understood as within 24 hours”. A deployer is unable to reach the provider where “the Provider does not answer within 24 hours”. Serious harm to property “should in any case exceed 5% of the purchase price”.
The fundamental-rights limb is narrowed to infringements that interfere with Charter rights “on a large scale”. And a bridge runs to NIS2: where a provider has reported an incident under NIS2 for severe operational disruption, “such an incident should also be considered a serious incident under the AI Act, provided that the disruption is irreversible and that the disruption is caused by an incident or malfunctioning of an AI system”.
Where the report will go, and the nine addresses that currently exist
An AI incident report goes to the market surveillance authorities of the Member State where the incident occurred, under Article 73(1). Member States were required to designate those authorities by 2 August 2025. The Commission publishes the resulting list and marks its own uncertainty on it: “For Single Points of Contact marked with *, the national designation decision is still pending final adoption.”
Counting that table as published on 7 September 2026 gives the state of the addressing system. Nine Member States have a contact listed without an asterisk: Denmark, Finland, Greece, Ireland, Italy, Latvia, Lithuania, Malta and Poland. Twelve carry the asterisk: Cyprus, Czechia, Estonia, France, Germany, Luxembourg, Netherlands, Portugal, Romania, Slovenia, Spain and Sweden.
Six show a dash: Austria, Belgium, Bulgaria, Croatia, Hungary and Slovakia. The European Data Protection Supervisor is the authority for EU institutions, bodies and agencies. The same Commission page notes that where a Member State fails to designate, “the Commission may launch a formal infringement procedure”.
The draft serious incident guidance supplies a tie-breaker worth adopting in advance: where the exact location is unknown to the provider, “it is the business location of the deployer that counts”.
Article 75(1a) moves part of the population to the AI Office
Regulation (EU) 2026/1744 inserted a paragraph, in force since 27 July 2026, that changes the addressee for a defined group. Article 75(1a) provides: “By way of derogation from Article 73, providers of high-risk AI systems subject to the competence of the AI Office pursuant to paragraph 1 of this Article shall report any serious incidents to the AI Office.
Article 73 (2) to (9), shall apply mutatis mutandis. The AI Office shall promptly transmit the relevant information to the market surveillance authority of the Member State in the territory of which the provider or its legal representative is situated.”
The group is defined by the amended Article 75(1), which gives the AI Office exclusive competence over AI systems “based on general-purpose AI models where the model and the system are developed by the same provider, or by providers forming part of the same undertaking as that provider”, and over systems inside a very large online platform or search engine. Four carve-outs stay national: Annex I products, Annex III point 2 systems, law enforcement, border and financial bodies under Article 74(6), and Annex III point 8 on the administration of justice.
A group company shipping a high-risk product built on its own model will therefore file its AI incident reports with the AI Office rather than nationally, on the same clocks and from the same commencement dates.
The other clocks are live now, and none of them is about AI
AI incident duties under the high-risk regime are waiting, but the regimes around them are already running, and an AI failure that also breaches data, security or product rules triggers them today. The deadlines below are taken from the instruments.
GDPR Article 33 requires notification of a personal data breach “without undue delay and, where feasible, not later than 72 hours after having become aware of it”, unless the breach is unlikely to result in a risk to rights and freedoms.
NIS2 Article 23 runs three clocks for a significant incident at an essential or important entity: an early warning “within 24 hours of becoming aware”, an incident notification “within 72 hours of becoming aware”, and a final report “not later than one month after the submission of the incident notification”.
DORA sets none of its hours in Regulation (EU) 2022/2554. Commission Delegated Regulation (EU) 2025/301 supplies them at Article 5: an initial notification “as early as possible, but in any case, within four hours from the classification of the ICT-related incident as a major ICT-related incident and no later than 24 hours from the moment the financial entity has become aware” of it, an intermediate report within 72 hours of that notification, and a final report no later than one month afterwards.
Medical Device Regulation Article 87 mirrors the AI Act’s shape at fifteen days, two days for a serious public health threat and ten days for death or unanticipated serious deterioration, filed through EUDAMED. Article 87(7) adds a rule the AI Act lacks: where the manufacturer is uncertain whether an incident is reportable, “it shall nevertheless submit a report”.
SEC Form 8-K Item 1.05 requires disclosure of a material cybersecurity incident within four business days of the registrant determining materiality, a clock that starts at a judgement rather than an event. CIRCIA in the United States has no final rule, so its 72-hour and 24-hour figures are statutory and proposed rather than operative.
Two carve-downs will matter for AI incident reporting when Article 73 does bind. Article 73(9) narrows the AI Act duty to fundamental-rights incidents under Article 3(49)(c) where the provider is already subject to equivalent Union reporting obligations. Article 73(10) does the same for medical devices and sends the report to a nationally chosen authority.
What fifteen months of runway should buy
Building the capability takes longer than submitting a filing, so deferral is not relief for AI incident work. Six parts of an AI incident response capability are worth building before December 2027, and each is independently useful in the meantime.
A classification test asking what a model output was used for and who was affected, sitting alongside the availability severity matrix rather than inside it. An awareness timestamp that is captured and stored, since every clock in every regime on this page runs from one. A preservation routine that snapshots weights, prompts, configuration, inputs, outputs and logs on detection of an AI incident.
Log retention raised to at least six months, which is the floor Articles 19 and 26(6) will impose and a defensible number regardless. A named authority to notify before any alteration, under Article 73(6). And an addressee register that tracks the Commission’s list as designations firm up, alongside the decision of whether the organisation will file nationally or to the AI Office under Article 75(1a).
Two AI incident counts are worth knowing while official ones do not exist. The AI Incident Database lists 1,682 incidents drawn from 6,503 distinct reports as at 19 September 2026, computed from the site’s own dataset, curated from news coverage against an adaptive editorial rule set rather than a statutory definition; its highest incident identifier is 1693, so the count is a floor.
The OECD AI Incidents and Hazards Monitor shows about 17,048 incidents and hazards combined, built from news media and classified by language models, and describes itself as beta. Neither is a regulatory record. No official count of Article 73 reports has been published by the Commission or by any Member State.
Where the evidence has to live
Every AI incident clock on this page runs from a moment an organisation must be able to evidence afterwards, and every filing has to be reconstructable long after the people involved have moved on. The awareness timestamp, the classification decision and its reasoning, the preservation snapshot, the notification made before any alteration, the incomplete initial report and the complete one that followed, and the record of which other regimes were notified and when.
Governance software earns its place at exactly that point, and AI incident reporting is the problem Govern365.ai was built around. Holding the addressee register, the classification criteria, the preservation checklist and the filing record in one place, with owners and dated versions, turns an AI incident from an improvisation into a file.
Govern365.ai maps each obligation to the record that proves it across the EU AI Act, ISO/IEC 42001 and the NIST AI Risk Management Framework, so an Article 55(1)(c) report today and an Article 73 report in 2027 draw on one artefact rather than two that drift apart.
Duties in commencement order
| Duty | Who it binds | Binds from | Deadline |
| Article 55(1)(c), serious incidents involving a general-purpose AI model with systemic risk | Model providers | 2 August 2025 | “Without undue delay”, no statutory number |
| Code of Practice Commitment 9, critical infrastructure | Signatory model providers | Voluntary, in force | 2 days from awareness |
| Code of Practice Commitment 9, serious cybersecurity breach | Signatory model providers | Voluntary, in force | 5 days, no AI Act equivalent |
| Code of Practice Commitment 9, death | Signatory model providers | Voluntary, in force | 10 days |
| Code of Practice Commitment 9, health, fundamental rights, property, environment | Signatory model providers | Voluntary, in force | 15 days |
| Code of Practice Commitment 9, follow-up | Signatory model providers | Voluntary, in force | Intermediate every 4 weeks, final within 60 days of resolution |
| Article 75(1a), reporting to the AI Office instead of nationally | High-risk providers under AI Office competence | 27 July 2026, subject to Chapter III commencement | Article 73(2) to (9) mutatis mutandis |
| Article 73(2), default serious incident report | High-risk providers | Article applies from 2 August 2026; Chapter III from 2 December 2027 or 2 August 2028 | 15 days from awareness |
| Article 73(3), widespread infringement or critical-infrastructure disruption | High-risk providers | As above | 2 days from awareness |
| Article 73(4), death of a person | High-risk providers | As above | 10 days, triggered on establishing or suspecting causation |
| Article 26(5), deployer informs the provider | Deployers of high-risk systems | 2 December 2027 or 2 August 2028 | “Immediately”, read in the draft guidance as 24 hours |
| Article 111(2), legacy high-risk systems | Operators | On significant design change after Chapter III applies; public authorities by 2 August 2030 | Per the relevant article |
| GDPR Article 33 | Controllers | Live | 72 hours from awareness |
| NIS2 Article 23 | Essential and important entities | Live | 24 hours, 72 hours, 1 month |
| DORA, Delegated Regulation (EU) 2025/301 Article 5 | Financial entities | Live | 4 hours from classification, 24 from awareness, 72 hours, 1 month |
| MDR Article 87 | Device manufacturers | Live | 15 days, 2 days, 10 days |
| SEC Form 8-K Item 1.05 | US registrants | Live | 4 business days from a materiality determination |
| CIRCIA | US covered entities | Not in force, no final rule | Not applicable yet |
Frequently asked questions
Is EU AI Act Article 73 in force today?
The article applies from 2 August 2026, because Chapter IX takes the Regulation’s general application date and appears in no Article 113 exception. Its subject is narrower than that suggests. Article 73(1) binds providers of high-risk AI systems, and the classification rules in Chapter III Sections 1 to 3 apply only from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems.
Which AI incident-reporting duty binds an organisation right now?
Article 55(1)(c), for providers of general-purpose AI models with systemic risk, which has applied since 2 August 2025. The article requires reporting to the AI Office without undue delay and sets no number. The numeric clocks sit in the voluntary Code of Practice.
What is a serious incident under the EU AI Act?
Article 3(49) defines it as an incident or malfunctioning of an AI system that directly or indirectly leads to the death of a person or serious harm to 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. The definition sits in Chapter I and has applied since 2 February 2025.
What are the Article 73 deadlines when they do apply?
Fifteen days by default under Article 73(2), two days for a widespread infringement or a critical-infrastructure disruption under Article 73(3), and ten days where a person has died under Article 73(4). The first two run their outer bound from awareness of the incident; the ten-day limb also triggers on establishing or merely suspecting a causal relationship.
Do deployers have an AI incident duty today?
Not yet. Article 26(5), which requires a deployer to inform the provider immediately and then the importer, distributor and market surveillance authority, sits in Chapter III Section 3 and applies from 2 December 2027 or 2 August 2028 depending on classification. The Commission’s draft guidance reads “immediately” as within 24 hours, but that gloss is a consultation draft rather than law.
Has the Commission published final Article 73 guidance?
No. Article 73(7) required guidance by 2 August 2025. A draft guidance and reporting template went to consultation from 26 September to 7 November 2025 and remains the only version, with unfilled placeholders in six paragraphs. No summary of consultation responses has been published as at 19 September 2026.
Where does an Article 73 report go?
To the market surveillance authorities of the Member State where the incident occurred. On the Commission’s list as last updated on 7 September 2026, nine Member States have a single point of contact whose designation is final, twelve are marked as pending final adoption, and six have none listed. Where the location is unknown to the provider, the draft guidance points to the business location of the deployer.
What can an organisation not do while investigating an AI incident?
Article 73(6) forbids any investigation that involves altering the AI system in a way which may affect a subsequent evaluation of the causes, before informing the competent authorities of that action. Rolling back weights, patching a prompt or redeploying a previous version all qualify, which makes the instinctive engineering response the prohibited one.
Which incident clocks are already running for an AI failure?
Any that a security compromise, personal data breach, financial-services classification or regulated product engages. GDPR Article 33 gives 72 hours from awareness. NIS2 Article 23 gives 24 hours for an early warning and 72 hours for a notification. DORA, through Delegated Regulation (EU) 2025/301, gives four hours from classification and 24 from awareness. None of them is triggered by a model simply being wrong.
Did the Digital Omnibus change AI incident reporting?
Article 73 itself was not amended. Regulation (EU) 2026/1744 inserted Article 75(1a), redirecting reports to the AI Office for providers under AI Office competence, and replaced Article 113 point (c), which is what deferred the high-risk commencement dates that decide who Article 73 reaches.
How many Article 73 reports have been filed?
No official figure has been published by the Commission or by any Member State. The AI Incident Database and the OECD AI Incidents and Hazards Monitor publish counts drawn from news coverage rather than from regulatory filings, and neither is a compliance record.
What should be built before December 2027?
A classification test based on what an output was used for and who was affected, a recorded awareness timestamp, a preservation routine that snapshots the model and its inputs and outputs on detection, log retention raised to at least six months, a named person authorised to notify before any alteration, and an addressee register for incident reports tracking the Commission’s list
