EU AI Act Art.73 Incident Reporting Timelines: The 2/10/15-Day Framework for GPAI Providers

Post #1508 in the sota.io EU AI Act GPAI Incident Reporting Series

When a serious incident occurs involving your GPAI system, the clock starts immediately — but which clock? The EU AI Act Art.73 does not impose a single uniform deadline. Instead it creates three distinct notification tiers based on the nature and severity of the harm, with deadlines of 2, 10, or 15 working days.

Most compliance teams know there is a reporting obligation. Far fewer have mapped out the triage decision tree that determines which deadline applies in a given scenario. That gap creates real risk: a 15-day incident misclassified as a 15-day item when it was actually a 2-day item leaves the provider in breach from day 3 onward, even if the report is eventually filed.

This post gives you the complete timeline framework — what each tier covers, how working days are calculated across EU member states, and how to build an internal escalation path that ensures the right notification reaches the right authority on time.

The Three-Tier Deadline Structure

Art.73 imposes tiered obligations based on incident type:

Tier 1 — 2 Working Days: Widespread Incidents and Critical Infrastructure

Art.73(3) imposes the strictest timeline: providers must notify the market surveillance authority within 2 working days when the serious incident involves:

• Widespread harm — incidents affecting or capable of affecting a large number of people simultaneously
• Critical infrastructure disruption — energy grids, water systems, transport networks, healthcare systems, financial market infrastructure

The 2-day clock is tight. For a team discovering a widespread model malfunction on a Friday afternoon, this means the preliminary notification must reach the relevant national MSA before close of business on Tuesday at the latest — assuming no public holidays intervene.

The rationale is coordination: MSAs need early warning for incidents with systemic potential so they can coordinate with other national authorities and with the EU AI Office before harm propagates further.

What counts as "widespread" under Art.73(3)?

The text does not specify a numeric threshold. Guidance from the AI Office suggests the following factors point toward widespread classification:

• The incident affects or could affect users in multiple EU member states simultaneously
• The AI system was deployed at scale (many deployers or end-users)
• The same model flaw could cause the same harm in parallel instances

When in doubt at the triage stage, treat an incident as potentially widespread and prepare for the 2-day timeline while your investigation continues. It is better to file an early preliminary notification and update it than to miss the deadline while debating classification.

Tier 2 — 10 Working Days: Death of a Person

Art.73(4) sets a 10-working-day deadline specifically for serious incidents where a person has died.

The 10-day window gives providers slightly more time than the 2-day critical-infrastructure tier, but it is still a compressed timeline for teams that need to conduct root cause analysis, engage legal counsel, and coordinate with deployers who may have additional information about the circumstances of harm.

Implications for GPAI providers

GPAI model providers occupy a unique position in the AI value chain: they do not typically deploy directly to end-users. If a downstream deployer's application caused a fatality and that application was built on your GPAI model, the obligation attaches to both the deployer (under Art.73 as a high-risk AI system operator) and potentially to you as GPAI provider (under Art.55(1)(d) if your model carries systemic-risk designation).

The practical implication: you need a contractual and technical mechanism to receive rapid notification from deployers when fatalities occur involving your model. If you learn about a deployment-layer death from a news article rather than a deployer notification, your 10-day clock started when you "became aware" — which in most interpretations includes the moment your team read the news.

Tier 3 — 15 Working Days: All Other Serious Incidents

Art.73(2) sets the baseline deadline of 15 working days for serious incidents that do not fall into the critical-infrastructure or death categories. These include:

• Serious health harm (non-fatal) — hospitalisation, long-term physical or psychological injury
• Infringement of Union law protecting fundamental rights — systematic discrimination, unlawful surveillance, privacy violations at scale
• Serious harm to property or the environment

The 15-day window is the default. When your initial triage does not identify critical-infrastructure or fatality elements, the 15-day clock applies.

Calculating Working Days: Cross-Border Complications

"Working days" under the AI Act means business days excluding weekends and public holidays in the member state where the incident occurred — not holidays in your home country of registration.

This creates a practical problem for GPAI providers operating across the EU: an incident occurring in France on July 14 (Bastille Day) gives you one extra working day on that tier. An incident in Germany on a regional holiday (which varies by Bundesland) may do the same. An incident spanning multiple member states simultaneously — the widespread tier — uses the holidays of the member state where the MSA receiving the notification is located.

Recommended approach: Build your incident timeline calculator with a public holiday table covering all 27 EU member states plus the EU-level AI Office calendar. This is not theoretical over-engineering — a 2-working-day tier in a country with adjacent public holidays can compress to a real-time window of less than 48 clock hours.

The "Became Aware" Starting Clock

All three timelines begin from the moment the provider "becomes aware" of the serious incident. This phrase carries significant compliance weight.

