Question 1

What qualifies as a "serious incident" under the EU AI Act?

Accepted Answer

Article 3(49) defines a serious incident as an incident or malfunctioning of an AI system that directly or indirectly leads to one of four listed outcomes. Regulation (EU) 2024/1689 defines a "serious incident" as "an incident or malfunctioning of an AI system that directly or indirectly leads to any of the following": (a) "the death of a person, or serious harm to a person's health"; (b) "a serious and irreversible disruption of the management or operation of critical infrastructure"; (c) "the infringement of obligations under Union law intended to protect fundamental rights"; and (d) "serious harm to property or the environment". The definition covers both a realised incident and a malfunctioning, and both direct and indirect causal chains. Category (b) turns on the notion of critical infrastructure defined elsewhere in Article 3, and category (c) links the definition to Union fundamental-rights law. This classification is the trigger that determines whether the reporting duties in Article 73 apply and which deadline governs a given event.

Question 2

What does Article 73 require providers of high-risk AI systems to report, and to whom?

Accepted Answer

Article 73(1) requires providers of high-risk AI systems placed on the Union market to report any serious incident to the market surveillance authorities of the Member States where the incident occurred. The obligation attaches to the provider of a high-risk AI system placed on the Union market. The report is directed to the national market surveillance authorities — defined in Article 3(26) as the authorities acting under Regulation (EU) 2019/1020 — of the Member State or States in which the incident occurred, rather than to a single central body. Two narrowing rules apply. Under Article 73(9), where the provider is already subject to Union instruments with equivalent reporting obligations, notification is limited to serious incidents falling under category (c), the infringement of fundamental-rights obligations. Under Article 73(10), for high-risk systems that are, or are safety components of, medical devices under Regulations (EU) 2017/745 and (EU) 2017/746, notification is likewise limited to category (c) and made to the national authority chosen for that purpose. Article 73(11) requires national competent authorities to notify the Commission of any serious incident in accordance with Article 20 of Regulation (EU) 2019/1020.

Question 3

What must a provider do after reporting a serious incident?

Accepted Answer

Article 73(6) requires the provider, without delay, to investigate the incident and the AI system concerned, including a risk assessment and corrective action, and to cooperate with the competent authorities. Under Article 73(6), the provider must, without delay, perform the necessary investigations in relation to the serious incident and the AI system concerned; those investigations must include a risk assessment of the incident and corrective action. The provider must cooperate with the competent authorities and, where relevant, the notified body concerned, and must not perform any investigation that alters the AI system in a way which may affect a subsequent evaluation of the causes of the incident before informing the competent authorities of such action. On the authority side, Article 73(8) requires the market surveillance authority to take appropriate measures under Article 19 of Regulation (EU) 2019/1020 within seven days of receiving the notification. Corrective action in this setting connects to the recall and withdrawal measures defined in Article 3(16) and (17). Detection and response here are the outward-facing counterpart to the post-market monitoring obligations covered in Stage 11.

Question 4

How are serious incidents involving fundamental-rights infringements routed, and what guidance exists?

Accepted Answer

For a serious incident under category (c), Article 73(7) requires the market surveillance authority to inform the national public authorities that supervise fundamental-rights obligations, and it tasks the Commission with issuing guidance. Article 3(49)(c) covers "the infringement of obligations under Union law intended to protect fundamental rights". Article 73(7) provides that, on receiving a notification of such an incident, the market surveillance authority informs the national public authorities or bodies referred to in Article 77(1) — the authorities that supervise or enforce Union fundamental-rights obligations. The same paragraph directs the Commission to develop dedicated guidance to facilitate compliance with the Article 73(1) reporting obligation, states that this guidance "shall be issued by 2 August 2025", and requires it to be assessed regularly. This routing is what allows a single serious-incident report to reach both the product-safety market surveillance authorities and the specialised fundamental-rights authorities, rather than remaining within one channel.

Question 5

What incident-tracking obligations do providers of general-purpose AI models with systemic risk carry?

Accepted Answer

Article 55(1)(c) requires providers of general-purpose AI models with systemic risk to keep track of, document, and report relevant information about serious incidents and possible corrective measures, without undue delay, to the AI Office and, as appropriate, national competent authorities. This obligation applies, in addition to the duties in Articles 53 and 54, to providers of general-purpose AI models classified as carrying systemic risk. Article 55(1)(c) requires them 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". The recipient differs from Article 73: it is the AI Office — defined in Article 3(47) as the Commission function for AI, references to which are construed as references to the Commission — rather than the national market surveillance authorities. Under Article 55(2), providers may rely on codes of practice to demonstrate compliance until a harmonised standard is published. The obligations in Chapter V, which include Article 55, have applied since 2 August 2025 under Article 113(b) and are not deferred by Regulation (EU) 2026/1744.

Question 6

How does serious-incident reporting relate to post-market monitoring?

Accepted Answer

