Testing for Compliance: What the EU AI Act Means for QA in 2026

The compliance deadline was not on most engineering teams’ radar until it was. The EU AI Act’s requirements for high-risk AI systems, the ones that affect employment, education, credit, or public services, include a mandate for demonstrated adversarial robustness. The deadline for systems deployed in the EU is August 2026. Systems that cannot demonstrate this robustness face market withdrawal requirements, not just fines.

Adversarial robustness sounds like a security research topic. In this context, it is a QA deliverable. The regulation requires that you can show, with test evidence, that your system behaves correctly under adversarial conditions, meaning inputs designed to cause failure, bias, or unsafe outputs. The test evidence has to be produced by a systematic testing process, documented, and available for regulator review.

This is a new category of QA work for most teams building AI-powered products. It is not the kind of testing that traditional functional test suites cover. It requires a different methodology, different tooling, and a different relationship between QA and the legal/compliance function. This post covers what the Act requires for high-risk systems, how to assess whether your system is in scope, the testing methodology that produces the evidence the regulation asks for, and the documentation structure that makes that evidence usable in an audit.

What the Act Requires and Who Is in Scope

The EU AI Act classifies AI systems into four risk tiers. The highest tier, prohibited applications, are banned outright (social scoring by public authorities, real-time biometric surveillance in public spaces). The next tier, high-risk applications, are permitted but subject to conformity requirements before they can be deployed in the EU. Most commercial AI applications fall in the limited-risk or minimal-risk tiers and face only transparency obligations (certain disclosure requirements).

High-risk is a defined category, not a judgment call. Annex III of the Act lists the specific use cases: AI in critical infrastructure, education and vocational training assessment, employment and HR decisions, credit scoring, insurance risk assessment, law enforcement and border control, judicial decisions, and deployment of AI in essential private and public services. If your system makes or significantly influences decisions in these domains for users in the EU, you are likely in scope.

For the adversarial robustness requirement specifically, Article 15 of the Act requires that high-risk systems be “resilient with respect to attempts by unauthorized third parties to alter the outputs.” This is not a soft requirement to have good security practices. It is a hard requirement to demonstrate resilience through documented testing, with the documentation available for inspection by the national market surveillance authorities in each EU member state.

If you are unsure whether your system is in scope, this is a question for your legal and compliance team with reference to Annex III and the European Commission’s guidance documents. Do not try to interpret “high-risk” on your own for compliance purposes. Get a legal opinion, document it, and let it inform whether you need to run the testing program described below.

The Three Categories of Adversarial Testing the Act Implies

The Act’s language on adversarial robustness does not specify a methodology, which means the methodology is yours to define. This is both flexibility and responsibility. Three categories of adversarial testing are implied by the requirement to demonstrate resilience against output manipulation.

Input perturbation testing checks whether small, plausible changes to inputs cause disproportionate changes in outputs. For a credit scoring model, this might mean varying income figures by small amounts while holding other inputs constant and checking that the score changes proportionally. Large output changes from small input changes are a sign of brittleness. For a hiring screening tool, it might mean adding or removing equivalent credentials across candidate profiles and verifying that similarly qualified candidates receive similar scores. Disproportionate variance indicates the system is not robust to the kinds of minor input variations that occur naturally in real-world data.

Adversarial prompt testing applies specifically to LLM-based systems. It checks whether the system can be manipulated into producing different outputs through crafted inputs: instructions to ignore constraints, role-playing scenarios designed to bypass safety guardrails, inputs in edge-case languages or encodings that the system handles differently than its default behavior. The test corpus should include the attack categories documented in the OWASP LLM Top 10 and any attack patterns specific to the system’s domain.

Bias and fairness testing checks whether the system produces systematically different outputs for protected groups under equivalent inputs. The EU AI Act has an explicit non-discrimination requirement for high-risk systems, and adversarial robustness testing must include checking whether adversarial inputs can amplify latent bias: inputs that are equivalent in every decision-relevant way but differ in demographic indicators should produce equivalent outputs. A system where adversarial inputs can surface differential treatment by gender, nationality, or age is not compliant regardless of its average-case performance.

Building the Test Evidence Package

The regulation requires documented evidence, not just passing tests. An audit-ready evidence package has a specific structure.

The test plan document describes the methodology: which categories of adversarial testing were performed, how the test corpus was constructed, what tools were used, what the pass/fail criteria were, and who was responsible for the testing. The test plan is dated before the testing runs, not written after as a retrospective description. A test plan created after the tests shows a lack of systematic process; a test plan created before shows a designed quality process.

