EU AI Act Art.73 Complete Incident Reporting Ops Playbook: August 2026 Readiness Guide

Post #1393 in the sota.io EU AI Act Compliance Series — EU-AI-ACT-INCIDENT-REPORTING-OPERATIONS-2026 #5/5 FINALE

August 2, 2026. Full EU AI Act enforcement begins. Your high-risk AI system causes a serious incident — a biometric misidentification that affects 200 users, a credit scoring error that triggers wrongful rejections, a medical decision-support failure that leads to delayed treatment. The market surveillance authority expects your early warning within 2 working days. Not 2 weeks. Two working days.

If you don't have a runbook in place, you won't meet that deadline. If you haven't registered with your national competent authority, you don't know where to send the report. If your Art.72 post-market monitoring system isn't logging the right data, you won't be able to reconstruct what happened in time to file accurately.

This is the fifth and final post in our EU AI Act Art.73 series. In the previous four posts, we covered what constitutes a serious incident (Post #1389), the 2/10/15-day reporting timeline structure (Post #1390), what every report field must contain (Post #1391), and how Art.73 runs in parallel with NIS2 Art.23 and CRA Art.14 (Post #1392).

This post pulls everything together into a complete operational playbook: the pre-conditions you need, the step-by-step runbook for each reporting phase, a RACI matrix, tools guidance, and a 30-item August readiness checklist you can use as your go/no-go test before enforcement begins.

What "Ops Playbook" Actually Means Here

A compliance checklist tells you what you're required to do. An ops playbook tells you who does what, when, using which systems, in what sequence, with what escalation paths. The difference matters enormously under time pressure.

When a serious incident occurs, you'll have a team of engineers who've just discovered the problem, a legal team asking what the exposure is, a C-level who wants to know if this makes the news, and a market surveillance authority expecting structured communication in less than 48 working hours. A checklist won't coordinate that. A runbook will.

This playbook is structured around five phases: pre-conditions (before any incident), detection and classification (T=0), early warning (T+2 working days), incident notification (T+10 working days), and final report (T+15 working days). Each phase has clear owners, deliverables, and verification checkpoints.

Phase 0: Pre-Conditions — What Must Exist Before T=0

The most common reason companies miss Art.73 deadlines isn't that they don't know the regulation. It's that they don't have the infrastructure in place to respond quickly. These are the prerequisites that must be built and tested before your first real incident.

1. Art.72 Post-Market Monitoring System

Art.72 requires providers of high-risk AI systems to maintain a post-market monitoring plan and collect data on system performance post-deployment. This isn't a reporting obligation — it's an operational one. And it's the foundation of Art.73 reporting because without monitoring data, you can't reconstruct what happened quickly enough to meet the 2-working-day early warning deadline.

Your Art.72 monitoring system must log:

• Every AI decision or recommendation made on an individual user
• The input data used for each decision (or a reference to it)
• The confidence score or probability output of the model
• Whether a human override occurred (Art.14 oversight records)
• User feedback or dispute signals, if applicable

Without this data, reconstructing a serious incident after the fact takes days. With it, your incident lead can pull a complete picture of what happened within hours.

2. Incident Classification Matrix

Build a decision tree before you need it. The Art.73 trigger conditions — death or serious injury, significant harm to fundamental rights, property damage above €50,000, disruption of critical services — should be translated into concrete questions your on-call engineer can answer at 2 AM:

"Did the AI decision or output directly contribute to this outcome? Was there a causal chain, even indirect? Is this an isolated error or a systematic pattern affecting multiple users?"

The classification matrix should output a Reportable / Monitor / No Action verdict, with escalation criteria for borderline cases. It should also output which parallel regimes apply (NIS2, CRA, or both — based on your product scope).

3. NCA Contact Registry

Your Art.73 report goes to the market surveillance authority responsible for the Member State where the incident occurred, or where your principal establishment is located. Different Member States may designate different bodies as their national competent authority for AI Act enforcement.

Before enforcement begins, you need to know:

• Which NCA covers your primary market
• The reporting portal or contact point for that NCA
• Whether a single incident requires parallel notifications to multiple NCAs (multi-jurisdictional incidents)
• The format and channel requirements of each NCA

This sounds administrative. It is. And it takes 1-2 hours to research and document, not 1-2 days. Do it now, not at T+1.

4. Pre-Populated Report Templates

Using the field structure from Post #1391, create company-specific templates with the stable fields pre-filled:

• Notifying party identification (company name, registration, contact)
• AI system identification (system name, version, EUASN reference if assigned)
• Your primary market surveillance authority details
• Your legal representative for AI Act matters

Blanks that will always need filling: incident description, dates, causal chain, corrective actions. Blanks that can be pre-populated: who you are and what system you operate.

The Four-Phase Reporting Runbook

Phase 1: Detection & Classification (T=0 to T+4h)

Trigger: On-call alert, user complaint, internal monitoring flag, or external report indicates a potential serious incident.

Responsible: Incident Lead (typically: Senior Engineer or Platform Reliability Lead)

Actions:

1. Activate incident response channel (Slack/Teams/PagerDuty)
2. Pull Art.72 monitoring data for the affected users and time window
3. Apply the incident classification matrix
4. If Reportable: escalate immediately to Legal Counsel and notify AI Safety Officer
5. If Monitor: set 2-hour reassessment window; document in incident log
6. If No Action: close with documentation

Output: Incident classification decision, documented with timestamp, evidence references, and responsible party sign-off.

Checkpoint: Has the incident been classified? Has the classification been challenged by at least one second reviewer? Have parallel regime triggers been checked (NIS2 scope, CRA product scope)?

Phase 2: Early Warning (T+4h to T+2 Working Days)

This is the most time-sensitive phase. Two working days is not two calendar days — weekends and public holidays don't count. But in practice, if your incident is discovered on a Friday afternoon, your early warning must still reach the NCA by the end of Tuesday.

Responsible: Legal Counsel, with support from AI Safety Officer and Incident Lead.

Actions:

1. Draft Early Warning using pre-populated template (Section 1: Notifying Party, Section 2: AI System, Section 3: Incident Description — preliminary only)
2. Legal review of causal chain framing (preliminary causal hypothesis, not admission)
3. Submit to market surveillance authority via designated channel
4. Obtain confirmation of receipt; log reference number

Content of the Early Warning: Notifying party identity, AI system identity, date and time of incident detection, preliminary description of harm type, number of affected users (estimate if exact unknown), whether corrective action has been taken. This is the "we know something happened" filing — detailed root cause analysis comes later.

If you operate under NIS2 or CRA: The 24-hour early warning for both regimes has already passed by this point. Phase 1 should have triggered parallel NIS2/CRA notifications if applicable. If this is the first recognition that NIS2 or CRA also applies, notify immediately under those regimes as well — the clock started at T=0, not at classification.

Phase 3: Incident Notification (T+2 to T+10 Working Days)

Responsible: AI Safety Officer (primary drafter), Legal Counsel (review), C-Level (sign-off for material incidents)

Actions:

1. Complete the Five-Layer Root Cause Analysis (Technical → Design → Human Oversight → Monitoring Gap → Systemic Pattern)
2. Compile full incident narrative: affected users (exact count), AI system inputs/outputs at time of incident, causal pathway from AI decision to harm
3. Draft corrective and mitigation actions: immediate measures taken + planned corrective measures + timeline
4. Submit full incident notification to market surveillance authority; update early warning reference

Quality check: Can you answer these questions from the report alone?

• Exactly what did the AI system output?
• Why was that output harmful rather than expected?
• Who was harmed, how severely, and how many?
• What has been done to prevent recurrence?

If no to any of these, the report is incomplete. Market surveillance authorities can and do request supplementary information, which extends the interaction timeline.

Phase 4: Final Report (T+10 to T+15 Working Days)

Responsible: AI Safety Officer with Legal Counsel review

If the investigation is complete: submit the Final Report within 15 working days of initial awareness. This report must include completed root cause analysis, closed-loop corrective actions (with evidence they've been implemented or are underway), and any systemic findings.

If the investigation is still ongoing at T+15 working days: submit a Progress Report at T+15 with current findings, and commit to a final report within one month of incident resolution. Document the reason for the delay and the expected timeline.

Art.72 loop-back: The final report findings must be fed back into your Art.72 post-market monitoring plan. A serious incident is a signal that your monitoring infrastructure had a gap — either it didn't catch the harm quickly enough, or it lacked the data needed to investigate effectively. Both are Art.72 obligations to fix.

RACI Matrix

R = Responsible, A = Accountable, C = Consulted, I = Informed

Parallel Obligation Coordination

When NIS2, CRA, and AI Act reporting apply simultaneously — which they will for any SaaS provider whose product includes a high-risk AI feature, operates as an essential/important entity under NIS2, and ships software with digital elements — the coordination challenge is real.

The central rule: each regime's clock runs independently from awareness under that regime's scope. If you become aware of an NIS2-triggering incident at T=0 and only recognize the AI Act component at T+4h, the Art.73 2-working-day clock starts at T+4h, but the NIS2 24-hour clock started at T=0.

Practically, you should assume all three apply and trigger all three simultaneously at T=0 classification if there is any reasonable basis. Failing to notify under NIS2 because you were focused on Art.73 — and vice versa — is the most predictable mistake. The parallel obligations section of your classification matrix should output which regimes to trigger.

Cross-regime efficiency: Where the same underlying facts need to be reported under multiple regimes, you can draft a single incident narrative and adapt it for each regime's required fields. The core facts — what happened, when, to whom, what AI system caused it — don't change. What changes is the framing (NIS2 focuses on service disruption, AI Act focuses on harm to individuals, CRA focuses on product vulnerabilities) and the recipient (NIS2 goes to CSIRT and competent authority, CRA goes to CSIRT coordinator and ENISA via the Art.16 single platform, AI Act goes to market surveillance authority).

Tools and Technology Stack

For Art.72 monitoring that feeds Art.73 reporting, you need infrastructure that captures decisions in real time and can be queried by incident timeline:

Logging: Structured JSON logs per AI inference call — timestamp, system ID, model version, input hash (not full input if PII), output, confidence, human override flag. These are the raw material for incident reconstruction.

Alerting: Threshold alerts on anomalous output distributions, user complaint rates, override rates. The goal is to catch potential serious incidents within hours, not days. Art.73's 2-working-day clock starts when you become aware — a monitoring system that catches incidents early gives you more time to file accurately.

Document management: Incident reports contain legally significant content. Version-control your drafts, log submission timestamps and NCA reference numbers, retain for the duration required under Art.12 record-keeping obligations.

Parallel regime tracking: A single incident management ticket with fields for each applicable regime (Art.73 deadline, NIS2 deadline, CRA deadline) prevents situations where one filing is missed because attention was on another.

Training and Simulation

Before August 2, 2026, run at least one full tabletop exercise simulating a serious incident:

1. Present your incident response team with a fictional but realistic serious incident scenario (example: high-risk AI system in HR context causes systematic discriminatory rejections across a protected characteristic)
2. Run through the classification matrix in real time
3. Draft an Early Warning against the clock — 2-working-day timer running
4. Identify gaps: where did the team get stuck? Where was data missing? Where was escalation unclear?

Document what broke and fix it before enforcement begins. The tabletop exercise is also evidence of due diligence under Art.9 (Risk Management System) — document that you conducted it.

30-Item August 2026 Readiness Checklist

Pre-Conditions (10 items)

• Art.72 monitoring system deployed — per-decision logs with timestamp, system ID, output, confidence, override flag
• Incident classification matrix documented — clear Reportable/Monitor/No Action criteria with 2 reviewers required for borderline
• NCA contact registry complete — primary and fallback contact details for each relevant Member State NCA
• Report templates pre-populated — notifying party + AI system fields filled; blank fields identified
• RACI matrix finalized and shared — every person in the matrix knows their role before any incident
• Legal counsel briefed on Art.73 — they know the timeline, the causal chain framing requirement, and the parallel regime scope
• Parallel regime scope assessed — written determination of whether NIS2 Art.23 and/or CRA Art.14 also apply to your product
• Art.12 record-keeping baseline — retention policy set for monitoring logs and incident reports
• Escalation phone tree — 24/7 contacts for Incident Lead, AI Safety Officer, Legal Counsel, and C-Level
• Tabletop exercise completed — at least one full simulation before August 2, gaps documented and resolved

Runbook Readiness (10 items)

• Phase 1 playbook published — classification steps documented, checklist format, 4-hour completion target explicit
• Phase 2 playbook published — early warning draft procedure, legal review SLA, NCA submission channel documented
• Phase 3 playbook published — root cause analysis framework (5-layer), incident notification review process
• Phase 4 playbook published — final report completion criteria, progress report procedure if ongoing
• Working day calculator accessible — the 2/10/15-day clocks count working days; team knows how to calculate deadlines across weekends and public holidays
• NCA submission channel tested — you've verified the submission portal or contact works (test submission if offered)
• Monitoring data query procedure documented — on-call engineers know how to pull Art.72 data for a given user and time window quickly
• Incident log template deployed — structured log for each incident with regime, timeline, decisions, actions, references
• Receipt tracking procedure — confirmation of NCA receipt is logged with reference number for every submission
• Art.72 loop-back procedure — post-incident, findings feed back into monitoring plan update

Parallel Obligations (5 items)

• NIS2 early warning T+24h — if NIS2 applies, 24-hour early warning triggered simultaneously with Art.73 classification
• CRA Art.14 early warning T+24h — if CRA applies, 24-hour notification triggered simultaneously
• Single narrative, multiple filings — cross-regime efficiency: one incident narrative adapted per regime's field requirements
• Regime-specific recipients documented — NIS2 → CSIRT + competent authority; CRA → CSIRT coordinator + ENISA via Art.16 platform; AI Act → market surveillance authority
• Incident ticket has deadline fields for all applicable regimes — prevents any single-regime tunnel vision during active incidents

Training and Documentation (5 items)

• Incident classification training completed — all members of RACI matrix have trained on the classification matrix with real examples
• Tabletop exercise documented — written record of exercise, findings, and fixes — evidence for Art.9 due diligence
• Playbook version control active — incident runbook is version-controlled with review dates and owner
• Lessons-learned procedure — post-incident review within 30 days of final report, output feeds Art.72 plan update
• Legal review of final playbook — outside counsel or DPO has reviewed the completed playbook against Art.73 text

Conclusion: Compliance as Operations

The EU AI Act Art.73 incident reporting obligation is not primarily a legal compliance requirement — it's an operations requirement. Meeting it under time pressure, while managing an active incident, while coordinating across multiple reporting regimes, requires the same engineering discipline as any other critical operational process.

Build the infrastructure. Write the runbook. Test it before the clock starts. The companies that will struggle with Art.73 in August 2026 are not the ones that don't know the regulation — they're the ones that know it but haven't operationalized it.

The checklist above is your go/no-go test. If you have 27 of 30 boxes ticked by July 15, you have two weeks to close the gaps. If you have 15 boxes ticked on August 1, you're not ready and you know it.

This is the final post in the EU-AI-ACT-INCIDENT-REPORTING-OPERATIONS-2026 series. For the full series: Part 1 — Serious Incident Definition | Part 2 — Reporting Timelines | Part 3 — Report Content Guide | Part 4 — Multi-Regulation Comparison.