A single AI malfunction can start several statutory reporting clocks at once, and most incident response plans model only one of them. Article 73 of the EU AI Act, Article 14 of the Cyber Resilience Act, Article 23 of NIS2 and Article 33 of the GDPR each define their trigger differently, name different recipients and run at different speeds. The analysis below maps those triggers into an AI incident response plan and sets out a decision rule for the conflict that Article 73(6) of the AI Act creates between containment and evidence preservation.
An AI incident response plan that holds up under EU law does four things. It tests every event against the definition of serious incident in Article 3(49), identifies which role holds each reporting duty, starts every applicable clock at awareness, and preserves system state until the competent authority has been informed where Article 73 may apply. Each element is built from the legal text in the sections that follow.
Article 73 Application Dates: Two Readings and One Planning Assumption
Regulation (EU) 2026/1744, the Digital Omnibus on AI (published in the Official Journal on 24 July 2026), amended Article 113 of the AI Act. The general date of application remains 2 August 2026. Under the amended text of Article 113, Chapter III, Sections 1, 2 and 3, apart from Article 6(5), apply from 2 December 2027 for systems classified as high-risk under Article 6(2) and Annex III, and from 2 August 2028 for systems classified under Article 6(1) and Annex I.
Article 73, the serious-incident reporting provision, sits in Chapter IX, Section 2, not in Chapter III. The amended Article 113 gives Chapter IX no separate date. The provisions that moved are the ones that hold the high-risk classification rules and the provider and deployer obligations.
That structure supports two readings, and published commentary reaches both. Under the first, Article 73 applies from the general date of 2 August 2026 because no exception reaches it. Under the second, Article 73(1) addresses providers of high-risk AI systems, the rules that classify a system as high-risk do not apply until December 2027 or August 2028, and the reporting duty has no addressees before those dates. Both are editorial analysis of the text, not an official interpretation, and the Commission materials located for this analysis do not resolve the question.
Building to the Article 73 clocks now produces a plan that is valid under either reading. It also serves the other regimes compared below, several of which already apply.
Article 73(7) directs the Commission to issue dedicated guidance by 2 August 2025. The Commission’s published materials on Article 73 consist of draft guidance and a draft reporting template opened for consultation on 26 September 2025, and the consultation page presents both as drafts.
Two further points affect who reports to whom. Article 55(1)(c) obliges providers of general-purpose AI models with systemic risk to keep track of, document and report serious incidents without undue delay to the AI Office and, as appropriate, to national competent authorities; the text is on the Article 55 page of the AI Act Service Desk. Chapter V applies from 2 August 2025 under Article 113(b), while Article 101, on fines for providers of general-purpose AI models, is excluded from that date and follows the general date of 2 August 2026. Separately, Regulation (EU) 2026/1744 provides that providers of high-risk AI systems within the AI Office’s competence report serious incidents to the AI Office instead of a national authority, with Article 73(2) to (9) applying mutatis mutandis.
What Counts as a Serious Incident Under Article 3(49)
Article 3(49) defines a serious incident as an incident or malfunctioning of an AI system that directly or indirectly leads to one of four outcomes:
- the death of a person, or serious harm to a person’s health;
- a serious and irreversible disruption of the management or operation of critical infrastructure;
- the infringement of obligations under Union law intended to protect fundamental rights;
- serious harm to property or the environment.
Two related definitions drive the shortest clock. Article 3(62) takes its meaning of critical infrastructure from Article 2, point (4), of Directive (EU) 2022/2557. Article 3(61) defines a widespread infringement by reference to harm to the collective interests of individuals in at least two Member States other than those where the act originated or the operator is established, or concurrent harm with common features, committed by the same operator, in at least three Member States.
The definition is outcome-based. A degraded model metric, a biased output or an unsafe response matters to Article 73 only when it directly or indirectly leads to one of the four listed outcomes. Internal severity tiers that rank incidents by technical symptom therefore need a second axis that asks which Article 3(49) outcome, if any, the event produced or may have produced. That design point is analysis, not a legal requirement.
Article 73(9) and (10) narrow the duty in two situations. For Annex III systems whose providers are subject to Union reporting obligations equivalent to those in the AI Act, notification is limited to the fundamental-rights category in Article 3(49)(c). For high-risk systems that are safety components of devices, or are devices, covered by Regulations (EU) 2017/745 and (EU) 2017/746, notification is limited to the same category and goes to the national competent authority chosen by the Member State where the incident occurred.
Reporting Clocks Across Four Regimes
The table sets the AI Act duties beside the three other EU instruments most likely to fire on the same facts. The AI Act rows are taken from the text of Article 73 and the text of Article 26.
| Instrument and duty holder | Trigger | Deadline | Recipient and application |
|---|---|---|---|
| AI Act Article 73: providers of high-risk AI systems | Serious incident under Article 3(49) | Immediately after a causal link or its reasonable likelihood is established, and no later than 15 days from awareness; two days for a widespread infringement or an Article 3(49)(b) incident; 10 days for a death | Market surveillance authority of the Member State where the incident occurred; AI Office for providers within its competence. Application: see the first section |
| AI Act Article 26(5): deployers of high-risk AI systems | Serious incident identified; or reason to consider that use may present a risk within Article 79(1) | Immediately inform the provider first, then the importer or distributor and the market surveillance authorities; without undue delay and with suspension of use for an Article 79(1) risk | Provider, then authorities; Article 73 applies mutatis mutandis if the provider cannot be reached. Chapter III, Section 3: from 2 December 2027 (Annex III) or 2 August 2028 (Annex I) |
| AI Act Article 55(1)(c): providers of general-purpose AI models with systemic risk | Serious incidents and possible corrective measures | Without undue delay | AI Office and, as appropriate, national competent authorities. Chapter V: from 2 August 2025 |
| Cyber Resilience Act Article 14: manufacturers of products with digital elements | Actively exploited vulnerability; severe incident affecting product security | Early warning within 24 hours; notification within 72 hours; for an exploited vulnerability, a final report within 14 days after a corrective or mitigating measure is available | Single reporting platform under the Regulation. Article 14: from 11 September 2026, including products already on the market |
| NIS2 Article 23: essential and important entities | Significant incident | Early warning within 24 hours; notification within 72 hours; final report no later than one month after the notification | CSIRT or competent authority. Binding through national transposition of the Directive |
| GDPR Article 33: controllers (processors notify the controller) | Personal data breach likely to result in a risk to rights and freedoms | Without undue delay and, where feasible, within 72 hours of awareness; reasons for any later notification | Competent supervisory authority. Applies |
The triggers differ in kind. Article 73 turns on outcome and on a causal link that may be only reasonably likely, the CRA on product security, NIS2 on significance for the entity, and the GDPR on risk from a personal data breach. One event, such as an AI system that exposes personal data while producing a fundamental-rights harm, can satisfy several of these tests together.
Article 73(5) allows an incomplete initial report followed by a complete one, which parallels the phased notification in GDPR Article 33(4) and the staged sequence in NIS2 Article 23(4). A single incident record can therefore feed several filings, provided it captures awareness times and the facts each regime asks for. As a design rule (analysis, not law), the shortest applicable clock sets the internal escalation deadline for the whole event.
Where an AI-enabled product is also a product with digital elements, Article 14 of the CRA sits alongside Article 73 and runs from the manufacturer’s awareness, so the two regimes should share the same awareness timestamp in the incident record.
Containment and Evidence Preservation Under Article 73(6)
What the provision restricts
After a report is made, Article 73(6) requires the provider to investigate without delay, including a risk assessment of the incident and corrective action, and to cooperate with the competent authorities. The second subparagraph adds a limit: the provider shall not perform any investigation that involves altering the AI system concerned “in a way which may affect any subsequent evaluation of the causes of the incident” before informing the competent authorities of that action.
The text addresses investigations. Whether urgent mitigation falls inside the same restriction is an interpretive question that the statute does not answer. The decision rule below adopts the conservative position and is analysis, not an official reading.
A decision rule for containment actions
Class A, state-preserving actions. Examples include isolating traffic, disabling an endpoint, revoking access, routing decisions to human review, placing logs on hold and taking a snapshot of the model version and configuration. These can proceed immediately and are recorded with a timestamp.
Class B, system-altering actions. Examples include changing model parameters, retraining or fine-tuning, replacing the model version, modifying guardrail or prompt configuration and changing a data pipeline. Where Article 73 may apply, Class B actions wait until a preserved copy exists and the notification owner has recorded either that the authority has been informed or the reason for proceeding.
The rule connects to the deployer’s duties. Under Article 26(5), a deployer with reason to consider that use may present a risk within Article 79(1) must suspend use of the system. Suspension implemented at the access or routing layer is state-preserving, whereas suspension implemented by changing the model or its configuration is not. Article 26(6) requires deployers to keep automatically generated logs under their control for a period appropriate to the intended purpose and of at least six months, so a suspension procedure should place those logs on hold at the moment of suspension.
Evidence to preserve at suspension
The following list is governance practice, not a legal requirement, and follows from the investigation and cooperation duties in Article 73(6):
- the model version, configuration and deployment parameters in force at the time of the event;
- automatically generated logs for the affected period, including inputs and outputs for the affected sessions or decisions;
- records of human oversight actions and overrides;
- the timestamps of occurrence, detection and awareness for each actor;
- a record of every containment action, classified A or B.
Severity Tiers Mapped to Statutory Tests
The tiering below is a design proposal. It anchors internal severity to the legal tests so that escalation decisions can be traced to a provision.
| Tier | Trigger test | Regimes evaluated | Minimum internal action |
|---|---|---|---|
| Tier 1: suspected serious incident | Event that directly or indirectly led, or may have led, to an Article 3(49) outcome | Article 73, Article 26(5), Article 55(1)(c) where applicable, with GDPR, NIS2 and CRA tested in parallel | Record awareness time, activate the notification owner, apply Class A actions only until the authority is informed |
| Tier 2: link under assessment | Harmful output or malfunction with a plausible but unestablished link to an Article 3(49) outcome, or with personal data or product-security involvement | Each regime’s trigger test, including the GDPR risk assessment and the CRA tests | Time-boxed assessment, written causal-link reasoning, Class A actions, escalation to Tier 1 on any positive finding |
| Tier 3: internal incident | Degraded or harmful output with no Article 3(49) outcome on current facts | Reassessed if new facts emerge | Standard remediation, root-cause analysis, register entry |
| Tier 4: near miss | Event caught before any harm | None triggered | Register entry and review at the next risk meeting |
Roles, Authority and Provider-Deployer Hand-Offs
Three decision rights need a named holder before an incident occurs: the authority to suspend a system, the owner of the regulatory notification, and the person who assesses whether a causal link is reasonably likely. Where those rights sit depends on the organization’s AI governance operating model, whether centralized, federated or hybrid. A federated model that leaves suspension with the business unit and notification with a central function needs a documented hand-off, because Article 73(2) starts its clock at the awareness of the provider or, where applicable, the deployer.
The order of notification in Article 26(5) shapes the hand-off between roles. A deployer that has identified a serious incident informs the provider first, then the importer or distributor and the relevant market surveillance authorities, and Article 73 applies mutatis mutandis if the provider cannot be reached. A deployer plan therefore needs a verified provider contact path and a documented fallback when that path fails.
Contracts carry part of this load. Article 25(4), as amended by Regulation (EU) 2026/1744, requires the provider of a high-risk AI system and a third party that supplies an AI system, model, tool, service, component or process integrated into it to specify by written agreement the necessary information, capabilities, technical access and other assistance. The provision excludes third parties that make tools, services, processes or components other than general-purpose AI models publicly accessible under a free and open-source licence. Incident-notice terms belong in that agreement, with supplier notice periods set shorter than the statutory clock they feed. The GDPR applies the same logic to processors, which must notify the controller without undue delay under Article 33(2).
Incident Record Fields That Support Initial and Complete Reports
The field groups below are a design for the incident register. They are arranged so that an initial report under Article 73(5) can be assembled from the first group or two, and the complete report from the full record.
| Field group | Content | Supports |
|---|---|---|
| Identification | Incident ID, reporter role, system name, version, model identifier, registration reference where one exists | Initial report under Article 73(5) |
| Timeline | Occurrence, detection and awareness times for each actor | Starting the clocks in Article 73, the CRA, NIS2 and the GDPR |
| Classification | Article 3(49) limb or limbs assessed, widespread infringement assessment, written reasoning on the causal link or its reasonable likelihood | Article 73(2) to (4) deadline selection |
| Impact | Persons affected, Member States affected, infrastructure involved, personal data involved | Widespread infringement test; GDPR and NIS2 notification content |
| Containment log | Each action with timestamp and class (A or B), and whether the authority was informed before any Class B step | Article 73(6) investigation limit |
| Parallel filings | Other regimes triggered, with filing references and times | Consistency across filings made on the same facts |
| Analysis and corrective action | Root cause, risk assessment, corrective action and owner | Article 73(6) investigation; final reports under NIS2 and the CRA |
Guidance and Standards That Inform the Plan
The sources feeding an incident plan carry different weight, and the plan should record which is which. Article 73 and the other Regulation and Directive provisions above are binding law. The Commission’s draft Article 73 guidance and reporting template are drafts. The Commission’s reporting template for serious incidents involving general-purpose AI models with systemic risk, published on 4 November 2025, supports providers in demonstrating compliance with Commitment 9 of the General-Purpose AI Code of Practice, which is a voluntary instrument.
On the standards side, NIST published SP 800-61 Revision 3 in April 2025. It supersedes Revision 2 and frames incident response as a CSF 2.0 Community Profile that is incorporated throughout cybersecurity risk management activities. ISO/IEC 42001:2023 addresses nonconformity and corrective action in Clause 10.2. An incident and a nonconformity are distinct: an event becomes a nonconformity when a requirement of the management system was not fulfilled, so the incident register and the corrective-action record should be linked but kept separate. Neither standard creates a reporting duty under EU law.
Why Incident Readiness Under the AI Act Depends on Evidence Discipline
The legal text asks for speed, but the record behind each report determines whether the report holds up. Reports under Article 73 are followed by an investigation that the provider must conduct and the authority may scrutinize, and GDPR Article 33(5) requires documentation of every personal data breach, including those not notified. The record is the control.
Compliance priorities that follow from the analysis above:
- Document which reading of Article 73 application the organization adopts, and the reasoning, so the position is auditable.
- Map internal severity tiers to Article 3(49) and to the triggers in the other regimes.
- Pre-approve the Class A and Class B containment lists, with a named notification owner for Class B exceptions.
- Set provider-deployer notice terms in the written agreements contemplated by Article 25(4), shorter than the statutory clocks they feed.
- Hold logs automatically at suspension, consistent with the six-month minimum for deployers in Article 26(6).
- Rehearse a two-day scenario that combines a widespread-infringement trigger with a parallel GDPR or NIS2 filing.
The next regulatory milestones in the legal text are 2 December 2027, when Chapter III Sections 1 to 3 begin to apply for Annex III systems, and 2 August 2028 for Annex I systems. Final Commission guidance under Article 73(7) remains the open item that would settle the interpretive questions raised above.
Covering responsible AI, governance frameworks, policy, ethics, and global regulations shaping the future of artificial intelligence.