What starts the clock:

• A monitoring alert fires indicating model outputs caused documented harm
• A deployer contacts you to report that their application (built on your model) caused a qualifying incident
• You read credible public reporting about harm caused by your model's deployment
• An internal employee report escalates a potential serious incident

What does not pause or reset the clock:

• Continued investigation to confirm root cause
• Waiting for the deployer to provide more information
• Internal legal review to confirm the incident meets the "serious" threshold
• Uncertainty about which national MSA has jurisdiction

The "became aware" standard is objective, not subjective. If a reasonable team would have identified the situation as a potential serious incident, the clock is running. Filing a preliminary notification under reservation — "we are investigating a potential Art.73 incident, full report to follow within X days" — is explicitly contemplated by the framework and is better than waiting for certainty.

Preliminary vs. Final Reports: A Two-Step Process

Art.73 contemplates a two-step notification process for all tiers:

Step 1 — Initial notification: Filed within the applicable deadline (2, 10, or 15 working days from awareness). This notification covers the basic facts known at the time: what happened, what AI system was involved, what harm occurred, and what immediate measures have been taken.

Step 2 — Updated notification: Filed as new information becomes available. The initial notification does not need to be complete or conclusive. Regulators understand that root cause analysis takes time. What they do not accept is silence — the initial notification is the mandatory baseline.

For the 2-day critical-infrastructure tier, the initial notification is necessarily preliminary. There is simply not enough time to conduct a thorough investigation. The MSA expects a brief, factual notification: "On [date], we became aware of [incident type] involving [system]. We are investigating. We will provide a full report within [X] working days." This structure satisfies the notification obligation and triggers the collaborative coordination process.

Parallel Obligations: Art.73 and Art.55(1)(d) Simultaneously

As covered in Post #1507, GPAI providers with systemic-risk designation face parallel notification obligations. When the same incident triggers both Art.73 (because the GPAI model underlies a high-risk AI system in an Annex III application) and Art.55(1)(d) (because the GPAI model itself carries systemic-risk classification), the timelines are not harmonised by the text of the Regulation.

Practical implication: Build a single incident intake form that simultaneously initiates both notification workflows. The Art.73 notification goes to the national MSA in the member state where the incident occurred. The Art.55(1)(d) notification goes to the EU AI Office. The factual content overlaps substantially; the addressees and communication channels differ.

Do not assume that notifying one authority satisfies the other. Until the AI Office issues implementing guidance that harmonises the two tracks, treat them as parallel independent obligations.

Building the Internal Triage System

Given the three-tier structure, your incident response team needs a triage decision tree that fires within hours of an incident becoming known. The decision tree has three branches:

Branch A — Critical Infrastructure or Widespread: 2-working-day clock. Activate this branch if: (1) the incident affects energy, water, transport, health, or financial systems; or (2) the incident affects or could affect users across multiple member states simultaneously or a very large number of users.

Branch B — Death: 10-working-day clock. Activate this branch if: a person has died and the model's output contributed causally to that death.

Branch C — All Other: 15-working-day clock. Activate for serious health harm (non-fatal), fundamental rights infringements, property or environmental harm.

Escalation rule: When a single incident has features of multiple branches (a widespread infrastructure disruption that also causes deaths), use the strictest applicable deadline. A multi-element incident does not average its deadlines — it takes the most conservative one.

Practical Readiness Checklist

Before August 2, 2026, every GPAI provider operating in the EU should have:

• Incident triage classification tool that assigns tier (2/10/15 days) within 2 hours of incident intake
• Public holiday calendar for all 27 EU member states integrated into deadline calculation
• Templated preliminary notification for each tier (2-day template is the most time-critical)
• Identified contact points at all relevant national MSAs for your deployment footprint
• Contract clauses with downstream deployers requiring rapid notification when fatalities or widespread harm occurs
• Designated incident response owner with authority to file preliminary notifications without lengthy internal approval chains
• Parallel Art.55(1)(d) notification workflow if your model has systemic-risk designation

The 2-day tier is where most teams will fail first. At 2 working days from awareness, your preliminary notification needs to be signed, formatted, addressed to the right national MSA, and transmitted. That requires pre-prepared templates, clear escalation authority, and a working relationship with at least the primary MSAs in your largest deployment countries.

What Comes Next in This Series

Post #1509 covers the content requirements for the Art.73 notification itself: what a GPAI provider must include, what format the MSAs expect, and how to structure the preliminary notification to satisfy regulators without over-committing to conclusions still under investigation.

sota.io is an EU-native managed PaaS built for teams deploying AI-adjacent infrastructure — no CLOUD Act exposure, Hetzner Germany, GDPR-compliant by architecture. Learn more →