The EU AI Act high-risk dates moved, but a production AI system still has to survive customer review, security review, board scrutiny, and misuse. For 2026, the real test is simpler: can your team show evidence before the next review asks for it.
On 29 June 2026 the Council of the EU gave final approval to the Digital Omnibus on AI, setting new application dates for high-risk systems: 2 December 2027 for stand-alone high-risk AI systems and 2 August 2028 for high-risk systems embedded in products (Council of the EU, 29 June 2026). That extra runway is real. Use that time to build reviewable evidence.
For one named AI system, this is the evidence to have ready now. If you need the classification and role-mapping fundamentals first, read what the EU AI Act requires from high-risk AI systems. Here the focus is narrower and more practical: given the new timeline, what should a CTO, CISO, AI lead, or compliance lead prove this quarter.
What the Digital Omnibus Actually Changed
The Digital Omnibus changed the planning horizon, not the evidence burden.
The Council’s 29 June 2026 approval confirmed the dates most teams should now plan around: 2 December 2027 for stand-alone high-risk AI systems, and 2 August 2028 for high-risk AI systems integrated into products such as lifts or toys (Council of the EU, 29 June 2026). The adopted text is available as Council document PE-CONS 30/26, and it amends Article 113 of the AI Act to set those two high-risk application dates. The European Commission’s standardisation page gives the same sequencing and the reason for it: support tools, including standards, should be in place before the high-risk rules apply (European Commission, Standardisation of the AI Act).
Two points of discipline before anyone treats this as settled. First, the Council said the act would be published in the Official Journal shortly and enter into force on the third day after publication. As of 7 July 2026, EUR-Lex still listed procedure 2025/0359/COD as ongoing, so the Official Journal reference and exact entry-into-force date remain points to confirm before publication. Second, the shift is specific to high-risk application dates. It applies only to the high-risk application dates. The other obligations under the Act are unchanged.
That matters because the original timeline still shapes the baseline. Under the AI Act text, the regulation applies from 2 August 2026, with earlier provisions already live: Chapters I and II from 2 February 2025, and several general-purpose AI and governance provisions from 2 August 2025 (AI Act Service Desk, Article 113). The Digital Omnibus moved the high-risk milestones further out. The provisions already in force stayed where they are.
The Delay Is an Evidence Window, Not a Pause
Waiting until late 2027 recreates the exact readiness crunch the Digital Omnibus was meant to avoid.
The obligations that define high-risk readiness all depend on artefacts that take time to produce and validate. Article 9 requires a documented risk management system that runs as a continuous, iterative process across the lifecycle, including testing before a system is placed on the market to identify measures and verify performance (AI Act Service Desk, Article 9). Article 11 requires technical documentation before the system is placed on the market or put into service, kept up to date over time (AI Act Service Desk, Article 11).You can’t assemble any of that credibly in a final quarter.
Treat the runway as a window for four things: defining systems, building test and control evidence, tracking the standards that will support conformity, and assigning ownership. Obligations already in force still apply. Article 50 transparency duties still matter for systems that interact with people or generate synthetic content (AI Act Service Desk, Article 50). Sectoral law, customer due-diligence requests, and internal security review don’t wait for December 2027.
The useful response is evidence readiness for the systems you’ve already deployed.
Production Risk Doesn’t Follow the Regulatory Calendar
A live AI system creates risk whenever it runs, regardless of the regulatory calendar. The useful response is evidence readiness for the systems you’ve already deployed.
A deployed large language model (LLM), a retrieval-augmented generation (RAG) workflow, or a tool-connected agent can leak data, take unauthorised actions, bypass policy, or mislead a user well before any high-risk provision applies. The system is exposed today: to users, to data, to tools and permissions, and often to decisions that carry weight. No regulator has to act for that to matter.
This is where the buyer’s real trigger sits. The next request for AI assurance evidence rarely comes from a regulator first. It comes from a customer security questionnaire, a procurement review, a board or risk committee asking about EU AI Act readiness, or an internal security sign-off before a wider rollout. An agentic workflow gaining tool access is its own trigger. So is a system moving from pilot to production. Each of those asks the same question: can you show how this system behaves under pressure.
Customers, auditors, and security reviewers ask for evidence on their own schedule, whatever the regulatory calendar says.
What the Act Asks You to Evidence
The high-risk regime is, in practice, an evidence specification. Four articles carry most of the weight.
- Risk management (Article 9). A documented, iterative risk management process across the lifecycle, including testing to identify risk measures and verify performance against the Act’s requirements (AI Act Service Desk, Article 9).
- Technical documentation (Article 11 and Annex IV). Documentation prepared before deployment and kept current. Annex IV lists what it should contain where applicable: intended purpose, system versions, design choices, architecture, data requirements, human oversight, validation and testing procedures, accuracy and robustness metrics, test logs, test reports, cybersecurity measures, and monitoring (AI Act Service Desk, Article 11 and Annex IV).
- Accuracy, robustness, and cybersecurity (Article 15). High-risk systems must reach appropriate accuracy, robustness, and cybersecurity and stay consistent across their lifecycle. Article 15 names the threats to resist where appropriate: data poisoning, model poisoning, adversarial examples or model evasion, confidentiality attacks, and model flaws (AI Act Service Desk, Article 15).
- Post-market monitoring (Article 72). A documented monitoring system, proportionate to the technology and the risk, that keeps evidence current after deployment (AI Act Service Desk, Article 72).
Together, these four articles ask the same thing: can you produce documented, testable evidence about how a specific system behaves, and can you keep it current as the system changes.
What to Evidence for One Named System
Pick one AI system or workflow and ask what evidence exists for it today. Five categories cover most of what a serious review will want.
System definition evidence. Intended purpose, system boundary, users, model and provider dependencies, retrieval sources, tools, APIs, permissions, data flows, version history, deployment context, and operator role. Without this, every later finding is ambiguous.
Risk and misuse evidence. Reasonably foreseeable misuse, attack paths, harm scenarios, user impact, business impact, role assumptions, and which residual risks the owner has accepted. This is the layer Article 9 depends on.
Testing evidence. Threat model, access model, test objectives, adversarial test plan, manual testing notes, automated results where used, proof of concept, severity logic, affected components, logs, known limits, remediation guidance, and retest evidence. This is what Annex IV means by validation and testing procedures, logs, and reports.
Control evidence. Input and output handling, retrieval-source controls, guardrails, tool allowlists, least-privilege permissions, human approval for high-impact actions, monitoring, logging, rate limits, incident escalation, fallback behaviour, and rollback procedures.
Lifecycle evidence. The triggers that should force a retest: a change to the model, prompt, data, retrieval source, connected tool, user group, intended purpose, or deployment environment. Article 72 monitoring logic lives here, and it’s why evidence has a shelf life.
Run one honest pass over those five categories for a single system and you’ll usually find the same result: the definition and control layers are partly there, and the testing and lifecycle layers are thin. That gap is the work the runway is for. Our companion piece on whether your AI system is ready for production review walks the same categories from an engineering angle.
Adversarial Testing Becomes Useful When It’s Documented
Adversarial testing earns its place when it produces evidence other teams can reuse.
Article 15 names AI-specific vulnerability classes. Article 9 requires testing for risk management. Annex IV requires validation and testing procedures, logs, and reports. Put those three together and iindependent adversarial testing becomes a source of structured evidence that security, engineering, governance, and compliance can each use. The point: one testing effort, documented well, feeds several reviews.
The wider set of standards points the same way. The NIST AI Risk Management Framework, and its Generative AI Profile (NIST AI 600-1, July 2024), include suggested actions to run adversarial testing at a regular cadence to surface vulnerabilities, misuse scenarios, and unintended outputs (NIST). The OWASP Top 10 for LLM Applications 2025 and the OWASP Agentic AI Threats and Mitigations guide give application-layer and agentic attack taxonomies that structure what to test (OWASP). In Europe, ETSI announced EN 304 223 in January 2026 as a European cybersecurity standard for AI models and systems, naming risks such as data poisoning, model obfuscation, and indirect prompt injection (ETSI). Treat it as supporting cybersecurity evidence, not as an AI Act harmonised standard, unless and until its reference is published in the Official Journal for the AI Act. None of these is a substitute for the Act’s high-risk regime, but together they show that documented adversarial testing is an accepted form of AI risk evidence.
One caution keeps this honest. ISO/IEC 42001:2023 is an AI management system standard for organisation-level governance. ISO frames it as management-system assurance, not proof that one specific system is secure (ISO). A management certificate and a policy library describe how you govern AI. They don’t show how a named workflow behaves under misuse, tool abuse, or data-exposure attempts. That behavioural evidence is a separate layer, and it’s the one most often missing.
Where This Leaves You Before 2027
The date change made weak readiness arguments harder to defend. “The deadline moved, so we can wait” now reads as choosing to spend the only useful part of the delay on nothing.
The stronger position is quieter. Take one AI system already in or near production. Map it against the five evidence categories above. Find out what documented, testable evidence exists today for how it behaves under adversarial pressure, and what would happen if a customer, auditor, or security reviewer asked for it next month. The gaps you find are your work list for the runway.
That’s the job Provion is built to do: independent adversarial testing of AI systems or workflow, with severity-rated findings, remediation guidance, and a structured report your security, engineering, and governance teams can each use. It supports EU AI Act readiness and helps produce structured evidence. It doesn’t certify compliance or replace your counsel. For a fuller view of scope and outputs, see what an external AI red teaming assessment actually includes. To inspect the output format, see what reviewable evidence looks like in an AI System Robustness Assessment report.
If you can name one system and one upcoming review, that’s enough to scope a conversation. Book a scoping call around a single AI system or workflow, and we’ll start from the evidence you already have.
