One AI Incident, Four Reporting Regimes, and the Carve-Outs That Decide Which Apply

On 11 September 2026 the Cyber Resilience Act starts requiring manufacturers of products with digital elements to report actively exploited vulnerabilities and severe security incidents. An early warning is due within twenty-four hours of becoming aware and a fuller notification within seventy-two, filed through a Single Reporting Platform that the European Union Agency for Cybersecurity operates. ENISA’s platform FAQ, checked on 5 September 2026, states that the platform is not yet live and is scheduled to become operational on 11 September, the same day the obligation begins. Only mandatory reporting under Articles 14 and 24 will be accepted at launch; voluntary reporting under Article 15 will not be available.

Three other European regimes can require notification of the same incident. The EU AI Act requires serious incident reporting under Article 73 on a fifteen, ten or two day deadline. NIS2 requires a twenty-four hour early warning and a seventy-two hour notification to a national computer security incident response team. The GDPR requires notification of a personal data breach within seventy-two hours to a data protection authority.

Here is the sentence for your CISO. The AI Act already limits its own reporting duty where another Union instrument imposes an equivalent one, so the interesting question for an incident response runbook is not how many regimes exist but which of them the Act pre-empts and which it leaves stacked. Most compliance summaries get this backwards, because the carve-outs are in paragraphs 9 and 10 of Article 73 and almost nobody reads that far.

The four obligations, precisely

EU AI Act, Article 73

Applies to providers of high-risk AI systems. The trigger is a serious incident. Article 3(49) defines it as an incident or malfunction directly or indirectly resulting in (a) the death of a person or serious harm to a person’s health, (b) serious and irreversible disruption to the management or operation of critical infrastructure, (c) infringement of obligations under Union law intended to protect fundamental rights, or (d) serious harm to property or the environment.

Article 73(2) requires the report immediately after the provider establishes a causal link between the AI system and the serious incident, or the reasonable likelihood of such a link, and in any event not later than fifteen days after becoming aware. The period must take account of severity. Ten days applies where a death may have been caused. Two days applies to a widespread infringement or a serious and irreversible disruption of critical infrastructure. Reporting goes to the market surveillance authority of the Member State where the incident occurred, which must take measures within seven days under Article 73(8).

Article 73 belongs to the high-risk regime, which the Digital Omnibus, Regulation (EU) 2026/1744, deferred to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems. The obligation is law now and applies from those dates.

Cyber Resilience Act, Article 14

Applies to manufacturers of products with digital elements placed on the EU market, which includes software. The trigger is an actively exploited vulnerability or a severe incident affecting product security. Twenty-four hours for the early warning, seventy-two hours for the notification, and then two different final report deadlines: for an exploited vulnerability, no later than fourteen days after a corrective or mitigating measure becomes available, and for a severe incident, one month after the seventy-two hour notification. Reports go simultaneously to the designated coordinating CSIRT and to ENISA.

The fourteen-day trigger deserves attention from anyone building a runbook, because it is the one deadline in this set anchored to an event the manufacturer partly controls.

Two features separate the CRA from the others. The obligation covers products placed on the market before the CRA applied in full, not only new releases. It also continues after a product’s support period ends, which the vulnerability handling duties do not.

NIS2

Applies to essential and important entities in the listed sectors. Twenty-four hour early warning, seventy-two hour incident notification, one month final report, to the national CSIRT or competent authority. NIS2 is a directive, so national transpositions differ in wording, reporting fields and occasionally timelines. An organisation operating in more than one Member State faces a different version of the same obligation in each.

GDPR, Article 33

Applies where the incident constitutes a personal data breach. Seventy-two hours from becoming aware of the breach, to the supervisory authority, with notification to affected individuals under Article 34 where the risk to their rights is high.

What the Act pre-empts

Article 73 contains two carve-outs that most summaries omit.

Article 73(9) provides that for high-risk AI systems referred to in Annex III placed on the market by providers subject to Union legislative instruments laying down reporting obligations equivalent to those in the Regulation, notification of serious incidents is limited to those referred to in Article 3(49)(c). Article 3(49)(c) is the fundamental-rights limb: infringement of obligations under Union law intended to protect fundamental rights.

Article 73(10) provides that for high-risk AI systems which are safety components of devices, or are themselves devices, covered by the Medical Device Regulation 2017/745 and the In Vitro Diagnostic Regulation 2017/746, notification is likewise limited to Article 3(49)(c) incidents. It goes to a national competent authority chosen for that purpose by the Member State where the incident occurred.

