GPAI Incident Reporting Readiness: Internal Playbook, Escalation Paths & NCA Coordination — Pre-August 2026 Finale

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

This is the concluding guide in our five-part series on EU AI Act Article 73 serious incident reporting for GPAI model providers. The previous four posts covered what triggers mandatory reporting, the 2/10/15-working-day timeline framework, the NCA submission template, and multi-regulation overlap with CRA Art.14 and NIS2 Art.23. This finale focuses on organisational readiness: how to build the internal playbook, set escalation paths, and structure NCA coordination before enforcement begins on August 2, 2026.

Why an Internal Playbook Is Non-Negotiable Before August 2

Art.73 imposes tight working-day deadlines that begin the moment you become aware of a qualifying incident — not when you decide to report, not when legal counsel reviews the facts, and not when the engineering post-mortem is complete. Under the 2-working-day tier for incidents involving critical infrastructure, the clock runs almost immediately. That means the decisions about who escalates, who drafts, who approves, and who submits must be made before an incident occurs.

A post-incident playbook written under pressure produces incomplete reports, missed deadlines, and regulatory exposure. A pre-built playbook tested through tabletop exercises produces defensible, on-time notifications even when the underlying technical situation is still evolving.

The playbook structure below reflects the reporting obligations created by Art.73, the AI Office notification duties under Art.55 for systemic-risk GPAI models, and the practical reality that GPAI providers typically serve multiple EU member states simultaneously.

Part 1 — The Four-Layer Playbook Structure

Effective GPAI incident response requires four distinct but tightly connected layers.

Layer 1: Classification Gate

The classification gate answers a single question in under four hours: does this event qualify as a serious incident under Art.73?

Art.73 defines serious incidents as incidents that cause — or could reasonably be expected to cause — death or serious harm to health, significant disruption to critical infrastructure, significant property damage, or a serious breach of fundamental rights. Classification is a legal and technical joint judgement, not a purely engineering decision.

Classification gate checklist:

• Does the incident involve a high-risk AI system deployment (Annex III categories)?
• Does the incident involve a GPAI model integrated into a high-risk deployment by a downstream deployer?
• Has actual or plausible harm occurred in any of the four Art.73 categories?
• Is the harm attributable to AI system performance rather than external factors?
• Is the provider aware (direct report, deployer notification, media, regulator contact)?

If three or more boxes are checked, treat the incident as presumptively Art.73-qualifying and activate the full reporting chain immediately. Do not wait for certainty — the 2-working-day clock is already running.

Layer 2: Parallel Workstreams

Once the classification gate activates, three workstreams run simultaneously:

