Updated 17 October 2026. The high-risk AI deadline moved, but the AI Act did not disappear into a drawer. Treating the change as a blanket pause is how a useful extra runway becomes a very expensive nap.
The important question is which rules apply to which system. “We are waiting until 2027” is not a complete answer. Neither is “everything became mandatory in August”. Both skip the classification work that makes a deadline meaningful.
The current timeline
The European Commission’s AI Act implementation page records the AI Omnibus entering into force on 27 July 2026. It lists 2 December 2027 for the relevant Annex III high-risk uses and 2 August 2028 for high-risk AI embedded in regulated products under Annex I. These are different categories, not interchangeable dates.
| Category | Application date |
|---|---|
| Original prohibited practices and AI literacy | 2 February 2025 |
| Governance and general-purpose AI obligations | 2 August 2025 |
| General application, including relevant transparency rules | 2 August 2026 |
| Annex III high-risk uses | 2 December 2027 |
| Annex I regulated-product high-risk systems | 2 August 2028 |
The change from August 2026 to December 2027 is sixteen months. It does not mean every AI obligation starts then. The distinction matters for a team selling a system, a team deploying it and a provider supplying a general-purpose model.
Separate the legal clock from the product clock
A release can introduce a consequential decision before a particular regulatory deadline. A customer can ask for evidence before an enforcement milestone. An internal risk owner can require a review before a procurement contract is signed. Those are separate triggers.
For example, imagine an assistant that initially summarises approved internal policies. A later release ranks job applicants. The team has changed the purpose and potential consequences of the system. Carrying over the original assessment because the underlying model stayed the same would miss the important change.
This is an illustrative product scenario, not a classification verdict. The point is to bring the intended use, affected people and actual workflow into the assessment. A model name cannot do that work on its own.
Use the extra time for evidence
I would start with a system inventory that names an owner and records what each system actually does. Then connect each important risk to a control and each control to evidence. “Human oversight” should point to a real review step with enough context and authority to intervene.
A useful readiness review asks for a demonstration. Show an access denial. Show an unresolved question reaching the right person. Show how a change to the model, tools or data sources triggers reassessment. Screenshots of a policy document are evidence that a document exists. They are not evidence that the workflow follows it.
The practical companion is an evaluation plan that separates outcomes, authority and recovery. A successful answer does not establish that the system respected its permissions or handled failure properly.
Keep the interpretation visible
Every compliance decision should name the rule, the system it applies to, the interpretation date and the person responsible for reviewing it. When the legal position changes, you can revisit the decision instead of searching through six decks with “FINAL” in their filenames.
A short decision record is enough to begin. It should distinguish a confirmed requirement from an assumption and keep unresolved questions visible. Legal review and product evidence serve different purposes; one cannot substitute for the other.
The delay gives teams time. What they do with that time is still a product decision.
