The EU AI Act deadline moved. Here is what did not.

The date changed, the problem did not.

The EU's Digital Omnibus changed the timetable for the high-risk provisions of the AI Act. For systems listed in Annex III, the principal date is now 2 December 2027. High-risk systems embedded in products covered by existing product safety law have a later date, 2 August 2028. Those changes matter. They give providers and deployers more time to establish conformity processes, obtain documentation and make technical changes.

They do not turn the AI Act into a future problem. Several parts of the regime already apply, commercial counterparties are already asking questions, and the first operational task remains difficult even without a legal deadline. An organisation still needs to know what AI it uses, what each system does, whose decision it affects, which provider sits behind it, and who inside the organisation is accountable for it.

The amendment entered into force in July 2026. It moved the application dates for the most demanding high-risk obligations, but it did not withdraw the underlying duties. Treating the change as permission to pause creates the same problem with a later due date. The work that takes longest is not writing a policy. It is finding systems, resolving unclear ownership, understanding data flows, and changing production processes without disrupting them.

What is already in force.

The prohibited-practice rules and AI literacy obligation have applied since 2 February 2025. General-purpose AI obligations have applied since 2 August 2025, subject to the transitional position for models placed on the market before that date. The governance structure, including powers for the AI Office and national authorities, is operating. The Article 50 transparency duties applied from 2 August 2026.

Article 50 is particularly easy to overlook because it sits outside the delayed high-risk timetable. It includes disclosure duties for systems that interact directly with people and marking or disclosure requirements for certain synthetic content. The exact duty depends on the system and the actor's role. A customer-service assistant, a tool producing synthetic media and an internal summarisation service do not present the same question, but each needs to be identified before anyone can decide whether Article 50 applies.

The practical consequence is that there is no single compliance date for an organisation's AI estate. Different obligations attach to different actors, systems and dates. A programme built around one deadline will miss systems that are already in scope and may spend time on systems that are not. The correct starting point is a system-level view.

Inventory is evidence, not a spreadsheet exercise.

An AI inventory usually begins as a list and quickly becomes a series of unresolved questions. Procurement knows about contracted platforms. Engineering knows about models called through an API. Business teams know about assistants bought on departmental cards. Security sees traffic to providers, but not always the purpose. Legal may have reviewed terms without seeing the final workflow. None of those views is complete on its own.

A useful inventory records the system owner, business purpose, provider and model, deployment status, affected people, input and output data, decision role, human oversight, geography, integration points, contractual terms and available technical evidence. It should distinguish experimentation from production, and assistance from automated decision-making. It should also identify systems where the organisation supplies a model, deploys another provider's system, or embeds AI in a product supplied to customers. Those roles affect the obligations.

Classification comes after discovery. Annex III categories are defined by use, not by whether the product is marketed as AI. A general-purpose model used to draft internal notes may sit outside high-risk categories. The same underlying model used in an employment decision workflow may need a different analysis. Classification therefore requires someone to understand the actual process, the decision and its effect, not just the model name.

This work takes months in a distributed organisation because ownership is rarely clean. Systems change, features are enabled by providers, proofs of concept become permanent, and workflows acquire unofficial manual checks. An inventory is only useful if there is a route for new systems and material changes to enter it. Otherwise it records one point in time and begins drifting immediately.

What the extra time should buy.

The extension should buy evidence, not inactivity. First, establish a complete inventory and assign accountable owners. Second, classify systems against the Act and record the reasoning. Third, identify the organisation's role for each system and map the duties that follow. Fourth, prioritise systems already subject to transparency, literacy, contractual or sector requirements. Fifth, define how new AI enters procurement, engineering and risk review.

For likely high-risk systems, the additional period can be used to improve data governance, logging, human oversight, technical documentation, monitoring and incident handling. These are operating capabilities. They need design, implementation and repeated use. A control demonstrated once for a project review is not the same as a control that works every week in production.

Customers may also move faster than the statute. Regulated buyers already request model documentation, data lineage, evaluation results, security controls and named accountability. They do not need to wait for a conformity deadline before making those requirements contractual. An organisation that can answer clearly now reduces sales friction and avoids rebuilding evidence separately for every questionnaire.

Where ISO 42001 helps, and where it does not.

ISO/IEC 42001 provides a certifiable management-system structure for AI. It creates a disciplined way to set scope, assign accountability, assess impacts and risks, control the lifecycle, monitor performance, audit the system and correct failures. For an organisation with ISO 27001, much of the management machinery can be aligned rather than duplicated. Document control, internal audit, management review, competence and corrective action should not become two parallel bureaucracies.

Certification to ISO 42001 is not a legal safe harbour. It does not decide whether a use is prohibited, determine an Annex III classification, or replace conformity assessment where the Act requires one. A certificate shows that a management system has been assessed against the standard. It does not prove that every product or deployment complies with every applicable legal duty.

The relationship is still useful. The Act asks organisations to perform repeatable work across governance, risk, data, documentation, oversight and monitoring. ISO 42001 provides an operating system for that work. The sensible approach is to map legal obligations into the management system, retain the legal analysis separately, and make sure technical controls produce evidence that supports both.

The deadline moved. The cost of not knowing what you operate did not. Use the extension to create an inventory that stays current, make classifications that can be defended, and implement the controls while there is still time to change the systems rather than explain them after the fact.