EU AI Act Annex III implementation roadmap: what to build first

What the December 2027 date changes

Regulation (EU) 2026/1744, the Digital Omnibus on AI, was adopted on 8 July 2026 and entered into force on 27 July 2026. It amends Regulation (EU) 2024/1689 and sets the date of application for Sections 1, 2 and 3 of Chapter III at 2 December 2027 for systems classified as high-risk under Article 6(2) and Annex III. Systems classified under Article 6(1) and Annex I move to 2 August 2028. The original date was 2 August 2026. Earlier Commission material that still refers to August 2026 or a conditional transition period has been superseded by these fixed dates.

The stated reasons for the postponement were the delayed availability of standards, common specifications and guidance, and the delayed establishment of national competent authorities. For a team planning work, this means the date is a fixed constraint and the open variable is the evidence and standards landscape. That argues for building controls whose outputs can adapt, rather than for compressing a schedule.

Annex III covers eight areas of sensitive AI use, each with concrete use cases. Which obligations reach your system depends on that classification, so it is the first piece of work, ahead of any control design.

What belongs in the execution path and what does not

Three requirements bear directly on what happens while a system runs. High-risk systems must be designed so that natural persons can effectively oversee them while in use, including through appropriate human-machine interface tools. The regulation specifies minimum logging capabilities, including for systems under point 1(a) of Annex III. And testing must be carried out against metrics and probabilistic thresholds defined in advance and appropriate to the intended purpose.

A runtime enforcement layer can act on the first two: it can apply behavioural policy to live interactions, route actions to a human, and produce records as it does so. It cannot replace the processes around them. A risk management system must be established, implemented, documented and maintained. Providers must complete conformity assessment, either internal control under Annex VI or assessment with a notified body under Annex VII, depending on category and on whether harmonised standards or common specifications were applied. Providers of Annex III systems, except point 2, must register themselves and their system in the EU database before placing the system on the market or putting it into service. Technical documentation and quality management also remain separate work.

This split is a practical interpretation, not a statement from the regulation, but it is a useful one. It keeps compliance teams from expecting a technical control to close a process obligation, and keeps engineers from treating documents as a substitute for controls.

A defensible build order

The order below is practitioner sequencing, not a requirement of the regulation. Each step produces something the next step depends on.

• 1. Scope and classify systems: Inventory AI systems, including agents and the tools they can call, and classify each against the eight Annex III areas. The Commission's guidelines for providers and deployers of high-risk systems are a reference point for borderline cases. Record whether you act as provider, deployer or both.
• 2. Define enforceable policy: Translate intended purpose and risk decisions into rules a system can evaluate: which data may enter a prompt, which tools an agent may call, which actions need approval. Define test metrics and thresholds at the same time, since they must be set before testing.
• 3. Enforce policy at runtime: Apply those rules to each interaction and tool call across every model and agent in scope. Decisions such as allow, redact, block or escalate should be explicit and recorded.
• 4. Route high-consequence actions to human approval: Identify actions where an automated outcome materially affects a person, and require a named approver. Treat this as one way to meet the oversight design requirement, alongside interface design.
• 5. Retain evidence as a by-product: Store the records of enforcement decisions and approvals with defined retention, in a schema you can version.
• 6. Run parallel processes: Keep risk management, documentation, quality management, conformity assessment and registration moving alongside, fed by what the runtime layer shows.

Designing evidence from the regulation outward

Start the evidence schema from the regulation's logging provisions rather than from whatever a tool records by default. The regulation specifies minimum logging content for at least some Annex III systems, so confirm the provisions that apply to your category against the full text before fixing fields.

The standards picture is still developing. Implementing Decision (EU) 2026/2274, adopted on 12 October 2026, publishes the reference of a CEN and Cenelec harmonised standard on quality management systems for AI providers, including post-market monitoring. That is a process standard. It does not define evidence formats for oversight or runtime records, so schemas for those should be versioned and able to change as further standards and guidance appear. Whether applying the quality management standard gives a presumption of conformity is a question for counsel.

The useful property of evidence generated by enforcement is that it describes what the system was allowed to do and what it did on live traffic, at the time. A policy document shows intent. A record of a blocked tool call or an approved action shows operation. An auditor or regulator is likely to want both, and the second is the one that cannot be produced retroactively.

Evaluating a runtime enforcement layer

Whether you build or buy, judge the layer on a few criteria. First, coverage: does it sit in the path for every model, agent and tool in scope, or only some entry points? Second, action set: can it do more than detect, for example allow, redact, block and escalate for approval? Third, evidence: can records be exported in a form an auditor or notified body can use, and can the schema map to the logging provisions that apply to you? Fourth, retention and residency: who sets retention periods, how are they enforced, and where does the evidence store run? Fifth, adaptability: how does the format change when new standards arrive?

Deployment location deserves early attention. Evidence may contain sensitive interaction data, so running the enforcement layer and its store in your own cloud, with configurable retention and data residency, can simplify internal review.

Trussed is one example of this approach. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, with allow, redact, block, rate limit and escalate-for-approval actions on individual interactions and tool calls. Enforcement produces continuous audit-ready evidence mapped to the EU AI Act, among other frameworks, and it can be self-managed in the customer cloud with configurable retention and data residency. It has run in continuous production in a regulated enterprise for more than 18 months and holds more than 100 models under one policy plane.

What runtime enforcement does not cover

A runtime layer does not perform risk management, conformity assessment, EU database registration or technical documentation. It does not establish model provenance, dataset lineage or the data governance work that depends on them, and Trussed does not provide those. It does not provide end-to-end tracing of agentic workflows either; its scope is individual interactions and tool calls.

Plan those obligations as their own workstreams with their own owners. The practical goal for the runtime work is narrower and achievable: by December 2027, be able to show that defined policy operated on live interactions, that high-consequence actions reached a human where required, and that the records survive in a form you can hand over.