If you build, deploy, or sell AI systems into the European market, you probably saw the headlines in May 2026 and exhaled: the EU AI Act's toughest deadline has been pushed back. For overstretched compliance and engineering teams, that sounds like a reprieve.
It isn't at least not the kind you can act on by doing nothing. The delay is real, but it was granted because the work is hard, the technical standards aren't finished, and regulators expect serious preparation to already be underway. For teams that respond to the extension by parking AI compliance for another year, the new timeline is less a gift than a trap.
This guide breaks down exactly what changed, what is still due in 2026, and most importantly what the Act actually requires you to test before your high-risk AI system can be placed on the EU market. If you walk away with one idea, make it this: conformity testing is the long pole in the compliance tent, and the organisations that start now are the ones that will be ready in time.
What actually changed in May 2026
The EU AI Act entered into force on 1 August 2024 as the world's first comprehensive, horizontal AI regulation. Its obligations were always designed to roll out in waves: the ban on prohibited AI practices took effect in February 2025, obligations for general-purpose AI (GPAI) model providers landed in August 2025, and the most demanding wave the rules governing high-risk AI systems was originally set for 2 August 2026.
That third wave is what moved. As part of the European Commission's "Digital Omnibus on AI" simplification package, EU lawmakers reached a provisional agreement on 7 May 2026 to defer high-risk obligations:
- Annex III high-risk systems (use-case-based recruitment, credit scoring, education, biometric identification, critical infrastructure, law enforcement, migration and border control) now apply from 2 December 2027, a 16-month postponement.
- Annex I high-risk systems (AI embedded in regulated products such as medical devices, machinery, lifts and radio equipment) moved from 2 August 2027 to 2 August 2028.
The European Parliament endorsed the agreement on 16 June 2026, with formal adoption and publication in the Official Journal expected in July 2026. Until that publication happens, the original dates technically remain on the books which is one more reason not to down tools.
The reason for the delay matters for your planning. Lawmakers acknowledged that the harmonised technical standards and compliance tools companies need to demonstrate conformity are still being written. In other words: the deadline didn't move because the work got easier. It moved because the supporting machinery isn't ready and that machinery is exactly what your testing and documentation must eventually map to.
What's still due in 2026 don't celebrate yet
Here's the part the celebratory headlines skipped: not everything moved to 2027. Several obligations remain firmly anchored in 2026.
- Transparency obligations stay on schedule. The broader Article 50 duties including the requirement to clearly disclose to users when they are interacting with an AI system, and to label AI-generated content continue to apply from 2 August 2026.
- Watermarking of AI-generated content (the machine-readable marking obligation under Article 50(2)) applies from 2 December 2026.
- New prohibitions were added to the Act, including a ban on AI systems that generate child sexual abuse material or non-consensual intimate imagery, with compliance required from 2 December 2026.
- AI literacy duties continue to apply to providers and deployers, with a softened obligation to "take measures to support the development of" AI literacy among staff.
If your product uses generative AI to produce text, images, audio or video, or if it interacts conversationally with users, you have 2026 obligations regardless of the high-risk delay. Validating that your disclosures fire correctly, that watermarks survive real-world content pipelines, and that your prohibited-use guardrails actually hold under adversarial pressure is squarely a software quality and AI testing problem and the clock on that part has not been reset.
Why the delay is a trap if you wait
It is tempting to read "December 2027" and reallocate the budget. Three realities make that a mistake.
1. Conformity testing is slow, sequential work. A high-risk AI system can't be certified in a sprint. Providers must complete a conformity assessment, register the system in the EU database, stand up a quality management system, and activate post-market monitoring before the system goes to market. Deployers must implement human-oversight mechanisms, retain automated logs for a minimum period, and where required conduct Fundamental Rights Impact Assessments. Each of these depends on evidence that only structured testing can produce. Working backwards from December 2027, a serious programme needs most of 2026 and 2027 to execute.
2. Standards are arriving late, and retrofitting is expensive. The harmonised standards that will define "good enough" are still in draft. Teams that build their test strategy around the Act's underlying principles now will adapt cheaply when the standards finalise. Teams that wait for a finished rulebook will be retrofitting evidence under deadline pressure, which is where costs and mistakes multiply.
3. The delay is conditional. Until the amendment is formally adopted and published, the original August 2026 deadline remains the letter of the law. Building a compliance plan on an extension that is "expected" but not yet enacted is a documented enterprise risk. Mature teams prepare for the binding date and treat relief as upside.
The throughline: the organisations that will sail through conformity in 2027 are the ones treating 2026 as build-and-test time, not a holiday.
What the EU AI Act actually requires you to test
This is where compliance stops being a legal abstraction and becomes an engineering and QA programme. High-risk obligations (Articles 9–17 for providers, Article 26 for deployers) translate into concrete, testable requirements. Here's how to think about each.
Data governance and bias testing
The Act demands that training, validation and test datasets be relevant, representative, and examined for bias. In practice, that means measurable testing: slicing model performance across demographic and edge-case cohorts, quantifying disparate error rates, and demonstrating that mitigation actually improved outcomes rather than masking them. This is rigorous data analysis and validation work, not a one-line fairness claim in a policy document.
Accuracy, robustness and cybersecurity testing
High-risk systems must perform consistently and resist manipulation. That breaks into three test streams: accuracy benchmarking against declared metrics, robustness testing under noisy, shifted, or out-of-distribution inputs, and adversarial security testing prompt injection, data poisoning, model evasion, and extraction attacks. The security dimension overlaps heavily with established penetration and security testing discipline, applied to the model and its surrounding pipeline rather than just the application layer.
Human oversight validation
Article 14 requires that humans can meaningfully oversee a high-risk system understand its output, interpret it correctly, and intervene or override when needed. That is a testable property. You validate that override controls work under realistic conditions, that the interface surfaces the right confidence and explanation signals, and that "human in the loop" isn't a rubber stamp on an automated decision the operator can't actually contest.
Logging, traceability and post-market monitoring
The Act requires automatic event logging and continuous post-market monitoring. From a QA perspective, this means verifying that logs capture the right events with the right fidelity, that traceability holds from input to decision, and that monitoring can detect model drift and performance degradation in production. Standing this up reliably is a test automation and continuous monitoring challenge the same regression and pipeline-integration muscles you already use, pointed at model behaviour over time.
Technical documentation as conformity evidence
None of the above counts unless it's documented to a standard an auditor will accept. The Act and its supporting standards lean on structured, repeatable documentation, closely aligned with the ISO/IEC/IEEE 29119 testing-documentation family. Producing test plans, test reports, traceability matrices and conformity evidence in that format is a discipline in itself and it's where many internal teams discover their testing "happened" but was never captured defensibly. Rigorous QA documentation is what turns testing activity into a conformity dossier.
Is your AI system "high-risk"? A quick self-check
Before you invest in a full conformity programme, confirm scope. Most AI systems are not high-risk but misclassifying one that is can be costly.
Ask, in order:
- 1Is it a prohibited use? Social scoring, certain biometric categorisation, manipulative or exploitative systems are banned outright these aren't "high-risk," they're off-limits.
- 2Does it fall under Annex III? This is the big one. If your system is used for recruitment or worker management, credit or insurance scoring, access to education or essential services, biometric identification, critical infrastructure, law enforcement, or migration and border control, assume high-risk until proven otherwise.
- 3Is it a safety component of a regulated product? AI inside a medical device, vehicle, or machinery governed by EU product-safety law (Annex I) is high-risk though the revised definition of "safety component" narrows this where the AI only assists or optimises without creating health or safety risk.
- 4Does a transparency-only obligation apply? Chatbots, emotion-recognition systems, and generative-content tools may not be high-risk but still owe disclosure and labelling duties from 2026.
If you answered "yes" or "unsure" to questions 2 or 3, you're in scope for the full high-risk regime and your testing programme should start now. Industries like banking and finance, healthcare, and HR-tech sit disproportionately in Annex III territory, which is why regulated-sector teams are moving first.
How an independent testing lab gets you conformity-ready
There's a structural reason to bring in an external partner for AI Act conformity rather than relying solely on the team that built the model: independence. Conformity evidence is more credible when the people validating bias, robustness and oversight aren't the same people whose model is under review. An independent, ISTQB-certified testing lab provides that separation, plus the standards fluency most internal teams haven't had time to build.
A mature engagement typically covers four things: a scoping and risk-classification assessment to confirm which obligations actually apply; a structured test programme across data governance, bias, robustness, adversarial security and human oversight; production-grade logging and drift monitoring; and an ISO 29119-aligned documentation package that doubles as your conformity dossier. Done well, this isn't a compliance tax bolted on at the end it's the same quality engineering that makes your AI system more reliable and trustworthy in the first place.
It also dovetails with the broader trend toward governing AI quality systematically. The new ISO/IEC 42001 AI management-system standard gives organisations a framework for ongoing AI governance, and aligning your AI Act conformity work with it means you build the muscle once and reuse it as regulations evolve.
Start now: a 2026 readiness checklist
You don't need the final harmonised standards to make real progress this year. A practical 2026 roadmap looks like this:
- Inventory every AI system touching the EU market purpose, data, decisions affected, and populations impacted.
- Classify each system against prohibited, high-risk (Annex III / Annex I), and transparency-only categories.
- Close 2026 obligations now disclosure, content labelling, watermarking readiness, and prohibited-use guardrails.
- Baseline your high-risk systems with bias, accuracy and robustness testing so you know the gap you're closing.
- Stand up logging and monitoring before you need it for post-market obligations.
- Document in conformity format from day one, so testing produces audit-ready evidence, not rework.
Treat December 2027 as the exam date and 2026 as the syllabus. The teams that pass comfortably will be the ones that started while everyone else was celebrating the delay.
Frequently asked questions
Has the EU AI Act been cancelled or weakened? No. The Digital Omnibus on AI postponed high-risk deadlines and simplified some administrative requirements, but the Act's core risk-based architecture prohibited practices, high-risk obligations, GPAI rules and transparency duties remains intact. Timelines shifted; the obligations did not disappear.
When is the real deadline now? High-risk Annex III systems: 2 December 2027. High-risk Annex I (product-embedded) systems: 2 August 2028. But transparency obligations apply from August 2026 and watermarking from December 2026, so some duties are already imminent.
Can't we just self-assess and skip external testing? Some lower-risk systems allow self-assessment, but high-risk conformity demands defensible, independent evidence across data quality, bias, robustness, security and human oversight. Self-attestation without rigorous, well-documented testing is exactly what auditors and market-surveillance authorities probe.
What does AI Act testing actually produce? A conformity dossier: test plans and reports, bias and robustness results, adversarial security findings, human-oversight validation, logging and monitoring verification, and an ISO 29119-aligned documentation set you can present during conformity assessment and registration.
Ready to find out where you stand?
The deadline moved, but the smart money is already testing. The fastest way to know your real exposure is a scoping assessment that maps your AI systems to the Act's obligations and tells you exactly what to test and in what order.
Get a free EU AI Act readiness assessment from Testriq's AI testing experts. We'll classify your systems, identify your 2026 and 2027 obligations, and hand you a prioritised testing roadmap aligned with ISO/IEC 42001 and ISO 29119.
Don't wait for the standards to land. Start building the evidence now so that when conformity comes due, you're ready, not racing.