Post-market monitoring under Article 72 is the internal system that surfaces incidents, while Article 73 is the outward duty to report serious incidents to authorities once the definition in Article 3(49) is met. Article 72 requires providers of high-risk AI systems to establish and document a post-market monitoring system that actively and systematically collects, documents and analyses data on the system's performance, including data provided by deployers or collected through other sources. That continuous monitoring — the subject of Stage 11 — is the mechanism through which providers detect events that may amount to serious incidents. Article 73 then governs what happens once an event meets the "serious incident" threshold in Article 3(49): the provider reports to the market surveillance authorities on the deadlines set in Article 73(2) to (4). Detection and reporting are therefore sequential — monitoring identifies and characterises events, and the serious-incident classification and its deadlines determine whether and how quickly they are notified externally.

Question 7

What is the OECD AI Incidents and Hazards Monitor (AIM)?

Accepted Answer

The AI Incidents and Hazards Monitor is a beta media-monitoring registry, published on the OECD.AI platform, that documents AI incidents and hazards drawn from global news coverage. The OECD.AI platform presents the monitor as a resource that catalogues AI incidents and hazards so that policymakers, AI practitioners and other stakeholders can gain insight into the risks and harms associated with AI systems. It identifies events from media coverage supplied by the Event Registry news-aggregation service, then classifies them — since November 2024 using a two-stage large-language-model process — as incidents, hazards, or unrelated, and enriches each entry with metadata such as severity, affected stakeholders, location, industry, and the OECD AI principles implicated. The processing pipeline runs daily, and the monitor is described as being in beta. It records events as reported in the press rather than as adjudicated findings, and it separates realised harms, treated as incidents, from credible risks of future harm, treated as hazards. It is a public monitoring resource distinct from the mandatory reporting channels created by the AI Act.

Question 8

What is the AI Incident Database (AIID)?

Accepted Answer

The AI Incident Database is a curated, publicly searchable collection of reports about harms and near-harms involving deployed AI systems, maintained by the Responsible AI Collaborative. The database indexes past cases in which AI systems caused or nearly caused harm, on the stated premise that recording and learning from such failures can help prevent or mitigate their repetition — an approach it compares to incident databases in aviation and computer security. It is maintained by the Responsible AI Collaborative, a non-profit organisation, and is edited and expanded through contributed reports. As of July 2026 its public index listed incident records numbered above 1,580, placing the catalogued collection above 1,500 entries; each incident groups one or more media or research reports describing the same event. Like the OECD monitor, it is a voluntary, openly accessible reference compiled from published accounts rather than a regulatory reporting system, and its entries are descriptive records rather than official determinations of liability or breach.

Question 9

How does the OECD distinguish an AI incident from an AI hazard?

Accepted Answer

In the OECD framing, an AI incident is an event where the development, use, or malfunction of an AI system leads to actual harm, whereas an AI hazard is an event that could plausibly lead to such harm but has not yet caused it. The OECD.AI methodology draws the line on whether harm has been realised. An AI incident, in this framing, is an event, circumstance, or series of events in which an AI system's development, use, or malfunction directly or indirectly results in one of a defined set of harms — to a person's health, to critical infrastructure, to rights protected by applicable law, or to property, communities, or the environment. An AI hazard is defined by reference to the same harms, but as a situation that could plausibly lead to such an incident rather than one that already has. This realised-versus-potential distinction, developed by the OECD and its network of experts, parallels the harm categories used in the AI Act's own "serious incident" definition and underpins how the monitor sorts the events it tracks. Both terms are set out in The AI Glossary; this stage applies them.

Question 10

From when do these serious-incident reporting obligations apply?

Accepted Answer

Under Article 113 of Regulation (EU) 2024/1689, as amended by Regulation (EU) 2026/1744, the Article 73 serious-incident reporting duties apply from 2 August 2026, while the Article 55 obligations for general-purpose AI models with systemic risk have applied since 2 August 2025. Article 113 sets 2 August 2026 as the general date of application of Regulation (EU) 2024/1689. Article 73 sits in Chapter IX, which Regulation (EU) 2026/1744 did not defer, so its serious-incident reporting obligations apply from that date; Chapter V, which contains the Article 55 duties for general-purpose AI models with systemic risk, has applied since 2 August 2025 under Article 113(b). The amending instrument, Regulation (EU) 2026/1744 (the Digital Omnibus on AI), was published in the Official Journal on 24 July 2026 and is in force from 27 July 2026. It defers the high-risk obligations in Chapter III, Sections 1 to 3 (Articles 6 to 27), except Article 6(5) — to 2 December 2027 for systems high-risk under Article 6(2) and Annex III, and to 2 August 2028 for systems high-risk under Article 6(1) and Annex I. Chapter III, Section 5 (Articles 40 to 49) and Article 6(5) are not deferred and apply from 2 August 2026, as does Chapter IX.

Trigger	Reporting timing	Provision
General serious incident	Immediately after the provider establishes a causal link (or its reasonable likelihood) between the AI system and the incident, and no later than 15 days after awareness	Art. 73(2)
Widespread infringement, or a serious and irreversible disruption of critical infrastructure (Art. 3(49)(b))	Immediately, and no later than 2 days after awareness	Art. 73(3)
Death of a person	Immediately after a causal relationship is established or suspected, and no later than 10 days after awareness	Art. 73(4)
Initial report incomplete	An incomplete initial report may be submitted where necessary to ensure timely reporting, followed by a complete report	Art. 73(5)

Explore 1BusinessWorld

Welcome to 1BusinessWorld

Incident Detection & Serious-Incident Reporting