EU AI Act Article 73 Reporting Timelines 2026: The 15/10/2-Day Developer Operations Guide

Post #2 in the sota.io EU AI Act Incident Reporting Operations Series

August 2, 2026 is 64 days away. On that date, EU AI Act enforcement begins for providers and deployers of high-risk AI systems — including the Article 73 obligation to report serious incidents to national market surveillance authorities within tightly bounded time windows.

Three reporting deadlines. Two calendar days. Ten calendar days. Fifteen calendar days. Miss any of them and the penalty is up to €15 million or 3% of global annual turnover.

Most developer documentation focuses on what triggers reporting (the incident definition). Almost nothing addresses the operational question: once the trigger fires, when exactly does the clock start, what format does the NCA expect, and how do you build a pipeline that reliably hits the deadline?

This post answers that. By the end you will have: the precise rule for each timeline, the legal definition of "awareness" that starts the clock, the minimum required content for each notification tier, and a concrete alert pipeline architecture you can implement before August.

The Three Timelines at a Glance

EU AI Act Article 73 establishes three reporting windows based on incident severity. These are calendar days, not business days. Weekends and public holidays count.

The critical engineering insight: these are parallel tracks, not a tiered escalation. You cannot file a 15-day notification for a potential-death incident and "upgrade" it later. If your incident assessment determines that death is possible, the 10-day clock starts immediately — even if you later determine no death occurred.

This parallel-track architecture has significant implications for your triage pipeline, which we will address in the implementation section.

When Does the Clock Start? The "Awareness" Definition

The 2/10/15 day window begins when the provider or deployer first becomes aware that a serious incident has occurred or may have occurred.

"Aware" is defined by Art.73(3) as the point at which the provider has sufficient information to reasonably conclude that one of the four harm categories may have been triggered. This is not the point at which you have confirmed the incident, root-caused it, or determined your system was causally responsible. It is the point at which you know enough to have reasonable grounds for suspicion.

The Awareness Threshold in Practice

Scenario A — Direct notification: A hospital deploying your diagnostic AI support tool contacts your support team reporting that a patient was admitted after acting on an AI recommendation. Clock starts: when your support system logs the ticket, not when your engineering team investigates it.

Scenario B — Internal detection: Your post-market monitoring system (required under Art.72) flags an anomalous output pattern in a high-risk AI system. The anomaly is in a medical device context. Clock starts: when the monitoring alert fires, not when an engineer reviews the alert.

Scenario C — Third-party report: A media report describes an incident involving your AI system in an employment screening context that may have discriminated against a protected group. Clock starts: when your compliance team reads the report, not when they verify the facts.

The common thread: awareness is defined generously from the regulator's perspective. Any point at which a reasonable person in your organisation would conclude that a reportable incident may have occurred is the awareness trigger.

The Constructive Awareness Problem

A critical operational issue: constructive awareness. If your monitoring system would have detected an incident but was disabled, improperly configured, or not reviewing the relevant signals, a regulator can argue you should have been aware earlier than you claim.

This means your Art.72 post-market monitoring plan is not just a compliance checkbox — it is directly protective. A well-documented, operational monitoring system gives you a defensible awareness timestamp. A missing or broken monitoring system leaves you exposed to retroactive clock-start determinations.

The 2-Day Timeline: Death Confirmed

The 2-day reporting window applies when your incident assessment determines that a death has occurred and there is a plausible causal link to your AI system.

What Must Reach the NCA in 2 Days

The initial notification within 2 days is an awareness notification, not a full investigation report. The Commission's draft guidance (expected final August 2026) specifies the minimum content for this initial tier:

• System identifier: name, version, and registration number of the AI system under the EU database (Art.71)
• Incident description: what happened, when it happened, where it happened (deployment context)
• Victim information: number of people affected, severity of harm (anonymised where required by GDPR)
• Causal hypothesis: your current best assessment of how the AI system contributed — even if preliminary
• Immediate containment: what you have done in the first hours to limit further harm (e.g., taken the system offline, flagged affected cases for human review)
• Estimated timeline for full investigation report: when you expect to provide Art.73(4) documentation

What you do NOT need in 2 days:

• Root cause analysis (that comes later)
• Confirmed causal determination (preliminary assessment is sufficient)
• Remediation plan (that is part of the follow-up report)

The 2-day notification is deliberately minimal. Its purpose is to give the NCA visibility that a death has occurred involving an AI system in their jurisdiction. Speed matters more than completeness at this tier.

2-Day Pipeline Architecture

The 2-day window translates to approximately 46 working hours from awareness to NCA submission. In practice, assume 36 usable hours after discovery, internal escalation, and coordination.

