The EU AI Act for technical teams: what it requires for testing and evidence
What the EU AI Act requires in terms of testing and evidence, explained for the technical teams that have to comply with it.
The European Union’s AI Regulation (EU AI Act) usually reads like a dense legal text written for lawyers. But much of what it requires for high-risk systems is not legal work: it is engineering and QA work. Risk management, logging, accuracy testing, human oversight, robustness. This guide translates that part (Articles 9 to 15, the technical heart of the regulation) into what a technical team has to be able to do and demonstrate. It is, in practice, the mandatory face of Responsible AI: what you have to be able to prove, not just declare.
First, three pieces of context worth having clear.
The essentials before you start
Who it applies to. It is a European Union regulation, but it does not apply only to European companies: it reaches any provider, wherever it is based, that places its AI system on the EU market or whose system’s output is used there, even if the company has no offices or formal commercial ties in Europe. The reach is similar to that of the GDPR (the General Data Protection Regulation, the European privacy law). Within that universe, the most demanding obligations fall on high-risk AI systems, those in Annex III: critical infrastructure, education, employment, access to essential services (including credit), law enforcement, migration, among others.[1] If your AI makes or influences decisions in any of those areas, you probably fall into this category.
By when. The application date for high-risk Annex III systems is August 2, 2026.[2] Important and in flux: in November 2025 the European Commission proposed, through the “Digital Omnibus” package, relaxing some deadlines (with a political agreement reached in May 2026), but at the time of writing the measure was still in the legislative process, and analysts recommend planning as if August 2026 were the firm date.[3]
What happens if you do not comply. Penalties escalate by tier: up to 35 million euros or 7% of annual global turnover for the most serious infringements (prohibited practices), and lower amounts for high-risk non-compliance or incorrect information.[4] Authorities can also withdraw the system from the European market.
With that in mind, here is the walk through the seven technical articles.
Article 9: Risk management system
It requires a continuous and systematic process of identifying, analyzing, evaluating, and controlling risks across the entire lifecycle of the system, including post-deployment monitoring.[5]
What this means in practice: it is not a document you draft once. It is a living process in which you identify your AI’s risks (for example, that it hallucinates in a critical domain or that it discriminates), measure them, mitigate them, and measure again. Systematic quality evaluation is, literally, the engine of this article.
Article 10: Data and data governance
It calls for quality measures on the data used to develop the system: relevance, representativeness, absence of errors, and attention to potential bias. This applies to training, validation, and test data, when the system actually trains a model on that data.[5:1]
What this means in practice: if your company builds its agent on top of an already trained model (GPT, Claude, or another) without training its own, which is the case for most conversational agents today, the regulation itself recognizes that difference: Article 10(6) clarifies that in those cases the quality requirements apply only to the test data, not to training data the company does not even have. In practice, for a good part of those who test with ArtificialQA, Art. 10 boils down almost entirely to this: having well-built, representative test datasets with attention to bias.
Article 11: Technical documentation
It requires complete technical documentation, which Annex IV breaks down into nine sections, prepared before going to market and kept up to date throughout the system’s life. Two of those sections are directly about testing: one asks for the accuracy and robustness metrics together with the logs and reports of each test, dated and signed by those responsible; the other asks for a post-market monitoring system that actively collects and analyzes performance throughout the system’s useful life, with thresholds that trigger a correction. The other seven sections (general description, development process, risk management, version changes, standards applied, and the declaration of conformity) are the responsibility of the team that builds and documents the system.[5:2]
What this means in practice: the technical documentation is not completed once before launch. It needs dated and signed test reports, and a living process of continuous monitoring in production, although the bulk of the document is development work, not testing work.
Article 12: Record-keeping
It requires the system itself to automatically record the events of its real operation, without human intervention, throughout its useful life, so that what it did and when can be reconstructed in a review.[5:3]
What this means in practice: this is an engineering requirement on the system in production, the automatic logging of real conversations and decisions. It is different from the test history a QA team builds, and one does not replace the other: you will probably need both.
Article 13: Transparency and information
It requires the system to come with clear instructions for use for whoever deploys it: capabilities, limits, the accuracy levels with their metrics (which refer back to Article 15), robustness, cybersecurity, and the human oversight measures. It is a document the system’s provider writes and signs.[6]
What this means in practice: that document needs real numbers to be completed, not estimates. The accuracy, robustness, and per-group performance metrics your evaluation produces are an input to that document; they do not replace it or write it.
Article 14: Human oversight
It establishes that systems operate under meaningful human control: the people who supervise must understand the system, be able to intervene, and override decisions to prevent or mitigate risks. The regulation is specific on one point: that person has to be able to monitor the system’s operation and detect anomalies or unexpected performance, and stay alert to the tendency to over-rely on what the AI says.[7]
What this means in practice: there are two distinct testing angles here. One is verifying that the agent itself hands off to a human in the cases where doing so is a risk measure, not just a customer preference (sensitive queries, decisions the system should not make alone), and measuring how often it does so correctly. The other is giving the human responsible for supervising the system real, periodic information on how it has been responding in each run, so they can monitor, detect anomalies, and decide whether to intervene. Without that information, the human oversight the regulation asks for stays on paper.
Article 15: Accuracy, robustness, and cybersecurity
It requires that systems reach appropriate levels of accuracy, robustness, and cybersecurity throughout their useful life, withstand errors and adversarial attacks, and (key detail) that the levels and accuracy metrics be declared in the instructions for use.[8]
What this means in practice: you have to measure your system’s accuracy and be able to declare it with a defensible number. You also have to test its robustness against unexpected or adversarial inputs. If accuracy degrades over time, it must be detected and corrected, which connects again to continuous monitoring.[9]
The complete map: requirement → what you have to be able to demonstrate
| Article | Requires | Supporting evidence |
|---|---|---|
| 9: Risk management | Continuous process of identify/measure/mitigate | Systematic evaluations repeated over time |
| 10: Data | Quality and attention to bias | Test datasets (and only test data, if there is no in-house training) |
| 11: Technical documentation | Nine sections, two on testing and monitoring | Dated/signed test reports and runs scheduled over time |
| 12: Record-keeping | Automatic logs of the system in production | Separate engineering requirement, outside ArtificialQA’s scope |
| 13: Transparency | Instructions for use with declared accuracy levels | Metrics that feed that document, without writing it |
| 14: Human oversight | Human control and ability to intervene | Risk-based handoff, plus reports that sustain the supervisor’s monitoring |
| 15: Accuracy and robustness | Declared levels, resistance to failures | Accuracy metrics and robustness tests |
The cross-cutting reading of the table is what matters: a good part of the technical body of the EU AI Act (above all Articles 9, 10, 14, and 15) is largely satisfied by producing evaluation evidence. Others (11 and 13) feed on that evidence without being exhausted by it. And at least one (12) is a separate engineering requirement. The regulation defines what must be demonstrated; testing is a central piece of that demonstration, not the only one.
A distinction that avoids overspending
When a team faces the EU AI Act for the first time, it often confuses two things that are different:
- Governance platforms (GRC: governance, risk, and compliance) manage policies, system inventories, approval flows, and documentation. They help you organize compliance and know what you should test.
- Evaluation platforms generate the technical evidence: the measurements of accuracy, hallucinations, bias, robustness, and handoff that Articles 9 to 15 require.
They are not competitors; they are layers. But it is worth not buying one expecting it to do the other’s job. A GRC platform will not measure whether your agent hallucinates; an evaluation platform will not manage your policy register.
Where ArtificialQA fits
Not equally across all seven articles. ArtificialQA connects to your AI agent (by URL or by API, no code) and solidly covers four of the seven: it helps organize what to test for each identified risk as part of the Article 9 risk management system, not just as evidence after the fact; it tests bias and data accuracy on the Article 10 test datasets; it verifies risk-based handoff to a human and provides the history that sustains the continuous monitoring by the human supervisor that Article 14 asks for; and it measures the accuracy and robustness that Article 15 requires.
In two others, it contributes a part, not the whole: its dated reports feed two of the nine sections of the Article 11 technical documentation (test metrics and post-market monitoring), and its accuracy and performance metrics are an input to the Article 13 instructions for use, although that document is written and signed by the system’s provider.
One is left out: the automatic logging of the system in production that Article 12 requires is an engineering requirement on the live system, distinct from a QA team’s test history.
Its AI evaluators come calibrated out of the box, against the judgment of human experts, so the numbers it delivers withstand the scrutiny of an audit. But that is not enough for everything: no tool “certifies” your compliance on its own, and formal conformity also involves conformity assessment, an EU declaration, the system’s own automatic logging, and other steps that go beyond testing. Measuring, reviewing those results, and adjusting (the continuous process Article 9 requires) is the foundation on which everything else is built, and it is, precisely, the part a technical team can start producing today, without waiting for every regulatory detail to be clarified.
Frequently asked questions
Does the EU AI Act apply to me if I am not in Europe? It may apply to you if your AI system is used or has effects in the EU market, regardless of where your company is located. Verify your case with legal counsel.
What is a “high-risk” AI system? They are the systems listed in Annex III (used in areas such as credit, employment, education, healthcare, or essential services) on which the most demanding technical obligations fall (Articles 9 to 15).
When do the high-risk obligations take effect? The reference date is August 2, 2026, although an EU proposal (“Digital Omnibus”) could relax certain deadlines. It is worth verifying the current status and planning as if the date still held firm.
Is testing enough to comply with the EU AI Act? Not on its own, and it does not cover the seven articles equally. Systematic evaluation (testing the system and scoring its results against a criterion) produces the technical evidence required above all by Articles 9, 10, 14, and 15, feeds part of what Articles 11 and 13 ask for, and does not cover the automatic logging of Article 12. Formal conformity also includes conformity assessment, documentation, and other steps. Testing and evaluation are the foundation, not the entire building.
What are the penalties for non-compliance? They escalate by tier, up to 35 million euros or 7% of annual global turnover for the most serious infringements, with lower amounts for other non-compliance. Authorities can also withdraw the system from the market.
Product Manager of ArtificialQA at QAlified, with 15+ years in software testing and automation. She works at the intersection of quality and AI: designing and evaluating approaches to test non-deterministic systems and ensure their behavior in production.
Related articles
