EU AI Act GPAI Serious Incident Reporting: What Triggers Art.73 and Art.55 Mandatory Notifications in 2026

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

GPAI model providers in Europe face a compliance question that catches many teams unprepared: when something goes wrong with your model, who do you notify, and how fast? The answer is not straightforward because the EU AI Act creates two parallel incident reporting regimes that can apply simultaneously.

Art.73 covers providers of high-risk AI systems and requires notification to national market surveillance authorities (MSAs) — the regulators in each EU member state. Art.55(1)(d) covers providers of GPAI models with systemic risk and requires notification to the EU AI Office in Brussels. If your GPAI model is used as the backbone of a high-risk AI application, both obligations may fire at the same time, to different authorities, on different timelines.

This post maps both triggers precisely, explains what counts as a "serious incident" under each regime, and gives you the classification logic your team needs before the August 2, 2026 enforcement deadline.

The Two-Regime Architecture

The EU AI Act separates AI incident reporting by the nature of the AI product and who is harmed:

Regime 1 — Art.73 (High-Risk AI System Providers): Applies to providers who place high-risk AI systems (listed in Annex III, or self-classified under Art.6) on the EU market. When a serious incident occurs in the EU, the provider notifies the market surveillance authority of the member state where the incident occurred. Art.73 enforcement begins August 2, 2026.

Regime 2 — Art.55(1)(d) (GPAI Models with Systemic Risk): Applies to providers whose GPAI models exceed the systemic-risk threshold — currently operationalised at 10²⁵ cumulative floating point operations (FLOPs) during training. When a serious incident becomes known to the provider, they notify the EU AI Office directly. This obligation has been in force since August 1, 2025 — twelve months after the AI Act's entry into force — meaning GPAI providers with systemic-risk models are already under this reporting duty today.

The practical result: a frontier model provider (GPT-4 class, Claude class, Gemini class) operating in the EU with systemic-risk designation AND whose model is integrated into a high-risk application faces simultaneous obligations to both the AI Office and the relevant national MSA.

What Counts as a Serious Incident Under Art.73?

The AI Act defines a serious incident for high-risk AI systems as any incident or malfunctioning that results in:

1. Death of a person or serious harm to a person's health — physical or psychological harm that is more than transient
2. Serious and irreversible disruption to the provision of critical infrastructure — energy, water, transport, health, finance
3. Infringement of obligations under Union law intended to protect fundamental rights — discrimination outputs, privacy violations, violations of freedom of expression
4. Serious harm to property or the environment

For GPAI providers, the definition maps to incidents where the model's output — directly or through a downstream application — contributes causally to one of these harms in the EU. The key word is "contributes": the AI Act does not require that the AI system be the sole cause, only that it played a material role.

The Causation Question

Teams frequently underestimate how broadly "contribution" is read in regulatory practice. Consider:

• A GPAI model used in a hiring tool outputs systematically discriminatory recommendations → potential fundamental rights violation, regardless of whether a human approved each decision
• A GPAI model integrated into a medical advice platform produces a dosage recommendation that causes hospitalisation → health harm with clear AI contribution
• A GPAI model used in power grid management outputs an erroneous load-balancing instruction that causes a blackout → critical infrastructure disruption

None of these require that the AI system acted autonomously or that it was the only cause. The question is whether removing the AI system output would have prevented the harm.

GPAI Systemic Risk: What Art.55(1)(d) Requires

For GPAI providers with systemic risk designation, Art.55(1)(d) creates an independent reporting obligation to the EU AI Office. The threshold for this obligation:

• GPAI model trained with >10²⁵ FLOPs, OR
• GPAI model designated by the European Commission as having systemic risk based on reach, capability, or other risk indicators

The "without undue delay" standard in Art.55(1)(d) is not the same as the specific working-day timelines in Art.73. The AI Office has published guidance that providers should interpret "without undue delay" as within 24 hours of the provider becoming aware that a serious incident may have occurred — with a fuller report following within 15 working days.

The Art.55(1)(d) obligation covers incidents involving:

• Systemic misuse at scale (coordinated harmful use affecting many users simultaneously)
• Model behaviour that undermines critical infrastructure or democratic processes
• Security incidents affecting the model's integrity (poisoning, extraction, jailbreaks at scale)
• Incidents that reveal systemic flaws in the model's safety evaluations

Unlike Art.73 (which is harm-triggered), Art.55(1)(d) also covers incidents that could cause systemic harm even if no harm has yet occurred — the AI Office wants early warning of capability failures.

Art.73 Timelines: The 2/10/15 Working-Day Framework

For high-risk AI system providers, Art.73 establishes a three-stage reporting timeline:

Critical note: The 2-working-day initial notification clock starts from when the provider "becomes aware" of the incident — not from when the harm is confirmed. Internal incident response logs, user complaints, and monitoring alerts all count as the awareness trigger. Providers who delay investigation to confirm severity before notifying risk violating the 2-day deadline.

