Serious incident reporting under Article 73. What deployers must do.

Article 73 of Regulation (EU) 2024/1689 creates a mandatory incident reporting regime for serious failures of high-risk AI systems. The primary obligation rests on providers, but deployers carry specific reporting duties and broader operational responsibilities that activate the moment a serious incident occurs. This article reads the provision closely and maps the practical compliance requirements for deployers.

What Article 73 actually says

Article 73 of Regulation (EU) 2024/1689 is titled "Reporting of serious incidents." It sits within Title VII of the Act, which covers post-market monitoring and market surveillance. The article's primary mechanism is straightforward: providers of high-risk AI systems that are placed on the market or put into service in the Union are required to report any serious incident to the market surveillance authorities of the member states where the incident occurred.

The obligation is triggered not by the formal confirmation of a serious incident but by the provider "becom[ing] aware" of it. This awareness threshold is significant because it means the reporting obligation can be triggered before the full causal chain has been established. A provider who learns that a high-risk AI system may have caused a serious harm must report to the relevant authority even while the investigation is ongoing. The report documents the awareness and the initial assessment, not a final determination of causation.

The phrase "without undue delay" sets the timeframe. The Act does not specify a number of hours, which distinguishes it from GDPR Article 33's explicit 72-hour standard for personal data breach notification to supervisory authorities. In the absence of a statutory number, the GDPR standard is frequently used as a practical benchmark by compliance teams who operate under both regimes. EIOPA's AI governance opinion, published in August 2025, noted the parallel between AI incident reporting and GDPR breach notification timelines for regulated entities operating under both frameworks.

The definition of a serious incident

Article 3(49) of Regulation (EU) 2024/1689 defines a serious incident as any incident or malfunction of a high-risk AI system that "directly or indirectly" leads to one of four categories of harm.

The first category is the death of a person or serious damage to a person's health. This is the most straightforward trigger. An AI-assisted medical diagnostic system that recommends an incorrect treatment, leading to patient harm, is the paradigm case. But the category is not limited to healthcare. An AI system used in employment screening that routes a candidate to a role for which they are unqualified, and where that role involves safety-critical tasks, could create indirect causal chains to physical harm.

The second category is a serious and irreversible disruption of the management and operation of critical infrastructure. Critical infrastructure for these purposes includes energy grids, water systems, transport networks, digital infrastructure, and financial market infrastructure. An AI agent deployed in industrial control systems for a water treatment facility would fall squarely within this category if its failure disrupted water quality management.

The third category is a violation of obligations under Union law intended to protect fundamental rights. This is the broadest of the four triggers and the most likely to generate legal uncertainty at the margin. A high-risk AI system used in employment decisions that produces outputs constituting direct discrimination under Directive 2000/78/EC would fall within this category. So would an AI system used in access to essential services that produces outputs violating the rights of persons with disabilities under Directive 2019/882/EU. The fundamental rights dimension connects the incident reporting obligation directly to the FRIA requirement under Article 27 of the Act.

The fourth category is serious damage to property or the environment. This is the least frequently discussed trigger but potentially significant for AI systems deployed in automated manufacturing, logistics, or resource management contexts.

The deployer's position within the reporting architecture

The primary reporting obligation in Article 73 runs from the provider to the market surveillance authority. This allocation reflects the structural logic of the Act: the provider designed and built the system and is responsible for its fundamental compliance, including the risk management system under Article 9, the post-market monitoring system under Article 72, and the quality management system under Article 17.

Deployers occupy a different position. Their primary incident-related obligation is in Article 26(5), which requires a deployer that "has reasons to consider" that a high-risk AI system poses a risk to the health, safety, or fundamental rights of persons to immediately notify the provider or distributor and the relevant national competent authority. The phrase "has reasons to consider" is a lower threshold than actual certainty. It is triggered by reasonable grounds for concern, not confirmed harm.

The practical consequence of Article 26(5) is that deployers must maintain internal triage mechanisms capable of identifying potential serious incidents at the earliest stage and escalating them both to the provider and to relevant authorities without waiting for a full causal investigation to complete. A deployer that discovers an output from its high-risk AI agent that could constitute a serious incident must act on that discovery immediately, not after its legal team has confirmed the position.

