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 operational records, identity context, and configuration state at the moment of the incident. Where it has modified the system to become a provider under Article 25, it inherits the reporting duty directly.

When does the 15-day clock actually start?

The 15-day outer limit runs from awareness of the serious incident. Article 73 also refers to a system-to-incident connection or reasonable likelihood of one, so the provider should document its assessment and avoid delaying the filing for exhaustive analysis.

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, and the basis for connecting the system to the incident). Supplementary reports include technical investigation findings, operational records, and 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 Serious-Incident Duties

EU AI Act Article 73 requires a provider of a high-risk AI system to report a serious incident after it establishes a causal link, or a reasonable likelihood of one, between the system and the incident. The report must arrive within 15 days of awareness. The current text shortens the period to two days for a widespread infringement and 10 days where a person has died. I want to walk through the Article 3(49) trigger, the provider and deployer roles, and the operational record that makes an investigation possible.

TL;DR

Article 73 places the reporting duty on the high-risk AI system provider. Teams need a retrievable record of the incident facts, system state, and authenticated caller, then must apply the 15-day, two-day, or 10-day timeline that matches the event.

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 an incident or malfunctioning that directly or indirectly leads to death or serious harm to health, serious and irreversible disruption of critical infrastructure, infringement of Union-law obligations protecting fundamental rights, or serious harm to property or the environment.

The reporting obligation in Article 73(1) requires the provider to report immediately after establishing the connection, or a reasonable likelihood of one, and no later than 15 days after awareness. Article 73 sets two special timelines: two days for a widespread infringement and 10 days for an incident resulting in death. Check the official Regulation (EU) 2024/1689 text before filing because the applicable authority and its reporting process depend on the incident facts and Member State.

Who reports and who supports

The provider reports. The deployer must cooperate with the provider's investigation and provide the operational records needed to establish the connection. In practice, the deployer is often the first to detect the incident because it operates the system. Its notification to the provider starts the provider's clock.

The reporting chain has three roles. The deployer detects and captures operational evidence before notifying the provider. The provider investigates, assesses the system-to-incident connection, and reports to the market-surveillance authority. That authority may share information with the Commission and other authorities under Article 73(7).

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 can arise when clinical decision support recommends a contraindicated medication, a diagnostic system misclassifies a malignant condition as benign, or a triage system systematically deprioritizes high-acuity cases.

Critical-infrastructure disruption can arise when a substation control system causes a cascading outage, traffic management creates a sustained safety hazard, or an authentication system at a covered entity fails open under a specific input pattern.

Fundamental-rights infringement can arise when a high-risk HR screening system excludes a protected group, credit scoring produces discriminatory outcomes, or biometric categorization draws prohibited inferences.

Property or environmental harm can arise from an industrial-control failure causing equipment damage or release, or from an autonomous vehicle causing sufficiently serious property damage.

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, two-day, and 10-day timelines

Three timelines apply under Article 73. The standard limit is 15 days after the provider or, where applicable, deployer becomes aware of the serious incident. Article 73 also refers to a system-to-incident connection, or a reasonable likelihood of one, which means the first report should record the basis for the assessment and any facts still under investigation. A provider that waits for an exhaustive root-cause analysis risks missing the limit.

The two-day period applies to a widespread infringement. Article 3(61) defines that construct around large numbers of users, multiple Member States, or a cross-border dimension.

The 10-day period applies to an incident resulting in death. The fatality must be identified in the initial report and followed by the supporting facts as they become available.

Article 73(5) allows the provider to supplement a provisional filing as additional information becomes available. The first filing puts the authority on notice while the investigation continues.

The operational evidence the provider needs

Establishing the system-to-incident connection requires an operational record from the moment of the incident. Three evidence categories matter in that review.

Request and response records identify the input received before and during the incident, the output produced, and the natural person, agent, or system that initiated the call. The records need a form that supports forensic reconstruction.

System-state records identify the model version, policy version, retrieval set, and applied configuration parameters. That state distinguishes a one-off incident from a systematic failure.

Identity context identifies the verified caller, their operating role, and the authorization that permitted the call. It links the request to an accountable actor.

Application-controlled logs can be incomplete evidence when the application that made the AI call is under investigation. A crash can prevent a write, and an application-controlled schema can omit fields needed for reconstruction. An independent decision record limits that self-attestation problem.

How this lines up with Article 19 logging

Article 19 addresses provider obligations for automatically generated logs. Article 26(6) requires a deployer of a high-risk system to keep logs generated under its control for at least six months, where those logs are under its control. Article 73 investigations often depend on that retained evidence, but the reporting obligation and the log-retention obligations remain distinct. EU AI Act providers and deployers explains the role split.

The architectural conclusion concerns the inference layer. A gateway between authenticated callers and a routed model endpoint can produce a record with identity, policy version, model route, and timestamp. Application records still supply retrieval state, downstream action, and sector-specific evidence. EU AI Act Article 12 logging covers the record-keeping design, while AI audit-log immutability covers integrity and retention evidence.

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 connection assessment. 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 records that determination.

Reporting and supplementation. The provider files the initial report with the relevant authority within the applicable timeline, then supplements it as the investigation develops.

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 a provider can use to assess the system-to-incident connection 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 your Article 73 evidence requires analysts to reconstruct a request path across scattered logs, test that retrieval before the incident clock starts. Let's talk today.