CRA Article 14 vs AI Act Article 73 incident reporting: do you file twice?

What AI Act Article 73 actually requires

Regulation (EU) 2024/1689 Article 73(1) obliges providers of high-risk AI systems placed on the Union market to report any serious incident to the market surveillance authorities of the Member States where that incident occurred. Article 3(49) defines a serious incident as an incident or malfunctioning of an AI system that directly or indirectly leads to any of: (a) the death of a person, or serious harm to a person's health; (b) a serious and irreversible disruption of the management or operation of critical infrastructure; (c) the infringement of obligations under Union law intended to protect fundamental rights; or (d) serious harm to property or the environment.

Article 73(2) sets the baseline: report immediately after the provider has established 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 15 days after the provider or, where applicable, the deployer becomes aware — taking account of severity. Article 73(3) shortens that outer bound to two days for a widespread infringement or a serious incident as defined in Article 3, point (49)(b) (critical-infrastructure disruption). Article 73(4) sets a 10-day outer bound where a death is involved, counted from awareness, once a causal relationship is established or suspected. Incomplete initial reports are allowed (Art 73(5)); investigation and corrective action follow without delay (Art 73(6)).

Article 14 stays on the product / SRP track

CRA Article 14 obliges manufacturers to notify actively exploited vulnerabilities and severe incidents having an impact on the security of the product — early warning within 24 hours of becoming aware, fuller notification within 72 hours, then the final report on its own trigger (14 days after a corrective or mitigating measure is available for an AEV under Art 14(2)(c), or within one month of the 72-hour notification for a severe incident under Art 14(4)(c)) — through ENISA's Single Reporting Platform to the coordinating CSIRT. That duty has applied from 11 September 2026 (Article 71(2)), including for in-scope products already on the market (Article 69(3)). Measure-available timing for the AEV final: corrective or mitigating measure. CSIRT routing: which CSIRT applies.

Clock overview: Article 14 reporting deadlines; awareness timing: when the 24-hour clock starts.

The clocks are not the same ladder

Article 14 runs a three-step cascade from awareness (24h / 72h / final on a separate trigger). Article 73 runs a single market-surveillance report with severity-dependent outer bounds (15 days / 2 days / 10 days) and a causal-link gate on the baseline and death limbs — not a CRA-style early-warning-plus-final chain. Sharing an internal awareness timestamp helps both processes; sharing one external filing does not. An incomplete Art 73(5) initial report still does not appear in the CRA SRP workflow, and an SRP early warning does not appear as an Article 73 notification.

What Article 12 actually does (conformity, not reporting)

CRA Article 12 and Recital 51 bridge conformity between the Cyber Resilience Act and the AI Act. For products with digital elements that are also high-risk AI systems under AI Act Article 6, the product is deemed to comply with the cybersecurity requirements in AI Act Article 15 where: Annex I Part I essential cybersecurity requirements are fulfilled; manufacturer processes meet Annex I Part II; and the AI Act Article 15 cybersecurity protection level is demonstrated in the CRA EU declaration of conformity — without prejudice to AI Act accuracy and robustness requirements. Article 12(2)–(3) then allocate which conformity-assessment procedure applies.

That is the same family of trap as EHDS Article 32(5a) or Annex III/IV class: assessment paperwork changes how you prove cybersecurity for market access. It does not rewrite Article 14. A declaration of conformity, notified-body opinion or AI regulatory sandbox participation (Article 12(4) / AI Act Article 57) is not an early warning.

The trap: “Art 73 / Art 12 covered ENISA”

Two failure modes show up in triage. First: filing Article 73 to market surveillance and assuming the 24-hour CRA early warning can wait because “AI incident reporting is already running,” or waiting for finished Annex I / Article 12 DoC evidence before opening an SRP case. Second: reading Article 12 as an Article 2-style exclusion or as a reporting merge, and skipping ENISA when an AEV or severe incident hits an in-scope AI product. Conformity presumption and SRP are different calendars; Art 73's 15-day outer bound is not a CRA holiday.

Neighbouring traps: Annex III/IV class (also Art 32 / certification — same Art 14 clocks; biometric IAM products can also be AI Act Annex III); MDR/IVDR exclusion (true CRA carve-out — and AI Act Article 73(10) has its own MDR/IVDR notification limit to Art 3(49)(c) limbs); NIS2 Article 23 (same 24h/72h/final shape as CRA, still a separate entity filing); GDPR Art 33/34; DORA Article 19; civil Product Liability Directive claims (FAQ 2.3.1 — not an SRP substitute); and standalone SaaS outside CRA versus a shipped AI product with remote data processing inside the product.

