What the EU AI Act means for your test plan

A QA lead at a recruitment software company got an email from legal: "Can you send us the test evidence for the CV ranking model?" She had test results. She did not have them organised by risk, dated, linked to a version, or signed off by anyone. It took three weeks to assemble what should have taken an afternoon.

The EU AI Act does not ask QA teams to test differently. It asks them to prove what they tested, and to keep proving it after launch.

This article is general information, not legal advice. Talk to your legal or compliance team before making decisions.

Short version

• The EU AI Act sorts AI systems into risk tiers, and the duties follow the tier.
• Most testing duties land on high-risk systems, such as AI used in hiring, credit, or education.
• The theme for QA is evidence: dated, versioned, and traceable to a requirement.
• Post-launch monitoring is part of the rules, not an optional extra.
• Timelines have been subject to proposed changes, so confirm current dates with your legal team.

---

What the law is, in one paragraph

The EU AI Act is a European regulation covering AI systems placed on the EU market or used in the EU. It applies whether or not your company is based in Europe. Like the GDPR, reach follows the market, not the office address. It entered into force in August 2024, and its obligations switch on in stages rather than all at once.

The risk tiers, explained simply

The Act sorts systems by what could go wrong for people, not by how clever the technology is.

There is a separate set of duties for general-purpose AI models — the large foundation models other products are built on. If you build products on top of someone else's model rather than training your own, those duties mostly sit with the model provider, but you may need documentation from them.

Two practical notes.

Your role matters as much as your tier. The Act distinguishes providers, who develop and place a system on the market, from deployers, who use one. If you buy a hiring tool and use it on candidates, you are a deployer, with lighter but real duties. If you build and sell it, you are a provider. Some changes to a bought system can make you a provider of it.

One product can hold several tiers. A recruitment platform might have a high-risk CV ranking feature, a limited-risk chatbot, and a minimal-risk search box. Classify per feature.

What actually lands on QA

If you work on a high-risk system, these are the parts of the rules that turn into work on your test plan.

1. Testing against defined requirements

The Act expects high-risk systems to be tested against the purpose they were designed for, with metrics that are appropriate and declared in advance. In practice, that means writing down your acceptance thresholds before you test, not after.

Weak: We test the ranking model for accuracy.

Strong: For the CV ranking model v4.2, top-10 precision must be at least 0.72 on the held-out set of 8,000 applications from 2024-2025. Selection rate for each protected group must sit within 0.8 to 1.25 of the highest group's rate.

The second version can be audited. The first cannot.

2. Data governance evidence

You need to be able to describe your training, validation, and test data — where it came from, what it covers, what it does not, and what you did about bias.

QA usually owns the test set. Document for each set: its size, its date range, which populations appear and in what proportion, and any known gaps. A one-page data sheet per set is enough, and it must be versioned.

3. Accuracy, robustness, and cybersecurity checks

Three separate things, and teams often only test the first.

• Accuracy — does it get the right answer on realistic data?
• Robustness — does it hold up on messy input, edge cases, and errors? Test malformed input, missing fields, unusual encodings, and how the system behaves when a dependency fails.
• Cybersecurity — can it be manipulated? For language-model features, this includes prompt injection, where hidden instructions in user content change the system's behaviour.

Record results for all three, per version.

4. Human oversight, tested as a feature

High-risk systems must allow people to oversee them, including the ability to intervene or stop the system. That is testable, and it is often untested.

Write test cases for it:

1. A reviewer opens a decision. Can they see the inputs that produced it?
2. Can they override the output, and is the override recorded?
3. Can they stop the system entirely, and how fast?
4. Does the interface show the confidence or limitations of the output?
5. Does the interface avoid pushing the reviewer toward agreeing automatically?

Case 5 covers automation bias — the tendency of people to trust a machine's suggestion without checking. A screen that pre-selects the AI's answer and requires two clicks to disagree is a design problem with a legal edge.

5. Logging

High-risk systems must automatically record events over their lifetime, at a level that supports tracing how a result was produced. QA should test that the logs actually contain what an investigation would need: input reference, model version, output, timestamp, and any human override.

Test the logs by using them. Take a decision from last month and try to explain it using logs alone.

6. Post-market monitoring and incident reporting

The duties do not stop at launch. Providers of high-risk systems must monitor performance in real use and report serious incidents to authorities within set deadlines. That means someone has to notice, and noticing needs a process.

For QA, this usually turns into: a sampling routine on live outputs, a defined threshold for what counts as a serious incident, and a clear escalation path with names on it.

The dates

Obligations phase in over several years from entry into force in August 2024. The broad shape has been:

• Bans on prohibited practices and AI literacy duties applying first, in early 2025
• General-purpose AI model obligations following in 2025
• The main body of obligations, including most high-risk duties, applying from August 2026
• A later date, around August 2027, for high-risk AI that is a safety component of products already covered by other EU product rules

Treat these as orientation, not as a compliance calendar. The phasing has been the subject of proposals to adjust timing, and some details depend on standards and guidance still being finalised. Ask your legal team for the current dates that apply to your specific product and role.

A five-step plan for a QA team

1. Classify each feature. Write one line per AI feature: what it does, who it affects, and which tier you believe it falls in. Send it to legal for confirmation. Do not decide this alone.
2. Find your evidence gaps. For any high-risk feature, ask: could I produce dated test results, tied to a version, against a written threshold, for the last three releases? Whatever you cannot produce is the gap.
3. Write thresholds before the next release. Turn vague goals into numbers with a date and an owner.
4. Build the evidence pack template. One folder per release containing the test plan, the data sheets, the results, the known issues, the human oversight test cases, and a sign-off with a name and date.
5. Set up the live sampling routine. Decide how many production outputs get reviewed each week, by whom, and what triggers escalation.

Step 4 is where most of the pain disappears. If the pack is produced every release as a matter of routine, an audit request becomes a file transfer instead of a project.

Evidence quality: two examples

Weak: "Regression suite passed. 412 tests green."

Strong: "Release 4.2.0, 14 April 2026. Regression suite v4.2 (412 cases) passed on build 8871. Fairness check run on holdout-2025-q4 (8,000 records): selection rate ratio 0.91 across the four largest groups, above the 0.8 threshold. Two known issues open: AI-3312 (low confidence on CVs under 200 words) and AI-3320 (timeouts above 40 concurrent requests). Signed off by M. Okafor, QA lead."

The second one answers the questions an auditor will ask without a follow-up email.

Frequently asked questions

Does the EU AI Act apply to us if we are not in Europe?

It can. The rules generally follow the market, so systems placed on the EU market or whose output is used in the EU can be covered regardless of where your company sits. Confirm your position with legal.

We only use a third-party AI tool. Do we have obligations?

Possibly, as a deployer. Deployer duties are lighter than provider duties but still include things like using the system as intended and ensuring human oversight. Substantially modifying a bought system can change your role.

Is a chatbot high risk?

Usually not by itself. A general customer support chatbot typically falls under transparency duties, meaning users must know they are talking to AI. It can become high risk if it makes or materially supports decisions in a listed area such as credit or employment.

What test evidence should we start keeping today?

Dated results tied to a specific model and code version, tested against thresholds written in advance, plus a description of the data you tested on. Add sign-off by a named person. Those four things cover most of what gets asked for.

Is this article legal advice?

No. It is general information to help you plan testing work. Your obligations depend on your product, your role, and current guidance, so check with qualified legal counsel.