EU AI Act 2026: delay, new deadlines & article 73 reporting
On July 27, 2026, the Digital Omnibus on AI, Regulation (EU) 2026/1744, entered into force and rewrote the EU AI Act's timeline. The high-risk obligations that were due to apply on August 2, 2026, including Article 73 serious-incident reporting, now apply from December 2, 2027 for standalone high-risk systems (Annex III) and August 2, 2028 for AI embedded in regulated products (Annex I).
Not everything moved. Since August 2, 2026, Article 50 transparency obligations apply and the Commission can fine providers of general-purpose AI models, and the GPAI obligations in force since August 2025, including serious-incident reporting for systemic-risk models, stay in force.
Deferred, not cancelled. The extra 16 months are the window to build serious-incident reporting into your operations, not a reason to shelve it. Here is what changed, what didn't, and what your incident process needs to be able to do.
What the Digital Omnibus changed
The European Commission proposed the Digital Omnibus on AI on November 19, 2025, after it became clear the compliance ecosystem would not be ready for the original August 2026 deadline: harmonised standards from CEN-CENELEC were running late, conformity-assessment bodies weren't designated, and many member states had not stood up their market surveillance authorities. Parliament and Council reached political agreement on May 7, 2026, formally adopted the text in June, and published it in the Official Journal on July 24, 2026. It entered into force three days later, six days before the original deadline.
One detail matters for planning: the new dates are fixed, not conditional. The Commission's original proposal tied the delay to the readiness of standards and guidance, with 2027/2028 as backstops. The co-legislators replaced that with hard dates. Dr. Nils Rauer of Pinsent Masons called the agreement "a pragmatic step towards greater legal certainty", there is no scenario where the obligations land earlier, and no realistic one where they slip again.
The EU AI Act timeline, as it stands now
- Feb 2, 2025 (in effect): Prohibited AI practices (Article 5); AI literacy duty (Article 4)
- Aug 2, 2025 (in effect): Obligations for general-purpose AI (GPAI) model providers, incl. systemic-risk duties (Chapter V)
- Aug 2, 2026 (in effect): Article 50 transparency obligations; Commission fining powers over GPAI providers (Article 101)
- Dec 2, 2027: High-risk obligations for standalone Annex III systems, incl. Article 12 logging and Article 73 serious-incident reporting
- Aug 2, 2028: High-risk obligations for AI embedded in regulated products (Annex I)
What applies in 2026 regardless of the delay
If you build or deploy AI systems in the EU, two things are live now:
Transparency (Article 50), since August 2, 2026. Users must be told when they are interacting with an AI system, and AI-generated or manipulated content must be labeled and machine-detectable. Not an incident duty, but the first AI Act obligation most engineering teams will actually be audited on.
GPAI enforcement, since August 2, 2026. The transparency, documentation, and copyright obligations for GPAI providers have applied since August 2025, what is new is the Commission's power to fine non-compliance, at up to 3% of global annual turnover or €15 million, whichever is higher. If you provide a GPAI model with systemic risk, serious-incident tracking and reporting is already expected under Article 55(1)(c), with the Code of Practice setting deadlines that mirror Article 73, plus a 5-day window for serious cybersecurity breaches.
Article 73: what serious-incident reporting actually requires
Article 73 is the AI Act's core incident-response obligation, and it is worth getting the numbers right, it is frequently misreported as a GDPR-style 72-hour rule. The actual windows for providers of high-risk AI systems:
- Immediately after establishing a causal link between the AI system and the incident, or the reasonable likelihood of one, and no later than 15 days after becoming aware of a serious incident.
- No later than 2 days for a widespread infringement or a serious and irreversible disruption of critical infrastructure.
- No later than 10 days in the event of a person's death.
A "serious incident" means an incident or malfunction that directly or indirectly leads to death or serious harm to health, a serious and irreversible disruption of critical infrastructure, an infringement of fundamental-rights obligations, or serious harm to property or the environment.
Three operational details engineers should note:
An incomplete initial report is explicitly allowed, followed by a complete one. The regulation expects you to notify while the investigation is still running, which means your reporting workflow can't depend on the postmortem being finished.
You must investigate, assess risk, and take corrective action, and you may not alter the AI system in a way that could affect the evaluation of the incident's causes before informing the authorities. Your evidence trail has to survive the response.
Deployers are in the loop too. Under Article 26(5), a deployer that identifies a serious incident must immediately inform the provider (then the importer/distributor and market surveillance authorities). Provider-deployer communication paths are part of compliance, not a nice-to-have.
The Commission has published draft guidance and a standard reporting template for Article 73; final versions are still pending. And the Act itself already de-duplicates: where a high-risk system falls under a sector regime with equivalent reporting duties, critical infrastructure under NIS2, medical devices under the MDR, Article 73(9)–(10) limit AI Act reporting to fundamental-rights incidents, with everything else routed through the sector rules. Translation: one well-built incident process serves multiple regulators.
Why build now, not in November 2027
The case for using the deferral rather than enjoying it:
The dates are now certain. Fixed deadlines removed the ambiguity that justified waiting.
The duties are process-heavy, not paperwork-heavy. Tamper-evident logging, cross-functional notification, evidence preservation, and reporting-while-investigating are operational muscles. Teams that add them late in 2027 will be scrambling to catch up; teams that run them now get a year of practice.
The same process already pays off elsewhere. NIS2's 24-hour early warning and 72-hour notification, GDPR's 72-hour breach window, and DORA's incident reporting all run on their own clocks, none of them was delayed. A single incident workflow with automatic timelines, role-based escalation, and audit-ready postmortems satisfies several regimes with one evidence set.
Article 73 readiness checklist
What your incident process has to be able to do before December 2027 and what pays off now under NIS2, DORA, and GDPR:
- Classify at intake. Triage asks whether an incident could meet the Article 3(49) definition of "serious", so the AI Act clock is recognised on day one, not in the postmortem.
- Timestamp awareness. The 2/10/15-day windows run from the moment you become aware. Capture it automatically, not from memory.
- Preserve evidence before you fix. No changes to the AI system that could affect causal analysis until authorities are informed (Article 73(6)). Logs, model versions, and inputs must survive the response.
- Report while investigating. An initial, incomplete report is allowed. The workflow can't wait for the root cause.
- Wire the deployer → provider path. Deployers must inform providers immediately (Article 26(5)). Agree the channel and template in advance.
- Notify legal and comms in parallel with engineering. The person who files the report is rarely the person fixing the system.
- Map the regime per system. Know which clock applies: AI Act, NIS2, DORA, GDPR or whether a sector rule absorbs the AI Act duty under Article 73(9)–(10).
- Export the timeline. Every notification is a document. Produce it from the record, not from recollection.
How ilert maps to the AI Act's incident duties
ilert doesn't make you AI Act compliant, no tool does. What it does is make the operational duties routine instead of heroic:
- Audit-ready timelines (Article 12, Article 73(6)). Every alert, escalation, acknowledgment, and action is captured automatically in the incident timeline and can be exported, evidence that survives the incident without anyone writing it down mid-outage.
- Reporting-grade speed (the 2/10/15-day windows). Multi-channel alerting, on-call schedules, and escalation policies mean awareness of an incident is measured in minutes. The hard part of Article 73 isn't the notification deadline, it's having the causal analysis and documentation ready. Automated timelines and AI-assisted postmortems produce that documentation as a by-product of response.
- Cross-functional loops (Article 26(5), Article 73(1)). Playbooks notify engineering, legal, and comms in parallel, and status pages give stakeholders verified updates without pulling responders into meetings.
- Monitoring-to-incident (Article 55(1)(c), Article 72). Threshold breaches from your monitoring stack, output drift, inference-error spikes, latency, open an incident automatically through ilert's alert sources, so post-market monitoring and incident tracking run on the same record.
- EU-grade data handling. ilert is built and hosted in Germany, ISO 27001 certified, and GDPR-compliant, with AI inference kept in-region, so the tooling you use to respond to AI incidents doesn't create a new data-transfer problem.
- Governance over autonomy. The AI Act's through-line is human oversight of AI. ilert AI SRE is built on the same principle: the agent investigates, correlates, and drafts, a responder reviews and decides what happens next. AI runs the investigation. You make the call.
See the whole flow, alerting, timeline, postmortem, in ilert's weekly live demo.
FAQ
Did the EU AI Act get delayed?
Partly. The Digital Omnibus on AI (Regulation (EU) 2026/1744, in force July 27, 2026) moved high-risk obligations to December 2, 2027 (Annex III) and August 2, 2028 (Annex I). GPAI obligations and Article 50 transparency kept their original dates.
What applies from August 2, 2026?
Article 50 transparency obligations, and the Commission's power to fine GPAI providers. GPAI obligations themselves, including serious-incident reporting for systemic-risk models, were already in force.
When does Article 73 serious-incident reporting apply?
It attaches to the high-risk regime: December 2, 2027 for standalone Annex III systems, August 2, 2028 for Annex I embedded systems. GPAI models with systemic risk already have a parallel reporting duty under Article 55(1)(c).
How fast must serious incidents be reported under the AI Act?
Immediately once a causal link (or its reasonable likelihood) is established, and no later than 15 days after awareness, 2 days for widespread infringements or critical-infrastructure disruption, 10 days for a death. Not 72 hours; that's GDPR.
Does the delay affect NIS2, DORA, or GDPR?
No. Those regimes and their reporting clocks are unchanged. (The wider Digital Omnibus package proposes amendments to GDPR and NIS2, but as of publication those are still under negotiation and are not law.) The AI Act itself routes most incidents involving sector-regulated systems through the sector rules (Article 73(9)–(10)), making one unified incident process the sensible hedge.
This article is practical incident-process guidance, not legal advice.
