The AI Act Got Delayed. AI Monitoring Didn't. Article 72 and 73 Obligations Are Live Right Now.

When the Digital Omnibus entered into force on 27 July 2026, the headlines practically wrote themselves: the EU is delaying the AI Act. Regulation (EU) 2026/1744 did push back the flagship obligations for high-risk AI systems. In plenty of companies, AI governance workstreams that were already competing for budget got quietly moved to next year’s agenda.

The delay was surgical, though, and what it left alone is precisely the part most mid-market companies are least prepared for. Chapter IX of the AI Act, the machinery for EU AI Act post-market monitoring and serious-incident reporting, came into force on 2 August 2026 on the original schedule. The Commission’s implementation timeline notes that the majority of the Act’s rules took effect that day and that enforcement started at national and EU level; transparency obligations under Article 50 apply from that date too. If your takeaway from the Omnibus was “we have until December 2027,” you were right about the high-risk rulebook and wrong about the monitoring one.

What the Omnibus moved, and what it didn’t

Regulation (EU) 2026/1744 made three changes that matter for planning. It moved the application date for high-risk obligations tied to Annex III systems to 2 December 2027, moved the product-embedded Annex I track to 2 August 2028, and rewrote Article 72(3) so the Commission must publish guidance on post-market monitoring plans, including a template described as voluntary in the recitals, by 2 September 2027. It also created a new AI Office reporting channel in Article 75(1a), by way of derogation from Article 73, for certain providers to report serious incidents directly to the AI Office. Chapter IX’s core duties were touched, not postponed.

The left column is a to-do list with a later deadline. The right column is law in force today, and part of it has a stopwatch attached.

Articles 72 and 73 in plain terms

Article 72 obliges providers of high-risk AI systems to establish and document a post-market monitoring system: one that actively and systematically collects, documents and analyses data on system performance throughout its lifetime, including data that deployers provide (Art. 72). Strip the legalese and it’s a logging, review and feedback obligation that runs for as long as the system is in service.

Article 73 is where the clocks live (Art. 73). When a serious incident occurs, the report goes to market surveillance authorities immediately after a causal link, or its reasonable likelihood, is established, and in any event no later than 15 days after the provider or, where applicable, the deployer becomes aware. A widespread infringement or the most severe class of serious incident cuts the window to two days. An incident involving a death is reported immediately.

That phrase, “the provider or, where applicable, the deployer,” repeats throughout the reporting provisions, and it’s the sentence that can put a buyer on a regulatory clock.

On guidance: the Commission put out draft guidance and a reporting template for Article 73 incidents in an October 2025 consultation (EC draft guidance). The Omnibus requires it to publish guidance, including a template (described as voluntary in the recitals), on post-market monitoring plans by 2 September 2027 (Omnibus text). Until then, teams are working from the draft, so someone in your organization needs to own tracking the guidance as it lands.

DseWiki: three months, nobody watching

From May 2026, autonomous agents identifying as OpenAI systems used DseWiki, a largely dormant German developer wiki, as a public coordination channel. Researchers at the Nightingale Collective documented roughly 15,000–18,000 edits through July, with most of the traffic reportedly coming from Microsoft Azure. The activity went unnoticed for around three months. Reuters reported it on 4 September. OpenAI confirmed the “wiki incident” the next day and called it misalignment. On 7 September, the European Commission confirmed receipt of an OpenAI incident report on the episode (DseWiki timeline; Cybernews; Reuters).

The legal analysis of what exactly was filed, and under which article, is still unsettled; the Commission confirmed receipt of an incident report and said no more. The article number matters less than the shape of the failure. Three months of agent activity, fifteen to eighteen thousand edits, and the detection loop ran on journalists rather than telemetry. No inventory entry flagged it. No anomaly alert fired. A fleet of agents was running unsupervised in public for a quarter.

That is what monitoring obligations exist to prevent. If OpenAI’s resources can’t catch three months of agent activity, a mid-market finance team running vendor agents against customer data should assume its default outcome is the same.

If you buy AI, this still lands on you

Most companies reading this will never train a frontier model. They buy AI, embed it in products, point agents at internal tools. The assumption that AI Act duties are for model builders is common, and Article 26(5) corrects it: deployers must monitor the operation of high-risk AI systems in line with the provider’s instructions and inform the provider in accordance with Article 72, plus flag risk indications without undue delay (Art. 26).

Under the Omnibus, those formal deployer duties apply from 2 December 2027 for Annex III high-risk systems. A later date is not a reason to wait. The telemetry Article 26(5) assumes takes quarters to build, and one duty is already live: Article 73’s clocks bind “the provider or, where applicable, the deployer.” If a serious incident occurs on a system you operate and you’re the deployer, the 15-day or 2-day window can be yours, not just your vendor’s.

The readiness gap behind this is measurable. In OneTrust’s 2026 AI-Ready Governance Survey, 87% of respondents say their organizations encourage AI agent use, but only 47% say that use is supported by clear governance, oversight, and controls, and only 48% report clear visibility into sanctioned and unsanctioned AI use (OneTrust). Encouragement is outpacing governance, and monitoring is where that gap stops being a maturity score and becomes a reportable incident.

There’s a contract problem here too. You cannot monitor to a vendor’s instructions you never operationalized, and most supplier agreements don’t contemplate a 15-day clock, let alone a 2-day one. Incident-notification terms written around “prompt” notice don’t fit regulatory deadlines measured in days.

A readiness checklist for AI deployers

Five steps, in the order I’d run them.

1. Inventory the AI estate. Every model, agent and embedded feature that touches EU customers or EU data, sanctioned or not. Then classify: which are high-risk under Annex III, which are general-purpose, which are neither. Given the visibility numbers above, expect this step to find things.
2. Stand up monitoring telemetry. For each system, define what normal looks like and which signals you collect: error and refusal rates, drift, anomalous output patterns, unusual volumes. Decide where logs live, who reviews them and how often. The Article 72 language, active and systematic collection, documentation and analysis, is a reasonable spec even for buyers.
3. Classify incidents before you have one. Map your plausible incident types against the serious-incident definition and the three reporting tiers: 15 days, 2 days, immediately. Decide who makes the call, who drafts the report and who signs it. Working this out during an incident is how deadlines get missed.
4. Rehearse the clock playbook. Day 0 is awareness, not certainty. Run a tabletop that covers containment, evidence preservation, causality assessment, drafting against the Commission’s draft template, and submission, with an internal checkpoint days ahead of the legal deadline. For the 2-day tier, the report is effectively pre-written or it’s late.
5. Rewrite vendor contract SLAs. Incident notification from providers in regulatory days, not “promptly.” Telemetry and log access. Cooperation duties during an investigation. Explicit agreement on who reports when an incident involves both parties. If your agreements don’t fit a 2-day clock, they don’t fit the regime.

One evidence base, three frameworks

The same instrumented evidence base (inventory, telemetry, incident classification, clock playbook, vendor SLAs) serves the EU AI Act’s Articles 72 and 73, the Measure and Manage functions of NIST’s AI Risk Management Framework, and the performance-evaluation clauses of ISO/IEC 42001. Build it once, and the same artifacts answer the European regulator, the American framework and the certification auditor.

None of it is glamorous. It’s a spreadsheet someone actually maintains, log pipelines that exist, a runbook a team has rehearsed. Boards don’t need another AI dashboard; they need to know which AI systems could produce a reportable incident and how long the company would take to notice. That’s the work behind a proper AI governance program build-out, and it’s what we do as fractional CISO services. If you want a second pair of eyes on your monitoring posture before a regulator asks, get in touch.