Hour 0–2: Automated detection or manual report → Incident Management System creates P0 ticket → On-call engineering lead + legal counsel + DPO notified simultaneously
Hour 2–8: Initial severity assessment → Confirm death information → Identify relevant NCA (jurisdiction of deployment)
Hour 8–24: Draft initial notification using NCA template → Legal review → CISO sign-off
Hour 24–36: Submit to NCA via designated channel → Obtain submission confirmation → Log in compliance system
Hour 36–46: Buffer for NCA acknowledgement questions

The 10-Day Timeline: Serious Health Harm or Possible Death

The 10-day window applies when:

• A person has suffered serious harm to health (hospitalisation, permanent disability, life-threatening condition requiring medical intervention), or
• A death may have occurred but has not been confirmed, or
• Initial information is ambiguous between death-confirmed and serious-harm

Triage: 2-Day vs 10-Day

The most operationally complex decision point is distinguishing 2-day from 10-day incidents. The rule:

If there is ANY plausible possibility that a death has occurred: treat as 2-day.

Do not wait for confirmation. If your initial information includes mention of a fatality — even unconfirmed, even reported secondhand — the 2-day clock starts. You can reclassify downward to a 10-day incident if your investigation rules out death, but you cannot reclassify upward from 10-day to 2-day after the fact without potential regulatory consequence.

What Must Reach the NCA in 10 Days

The 10-day notification is more complete than the 2-day awareness notification. It should include:

• All elements of the 2-day notification
• Updated causal assessment: what your investigation has found in 10 days about the link between the AI system and the harm
• Scope of impact: how many users/deployments were potentially affected
• System configuration at time of incident: version, parameters, any recent changes
• Immediate corrective measures taken: what you have changed in the system since the incident
• Ongoing investigation status: open questions and expected resolution timeline

The "Possible Death" Edge Case

"Possible death" creates ambiguous triage scenarios. A user who loses consciousness after acting on an AI system recommendation — possible death? A patient whose condition deteriorates significantly after an AI-guided treatment decision — possible death?

The conservative operational rule: if a reasonable person reading the incident report would have non-trivial uncertainty about whether death occurred or is occurring, treat it as possible death and trigger the 10-day clock.

This errs toward over-reporting. The regulatory consequence of over-reporting (filing a 10-day instead of a 15-day incident) is minimal. The consequence of under-reporting (treating a possible-death incident as a 15-day standard incident) is significant.

The 15-Day Timeline: All Other Serious Incidents

The 15-day window applies to serious incidents in Categories B (critical infrastructure disruption), C (fundamental rights breach), and D (property/environmental damage), plus Category A incidents where health harm is serious but neither death nor the possibility of death is present.

What Must Reach the NCA in 15 Days

The 15-day notification is the most comprehensive tier. By 15 days you should have:

• All elements of the 10-day notification
• Root cause analysis: what caused the incident (or your best assessment if investigation is incomplete)
• Corrective action plan: specific technical and procedural changes you will make
• Recurrence prevention: how you will prevent the same category of incident from occurring again
• Post-market monitoring updates: changes to your Art.72 monitoring plan based on this incident

The 15-Day Window Relative to Your Development Cycle

15 calendar days is not a long time for engineering teams to conduct root cause analysis, implement corrections, and write regulatory documentation. The operational implication: your incident response process needs to run in parallel with your normal sprint cycle, not replace it.

Teams that have no incident response documentation in place — no runbooks, no on-call escalation paths, no legal notification templates — will find 15 days extremely tight. Teams with a documented process should be able to meet the deadline comfortably.

Building the Art.73 Alert Pipeline

Architecture Overview

A compliant Art.73 alert pipeline has four functional layers:

Layer 1 — Detection: Feeds from post-market monitoring (Art.72), customer support ticketing, external monitoring services, social media monitoring, and direct user reports. Every input channel must have a clear path to Layer 2.

Layer 2 — Triage: Automated severity scoring + human review. Outputs one of: NOT SERIOUS INCIDENT (log and close), CATEGORY A POSSIBLE DEATH (trigger 2-day workflow), CATEGORY A SERIOUS HARM (trigger 10-day workflow), CATEGORY B/C/D (trigger 15-day workflow).

Layer 3 — Notification Preparation: Template-driven documentation assembly. Legal review integration. NCA contact lookup by jurisdiction of deployment.

Layer 4 — Submission and Tracking: Secure submission to NCA portal or designated email channel. Confirmation logging. Deadline calendar entries. Audit trail.

Integration with Existing Tools

PagerDuty: Create a dedicated ai-act-incident service with escalation policy: L1 on-call engineer → L2 CISO → L3 Legal Counsel. Set up custom fields: incident_category (A/B/C/D), harm_confirmed (boolean), death_possible (boolean). Route from this service to your ITSM (Jira/ServiceNow) for tracking.

