Art.73 Incident Report Template: What GPAI Providers Must Submit to National Competent Authorities

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

When a serious incident occurs and your Art.73 notification clock starts running, you will not have time to design a report format from scratch. The EU AI Act's implementing acts on incident report templates are still in draft — but the Act's text, the AI Office's consultation documents, and the regulatory precedents from NIS2 and DORA give you enough to build a submission-ready template today.

This post reconstructs the required reporting structure from those sources and gives GPAI providers a practical template they can adapt to their internal incident response process before the August 2, 2026 enforcement deadline.

What Art.73 Requires in the Notification

Art.73 ("Reporting of serious incidents") establishes the obligation to notify the relevant national market surveillance authority (MSA) when a serious incident becomes known to the provider. The notification must contain the information necessary for the authority to understand the incident, identify the AI system involved, and assess whether corrective action is required.

The Act does not enumerate a fixed list of fields — instead, it delegates the precise format and content requirements to implementing acts that the European Commission will adopt. Those implementing acts are expected to draw on the standardised templates already developed for NIS2 Art.23 notifications and DORA RTS major incident templates, which share the same "initial / intermediate / final" three-stage architecture.

Until those implementing acts are in force, providers should treat the following as the minimum viable reporting structure.

The Three-Stage Report Structure

Serious incident notifications under Art.73 follow the same pattern as the major incident reporting frameworks in NIS2 and DORA: three distinct reports filed over a defined timeline.

Stage 1 — Initial Notification

