What if we are a deployer, not a provider?

The deployer's primary Article 73 obligation is to cooperate with the provider's investigation. The deployer provides the operational records, the identity context, and the configuration state at the moment of the incident. Where the deployer has modified the system to become a provider under Article 25, the deployer inherits the reporting duty directly.

What about cross-border incidents?

A cross-border incident is reported to the market surveillance authority of the member state where the incident occurred. Article 73(7) provides for information sharing across member states and with the Commission. The provider reports once, to the primary authority, and the authority handles the cross-border coordination.

How does Article 73 interact with GDPR breach notification?

GDPR Article 33 requires personal-data breach notification within 72 hours. An incident can be reportable under both GDPR and Article 73 if it involves personal data and meets the serious-incident threshold. The reports go to different authorities (data protection authority for GDPR, market surveillance authority for the AI Act) and have different content requirements. A single incident-response process needs to handle both.

What evidence does the regulator actually expect?

Initial reports are typically narrative plus key data points (date, time, system, scope, observed harm, causal-link basis). Supplementary reports include the technical investigation findings, the operational records, and the corrective actions. The market surveillance authority can request additional evidence under Article 73 information-sharing.

How does this interact with the upcoming GPAI obligations?

GPAI providers have parallel obligations for systemic-risk models under Article 55. A serious incident involving a GPAI model with systemic risk triggers both Article 73 (for the high-risk system the GPAI is part of) and Article 55 (for the GPAI provider's own obligations). The two reporting chains can overlap in fact patterns where the same incident has both downstream and upstream causes.

EU AI Act Incident Reporting: Article 73 Obligations Before the August 2 Date

Q: When does the 15-day clock actually start?

The clock starts when the provider establishes the causal link. The Commission's expected interpretation is that the link is established when a reasonable investigation supports the conclusion, not when certainty is achieved. Providers should not delay reporting pending exhaustive analysis.

EU AI Act Article 73 requires providers of high-risk AI systems to report serious incidents to the market surveillance authority of the member state where the incident occurred. The reporting window is 15 days from the moment the provider establishes the causal link between the incident and the AI system, with a 72-hour window for widespread infringements and a 2-day window for incidents resulting in death. The clock starts when the provider becomes aware of the incident, not when the investigation concludes. With the August 2, 2026 high-risk enforcement date 34 days away, providers and deployers operating high-risk systems in the EU need a clear read on what counts as a serious incident, who reports, and what the reporting record needs to contain. I want to walk through Article 73 as the regulation actually writes it, the case patterns that trigger the reporting obligation, and the operational artifacts the obligation requires.

What Article 73 actually requires

Article 73 applies to providers of high-risk AI systems placed on the EU market. The provider is the entity that develops the system or that has the system developed and puts it on the market or into service under its own name or trademark. The deployer, the natural or legal person using the system under its own authority, has a parallel obligation under Article 26 to cooperate with the provider's reporting, but the primary reporting duty sits with the provider.

A serious incident under Article 3(49) is defined as an incident or malfunctioning 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. An infringement of obligations under Union law intended to protect fundamental rights. Serious harm to property or the environment.

The reporting obligation in Article 73(1) requires the provider to report immediately after establishing a causal link between the AI system and the incident, and no later than 15 days. Article 73(3) shortens that window to 2 days when the incident resulted in death. Article 73(4) shortens it to 72 hours when the incident is a widespread infringement. The reporting is to the national market surveillance authority of the member state where the incident occurred.

Who reports and who supports

The provider reports. The deployer is on the hook for cooperating with the provider's investigation and providing the operational records the provider needs to establish the causal link. In practice, the deployer is often the first to detect the incident because the deployer operates the system. The deployer's notification to the provider is the trigger that starts the provider's clock.

The reporting chain has three roles. The deployer detects, captures the operational evidence (logs, identity context, request and response records), and notifies the provider. The provider investigates, establishes the causal link, and reports to the market surveillance authority. The authority assesses, and may share with the Commission and other authorities under the Article 73(7) information-sharing framework.

A practical pattern that recurs in enterprise deployments is the integration partner case. An enterprise that deploys a high-risk AI system under its own authority and brand becomes a provider under Article 25 and inherits the Article 73 reporting duty. The reporting chain collapses to a single entity. The internal evidence chain still applies; the same operational records the deployer would have prepared in the two-entity case are now the provider-side evidence.

What counts as a serious incident in practice

The four outcomes in the Article 3(49) definition map to specific case patterns in AI deployments.

Serious harm to health. A clinical decision-support AI that recommends a contraindicated medication or fails to flag a serious diagnostic finding. A diagnostic AI that misclassifies a malignant condition as benign and causes treatment delay. A triage AI that systematically deprioritizes a high-acuity case.

Serious and irreversible disruption of critical infrastructure. An AI control system for a substation that causes a cascading outage. An AI traffic management system that creates a sustained safety hazard. An AI authentication system in a covered critical entity that fails open under a specific input pattern.

Infringement of fundamental-rights obligations. A high-risk AI used for HR screening that systematically excludes a protected group. A credit-scoring AI that produces discriminatory outcomes against a protected characteristic. A biometric categorization AI that draws prohibited inferences.

Serious harm to property or environment. An AI industrial-control system that causes equipment damage or an environmental release. An autonomous-vehicle AI that causes property damage of sufficient magnitude.

The threshold word in each case is "serious." The regulation does not give a monetary or quantitative threshold for serious harm to property; the market surveillance authorities are expected to develop sector-specific guidance. The provider should err on the side of reporting and document the rationale for the determination.

The 15-day, 72-hour, and 2-day windows

Three windows apply under Article 73. The standard window is 15 days, running from the moment the provider establishes the causal link between the incident and the AI system. The interpretation of "establish the causal link" is the operationally important question. The Commission's expected interpretation is that the link is established when a reasonable investigation supports the conclusion, not when the conclusion is certain. A provider that delays the report pending an exhaustive root-cause analysis risks missing the window.

The 72-hour window applies to widespread infringements under Article 73(4). A widespread infringement is an Article 3(61) construct that covers infringements affecting a large number of users across multiple member states, or that have a cross-border dimension.

The 2-day window applies to incidents resulting in death under Article 73(3). The shortened window reflects the regulatory expectation that fatal incidents are escalated immediately.

In all three cases, the initial report can be provisional. Article 73(5) provides that the provider supplements the initial report with additional information as it becomes available. The initial report is the trigger that puts the authority on notice; the investigation continues afterward.

The operational evidence the provider needs

Establishing the causal link requires evidence. The evidence has to come from the operational record of the AI system at the moment of the incident. Three categories matter.

The request and response records. What input did the system receive immediately before and during the incident? What output did the system produce? Which natural person, agent, or system initiated the call? The records have to be in a form that supports forensic reconstruction.

The system state records. Which model version was running? Which policy version was in effect? Which retrieval set was available? Which configuration parameters were applied? The system state is what distinguishes a one-off incident from a systematic failure.

The identity context. Who was the verified caller? Which role were they operating under? What was the authorization that permitted the call? The identity context is what links the request to the actor and produces the accountability trail.

Application-controlled logs are operationally insufficient for this evidence chain. The application that ran the AI call is the system under investigation. Its own logs are subject to the self-attestation problem: the application can suppress, the application can fail to write on crash, the application can selectively omit fields. The evidence chain has to live outside the application.

How this lines up with Article 19 logging

Article 19 already requires deployers to retain the automatic logs generated by the system for at least six months. Article 73 reporting depends on those logs. The Article 19 obligation produces the records the Article 73 investigation needs. A deployer that fails the Article 19 retention obligation simultaneously fails the Article 73 investigation support obligation.

The architectural conclusion is the same as for Article 19. The logs need to be produced and retained at a layer the application cannot control. The gateway between authenticated callers and the model is the natural location. Every request produces a record with identity, policy version, model version, retrieval reference, and timestamp. The record is signed and tamper-evident. The retention is configured to satisfy Article 19 minimums and any sector-specific longer obligations.

The reporting workflow

The reporting workflow at the provider has three phases.

Detection and triage. The deployer or the provider's own monitoring detects an anomaly. The provider's incident-response team triages the report against the Article 3(49) criteria. If the criteria are met or plausibly met, the clock starts.

Investigation and causal-link establishment. The provider pulls the operational records, reconstructs the sequence of events, and assesses whether the AI system caused or contributed to the outcome. The investigation produces the causal-link determination.

Reporting and supplementation. The provider files the initial report with the market surveillance authority within the applicable window (15 days, 72 hours, or 2 days). The provider supplements the report with additional findings as the investigation continues.

The workflow assumes the operational records are available. A workflow that depends on reconstructing application logs across multiple services and time zones cannot run inside the 2-day window.

DeepInspect

This is the evidence-chain infrastructure DeepInspect was built to provide for Article 73 reporting. DeepInspect sits inline between authenticated users or agents and the LLMs that high-risk AI systems call, writes a per-decision audit record with identity, policy version, model version, retrieval reference, and timestamp attached, and stores the records in a form that supports forensic reconstruction.

For the Article 73 reporting workflow specifically, DeepInspect produces the operational records the provider needs to establish the causal link inside the applicable window. The records are signed, tamper-evident, and retained for the configured retention period. The reporting record is generated from the audit trail, not reconstructed from application logs after the fact.

If you are facing the August deadline and your Article 73 readiness depends on application logs scattered across services, let's talk today.