7 min read AI Audit

AI audits: the AI Act delay to 2027 doesn't buy you the sixteen months you think

AI audits: the AI Act delay to 2027 doesn't buy you the sixteen months you think

On June 29, 2026, the Council of the European Union gave its final green light to the digital simplification package, two weeks after the Parliament's vote on June 16. The text, based on the provisional agreement reached between the co-legislators on May 7, postpones the obligations for Annex III high-risk AI systems from August 2, 2026 to December 2, 2027, and those for systems embedded in regulated products to August 2, 2028.

In many boardrooms, the reading was immediate: sixteen months of breathing room, compliance drops down the priority stack. That reading is a miscalculation, for a reason anyone who has been through an audit knows well. An audit doesn't verify what you can do on inspection day. It verifies what your systems recorded during the months before. And that material cannot be manufactured retroactively.

This is the counterintuitive instinct to correct first: a postponed application date almost always reads as postponed workload, when it only postpones the date on which the regulator can sanction. On the ground, compliance teams who have already been through a first GDPR audit recognize the pattern immediately: organizations that took this kind of delay at face value found themselves, at inspection time, scrambling to document months of history that never existed.

This article separates what is actually postponed from what is still due in 2026, details what auditors check in practice, and lays out four workstreams to get ready without over-investing.

Audit magnifying glass over a stack of documents with a timeline shifted to the right
Postponing an application date doesn't postpone evidence accumulation: logs, registers and documentation build up continuously, not the night before the inspection.

What is postponed, and what isn't

The delay only covers obligations tied to high-risk systems. Three deadlines remain active, and two of them land within the next six months.

The transparency obligations of Article 50 still apply on August 2, 2026, three weeks from now. They cover any system that interacts directly with people, generates synthetic content or performs emotion recognition: users must be told they are interacting with an AI, and generated content must be identifiable as such. Covington noted in late May 2026 that this date remained "live and proximate" despite the high-risk postponement.

The Article 5 prohibitions, in force since February 2025, are expanding. The package adopted in June adds a prohibition on systems generating non-consensual intimate content, applicable from December 2026 according to the text endorsed by the Parliament.

The obligations on providers of general-purpose AI models, applicable since August 2025, don't move either. And the June package extends the supervisory scope of the Commission's AI Office over systems built on top of those models, according to Gibson Dunn's analysis published after the agreement.

In other words, a company deploying a customer chatbot, a content generator or an internal conversational agent has enforceable obligations this year, regardless of any high-risk classification.

Why traceability can't be caught up on

Even the postponed part prepares poorly under time pressure, for a structural reason: Articles 9 through 15 of the regulation require evidence that accumulates over time.

Article 12 mandates automatically generated logs covering the traceability of the system's decisions, with a minimum retention of six months. A system brought into compliance in November 2027 will have nothing to show about its behavior in 2026 and 2027, precisely the period a regulator will want to understand if an incident is reported.

Post-market monitoring requires a performance history: model drift, incidents, corrections applied. Here again, the data only exists if collection started early.

Finally, organizations that choose to rely on ISO/IEC 42001, the certifiable AI management system standard often used to demonstrate structured compliance with the requirements of Articles 9 to 15, should plan for six to twelve months between kickoff and certification, according to field feedback compiled by Schellman and Deloitte in 2026. Starting mid-2027 for a December 2027 deadline doesn't work.

The delay therefore changes the date on which the regulator can sanction. It doesn't change the date on which you need to start.

What auditors check in practice

The audit guides published in 2026, including Raconteur's technical reference dedicated to the AI Act deadline and Kognitos's sector checklists for finance and healthcare, converge on four control zones.

The first is the inventory. Before any substantive check, the auditor asks for the list of AI systems in production, their risk classification and the rationale behind it. This is the most frequent point of failure: most organizations discover at this stage systems deployed outside any census, often introduced through SaaS tools whose AI features were switched on without a formal decision.

The second is technical documentation. For each system classified as risky, the auditor expects a description of the training data and its provenance, the architecture choices, the performance metrics and the conditions under which they were measured. Not a marketing document: documentation that would let a competent third party understand how the system produces its outputs.

The third is operational traceability. The auditor doesn't just read the AI usage policy, they test whether it is technically enforced. NeuralTrust's analyses of the first AI governance audits note that the gap between documented controls and controls actually in place is the leading cause of non-compliance: a policy that prohibits sending customer data to external models, without a mechanism that blocks that transfer, counts as an absent control. It's the same gap, between permissions granted on paper and permissions actually exploitable, that recurs in the agent security incidents covered in the article on AI agent access scoping: an unverified control doesn't exist, whether the context is a regulatory audit or a security incident.

The fourth is human oversight. Who can intervene on a system decision, at what point, with what information? The auditor looks for real cases of intervention, not a theoretical escalation diagram.

The four control zones of an AI audit with the expected evidence for each
The four control zones of an AI audit and the evidence expected for each.

Four workstreams, in this order

The right response to the delay is neither stopping the effort nor keeping a heavy compliance program sized for the August 2026 deadline. It is a minimal foundation that accumulates evidence continuously, sized to cost little while the final classification of your systems is still open.

The first workstream is the AI system register. A single inventory, with a named owner, purpose, data consumed, provisional risk classification and deployment status. It takes a few weeks to build and everything else depends on it. Without it, there is no way to know which systems will fall under the high-risk regime in December 2027, nor which are already covered by Article 50 next month.

The second is documentation produced as you go. Technical documentation is expensive when reconstructed after the fact by teams who didn't build the system. It is cheap when it is a by-product of the development cycle: a training data sheet filled in when the dataset is chosen, evaluation metrics archived at each release, architecture decisions recorded when they are made.

The third is logging by design. Every production system should already generate the traces Article 12 will require: inputs, outputs, model version, timestamps, any human intervention. The marginal cost is low on a system instrumented from the start, high on a system that needs retrofitting. And those logs are useful long before any audit: they are the same data that feeds drift detection and incident analysis.

The fourth is governance that works at small scale. A review committee that actually examines new use cases, a documented exception process, a risk register kept up to date. Organizations certified against ISO 42001 in 2026 report that the hardest thing to demonstrate to an external auditor is not the existence of the setup but the proof of its continuous operation: decision records, motivated rejections, risks tracked over time.

What to set in motion this week

Three actions fit within the week. Check your Article 50 exposure: list the systems that interact with people or generate content, and confirm that user disclosure and content marking will be in place by August 2. Launch the AI system register if it doesn't exist, starting with a declarative census across business units, refined later. And make the high-risk compliance timeline an explicit executive decision, with a written position: which systems will likely be classified high-risk, when documentation starts, who owns the budget.

Conclusion

The December 2027 delay is real calendar relief for sanctions. It relieves nothing for the systems themselves: every month of production without logs, documentation or a register is a month of evidence that will never exist. The companies that understand this will use these sixteen months to walk into the inspection with two years of clean history. The others will arrive in December 2027 exactly as they would have arrived in August 2026: rebuilding under pressure what should have accumulated on its own.

Sources: As of July 2026

Godwin AVODAGBE