If CRA, AI Act, GDPR, NIS2 and DORA all look relevant

Run each regime's own trigger test and file to each regime's own recipient. Keep one internal timeline of what you knew and when (the evidence log), then fork the external notifications. Article 73(9)–(10) narrow AI Act serious-incident notification for some systems already covered by other Union reporting instruments (including certain MDR/IVDR cases) — those limbs do not say a CRA Article 14 SRP filing replaces Article 73 for a dual-scope high-risk AI PDE. A DORA Article 19 filing to a financial competent authority likewise does not close Article 14. Confirm any equivalent-reporting claim with counsel against the current consolidated texts.

Questions people ask

Does an AI Act Article 73 serious-incident report satisfy CRA Article 14?

No. Article 14 does not name the AI Act as an alternative route. Article 73 sends high-risk AI serious incidents to market surveillance authorities of the Member States where the incident occurred (or, where Article 75(1) applies, with AI Office involvement). Article 14 sends actively exploited vulnerabilities and severe product-security incidents to the coordinating CSIRT and ENISA via the Single Reporting Platform. Different recipients, different trigger tests, different clocks. One filing does not put the report in front of the other regime.

Are the clocks the same shape as NIS2 or CRA?

No. CRA Article 14 uses 24-hour early warning, 72-hour fuller notification, then a final report — 14 days after a corrective or mitigating measure is available for an AEV (Art 14(2)(c)), or within one month of the 72-hour notification for a severe incident (Art 14(4)(c)). AI Act Article 73 uses a severity ladder from awareness: generally not later than 15 days after the provider (or, where applicable, the deployer) becomes aware once a causal link or reasonable likelihood is established (Art 73(2)); not later than two days for a widespread infringement or an Article 3(49)(b) critical-infrastructure incident (Art 73(3)); not later than 10 days where a death is involved (Art 73(4)). Matching the word “incident” does not merge the calendars.

What does Article 3(49) treat as a serious incident?

AI Act Article 3(49) defines a serious incident as an incident or malfunctioning of an AI system that directly or indirectly leads to any of: (a) the death of a person, or serious harm to a person’s health; (b) a serious and irreversible disruption of the management or operation of critical infrastructure; (c) the infringement of obligations under Union law intended to protect fundamental rights; or (d) serious harm to property or the environment. That product-harm / fundamental-rights test is not the CRA actively-exploited-vulnerability or severe product-security-incident test.

Does CRA Article 12 mean we skip Article 14 if the product is a high-risk AI system?

No. Article 12 is a conformity bridge: when a CRA-scope product is also a high-risk AI system under AI Act Article 6, meeting CRA Annex I Parts I and II and demonstrating the AI Act Article 15 cybersecurity protection level in the CRA EU declaration of conformity lets the product be deemed to comply with those AI Act cybersecurity requirements — without prejudice to AI Act accuracy and robustness. Nothing in Article 12 rewrites Article 14, the Single Reporting Platform, or the 24-hour / 72-hour clocks.

When can the same event trigger both?

When the facts independently meet both tests. CRA Article 14 needs an actively exploited vulnerability in your product with digital elements, or a severe incident with impact on that product’s security. AI Act Article 73 needs a serious incident (Article 3(49)) involving a high-risk AI system you provide that is placed on the Union market. A security compromise of a dual-scope AI product can trip both; a product AEV with no Article 3(49) serious-incident facts may be CRA-only; a high-risk AI serious incident with no product-security AEV/severe trigger may be AI Act-only.

Our AI product is not high-risk — do we still have Article 14?

Possibly. CRA Article 14 attaches to manufacturers of in-scope products with digital elements when an AEV or severe product-security incident is met — it does not require AI Act high-risk classification. AI Act Article 73 is a high-risk provider duty. Non-high-risk AI software placed as a product can still sit in CRA Article 14 if the product tests are met, while sitting outside Article 73.

When does each duty apply on the calendar?

CRA Article 14 has applied from 11 September 2026 (Article 71(2)), including for in-scope products already on the market (Article 69(3)). AI Act Article 73 runs with the AI Act’s own application calendar for high-risk systems (see AI Act Article 113 and current Commission guidance). Do not wait for a finished Article 12 / Annex I conformity file — or for AI Act high-risk application — before running the SRP chain on an in-scope PDE that already meets an Article 14 trigger.