EU AI Act Art.73 + CRA Art.14: Building a Unified Incident Reporting Pipeline

Post #3 in the EU AI Act + CRA Dual Compliance Developer Series (5 posts)

Post 1 established who falls under both regulations. Post 2 mapped the cybersecurity requirements overlap between Art.15 and CRA Annex I. This post addresses the operational question that keeps compliance engineers awake: when something goes wrong, what exactly do you report, to whom, within what window, and how do you satisfy both frameworks without running two parallel bureaucracies?

The answer is a unified incident reporting pipeline — a single event-detection layer that fans out into two regulatory notification channels with distinct clocks, distinct authorities, and distinct content requirements. Getting this right before August 2026 matters: AI Act Art.73 obligations apply from the August 2 deadline; CRA Art.14 reporting follows on September 11, 2026, giving you a six-week overlap window where you are live on one regime before the second kicks in.

Why Two Separate Reporting Regimes

Both regulations impose post-incident reporting obligations, but they emerged from different policy concerns and regulate different things:

EU AI Act Art.73 is titled "Reporting of serious incidents." It concerns what your AI system did — specifically, whether a malfunction or performance defect of a high-risk AI system caused or could reasonably be expected to cause specified categories of harm. The regulation cares about AI behaviour outcomes: did the AI system contribute to a death, a serious injury, a fundamental-rights violation, or disruption of critical infrastructure?

CRA Art.14 is titled "Reporting obligations of manufacturers." It concerns what was done to your product — specifically, whether an actively exploited vulnerability was discovered, or whether an incident had a significant impact on the security of the product. The CRA cares about product security state: was a vulnerability weaponised against the product's software components?

These are different questions. A high-risk AI system that begins drifting in accuracy (Art.73 serious incident territory if it causes harm) is not the same as an adversarial attack exploiting a memory-corruption bug in the inference engine (CRA Art.14 territory if it is actively exploited). But there is an overlap zone: an actively exploited vulnerability in the AI system that causes the AI to produce harmful outputs triggers both.

The Overlap Zone: When Both Clocks Start

Not every event triggers both regimes. You need a decision tree that maps each incident type to its applicable obligations.

The overlap zone is the third and fourth rows: security exploits that also produce AI harm outcomes. These are the events requiring the most coordination, because both clocks start simultaneously but run at different speeds.

EU AI Act Art.73: The Serious Incident Reporting Regime

What counts as a serious incident

Art.73 applies to providers of high-risk AI systems placed on the EU market. A serious incident is defined as any malfunction or performance defect that leads to, or could reasonably be expected to lead to:

• Death or serious injury to persons
• Serious damage to property or the environment
• Disruption to the provision of critical infrastructure services
• Infringement of obligations under Union law intended to protect fundamental rights
• Harm to public security or safety, or serious consequences for society

The key threshold is causal connection to specified harm. The AI system's behaviour must have contributed to the harm — it is not enough that a security incident occurred in a system that also happens to run AI.

Art.73 Reporting Timelines

The AI Act creates three timeline tiers based on incident severity (all measured from when the provider becomes aware):

Critical implementation note: These are calendar days, not working days. The 2-day tier for critical infrastructure disruption is genuinely fast — equivalent to the speed of GDPR Art.33's 72-hour breach notification window.

There is no 24-hour early-warning tier in Art.73. The minimum is 2 calendar days, and only for widespread/critical-infrastructure events. Do not confuse this with NIS2's 24-hour early warning — they are different regimes.

Where to report under Art.73

Reports go to the market surveillance authority (MSA) of the Member State where the serious incident occurred. For incidents affecting users in multiple Member States, each national authority receives a report. In practice, this is the national competent authority designated under Art.74.

The provider must keep the reporting authority informed of the incident's progress, any corrective measures taken, and the root-cause analysis when complete. Art.73 does not specify a machine-readable format for initial notifications; the Commission may adopt implementing acts under Art.73(7) specifying the format, but as of the August 2026 application date, format guidance is expected via EAIB templates.

Who must report under Art.73