For incidents involving immediate risk of death or serious health harm, national MSAs may require notification faster than 2 working days — the AI Act allows member states to set shorter timelines for critical situations.

Classification Logic: Does This Incident Trigger Reporting?

Building an internal classification tree is the practical way to operationalise these obligations. The minimum viable classification logic:

INCIDENT DETECTED
  ├── Does it involve a GPAI model with systemic risk (>10²⁵ FLOPs)?
  │     ├── YES → Art.55(1)(d) pathway active → notify AI Office within 24h
  │     └── NO → Art.55 not triggered
  │
  ├── Is the AI system used in a high-risk application (Annex III)?
  │     ├── YES → Art.73 pathway active
  │     │     ├── Has serious harm (death/injury/critical infra/fundamental rights/property) occurred OR is imminent?
  │     │     │     ├── YES → Art.73 notification to national MSA within 2 working days
  │     │     │     └── NO → No Art.73 obligation (document assessment for audit)
  │     └── NO → Art.73 not triggered (standard incident response)
  │
  └── Both Art.55 AND Art.73 triggered?
        └── Run parallel notification tracks — different recipients, different timelines, coordinated messaging

The most complex scenario is dual-trigger: a systemic-risk GPAI model integrated into a high-risk application in Germany, for example. The provider must notify both the AI Office (Art.55, within ~24h) and the German market surveillance authority (Art.73, within 2 working days) with consistent but jurisdiction-appropriate content.

What GPAI Providers Frequently Miss

1. The "becomes aware" standard is broad. Internal Slack messages, user bug reports, automated monitoring alerts — all count as awareness triggers. Your incident classification and notification systems need to be connected to your alerting infrastructure before an incident occurs.

2. Negative determinations need documentation. When you investigate an incident and conclude it does not meet the serious incident threshold, that determination needs a documented rationale. NCAs conducting post-market surveillance (Art.74) will examine your incident logs. "We did not think it was serious" without a written assessment is not an audit-ready response.

3. Art.55 applies NOW, Art.73 applies from August 2026. GPAI providers with systemic risk have been under the AI Office reporting obligation since August 2025. If your model qualifies under the FLOP threshold and you have not already established an AI Office notification protocol, you are already overdue on compliance setup.

4. Downstream deployer incidents may cascade to the GPAI provider. When a deployer of your GPAI model reports an Art.73 incident to a national MSA, that MSA will ask about the upstream model provider. If the root cause implicates the model itself (not just the deployer's integration), you may receive a regulatory inquiry requiring you to demonstrate your own Art.55 notifications and safety evaluations.

5. CLOUD Act implications for non-EU providers. GPAI providers headquartered in the US face a structural compliance challenge: your incident investigation systems, model weights, and safety evaluation logs may be subject to US government access under the CLOUD Act. EU regulators and the AI Office have noted this as a sovereignty concern. Hosting safety evaluation infrastructure on EU-native infrastructure (Hetzner Germany, OVHcloud, Scaleway) removes this exposure.

Before August 2, 2026: The Minimum Viable Incident Reporting Setup

For teams building out GPAI incident reporting compliance before the enforcement date:

1. Classify your model. Determine whether your model exceeds the 10²⁵ FLOP threshold. The European Commission's AI Office publishes a GPAI model registry — check whether you need to register and comply with Art.53 obligations first.

2. Map your downstream high-risk applications. For each production deployment, determine whether it falls under an Annex III category (biometric ID, critical infrastructure, employment, education, access to essential services, law enforcement). Each qualified deployment is a separate Art.73 obligation source.

3. Build the dual-notification workflow. Art.55 and Art.73 use different forms, different recipients, and have different information requirements. A single incident response playbook that handles both in parallel prevents the coordination failures that emerge during an actual incident.

4. Connect monitoring to the notification trigger. The awareness clock starts when your systems generate an alert, not when a human investigates. Automated monitoring rules need a human-in-the-loop escalation path with documented timestamps.

5. Establish AI Office contact. The EU AI Office (AI-Office@ec.europa.eu) is the Art.55 notification recipient. Establish the reporting channel and test your notification format before you need it under deadline pressure.

What Comes Next in This Series

Post #1508 covers the precise timelines in depth: the 2/10/15-working-day Art.73 framework versus the "without undue delay" Art.55 standard, and how regulators interpret simultaneous obligations when the deadlines conflict. Post #1509 provides an Art.73-compliant incident report template that GPAI providers can adapt for both national MSA and AI Office filings.

For teams managing EU infrastructure and incident response under sovereignty constraints, sota.io provides EU-native managed PaaS on Hetzner Germany — your incident investigation and safety evaluation infrastructure stays outside US CLOUD Act jurisdiction by default.

This post covers EU AI Act obligations as published in Regulation (EU) 2024/1689. GPAI systemic risk obligations (Art.55) are in force from August 1, 2025. High-risk AI system obligations including Art.73 incident reporting are in force from August 2, 2026.