Why the extension of selected EU AI Act deadlines should not be mistaken for time off

‍

By Richard Mort

‍

On 27 July 2026, the European Union moved two important AI Act clocks. The high-risk requirements for systems covered by Article 6(2) and Annex III, including certain uses in employment, education, critical infrastructure and law enforcement, now apply from 2 December 2027. For high-risk AI embedded in regulated products under Article 6(1) and Annex I, the date is 2 August 2028.

‍

Six days later, another clock started. On 2 August 2026, Article 50's transparency obligations became applicable. These cover matters including disclosure when people interact with certain AI systems, machine-readable marking of synthetic content and disclosure of deepfakes in specified circumstances. There is a narrow transition until 2 December 2026 for systems placed on the market before 2 August 2026, and only for the machine-readable marking requirement. The amended AI literacy obligation remains in force. The AI Office also began enforcing the rules that already apply to relevant general-purpose AI model providers.

‍

"The AI Act has been delayed" is therefore a dangerously tidy sentence. Parts of the high-risk regime moved. Other obligations were already live or became live in August.

‍

‍

The honest case for more time

‍

There was a sound reason for the extension. The European Commission acknowledged that standards were late and that national governance and conformity-assessment infrastructure had not developed as quickly as expected. Its own high-risk classification guidelines were still in draft form at the evidence cut-off on 11 August 2026.

‍

A company that fixes every final control, template and assessment route around unfinished material could spend heavily and then repeat the work. Waiting can reduce waste. Selecting a notified body before establishing whether one is needed makes little sense. Nor does treating a management-system certificate as proof of AI Act conformity when the applicable legal route and technical standards are still being settled.

‍

That concession matters because the useful argument is not "start doing everything now". It is more precise.

‍

Standards may clarify how an organisation demonstrates that a control is adequate. They cannot recreate the state of an AI system that was never preserved.

‍

‍

The evidence the extension cannot preserve

‍

I use conformity debt here as an analytical label, not as a term from the AI Act.

‍

Conformity debt is the growing cost, risk and loss of room to manoeuvre created when an organisation changes or uses an AI system faster than it preserves the evidence, role clarity and lifecycle controls needed to show what the system is, how it changed and whether its actual use meets the requirements that apply.

‍

It is narrower than general compliance debt. Execution debt asks whether operations can support what an AI purchase requires in practice. Sovereignty debt asks what an organisation really controls across models, infrastructure and jurisdictions. Conformity debt asks a more forensic question: can the organisation still demonstrate what the working system became?

‍

For affected high-risk systems, Annex IV of the Act gives that question real weight. When the relevant provisions apply, technical documentation can need to cover the intended purpose, the current version and its relationship to previous versions, relevant software or firmware, third-party tools and how they were integrated or modified, data provenance, validation and test data, performance metrics, dated test reports, predetermined changes and changes made through the lifecycle.

‍

That is not a demand for a policy written in the abstract. It is a demand for memory.

‍

Consider a hypothetical but entirely ordinary enterprise progression. An AI assistant is introduced to help draft job advertisements. A team later connects it to applicant data and begins using it to rank candidates. The supplier changes the underlying model. The retrieval index is refreshed. A prompt is adjusted after complaints. The acceptance threshold moves because managers think the results are too conservative.

‍

Eighteen months later, the company can show the system running today. It cannot reproduce the system that influenced the earlier shortlists. The old prompt sits in a former employee's account. The previous retrieval index was overwritten. The test set has changed. Human overrides were discussed in meetings but never linked to a release.

‍

No dramatic compliance failure occurred on one particular Tuesday. The evidential history simply fragmented while the system kept moving.

‍

This is why conformity debt can compound. A test result without the model, prompt, retrieval source and threshold to which it applied is weak evidence. A description of the model without the operational data and guardrails around it does not describe the deployed system. A current supplier document may say little about the version used sixteen months earlier.

‍

Shadow AI makes the position worse. When a tool enters use before it enters the inventory, the later exercise is not merely classification. Someone has to reconstruct who used it, for what purpose, with which data, under which supplier terms and through how many changes. Often the people involved believed they were adopting a productivity tool, not creating a future evidence problem.

‍

‍

When an integration changes the answer

‍

The AI Act also makes legal responsibility more fluid than many purchasing teams assume.

‍

Under Article 25, a distributor, importer, deployer or other third party can be treated as the provider of a high-risk system if it puts its own name or trademark on the system, substantially modifies it while it remains high-risk or changes the intended purpose of a previously non-high-risk system so that it becomes high-risk. The original provider then has specified cooperation duties, including technical documentation, known limitations and targeted technical access for testing and validation.