Article 73(3) creates a separate direct reporting obligation for two specific categories of deployer. First, public authorities deploying high-risk AI systems must themselves report serious incidents to the relevant market surveillance authority. Second, deployers who are subject to Union law obligations of professional secrecy, such as legal professionals, healthcare providers, and financial institutions under specific sector rules, must report directly to the authority rather than through the provider. For these deployers, the reporting chain is deployer-to-authority rather than deployer-to-provider-to-authority.

National market surveillance authorities: who receives the report

The competent recipient of an Article 73 serious incident report is the market surveillance authority of the member state where the incident occurred. The EU AI Act establishes a national market surveillance architecture under Article 74, requiring each member state to designate authorities with enforcement powers. The AI Office, established within the European Commission under Article 64, coordinates across member states and handles certain GPAI-related incidents centrally.

As of June 2026, member states have been designating their market surveillance authorities in line with Article 70's requirement to notify the Commission. The national designations vary. Germany has distributed responsibility across sector-specific authorities coordinated by a central AI Act coordination office. France has designated CNIL with extended scope for AI Act oversight alongside its existing data protection remit. The Netherlands has designated the Autoriteit Persoonsgegevens with a broader AI mandate. Italy has established a national AI Act coordination mechanism connected to AGID. The specific authority to which a deployer must report depends on the member state where the incident occurred, and for cross-border incidents, the Act's coordination mechanisms under Article 75 activate.

The content of the incident report

The AI Act does not specify in Article 73 itself the required content of a serious incident report. The Commission is empowered under Article 73(6) to adopt implementing acts specifying the information to be included. Until those implementing acts are published, deployers and providers should draw on the analogous GDPR framework and on the guidance issued by national market surveillance authorities as they become operational.

A well-structured Article 73 incident report should include the following elements as a minimum. First, a description of the incident: what happened, when it happened, where it happened, and which AI system was involved by model name, version, and deployment context. Second, an initial assessment of the potential harm: which of the four categories under Article 3(49) may be engaged, and what evidence supports that assessment. Third, the immediate mitigation steps taken: whether the system has been suspended, whether outputs have been rolled back, what notifications have been issued to affected persons. Fourth, the investigation plan: who is conducting the root cause analysis, what timeline is expected, and when a follow-up report will be provided. Fifth, the regulatory context: a statement of the system's high-risk classification under Annex III, the deployer's identity and contact details, and the provider's identity if different.

The overlap with Article 72 post-market monitoring

Article 72 requires providers of high-risk AI systems to establish and document a post-market monitoring system that actively monitors performance in real-world conditions and feeds findings back into the risk management system under Article 9. The monitoring system must include a plan to collect, document, and analyse relevant data from users on the system's operation and any incidents or malfunctions.

The relationship between Article 72 monitoring and Article 73 incident reporting is one of continuous flow rather than separate regimes. The post-market monitoring system is the infrastructure through which deployers and providers detect the signals that may constitute a serious incident. A deployer that has not implemented a meaningful monitoring system is unlikely to detect a serious incident in time to satisfy the "without undue delay" reporting obligation in Article 73. Conversely, a deployer with a well-designed monitoring system that generates anomaly alerts, conversation logs, output review queues, and escalation pathways is structurally prepared to meet the Article 73 obligation as a consequence of meeting the Article 72 obligation.

For deployers building their compliance infrastructure, the design of the monitoring system under Article 72 should explicitly incorporate the incident classification taxonomy from Article 3(49). Every monitoring alert should be assessed against the four serious incident categories before being closed as a non-reportable event. Those assessments should be documented, because the market surveillance authority may request evidence that the deployer's monitoring system applied the correct classification criteria.

The deployer-provider notification relationship