Both carve-outs are in the Regulation itself. Draft Commission guidance published on 26 September 2025, with consultation closing on 7 November 2025, interprets how Article 73 interacts with other reporting duties and proposes handling for entities covered by NIS2. The carve-outs apply whether or not that guidance is ever adopted. As of 5 September 2026 I found no final adopted version of that guidance.

Working an example

A medical device manufacturer sells an AI-enabled diagnostic tool into hospitals across four Member States. The device uses a model whose inference API is reachable from the hospital network. An attacker exploits an authentication flaw, obtains query access, and runs a model inversion attack that recovers attributes of patients in the training data. The manipulation also degrades diagnostic accuracy for a subset of cases before anyone notices.

The instinct is to count four regimes. Count them properly instead.

The device is a product with digital elements and the vulnerability is actively exploited, so CRA Article 14 applies at twenty-four hours. The manufacturer is likely an important or essential entity in the health sector, so NIS2 applies at twenty-four hours to a different recipient. Training data attributes about identifiable patients were recovered, so GDPR Article 33 applies at seventy-two hours to a third authority.

The AI Act is where the instinct fails. A diagnostic medical device goes through the Annex I route, which applies from 2 August 2028 and not from December 2027. When it does apply, Article 73(10) limits notification for MDR and IVDR devices to Article 3(49)(c) fundamental-rights incidents. Degraded diagnostic accuracy harming patients is an Article 3(49)(a) incident, reportable under the Medical Device Regulation’s own vigilance system. It does not generate a separate AI Act serious incident report.

Change one fact and the answer changes. If the same attack recovered patient data in a way that infringed a Union fundamental-rights obligation, Article 3(49)(c) is engaged and the AI Act notification arrives after all, to a nationally designated authority rather than to the ordinary market surveillance authority.

The overlap is conditional on which limb of Article 3(49) the incident engages, and that determination has to be made in the first hours.

Where the deadlines genuinely collide

Three collisions survive the carve-outs.

Article 73(9) covers Annex III systems facing equivalent Union reporting duties. It says nothing about the CRA or the GDPR, so a high-risk AI system inside a product with digital elements, processing personal data, still faces three separate notifications on two different deadlines to three authorities.

The regimes define awareness differently. Article 73(2) ties the AI Act report to establishing a causal link between the AI system and the incident, or the reasonable likelihood of one. Commission guidance C(2026) 5252 and Section 5.1 of the Commission’s FAQs on CRA implementation tie awareness to a reasonable degree of certainty, reached after a prompt initial assessment, that a vulnerability contained in the product is being actively exploited or that a severe incident has occurred and has compromised the security of the product. Establishing causation for an AI failure takes longer than establishing that exploitation occurred, so the deadlines begin at different moments for one event.

NIS2 and the GDPR both run seventy-two hours and both start on determinations that are not the same. Becoming aware of a security incident and becoming aware of a personal data breach are separate findings about the same facts.

What belongs in the runbook

Four things, before an incident tests them.

Map every AI system to its regimes in advance, and record for each one which limb of Article 3(49) a plausible failure would engage. That last column is what decides whether the AI Act notification exists at all. It is a table and it takes an afternoon. It cannot be produced during an incident.

Assign the awareness determination to a named role. Each regime begins its deadline on a different finding. Someone has to make each determination and record the time. In most organisations nobody currently owns this.

Prepare for CRA filing without pre-registering. ENISA’s guidance directs manufacturers to register and initiate validation when they need to submit a notification, so pre-registration is not the intended workflow. What can be done ahead is identifying the coordinating CSIRT for your main establishment, assigning the filing role, setting up the EU Login accounts that the platform requires, and running a dry submission if ENISA offers one.

Draft the notifications now. Twenty-four hour early warnings have limited content requirements and template well. The organisations that meet these deadlines will be the ones that wrote the templates in advance.

The direction this is going

Four regimes were drafted against different risks: individual rights for the GDPR, product vulnerability disclosure for the CRA, operational continuity for NIS2, and safety and fundamental rights for the AI Act. The AI Act’s drafters anticipated part of the overlap and wrote Article 73(9) and (10) to handle it. They did not anticipate the CRA reporting duty, which was agreed later.

A full deconfliction would need either a common reporting entry point across regimes or aligned definitions of awareness and severity. The Commission has proposed neither.

I would treat 11 September 2026 as the date this stops being theoretical. The CRA obligation reaches software already on the market, so most organisations shipping anything with digital elements into the EU acquire a twenty-four hour reporting duty that week, whether or not any AI Act obligation applies to them yet.

The other four provisions of the AI Act that touch a security function are covered in the EU AI Act for security teams.