‍

Those high-risk operator rules follow the revised 2027 or 2028 timetable. The management point today is simpler: the facts that will determine the later answer are being created now.

‍

A contract calling the customer a "deployer" cannot settle the question if the customer has, in reality, repurposed the system or altered it in a legally significant way. Equally, not every software update is a substantial modification. That is precisely why a baseline and a change record matter. Without them, the organisation may struggle to show whether a change was routine, foreseen and documented or whether it altered the system's purpose or conformity position.

‍

The supplier contract matters as much as the internal file. When the relevant high-risk provisions apply, Article 25(4) requires a written agreement covering the information, capabilities, technical access and assistance needed from third-party providers of models, systems, services or components integrated into the high-risk system.

‍

That turns a future regulatory question into a present procurement question. Which model and system versions can the supplier identify? Will it give notice of material changes? What documentation will remain available after an upgrade? Can the customer access relevant logs, known limitations and test support? Who cooperates when a regulator, customer or insurer asks for evidence?

‍

These rights are hardest to negotiate after the organisation has become dependent on the system.

‍

Nor should boards buy the wrong reassurance. Conformity assessment is not required for every AI system and it does not always involve an outside auditor. For most Annex III categories, Article 43 provides an internal-control route without a notified body. Product-related systems follow the applicable sectoral route. A CE mark is the provider's regulated indication of conformity, not an EU approval or a general quality badge.

‍

No certificate can repair a missing history.

‍

‍

Use the time on what does not improve with age

‍

The most sensible preparation now is the work whose value does not depend on the final wording of a standard.

‍

Start with a living inventory that records intended purpose, business owner, supplier, deployment geography and provisional legal role. Preserve versions across the application, model, prompts, retrieval sources, thresholds and guardrails. Keep the test sets, performance criteria, failures and sign-off decisions attached to the release they informed. Record material human overrides, incidents, exceptions and supplier changes while the people involved can still explain them.

‍

Add a change gate. Before a material release, somebody should ask whether the intended purpose, risk classification, supplier allocation or legal role may have changed. This does not need to turn every release into a legal seminar. It needs one named owner and a route for escalation when the answer is unclear.

‍

SAP's public EU AI Act FAQ gives a useful example of the instinct. The company says its AI feature classifications are "documented and reviewed as AI features evolve". That statement does not prove conformity. It shows why contemporaneous classification and revision history are more useful than a retrospective declaration of readiness.

‍

Current obligations also belong outside the waiting room. Organisations should already have addressed the Article 50 transparency duties that apply to them. They should be taking proportionate measures to support AI literacy under the amended Article 4. Relevant providers of general-purpose AI models cannot treat the 2027 legacy deadline as if it applied to models first placed on the market after 2 August 2025. Existing GDPR, employment, consumer, product-safety and cybersecurity duties continue on their own terms.

‍

What should wait? Final mappings to standards that are still under development. Full dress rehearsals for conformity routes where classification or sectoral treatment remains genuinely unsettled. Notified-body engagement where the law permits internal control. Any expensive exercise designed mainly to produce a reassuring percentage for a board slide.

‍

A useful board test is much harder to fake. Pick one material AI system and ask how long it would take to produce a defensible history of its purpose, versions, data sources, tests, major changes, suppliers and accountable decisions. Hours? Days? Or six departments and three vendors with no one quite sure which release the evidence describes?

‍

That recovery time is a better indicator than a single "AI Act readiness" score.

‍

Some conformity debt can be accepted consciously. A controlled exception has a named owner, a documented scope, a reason for waiting, a budget or resource assumption, a deadline, a trigger for earlier action and a remediation plan. An unowned exception with no end date is simply an unknown that is getting older.

‍

For a weak legacy system, the answer may not be more documentation. Management may decide to restrict its use, refactor it so logging and version control become possible, replace a supplier that will not provide the necessary evidence or retire a low-value system before the later high-risk date arrives.

‍

This is where software delivery discipline becomes practical. The evidence cannot live in a legal folder assembled at the end. It has to travel with releases, acceptance tests, supplier changes and operational decisions. For a cross-border delivery company such as Dirox, the useful contribution is not a compliance badge. It is an evidence-friendly software lifecycle, with clear ownership, versioned releases, testable acceptance criteria and supplier hand-offs that remain connected to the system they changed.

‍

More time can reduce waste. It can also hide decay.

‍

By December 2027 or August 2028, strength will be measured less by the thickness of a compliance binder than by the ability to explain, quickly and credibly, what the system is, how it got there and who owns the answer. Where the system keeps changing and the evidence lags, the extension merely gives the gap more time to grow.

‍

‍