The EU AI Act for technical teams: what it requires for testing and evidence

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.

First, three pieces of context worth having clear.

The essentials before you start

Who it applies to. 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 training, validation, and test data: relevance, representativeness, absence of errors, and attention to potential bias.^[5:1]

What this means in practice: you have to be able to demonstrate that your data —including test data— is adequate and that you are actively looking at bias. This is where well-built evaluation datasets come in.

Article 11 — Technical documentation

It requires detailed documentation demonstrating that the system meets the requirements, prepared before it goes to market and kept up to date.^[5:2]

What this means in practice: the documentation must rest on real evidence —test results, metrics— not on claims. An evaluation report is part of the input.

Article 12 — Record-keeping

It mandates the automatic recording of events (logs) during system operation, to ensure traceability across the lifecycle.^[5:3]

What this means in practice: you have to be able to reconstruct what the system did and when. A history of evaluations —ideally immutable— contributes directly to this traceability.

Article 13 — Transparency and information

Systems must be designed and documented so that users, regulators, and auditors understand their capabilities, limits, and decision logic. This includes explainability and disclosure that it is an AI.^[6]

What this means in practice: your evaluation scores must be explainable —not an opaque number— and it must be clear what each one measures.

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.^[7]

What this means in practice: this is one of the articles where testing provides the most direct evidence. Verifying that your agent hands off to a human when appropriate —and measuring how often it does so correctly— is demonstrating human oversight in action.

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

The cross-cutting reading of the table is what matters: almost the entire technical body of the EU AI Act is satisfied by producing evaluation evidence. The regulation defines what must be demonstrated; testing is what produces the demonstration.

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 (GRC) platforms 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, 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

In the evidence layer. ArtificialQA connects to your AI agent —by URL or by API, no code— and produces exactly the measurements the regulation’s technical body asks for: factual accuracy (Art. 15), bias tests (Art. 10), handoff to a human (Art. 14), explainable scores (Art. 13), and an evaluation history that provides traceability (Art. 12). And because it calibrates its own AI judges, the numbers it delivers withstand the scrutiny of an audit —which is, in the end, what all of this is about.

It is not magic or a legal shortcut: no tool “certifies” your compliance on its own, and formal conformity also involves conformity assessment, an EU declaration, and other steps that go beyond testing. But measurable evidence 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. Testing produces the technical evidence required by Articles 9 to 15, but formal conformity also includes conformity assessment, documentation, and other steps. Testing is 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.