Annex III vs Annex I High-Risk Deadlines: Why December 2027 and August 2028 Differ

Two routes to high-risk status

The AI Act reaches high-risk status through two separate legal tests, and most confusion about the deadlines comes from treating them as one.

The Annex I route sits in Article 6(1). An AI system is high-risk where it is intended to be used as a safety component of a product, or is itself a product, covered by the Union harmonisation legislation listed in Annex I. That product must also be required to undergo third-party conformity assessment before being placed on the market or put into service under that legislation. The classification applies whether or not the AI system is placed on the market or put into service independently of the product.

The Annex III route sits in Article 6(2). It works as a use-case list: AI systems referred to in Annex III are considered high-risk in addition to those caught by Article 6(1). The classification follows what the system is used for, not what product it is built into. An Annex III system is not considered high-risk by derogation where it does not pose a significant risk of harm to the health, safety or fundamental rights of natural persons, including by not materially influencing the outcome of decision making.

The practical difference is that Annex III asks a question about the use case, while Annex I asks a question about the product and its existing conformity regime.

Annex III and Annex I compared

The table summarises the structural differences that matter for planning.

• Legal basis: Annex III: Article 6(2). Annex I: Article 6(1).
• What triggers classification: Annex III: a use case listed in the annex. Annex I: a safety component of, or the AI system being, a product under listed harmonisation legislation.
• Third-party conformity assessment: Annex III: not part of the classification test. Annex I: the product must require it under the sectoral legislation.
• Derogation: Annex III: no significant risk of harm, including no material influence on decision outcomes. Annex I: for Section A legislation, only the derogations in that legislation apply.
• Application date: Annex III: 2 December 2027. Annex I: 2 August 2028.

Why the dates differ and what changed

The AI Act originally applied its high-risk requirements from 2 August 2026, with different initial dates for the two routes. Regulation (EU) 2026/1744 of 8 July 2026, the Digital Omnibus on AI, amended the Act and moved those dates. It is adopted law, not a proposal.

The legislature gave its reasons: standards, common specifications and alternative guidance were late, and national competent authorities had not been established on time. It said these delays jeopardised effective entry into application and risked a significant increase in implementation costs, so the 2 August 2026 date should not be maintained.

The recital also explains the split. The distinction between the Annex III and Annex I dates is consistent with the difference between the initial dates in the original Act, and it aims to give the necessary time for adaptation and implementation of the corresponding obligations. The date follows the legal basis. Each route keeps its own application date, and both moved later.

Two cautions apply. The Omnibus states that its own provisions apply on a staggered basis, with all of them in application by 2 August 2027. That is separate from the high-risk dates and should not be confused with them. The Commission also assesses annually whether to amend the lists of high-risk uses and prohibited practices, so the Annex III classification of a system can change over time.

Classifying your AI systems against the correct date

Classification should be a recorded decision per system, owned by a named person, with a rationale that can be shown to a regulator. The following steps give a defensible structure.

• Inventory every AI system you provide or deploy, including embedded components in products.
• Test each system against the Annex III use-case list and record the outcome, including the reasoning behind any claim that it is not high-risk.
• For systems inside products, identify the Annex I harmonisation legislation that applies and whether the product requires third-party conformity assessment under it.
• Where a system plausibly meets both tests, record both routes and the date attached to each.
• Tag each system with 2 December 2027 or 2 August 2028 and build the workplan from the amended dates, not 2 August 2026.
• Schedule a periodic reclassification review, because the high-risk lists are assessed annually.

Obligations that depend on runtime behaviour and retained evidence

The delayed dates cover Chapter III, Sections 1, 2 and 3. Before assigning controls to a system, confirm which specific requirements apply to your role as provider or deployer and which date governs the system. The Annex I route also interacts with sectoral rules: for Section A legislation, only that legislation's conformity-assessment derogations apply, and the Omnibus clarifies the interplay between the AI Act and EU product safety rules. Align AI Act governance with the product-safety governance you already run.

A general technical distinction helps with planning. Some requirements can be met largely through documents: policies, procedures, technical descriptions. Others describe how a system behaves in operation. Human oversight is only credible if a person can actually intervene at the point where the system acts. Records of system behaviour are only useful if they were captured when the behaviour occurred. Risk controls matter only if they are applied to live interactions. For these, a written policy is a statement of intent, and the evidence is what was enforced and what was retained.

This is where programmes tend to fall short. A team can complete its classification and documentation on schedule and still be unable to answer the regulator's basic question: what was this system permitted to do, and what did it do? That question should shape which controls you budget for well before the application date.

Where runtime policy enforcement fits

Trussed addresses one part of this problem. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, acting on individual interactions and tool calls. Enforcement actions are allow, redact, block, rate limit and escalate for human approval. Policy is enforced at runtime, not reviewed after the fact.

That enforcement continuously generates audit-ready evidence, mapped to the EU AI Act among other frameworks, so a regulated enterprise can show what its AI was allowed to do and what it did. Trussed can be self-managed in the customer cloud, with configurable retention and data residency.

The scope is deliberately narrow. Trussed does not perform conformity assessment, and it does not classify your systems or replace the sectoral procedures that apply to Annex I products. It supplies runtime control and evidence for the operational side of the timeline, which you can then place against the 2 December 2027 and 2 August 2028 dates in your own workplan.