The test corpus is the collection of adversarial inputs used in the testing. The corpus should be versioned, stored in a location that is not modifiable after the testing was performed (or where modifications are tracked), and annotated with the attack category each input represents. A corpus of 200 adversarial inputs, organized by category, with each input labeled with its intended attack vector and the expected correct system behavior, is the format that holds up in regulatory review.

The test results document records the outcome for each test case: the input, the output, whether the output matched the expected correct behavior, and if not, what the failure mode was. Results are stored at the individual test case level, not just as aggregate pass rates. An auditor reviewing your evidence package should be able to look at any individual test case and see exactly what was tested and what the result was.

The remediation log records what changes were made in response to test failures. If the initial testing found that the system produced different outcomes for equivalent inputs differing by gender indicator, the remediation log shows what was changed (model retraining, guardrail addition, threshold adjustment), when the change was made, and the re-test results that show the issue was resolved. A clear remediation loop is evidence that the quality process was effective, not just that tests were run.

The approval sign-off is a documented statement from a qualified person (typically the system’s technical lead plus a compliance or legal representative) that the evidence package is complete, that the testing methodology was adequate, and that the system is compliant with the adversarial robustness requirement. This sign-off closes the conformity assessment for this requirement.

Integrating Compliance Testing Into the QA Process

Treating compliance testing as a one-time audit-prep activity produces an evidence package that passes the initial review and then becomes stale as the system evolves. The regulation requires that systems remain compliant throughout their deployment lifecycle, not just at the point of initial conformity assessment.

The integration strategy embeds adversarial testing into the CI pipeline for each model or significant prompt change. The same test corpus runs as a CI gate, the same results are logged to the evidence repository, and any change that causes a previously passing test to fail is a blocker that requires remediation and re-documentation before the change ships.

The evidence repository is the persistent store for test results. It accumulates results from every CI run, creating an audit trail that shows the system’s adversarial robustness profile over time. If a regulator asks “what was your system’s performance against gender-indicator equivalence tests in January of this year?”, the evidence repository has the answer, with test case-level granularity.

Corpus expansion is a regular activity. The adversarial testing field is active, and new attack patterns are discovered regularly. The team responsible for compliance testing should monitor the OWASP LLM project, the EU AI Act enforcement guidance as it is published, and the academic literature on adversarial attacks relevant to their system’s domain, and add new attack categories to the corpus as they emerge. A corpus that was current at the initial conformity assessment but has not been updated in 18 months is not evidence of ongoing compliance.

The QA-Legal Partnership the Act Requires

Compliance testing for the EU AI Act cannot be done by QA in isolation. The regulation’s requirements are legal and technical, and the evidence package has to satisfy both a technical review (is the testing methodology adequate?) and a legal review (does the methodology satisfy the regulation’s requirements?).

The QA team’s contribution is the methodology, the tooling, the corpus construction, and the test execution and documentation. The legal team’s contribution is the interpretation of which requirements apply, the review of whether the methodology satisfies the legal standard, and the sign-off on the evidence package that makes it defensible in a regulatory review.

This partnership works best when it starts early, ideally before the system’s design is finalized, so that testability requirements can influence the system’s architecture. A system designed without consideration for adversarial testing will have gaps that are expensive to close after the fact: a model that does not support fine-grained output monitoring, a deployment that does not capture enough telemetry to reconstruct what happened during a test run, a prompt structure that makes it difficult to isolate the effects of specific changes. Building in testability is easier than retrofitting it.

The August 2026 deadline for high-risk systems deployed in the EU is not far for teams that have not started. A complete conformity assessment for adversarial robustness, done properly, takes two to three months: corpus construction, initial testing, remediation of failures, re-testing, documentation, legal review, and sign-off. Teams starting in Q2 2026 will be cutting it close. Teams starting this quarter have time to do it correctly.

Compliance as a Quality Driver

The EU AI Act’s adversarial robustness requirement is forcing teams to test a category of system behavior that most were not testing systematically. That is not a bad outcome for the quality of AI systems in general, even if the compliance pressure is the thing that made it happen.

Adversarial robustness testing finds real problems. A hiring tool that scores equivalent candidates differently based on name origin is a real quality problem independent of any regulation. A credit model that produces disproportionately variable outputs under small input changes is a real reliability problem. A conversational AI that can be manipulated into abandoning its constraints with a crafted prompt is a real security problem. The regulation is requiring you to find these problems and document that you found them and fixed them. That process produces a better system, and the documentation produces the evidence that you can point to.

QA engineers who build expertise in adversarial testing methodology, who understand what the Act requires and how to produce compliant evidence packages, who can partner with legal and compliance teams to make conformity assessment work as a quality process rather than a paperwork exercise, are developing skills that will matter for the next decade of AI regulation. The Act is the first; it will not be the last.