Article 26(5) creates a legal obligation on the deployer to notify the provider immediately when a risk to health, safety, or fundamental rights is identified. In practice, this obligation requires deployers to have a named provider contact for incident escalation before any incident occurs. Many AI deployment contracts, particularly those for off-the-shelf commercial models, do not currently include incident escalation provisions that satisfy this requirement. Deployers should review their vendor contracts specifically for the following elements: a designated incident contact at the provider; a contractual timeframe within which the provider commits to acknowledge the notification; an obligation on the provider to confirm whether it will file the Article 73 report or whether the deployer must proceed directly; and a commitment from the provider to share relevant technical logs that the deployer may need to include in any direct authority notification.

Where the provider is based outside the Union and has appointed an authorised representative under Article 22, the incident escalation obligation runs to the authorised representative, who then carries it to the provider. Deployers should identify the authorised representative of any non-EU provider in their AI system registry before an incident occurs rather than during one.

Parallel obligations: GDPR and sector-specific reporting

The EU AI Act's serious incident reporting obligation does not replace or absorb other notification requirements that may apply to the same incident. Three parallel regimes require particular attention.

Under GDPR Article 33, a personal data breach must be notified to the competent supervisory authority within 72 hours of the controller becoming aware of it. If a serious AI incident also constitutes a personal data breach, the 72-hour GDPR clock runs from the moment of awareness, which may be earlier than the "without undue delay" AI Act clock. Deployers must therefore run both timelines simultaneously. The GDPR notification goes to the data protection supervisory authority. The AI Act notification goes to the market surveillance authority. The two are different bodies in most member states, and the reports, while describing the same incident, must each be tailored to the legal requirements of their respective regimes.

Under DORA, Regulation (EU) 2022/2554, financial entities are required to report major ICT-related incidents to their competent authority. If the serious AI incident occurs within a financial entity and involves an ICT failure, DORA's ICT incident reporting regime under Article 19 activates in parallel. The definitions of major incident under DORA and serious incident under the AI Act do not perfectly align, which means both may be triggered by the same event or only one may be triggered depending on the specific facts. Financial entities should map these definitions before an incident occurs.

Under NIS2, Directive (EU) 2022/2555, operators of essential services and certain digital service providers must report significant incidents affecting their network and information systems within 24 hours of discovery. An AI failure that disrupts critical infrastructure within the scope of NIS2 may trigger both the NIS2 reporting obligation and the AI Act Article 73 obligation. The NIS2 report goes to the competent authority or CSIRT. The AI Act report goes to the market surveillance authority.

Building a compliant incident response procedure

The practical preparation for Article 73 compliance involves building an incident response procedure before any incident occurs. That procedure must address four operational questions: how incidents are detected, how they are classified, who is notified in what order, and what documentation is produced.

Detection requires a functioning post-market monitoring system under Article 72 that generates alerts when AI outputs fall outside expected parameters, when user complaints reach a threshold, or when specific harm indicators are triggered. The monitoring system should be configured to flag outputs that may engage the four serious incident categories, even at a preliminary level.

Classification requires a documented assessment against the Article 3(49) definition. The assessment should be performed by a person with sufficient authority and expertise to make a threshold determination. It should be documented even where the determination is that no serious incident has occurred, because that negative determination may need to be defended later if a regulatory inquiry follows.

Notification requires a pre-established escalation chain: from the AI system's operational monitor to the compliance function, from compliance to the provider under Article 26(5), and from compliance to the relevant national market surveillance authority where the deployer is a public authority or carries a professional secrecy obligation. The chain should include the timing of each step and the fallback where a step cannot be completed within the target timeframe.

Documentation requires a contemporaneous record of everything that happens from the moment awareness of the incident arises. The record must cover the initial alert, the classification assessment, the provider notification, the authority notification, the immediate mitigation steps, and the investigation findings. This record becomes the evidence file for any subsequent regulatory inquiry and should be retained for at least the log retention period specified in Article 12 of the Act, which requires logs to be retained for the period appropriate to the system's intended purpose or, where not otherwise determined, for at least six months.

Deployers who want to understand how their documentation obligations connect to certification and insurance eligibility can find the framework at agentcertified.eu's analysis of post-market monitoring as certification evidence. For the coverage implications of incident response preparedness, see the documentation-to-coverage evidence chain on agentinsured.eu.