The obligation sits with the provider — the entity that developed and placed the high-risk AI system on the market, or put it into service for its own use. If you are a deployer (using someone else's high-risk AI system), you must notify the provider when you become aware of a serious incident; it is then the provider's obligation to report to the authority.

CRA Art.14: The Manufacturer Reporting Regime

What triggers CRA Art.14

CRA Art.14 creates two distinct reporting triggers:

Trigger 1 — Actively exploited vulnerability: The manufacturer discovers that a vulnerability in any component of the product with digital elements is actively being exploited. This does not require that the exploit has caused harm — the act of active exploitation itself triggers the reporting clock.

Trigger 2 — Severe incident: An incident has, or could have, a significant impact on the security of the product. The CRA does not define "significant" with a precise threshold; the recitals indicate that incidents affecting many users, persisting for extended periods, or involving state-level threat actors should be treated as significant.

CRA Art.14 Reporting Timelines

CRA Art.14 creates a three-stage escalating notification structure, running from the moment the manufacturer becomes aware:

Where to report under CRA Art.14

Reports go through the single reporting platform established under CRA Art.16, operated by ENISA. The platform routes reports simultaneously to:

• The CSIRT designated as coordinator under Art.12(1) of NIS2 in the relevant Member State
• ENISA centrally (for aggregated pan-EU situational awareness)

This is important: you do not report directly to individual authorities. You use the Art.16 platform and ENISA routes the notification. This creates a single submission point that satisfies the multi-recipient requirement.

CRA Art.14 reports must be machine-readable and follow the format specified in the implementing regulation under Art.16. The Commission is expected to publish this format before September 2026.

Who must report under CRA Art.14

The obligation sits with the manufacturer — the entity that placed the product with digital elements on the market. If you both developed the AI system and deployed it as a commercial product (typical for AI SaaS), you are the manufacturer. Unlike Art.73, there is no comparable deployer-notify-provider mechanism in CRA Art.14; if you are the manufacturer, you report directly.

CRA Art.14 Application Date

CRA Art.14 reporting obligations apply from 11 September 2026 — specifically called out in CRA Art.71 as one of the early-application provisions. The main product obligations (Art.13, Annex I essential requirements) apply from December 11, 2027, but the reporting duties for manufacturers go live much earlier.

The Conflict Zone: Dual-Report Incidents

When an incident triggers both Art.73 and CRA Art.14, you face three structural tensions:

Tension 1: Timeline mismatch

CRA Art.14's 24-hour early warning is faster than Art.73's minimum 2-day clock. In practice, for a dual-trigger incident (exploited vulnerability causing AI harm), the CRA clock will expire before the Art.73 clock.

Day 0, T+0:   Incident discovered
Day 0, T+24h: CRA Art.14 — Early warning due (ENISA + CSIRT via Art.16 platform)
Day 2, T+48h: Art.73(3) — Urgent report due (if critical infrastructure)
Day 0, T+72h: CRA Art.14 — Full notification due
Day 10:       Art.73(4) — Report due (if death/serious injury involved)
Day 14:       CRA Art.14 — Final report due (if fix is available by then)
Day 15:       Art.73(2) — Standard report due (if no death/infra impact)
Day 30+:      CRA Art.14 — Severe incident final report (1 month from 72h notification)

A unified pipeline must track all these deadlines independently and trigger separate notification actions on schedule.

Tension 2: Authority mismatch

• Art.73 reports go to national market surveillance authorities (one per affected Member State)
• CRA Art.14 reports go to ENISA + CSIRT via the Art.16 platform

In a multi-Member-State incident, Art.73 requires multiple national filings; CRA Art.14 requires a single central filing that ENISA distributes. The data required by each regime overlaps significantly but the submission endpoints are completely different.

Tension 3: Scope mismatch

• Art.73 scope: the AI system's behaviour and its harm outcomes
• CRA Art.14 scope: the product's security properties and the exploitation of its vulnerabilities

The narrative framing for each report is different. An Art.73 report should describe what the AI system did and what harm resulted or could result. A CRA Art.14 report should describe what vulnerability exists, how it was exploited, what the product's security impact is, and what fix has been or will be deployed.

A single incident has two stories that must be told to different audiences in different ways.

Unified Pipeline Architecture

The solution is a centralized incident record that drives two separate notification workflows. The key design principle: collect data once, report twice with different formatting.

┌─────────────────────────────────────────────────────────────────┐
│                    INCIDENT DETECTION LAYER                      │
│  (model monitoring, anomaly detection, vulnerability scanner,   │
│   SIEM, user abuse reports, pentest findings)                   │
└──────────────────────────┬──────────────────────────────────────┘
                           │
                    ┌──────▼──────┐
                    │  INCIDENT   │
                    │  CLASSIFIER │
                    └──────┬──────┘
                           │
           ┌───────────────┼───────────────┐
           │               │               │
    ┌──────▼──────┐ ┌──────▼──────┐ ┌──────▼──────┐
    │  Art.73     │ │  CRA Art.14 │ │  BOTH        │
    │  Only       │ │  Only       │ │  (dual)      │
    └──────┬──────┘ └──────┬──────┘ └──────┬──────┘
           │               │               │
    ┌──────▼──────┐ ┌──────▼──────┐ ┌──────▼──────┐
    │  AI Act     │ │  CRA        │ │  AI Act     │
    │  Workflow   │ │  Workflow   │ │  Workflow   │
    │  15/10/2d   │ │  24h/72h/   │ │  +          │
    │  → NCA      │ │  14d/1m     │ │  CRA        │
    └─────────────┘ │  → ENISA+  │ │  Workflow   │
                    │  CSIRT      │ └─────────────┘
                    └─────────────┘
                           │
                    ┌──────▼──────┐
                    │  UNIFIED    │
                    │  INCIDENT   │
                    │  RECORD     │
                    │  (shared    │
                    │  evidence   │
                    │  base)      │
                    └─────────────┘

Core Data Model

The central incident record must capture fields needed by both regimes:

from dataclasses import dataclass, field
from datetime import datetime
from enum import Enum
from typing import Optional, List

class IncidentSeverity(Enum):
    CRITICAL_INFRA = "critical_infrastructure"  # Art.73(3): 2-day
    DEATH_INJURY = "death_or_serious_injury"     # Art.73(4): 10-day
    STANDARD_SERIOUS = "standard_serious"        # Art.73(2): 15-day
    PROPERTY_DAMAGE = "property_damage"
    RIGHTS_VIOLATION = "rights_violation"

class CRAIncidentType(Enum):
    ACTIVELY_EXPLOITED_VULNERABILITY = "exploited_vulnerability"  # 24h/72h/14d
    SEVERE_INCIDENT = "severe_incident"                           # 24h/72h/1m

@dataclass
class UnifiedIncidentRecord:
    # Identity
    incident_id: str
    discovered_at: datetime  # T+0: the clock starts here
    
    # AI Act Art.73 fields
    ai_act_applies: bool = False
    ai_act_severity: Optional[IncidentSeverity] = None
    ai_system_id: str = ""           # EU database registration number
    ai_malfunction_description: str = ""
    harm_occurred: bool = False
    harm_type: str = ""              # death, injury, property, rights, infra
    affected_member_states: List[str] = field(default_factory=list)
    
    # CRA Art.14 fields
    cra_applies: bool = False
    cra_incident_type: Optional[CRAIncidentType] = None
    cve_id: Optional[str] = None
    vulnerability_description: str = ""
    affected_components: List[str] = field(default_factory=list)
    fix_available: bool = False
    fix_available_at: Optional[datetime] = None
    
    # Shared evidence
    root_cause: str = ""
    corrective_measures: List[str] = field(default_factory=list)
    evidence_artifacts: List[str] = field(default_factory=list)  # s3 URIs, etc.
    
    # Deadline tracking
    art73_deadline: Optional[datetime] = None
    cra_early_warning_deadline: Optional[datetime] = None
    cra_full_notification_deadline: Optional[datetime] = None
    cra_final_report_deadline: Optional[datetime] = None
    
    # Status
    art73_notified: bool = False
    cra_early_warning_sent: bool = False
    cra_full_notification_sent: bool = False
    cra_final_report_sent: bool = False

Classifier Logic

from datetime import timedelta

def classify_incident(record: UnifiedIncidentRecord) -> UnifiedIncidentRecord:
    """
    Apply Art.73 and CRA Art.14 classification rules.
    Sets deadlines from discovered_at.
    """
    t0 = record.discovered_at
    
    # Art.73 classification
    if record.ai_act_applies and record.ai_act_severity:
        sev = record.ai_act_severity
        if sev == IncidentSeverity.CRITICAL_INFRA:
            record.art73_deadline = t0 + timedelta(days=2)
        elif sev == IncidentSeverity.DEATH_INJURY:
            record.art73_deadline = t0 + timedelta(days=10)
        else:  # all other serious incidents
            record.art73_deadline = t0 + timedelta(days=15)
    
    # CRA Art.14 classification
    if record.cra_applies and record.cra_incident_type:
        record.cra_early_warning_deadline = t0 + timedelta(hours=24)
        record.cra_full_notification_deadline = t0 + timedelta(hours=72)
        
        if record.cra_incident_type == CRAIncidentType.ACTIVELY_EXPLOITED_VULNERABILITY:
            # 14 days after fix/mitigation is available — not from T+0
            # Updated when fix_available_at is set
            if record.fix_available_at:
                record.cra_final_report_deadline = (
                    record.fix_available_at + timedelta(days=14)
                )
        else:  # SEVERE_INCIDENT
            # 1 month after the 72h full notification
            if record.cra_full_notification_deadline:
                record.cra_final_report_deadline = (
                    record.cra_full_notification_deadline + timedelta(days=30)
                )
    
    return record

Deadline Monitor

A simple cron-based monitor checks all open incidents and triggers alerts before deadlines expire:

import logging
from datetime import datetime, timedelta

ALERT_LEAD_HOURS = 4  # Alert 4 hours before deadline

def check_deadlines(incidents: List[UnifiedIncidentRecord]) -> List[str]:
    """Returns list of alerts for upcoming or missed deadlines."""
    alerts = []
    now = datetime.utcnow()
    
    for inc in incidents:
        checks = [
            (inc.art73_deadline, inc.art73_notified, "Art.73 report", 
             f"MSA in {', '.join(inc.affected_member_states)}"),
            (inc.cra_early_warning_deadline, inc.cra_early_warning_sent,
             "CRA Art.14 early warning", "ENISA + CSIRT via Art.16 platform"),
            (inc.cra_full_notification_deadline, inc.cra_full_notification_sent,
             "CRA Art.14 full notification", "ENISA + CSIRT via Art.16 platform"),
            (inc.cra_final_report_deadline, inc.cra_final_report_sent,
             "CRA Art.14 final report", "ENISA + CSIRT via Art.16 platform"),
        ]
        
        for deadline, sent, label, recipient in checks:
            if deadline is None or sent:
                continue
            
            time_remaining = deadline - now
            
            if time_remaining < timedelta(0):
                alerts.append(
                    f"⛔ MISSED: {inc.incident_id} — {label} → {recipient} "
                    f"(was due {abs(time_remaining)} ago)"
                )
            elif time_remaining < timedelta(hours=ALERT_LEAD_HOURS):
                alerts.append(
                    f"⚠️ URGENT: {inc.incident_id} — {label} → {recipient} "
                    f"due in {time_remaining} ({deadline.isoformat()})"
                )
    
    return alerts

Report Content: What Goes in Each Notification

Art.73 Report Content

Your Art.73 notification to the national market surveillance authority should cover:

1. Product identification: EU database registration number of the AI system (Art.51 registry), CE marking if applicable, provider name and contact
2. Incident description: What malfunction or performance defect occurred, when it was discovered, what the AI system did or failed to do
3. Harm description: What harm occurred or is reasonably expected (death, injury, property damage, fundamental rights violation, critical infrastructure disruption)
4. Immediate measures: What steps you took to stop or mitigate the incident
5. Affected population: Approximate number of affected users, geography (which Member States)
6. Root cause status: Preliminary root cause if known; "investigation ongoing" is acceptable for initial filings

Keep a copy of every submission. Art.73 requires you to follow up with a final report when the root cause is established and corrective action is complete.

CRA Art.14 Report Content

Your CRA Art.14 notification via the Art.16 platform requires:

For actively exploited vulnerabilities:

• Product name, version, SBOM reference
• CVE identifier (or "CVE requested" if not yet assigned)
• Vulnerability description: type (buffer overflow, injection, authentication bypass, etc.), component affected, exploitation mechanism
• Evidence of active exploitation: threat intelligence source, observed IOCs
• Impact on product security: confidentiality, integrity, availability
• Status of patch/mitigation: deployed, in progress, planned ETA

For severe incidents:

• Incident timeline: first detection, exploitation window, containment
• Technical description: attack vector, what was accessed or corrupted
• User impact: number of users affected, severity of impact on product security
• Countermeasures deployed
• Vulnerability status: whether an underlying vulnerability was identified

The dual-narrative challenge is clear: for a dual-trigger incident, you are writing two different reports about the same event. The Art.73 report centers the harm to people or infrastructure. The CRA Art.14 report centers the attack on the product's security. Both are factually accurate accounts of the same incident told through different regulatory lenses.

Infrastructure Consideration: Where the Pipeline Lives

The unified incident reporting pipeline processes security-sensitive data: technical details of vulnerabilities, exploit indicators, harm descriptions. The question of where this infrastructure runs is not trivial.

If the pipeline's backend is hosted in a jurisdiction subject to foreign-government compelled-disclosure laws (US CLOUD Act, UK Investigatory Powers Act), regulatory authorities and legal counsel in EU proceedings may ask whether the incident data was at risk of non-EU government access before the reports reached EU authorities.

This is not a hypothetical. The NIS2 Art.23 reporting regime and CRA Art.14 both presuppose that incident reports flow from the operator to EU authorities. A third-country government with compelled-access rights to the infrastructure could potentially receive the incident data before the EU authority does — creating a regulatory and political awkwardness, particularly for incidents involving critical infrastructure or fundamental rights violations.

EU-jurisdiction infrastructure removes this exposure: the incident record, the deadline tracker, the notification queue, and the evidence store all sit in data centres where EU law governs access. No US CLOUD Act, no UK IPA — the incident data's jurisdictional path is clean from detection to report submission.

When the Six-Week Window Opens

Between August 2, 2026 (AI Act Art.73 applies) and September 11, 2026 (CRA Art.14 applies), dual-compliance products face a six-week window where the Art.73 obligation is live but the CRA Art.14 duty is not yet in effect.

This creates a practical planning requirement:

• Before August 2: Your Art.73 notification process must be operational. The classifier, the deadlines, the MSA contacts for each Member State you operate in.
• Between August 2 and September 11: If a dual-trigger incident occurs, you only have to file under Art.73. Take the CRA Art.14 classification data anyway — you will need it when the obligation kicks in.
• After September 11: Both pipelines go live simultaneously. The full dual-report architecture is required.

Build the unified pipeline before August. Run both classification paths even during the six-week window so that the CRA Art.14 workflow is tested and ready before its application date.

Testing Your Pipeline Before Go-Live

A unified incident reporting pipeline that has never been exercised before a real incident is a liability, not an asset. Consider the following test programme:

Tabletop exercise (June–July 2026):
Simulate three scenario types: (a) pure Art.73 incident (model drift causing AI harm, no security exploit), (b) pure CRA Art.14 incident (exploited vulnerability, no AI harm), (c) dual-trigger incident (exploited vulnerability causing AI harm). Walk through the classification, deadline calculation, and draft notification for each. Identify which team owns each step.

Dry-run notification (August 2026):
Submit a test notification to your Art.73 channel. Many EU Member States are establishing test or notification portals — check with the national NCA for your primary market. Confirm you can reach the MSA before a real incident forces you to figure it out under time pressure.

CRA Art.14 platform registration (by September 2026):
Register your organisation with ENISA's Art.16 platform before September 11. Do not attempt first registration under deadline pressure.

Deadline monitor alert test:
Inject a synthetic incident with T+0 set to 20 hours ago and verify that the deadline monitor fires alerts for the upcoming CRA early-warning deadline. Check that the Art.73 deadline is calculated correctly for each severity tier.

Checklist: Dual Incident Reporting Readiness

Architecture:

• Single incident record model covers all fields for both Art.73 and CRA Art.14
• Classifier logic correctly identifies Art.73-only, CRA-only, and dual-trigger incidents
• Deadline calculator uses calendar days (not working days) for Art.73 and hours for CRA Art.14
• Deadline monitor runs at least every 30 minutes on open incidents

Notifications:

• Art.73 channel: list of national MSA contacts for each Member State you operate in
• CRA Art.14 channel: ENISA Art.16 platform registration complete (by September 2026)
• Report templates for both regimes: each drafts the incident from the correct regulatory angle

Process:

• Clear ownership: who declares an incident, who classifies it, who drafts which report
• Escalation path for incidents discovered outside business hours (2-day and 24-hour deadlines do not wait for Monday morning)
• Evidence preservation: artifacts stored in EU-jurisdiction storage before reports are submitted

Testing:

• Tabletop exercises for all three scenario types completed before August 2, 2026
• Art.73 test notification submitted to primary-market NCA
• ENISA Art.16 platform test submission completed before September 11, 2026

Six-week transition:

• Art.73 pipeline operational by August 2, 2026
• CRA Art.14 pipeline tested and ready by September 11, 2026

What Comes Next in This Series

Post 4 will cover the combined monitoring stack: how to implement Art.72 post-market monitoring (continuous AI performance tracking for Art.73 detection) alongside CRA vulnerability disclosure obligations (continuous component scanning, coordinated disclosure workflows). The same infrastructure that feeds your Art.73 incident classifier also feeds your CRA Annex I Part II vulnerability-handling process.

Post 5 will be the dual-compliance developer checklist — a single audit checklist covering all obligations from both regimes for a product that falls under both.

Previous posts in this series:

• Post 1: When Your AI System Is Also a CRA Cyber Product — Who falls under both regimes
• Post 2: Art.15 vs CRA Annex I Cybersecurity Requirements Overlap — Where the security requirements converge and diverge