Jira/ServiceNow: Create an AI_ACT_INCIDENT issue type with mandatory fields: ai_system_id, incident_category, awareness_timestamp, 2d_deadline (calculated), 10d_deadline (calculated), 15d_deadline (calculated), nca_jurisdiction, submission_status. Auto-calculate deadlines from awareness_timestamp.

SIEM: Configure alerts for your high-risk AI system outputs that cross predefined harm thresholds. For example: if your AI system feeds into a medical context and you can detect downstream outcomes via integrated EHR or support data — configure alert rules for keywords like "hospitalisation", "adverse event", "unexpected deterioration" in associated case notes.

NCA Contact Directory (Key Jurisdictions)

Each member state designates its own national market surveillance authority. For AI systems, these are typically the existing sector regulators or general market surveillance authorities. Key contacts as of 2026:

• Germany: Bundesnetzagentur (BNetzA) — for general AI; sector-specific NCAs for healthcare (BfArM), financial services (BaFin)
• France: ANSSI for cybersecurity context; CNIL for fundamental rights/GDPR overlap; sector NCAs for finance/health
• Netherlands: Rijksdienst voor Ondernemend Nederland (RVO) — general market surveillance
• Sweden: Konsumentverket for consumer-facing AI; MSB for critical infrastructure context
• Ireland: DCCAE (Digital Markets and Consumer Affairs) — significant for EU headquarters of US tech companies

For AI systems deployed in multiple member states, you report to the authority in the member state where the incident occurred. If the incident spans multiple states or the user's location is unclear, report to the authority in the state of your EU establishment (or the member state where your EU representative is registered under Art.25).

The Multi-Jurisdiction Problem

A serious incident involving your AI system deployed across 15 member states: do you file 15 notifications?

The Commission's implementing guidance (expected August 2026) is expected to address this, but the current text of Art.73 implies: report to the NCA of the member state where the incident occurred. For cloud-deployed SaaS where users are distributed, this means the member state of the affected user.

Practical approach: file the primary notification with the NCA of the most severely affected user's jurisdiction. Include in the notification that the system is deployed across multiple member states and list the other affected jurisdictions. Most NCAs have coordination mechanisms (EUASN — the EU AI Supervisory Network) for cross-border incidents.

The Awareness-to-Submission Checklist

A 15-item checklist covering the complete path from incident detection to NCA submission:

Detection & Triage

• Incident detected via monitoring, customer report, or external source
• Awareness timestamp logged immediately and immutably
• Initial harm category assessed (A-death / A-harm / B / C / D / not serious)
• Correct deadline calculated and entered in compliance calendar
• On-call legal counsel and CISO notified within 1 hour

Investigation

• AI system version and configuration at incident time captured
• System logs for the relevant session/interaction preserved
• Causal hypothesis documented (even if preliminary)
• Scope of impact assessed (how many users/deployments affected)
• Immediate containment measures implemented and logged

Notification Preparation

• Correct NCA jurisdiction identified (country of incident)
• NCA submission portal/channel confirmed (not assumed from last incident)
• Draft notification reviewed by legal counsel
• Draft notification includes all required fields for the applicable timeline tier
• Submission confirmation mechanism confirmed (portal receipt / email read confirmation)

What Happens After You Submit

The initial notification is the start of a regulatory interaction, not the end. After your Art.73(3) initial notification, the NCA may:

Request a follow-up investigation report: under Art.73(4), the NCA can request a more complete investigation report within a timeframe they specify. This is not the same as the initial notification — it is a deeper dive that can come days or weeks after initial filing.

Coordinate with other NCAs: for multi-jurisdictional incidents, your filing NCA may loop in the NCAs of other affected member states through the EUASN network. You may receive coordinated questions from multiple authorities.

Issue provisional measures: under Art.74, market surveillance authorities can require you to take corrective action (recall, restriction, or withdrawal of the AI system) while investigation is ongoing. These provisional measures can precede any finding of non-compliance.

Refer to the AI Office: for incidents involving General-Purpose AI models, the national NCA may refer the investigation to the EU AI Office under Art.74(11).

Developer Summary

Three timelines. One critical rule: the clock starts at awareness, not confirmation.

If your SaaS product deploys or uses high-risk AI:

1. Build awareness logging first — every channel that could generate an incident report must timestamp the moment of first knowledge
2. Automate deadline calculation — any incident ticket must have 2d/10d/15d deadlines calculated and calendared automatically
3. Pre-prepare NCA contact directory — for each jurisdiction where you deploy, know which authority to contact before you need them
4. Run a tabletop exercise — walk through a simulated Category A incident using your pipeline before August 2, 2026

64 days is enough time to build this. It is not enough time to start from scratch when the first incident occurs.

Post #2 in the EU AI Act Incident Reporting Operations 2026 series. Next: the Commission reporting template — exactly what fields must appear in your NCA submission.