The EU AI Act deadlines moved. Build the evidence trail anyway

The EU AI Act entered into force in August 2024 with obligations phased in over several years. In 2026 the EU agreed, through its digital omnibus package, to postpone the high-risk obligations: reports of the agreement put stand-alone high-risk systems, such as those used in recruitment, credit scoring and education, at 2 December 2027, and AI embedded in regulated products at 2 August 2028. Check the final text in the Official Journal for exact dates; this article is engineering guidance, not legal advice.

The problem: the delay invites the wrong conclusion

Nothing in the agreement removes the obligations themselves. Transparency duties for some systems are reported to apply sooner. And the work behind the high-risk requirements is not paperwork that can be written in the final quarter. It is evidence about how a system was built, tested and run, which only exists if the system produced it along the way.

What the high-risk requirements ask for

In engineering terms, the Act's requirements for high-risk systems map to things a well-run AI team should have anyway:

• Risk management: known risks identified, tested and mitigated, revisited as the system changes.
• Data governance: where training and evaluation data came from, how it was checked for quality and bias.
• Technical documentation: what the system is, how it works and how it was validated.
• Record-keeping: automatic logs that let you trace what the system did.
• Transparency to deployers: instructions for use, capabilities and limits.
• Human oversight: people able to understand, monitor and override the system.
• Accuracy, robustness and cybersecurity: measured, and defended against manipulation such as prompt injection.

The proposal: evidence as a by-product

1. 01Version everything. Datasets, prompts, models and configuration in version control or a registry, with a record of what shipped when.
2. 02Evaluate in CI. Accuracy, bias and robustness tests run on every change, with results stored. That is your validation record.
3. 03Log every request. Inputs, retrieved context, model outputs, decisions and overrides, retained according to a policy.
4. 04Build the override. A console where accountable people can see and overturn decisions, with each intervention recorded. This is the same design that gets agent pilots into production.
5. 05Red-team on a schedule. Adversarial tests for injection and data leakage, with findings tracked to closure.
6. 06Map once, reuse often. Map these artefacts to the AI Act, the NIST AI Risk Management Framework and ISO/IEC 42001 in one table, so one body of evidence serves several frameworks and customer questionnaires.

Why do it now

Enterprise buyers are already asking these questions in security reviews, regardless of the Act's dates. Teams that can answer with logs and test results close deals faster than teams that answer with policies.

What to measure

• Traceability. The share of production decisions you can reconstruct end to end from logs: input, context, output, decision and any override.
• Evaluation coverage. The share of model and prompt changes shipped with stored test results.
• Oversight in practice. How often people review and override decisions, and how quickly.
• Open findings. Red-team and risk findings, by age, until they close.

How we would start

Classify your AI systems by risk level under the Act with your counsel, then pick the highest-risk one and check which of the artefacts above exist today. Our LLMOps, evaluation and guardrails work builds most of them, and private deployment covers data that must stay in your control.