Filed within the applicable deadline (2 working days for critical infrastructure impact, 10 working days when death or serious harm has occurred, 15 working days for all other qualifying incidents — see Post #1508 in this series for the full timeline analysis).

The initial notification is intentionally brief. Its purpose is to alert the authority that an incident has occurred and give them enough information to decide whether to open an investigation. Detailed root-cause analysis is not required at this stage.

Minimum required fields:

Stage 2 — Intermediate Report

Filed when new information becomes available that materially changes the authority's understanding of the incident — typically within 30 to 60 days of the initial notification, though the Art.73 implementing acts will specify this.

The intermediate report updates the initial notification with:

• Preliminary root-cause findings
• Updated harm assessment (number of affected persons revised if necessary)
• Status of corrective measures (implemented, in progress, or planned with timeline)
• Any other AI systems that may be affected by the same root cause
• Coordination with other notification obligations (NIS2, DORA, GDPR Art.33 if personal data was involved)

Stage 3 — Final Report

Filed once the incident is fully resolved and root-cause analysis is complete — typically within 90 days of the initial notification.

The final report closes the record and must include:

• Confirmed root cause and contributing factors
• Full timeline of the incident from detection to resolution
• Complete list of corrective measures implemented
• Changes made to the AI system, training data, or deployment practices to prevent recurrence
• Post-market monitoring plan updates (Art.72 implications)
• Confirmation that the system has been cleared for continued deployment, or explanation of any permanent withdrawal or modification

Identifying the Correct NCA

Art.73 notifications go to the national market surveillance authority of the EU member state where the serious incident occurred. This is the jurisdiction of the harm, not the jurisdiction of the provider.

A German GPAI provider whose model is deployed by an Italian operator and causes a serious incident affecting Italian users must file the initial notification with the Italian market surveillance authority — not the German authority.

Current NCA designations (as of June 2026):

For most other member states, the final NCA designations are still being confirmed. Providers should verify current designations through the European AI Office's national authority registry before filing.

Important: If the incident affects multiple member states, notify each affected authority separately. The AI Office does not act as a central relay for Art.73 notifications — that role belongs to the national MSAs acting through the AI Board coordination mechanism.

Multi-Regulation Overlap: When You Must File More Than One Report

A single GPAI incident may trigger simultaneous reporting obligations under multiple EU regulations. Providers need a de-confliction protocol before an incident occurs.

GDPR Art.33 applies if the incident involves a personal data breach. The notification must reach the competent supervisory authority within 72 hours of the provider becoming aware of the breach — independently of and in addition to the Art.73 notification. GDPR and AI Act notifications go to different authorities (DPA vs. MSA) and cannot be combined.

NIS2 Art.23 applies if the provider or operator qualifies as an essential or important entity under NIS2 and the incident constitutes a significant incident. NIS2 timelines (early warning within 24 hours, full report within 72 hours) are shorter than Art.73 timelines, so the NIS2 clock typically fires first.

DORA applies if the provider or operator is a financial entity in scope of DORA and the incident qualifies as a major ICT-related incident. DORA's reporting goes to the relevant financial supervisor (ECB, EBA, or national competent authority for financial services), not to the AI Act MSA.

The practical de-confliction rule: identify which regulation has the shortest timeline, file that notification first, then cross-reference all subsequent notifications. Where the regulations share underlying facts, reference the earlier notification by its case number to avoid requiring the authority to conduct parallel investigations of the same underlying event.

Template in Machine-Readable Form

The following YAML structure represents a minimal incident report record that can be used as the source document for all three stages. Fill in Stage 1 fields immediately at incident detection; add Stage 2 and 3 fields as the investigation progresses.

# Art.73 Serious Incident Record
# Version: 1.0 (August 2026 enforcement)

incident:
  id: "INC-[YYYY]-[NNNN]"        # Internal tracking ID
  detected_at: "YYYY-MM-DDTHH:MM:SSZ"
  occurred_at: "YYYY-MM-DDTHH:MM:SSZ"  # If known; else use detected_at

provider:
  legal_name: ""
  registered_address: ""
  eu_registration_number: ""
  contact_name: ""
  contact_role: ""
  contact_email: ""
  contact_phone: ""

ai_system:
  name: ""
  version: ""
  eu_database_id: ""            # Art.51 EU database registration, if applicable
  deployment_context: ""        # Sector and use case
  operator_name: ""             # If different from provider
  operator_country: ""

incident_description:
  summary: ""                   # 2-5 sentence plain-language description
  harm_type: ""                 # personal_injury | property_damage | fundamental_rights | critical_infrastructure | other
  harm_severity: ""             # death | serious_harm | risk_of_harm
  affected_persons_approx: 0
  vulnerable_groups_involved: false
  affected_member_states: []

notifications_filed:
  # Stage 1 — Initial
  stage1_filed_at: ""
  stage1_nca_name: ""
  stage1_nca_reference: ""
  stage1_deadline: ""           # 2 / 10 / 15 working days from detected_at

  # Stage 2 — Intermediate
  stage2_filed_at: ""
  stage2_nca_reference: ""

  # Stage 3 — Final
  stage3_filed_at: ""
  stage3_nca_reference: ""

parallel_notifications:
  gdpr_art33: false
  gdpr_dpa_notified_at: ""
  nis2_art23: false
  nis2_csirt_notified_at: ""
  dora_major_ict: false
  dora_authority_notified_at: ""

root_cause:
  preliminary: ""               # Stage 2
  confirmed: ""                 # Stage 3
  contributing_factors: []      # Stage 3

corrective_measures:
  immediate: []                 # Taken before or at Stage 1 notification
  in_progress: []               # Status at Stage 2
  completed: []                 # Confirmed at Stage 3

post_market_monitoring:
  art72_plan_updated: false
  monitoring_changes: ""        # Stage 3
  system_status: ""             # operational | suspended | permanently_withdrawn

Building the Submission-Ready Document

Most national MSAs will accept PDF submissions, at least initially. Convert your YAML record to a human-readable PDF using the following structure: a cover page with the provider, system, and incident identifiers; a narrative incident description section; a harm assessment section; a timeline of corrective actions; and an appendix with any supporting technical logs or test results.

When the Commission publishes the official implementing act template, map your internal record fields to the official form. A well-structured internal YAML record makes this mapping a one-time exercise rather than a scramble under time pressure.

Infrastructure Considerations: Where Your Incident Records Live

If your GPAI model infrastructure and your incident logging system are hosted on platforms subject to the US CLOUD Act — AWS, Azure, GCP, or any service with a US parent — your incident records are potentially accessible to US authorities under a CLOUD Act production order, without notice to you or the EU authority. This is not hypothetical: CLOUD Act orders do not require a US server, only a US-controlled entity.

For AI systems processing data within the EU and subject to Art.73 reporting, incident records are operational documents with potential regulatory significance. Hosting them on EU-native, non-US-controlled infrastructure (Hetzner Germany, OVHcloud, Exoscale) removes this exposure vector entirely.

sota.io runs on Hetzner Germany. No US parent. No CLOUD Act. If your team is building the internal tooling to manage Art.73 incident records, deploying on sota.io means your compliance evidence stays under EU jurisdiction from first commit to NCA submission.

Next in the Series

Post #1510 will cover the multi-regulation overlap in detail: when the same incident triggers Art.73, CRA Art.14, and NIS2 Art.23 simultaneously, and how to structure a single-report strategy that satisfies all three frameworks without filing three separate investigations from scratch.

Post #1511 (the series finale) will deliver the complete GPAI Incident Reporting Readiness playbook — internal escalation paths, NCA contact registry, legal review checklists, and a go/no-go decision framework for the 15-working-day deadline.