EU AI Act Compliance Tooling: Buy or Wait Now That Annex III Applies from 2 December 2027
As of November 2026, the Annex III date is fixed in law at 2 December 2027, so the question is no longer whether the deadline will move. Most teams should phase the decision: start early on controls that generate evidence only while running in production, and defer documentation-oriented tooling until standards and guidance settle.
Evaluation criteria for compliance tooling
- Enforcement or documentation: does the tool enforce policy in the execution path, or only document and report on it?
- Evidence durability: is evidence generated continuously, retained in a form that survives an audit, and tamper-evident by design?
- Mapping: can evidence be mapped to the Act's articles, and re-pointed if standards, guidance or Annex III change after purchase?
- Retention and data residency: do the options fit your own regulatory obligations?
- Deployment model: can it run in your own cloud, and does that meet your security and procurement requirements?
- Scope tolerance: does it cover the use cases you have classified, and tolerate changes to the list?
What changed: the delay is law, not a proposal
Earlier planning assumed high-risk obligations would apply from 2 August 2026. The Commission said delayed availability of standards put that date in jeopardy, and on 19 November 2025 it proposed targeted amendments through the Digital Omnibus on AI. An agreement was reported on 7 May 2026, and the AI Omnibus entered into force on 27 July 2026.
The date of application for Chapter III Sections 1, 2 and 3 is now 2 December 2027 for systems classified as high-risk under Article 6(2) and Annex III, and 2 August 2028 for systems classified under Article 6(1) and Annex I. The legal text gives the reasons as delayed standards, common specifications and guidance, and delayed establishment of national competent authorities, and notes these risked a significant increase in implementation costs.
Annex III areas include biometrics, critical infrastructure, education, employment, migration, asylum and border control. Two caveats remain. The Commission can amend Annex III by delegated act under Article 97, so the list of use cases can change. Further Commission guidelines on high-risk obligations are also expected. Treat 2 December 2027 as a firm baseline, not as a guarantee that the surrounding scope and guidance are static.
What the date does and does not decide
A fixed date removes one uncertainty but leaves the purchasing decision dependent on several others. The deadline is the end point of a timeline that starts with your own lead times: procurement, security review, integration, rollout across use cases, and the period in which controls must run before anyone examines them.
The most useful distinction is between two kinds of control. Some controls produce evidence only while they operate in production, such as runtime enforcement and the records it generates. That evidence cannot be backfilled. If a control is deployed shortly before an audit, there is little history to show. Other controls are documentation-type work, such as technical files and conformity packaging. These can follow the standards and guidance as they are finalised, and can be completed later without losing anything.
Standards maturity matters here. The Commission describes harmonised standards as a way to provide legal certainty and to translate legal requirements into common technical language, and it also states that providers can choose other frameworks to demonstrate compliance. Early tooling therefore cannot be checked against a final standards baseline, and should be judged on how well it maps to the Act's requirements, not only on alignment with one standard.
First, classify your use cases. The Commission's guidelines on high-risk classification, with practical examples, support confirming whether a system falls under Annex III or Annex I before you apply a date.
Which capabilities are time-sensitive and which can wait
This split is an evaluation framework, not a statement of what the Act requires article by article. Confirm technical requirements against the text of the Act before finalising criteria.
- Runtime policy enforcement: Time-sensitive. Evidence exists only from the point enforcement starts running in production.
- Evidence capture and retention: Time-sensitive. Retention periods and data residency settings need to be decided before evidence accumulates.
- Human approval workflows: Time-sensitive where oversight is exercised in production, because operating history is itself evidence.
- Technical documentation tooling: Can reasonably wait. Content depends on standards and guidance still maturing.
- Standards-specific mapping and conformity packaging: Can reasonably wait, provided the evidence you collect can be re-pointed later.
- Annex I embedded-product programmes: Later date (2 August 2028), so sequence after Annex III work where use cases are separate.
Where runtime policy enforcement fits
Runtime policy enforcement is one category among several. It does not replace documentation, risk management or conformity work, and a team with strong existing enforcement and evidence capture may need little from it. Its relevance to timing is narrower: it is the category where delay costs the most, because evidence of operation accumulates only once enforcement is running.
Trussed is an example of this category. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, with actions that include allow, redact, block, rate limit and escalate for human approval. Enforcement applies to individual interactions and tool calls, and is enforced at runtime, not reviewed after the fact. That enforcement generates audit-ready evidence mapped to the EU AI Act, among other frameworks. It can be self-managed in the customer cloud, with configurable retention and data residency.
On operating track record, Trussed has run continuously in production in a regulated enterprise for more than 18 months, at 99.95% uptime on live production traffic. Trussed does not provide business transaction identity, model or dataset provenance, or end-to-end tracing of agentic workflows, so those needs should be assessed separately.
Building a defensible buy-now, phased or wait decision
Record the decision with the date inputs and the open uncertainties written down: standards, guidance and any Annex III delegated acts. Assign an owner to monitor each. The following checkpoints turn the framework into a decision.
- 1. Classify and date each use case: Confirm Annex III under Article 6(2) or Annex I under Article 6(1), since the dates differ by 8 months.
- 2. Work back from 2 December 2027: Subtract your own procurement, integration and rollout time, then the period of production operation you want before any inspection.
- 3. Test existing control coverage: Identify where current controls already enforce policy and retain evidence in production, and where there are gaps.
- 4. Choose the path: Buy now if the work-back leaves little margin for evidence-producing controls. Phase if production controls are urgent but documentation tooling can follow. Wait only where coverage is strong and lead times are short.
Buy, phase or wait: the inputs
Fixed date
2 December 2027 for Annex III systems; 2 August 2028 for Annex I products.
Lead time
Your own procurement, integration and evidence-accumulation time, worked back from the date.
Standards maturity
Harmonised standards and guidance are still maturing, which affects documentation tooling most.
Existing coverage
What your current controls already enforce and record in production.
Test your timing assumptions against your own use cases
Talk through how runtime enforcement and audit-ready evidence would fit your Annex III use cases and your work-back timeline.
Talk to an ExpertHow does your AI governance program compare?
See where your program has gaps in less than 2 minutes.