Legal-Regulatory Workstream: Identifies the relevant NCA (market surveillance authority of the provider's establishment member state), confirms timeline tier (2/10/15 days), checks for concurrent obligations under CRA Art.14 or NIS2 Art.23, and begins drafting the Art.73 notification using the template from the third post in this series.

Technical-Investigation Workstream: Preserves logs and evidence, identifies root cause hypotheses, assesses which downstream deployers are affected, and provides technical content for the notification. This workstream is not a blocker for initial notification — Art.73 explicitly allows incomplete initial reports with supplementary reports to follow.

Deployer-Communication Workstream: Notifies affected downstream deployers within the same timeline as the NCA notification (deployers need time to prepare their own reports if required). Documents deployer notifications as part of the incident record.

Layer 3: Escalation Paths

The escalation path defines who is authorised to approve and submit each type of notification. Ambiguity here is the single most common cause of missed deadlines.

Level 1 — Engineering / Safety Team: Detects and classifies. Within 2 hours of detection: completes classification gate, triggers Level 2.

Level 2 — Head of AI Safety / CTO: Reviews classification, makes final tier determination, approves activation of legal-regulatory workstream. Within 4 hours of detection.

Level 3 — General Counsel / DPO: Owns the NCA notification document. Liaises with external regulatory counsel if needed. Within 12 hours: has draft notification ready for review.

Level 4 — CEO / Managing Director: Approves and signs the notification submitted to the NCA. Within 24 hours of detection (for 2-working-day tier).

This four-level path must be documented with named individuals (not just job titles) and with named backups for each level. If the Head of AI Safety is unavailable, who is Level 2? If General Counsel is on leave, who is Level 3? These questions need answers before August 2026.

Layer 4: Documentation Close-Out

Every Art.73 notification must be followed by a completed incident record. This record serves two purposes: it provides evidence of regulatory compliance, and it feeds the post-market monitoring system required under Art.72.

The close-out documentation package includes: the initial NCA notification, any supplementary notifications, the deployer communication log, the root cause analysis, the corrective action plan, and the Art.72 post-market monitoring update reflecting the incident.

Part 2 — NCA Coordination in Practice

Which NCA Receives Your Notification?

Art.73 designates the NCA of the member state where the GPAI provider — or their authorised representative if the provider is established outside the EU — is established. For providers operating across multiple EU member states, this means a single NCA for Art.73 notifications, regardless of where the affected deployers or end users are located.

If your incident affects deployers in multiple member states, those deployers' NCAs may become involved separately. Your notification goes to your own NCA; you are not responsible for notifying NCAs in every affected jurisdiction. That responsibility falls to deployers as appropriate.

Practical identification step: Before August 2, identify and save the contact details of your NCA's AI market surveillance unit. As of mid-2026, designated AI Act NCAs include:

• Germany: Bundesnetzagentur (Federal Network Agency) — designated as the lead AI market surveillance authority
• France: ANSSI coordinates with Autorité de régulation des communications électroniques (ARCEP) for AI market surveillance
• Netherlands: Autoriteit Persoonsgegevens (AP) as data-related NCA; dedicated AI Act NCA designation in progress
• Ireland: Data Protection Commission (DPC) as interim NCA; dedicated AI Act unit being established
• Sweden: IMY (Integritetsskyddsmyndigheten) for data-related AI applications

Check your member state's official implementation status — designations are being finalised in the run-up to the August 2026 enforcement date. Keep the contact details in your playbook alongside an update trigger: "Verify NCA contact 30 days before August 2, 2026."

The Initial Contact Protocol

For most NCAs, the first Art.73 contact will be a formal written notification through their designated reporting channel. However, for incidents at the 2-working-day tier (critical infrastructure disruption), a preliminary phone or email contact is considered good practice before the formal written notification arrives. This aligns with DORA and NIS2 precedents where preliminary contacts are explicitly encouraged.

Initial contact message template (preliminary, not formal notification):

"We are contacting you as the market surveillance authority for [member state] to inform you that [company name] has identified a potential serious incident under EU AI Act Article 73 involving [brief description of affected system/model]. We are preparing the formal notification required under Art.73 and will submit it within [X] working days. The incident was identified on [date/time]. Point of contact for further coordination: [name, email, phone]."

This preliminary contact establishes good faith, opens the communication channel, and often allows the NCA to provide clarifications on their specific submission portal or format before the formal report arrives.

Handling NCA Follow-Up Requests

NCAs are likely to request supplementary information, particularly for incidents involving novel GPAI failure modes. The supplementary information protocol in your playbook should specify:

• Default response time: 5 working days for written requests (absent a specific NCA-imposed deadline)
• The designated point of contact for ongoing NCA correspondence (should be Legal/Regulatory, not Engineering)
• The process for coordinating technical and legal content before sending any response
• Retention of all NCA correspondence in the incident record

AI Office Coordination for Systemic-Risk GPAI Models

Providers of GPAI models classified as systemic-risk under Art.55 have a parallel obligation to notify the AI Office in addition to the NCA. The AI Office sits at the EU level and maintains oversight of systemic-risk GPAI models specifically.

If your GPAI model is subject to Art.55 obligations (training compute above the Annex XIII threshold, or AI Office designation), your playbook requires an additional workstream: drafting a separate AI Office notification that may have different content emphasis and that must be sent to the AI Office contact channel rather than your national NCA.

In practice, for the first year of enforcement, expect the AI Office and national NCAs to establish coordination protocols. Do not assume your NCA notification reaches the AI Office automatically — send both independently.

Part 3 — Pre-August 2026 Readiness Checklist

Playbook Completeness

• Classification gate checklist documented and distributed to L1/L2 responders
• Named individuals (not just roles) assigned to all four escalation levels
• Named backups assigned for each level
• NCA contact details recorded (portal URL, email, phone where available)
• AI Office contact details recorded (for systemic-risk GPAI providers)
• Downstream deployer contact list maintained and current

Legal and Procedural

• Outside regulatory counsel relationship established (for complex Art.73 scenarios)
• Multi-regulation overlap protocol documented (CRA Art.14 / NIS2 Art.23 coordination)
• Working day calculation method confirmed per your NCA's member state
• Legal entity confirmed as "provider" for Art.73 purposes (EU establishment or authorised representative)
• Authorised representative engaged if provider is non-EU-established

Technical Infrastructure

• Incident detection system triggers a timestamp-stamped alert at the moment of awareness
• Log retention policy ensures Art.73-relevant evidence is preserved for minimum 10 years (aligned with Art.18 technical documentation retention)
• Affected deployer notification capability confirmed (can you reach all deployers within 2 working days?)

Art.72 Post-Market Monitoring Integration

• Art.72 post-market monitoring plan references the incident reporting procedure
• Incident close-out process feeds findings into the monitoring system
• Serious incident threshold criteria in the monitoring plan match Art.73 classification gate

Tabletop Exercise

The single most effective readiness measure is a tabletop exercise before August 2, 2026. Run a scenario in which:

1. An engineering alert arrives at 09:00 Monday
2. The scenario involves a GPAI model integrated into a high-risk healthcare AI system
3. Three downstream deployers are affected across two EU member states
4. The event plausibly triggers both Art.73 (critical health infrastructure) and NIS2 Art.23 (significant cybersecurity incident)

Measure: how long does it take to reach a classification decision? Who approves the NCA notification? Is the draft ready within 24 hours? Document the gaps — they are your August 2 action list.

Series Summary

This five-part series has covered the complete Art.73 compliance journey for GPAI model providers:

1. What triggers reporting — the four harm categories, Art.73 vs Art.55 distinction, internal classification logic
2. The timeline framework — 2/10/15 working days, calculation methods, the supplementary report system
3. The NCA submission template — field-by-field breakdown of a submission-ready Art.73 notification
4. Multi-regulation overlap — CRA Art.14 and NIS2 Art.23 simultaneous obligations and single-report strategies
5. This guide — internal playbook, escalation paths, NCA coordination, readiness checklist

The enforcement date is August 2, 2026 — less than two months away. For most GPAI providers, the critical path items are: (1) NCA contact identification, (2) named escalation owners, and (3) the tabletop exercise. Everything else follows from having those three in place.

EU-Native Infrastructure as a Compliance Advantage

One factor that simplifies NCA coordination is having your AI infrastructure — model serving, inference logs, incident records — hosted within the EU under a provider not subject to US CLOUD Act access. When your NCA requests technical evidence or log access during an Art.73 follow-up, EU-hosted infrastructure means you can comply without conflicting with GDPR or triggering CLOUD Act tensions.

sota.io runs on Hetzner Germany with no US parent company. GPAI providers building their model-serving and logging infrastructure on sota.io start Art.73 with their evidence already jurisdiction-clean.

EU AI Act Art.73 enforcement begins August 2, 2026. This guide is educational and does not constitute legal advice. Verify NCA contact details and member-state implementation status with your regulatory counsel before that date.