EU AI Act AI evaluation evidence: what to collect before a high-risk system goes live

A practical guide to connecting EU AI Act technical documentation and record-keeping requirements to repeatable tests, traces, human review, and release evidence.

‍Scope: Practical evidence planning for teams developing or deploying AI systems that may fall within the EU AI Act's high-risk requirements. Confirm classification, role, applicability, and timing with qualified counsel or your competent authority.

For a high-risk AI system under the EU AI Act, an audit-ready evidence record joins each release to its technical description, risk and data decisions, repeatable evaluation results, relevant logs and traces, human review, incidents, and corrective actions. A test score on its own is not an audit record. An audit-ready record explains what was tested, against which expectation, on which version, with what result, who reviewed it, and what changed next.

The EU AI Act separates several obligations that teams often collapse into one vague idea of “compliance evidence.” Article 11 concerns technical documentation. Article 12 concerns automatic logging and traceability for high-risk AI systems. Articles 9, 10, 14, and 15 cover risk management, data governance, human oversight, and accuracy, robustness, and cybersecurity. Articles 17 to 20 add quality management, documentation keeping, automatically generated logs, and corrective actions for providers. The evidence map below turns those requirements into records an engineering, QA, risk, or compliance team can actually maintain.

Start with a versioned evidence record, not a folder of screenshots

The first record should identify the system and its intended purpose. Give every release a stable version identifier and connect the following items to it:

intended purpose, users, operating context, and reasonably foreseeable misuse;
architecture, model and prompt versions, retrieval or tool configuration, and dependencies;
applicable risk classification and the risks the team is managing;
datasets or scenario sources used for validation and testing, including their provenance and known limits;
evaluation suites, metrics, thresholds, test date, environment, and result;
traces or logs that show what the system did during a test or production interaction;
human reviewer decisions, escalations, overrides, and unresolved disagreements;
incidents, complaints, monitoring signals, corrective actions, and approval to release.

This record should be updated as the system changes. Keep the evidence readable outside the tool that generated it. Export a stable report or machine-readable record, preserve timestamps, and record the people or services responsible for each decision.

What Articles 9 to 15 mean for evaluation evidence

The AI Act's high-risk requirements are not a checklist for an evaluation vendor to certify on your behalf. They are a set of system and organisational responsibilities. Evaluation evidence supports those responsibilities when it is tied to the decisions and controls the team is expected to operate.

AI Act area	Question the evidence must answer	Useful records to retain
Article 9, risk management	What risks were identified, estimated, mitigated, and reviewed throughout the system lifecycle?	Risk register, hazard or misuse scenarios, mitigation decisions, residual risk, review dates, and links to tests that verify each control.
Article 10, data and data governance	How were training, validation, and testing data selected, examined, and governed for the intended purpose?	Dataset or scenario provenance, inclusion and exclusion rules, quality checks, representativeness limits, bias tests, privacy controls, and data-change history.
Article 11, technical documentation	Can a competent authority or notified body understand the system, its purpose, design choices, performance, and compliance evidence?	Current system description, instructions, architecture, model and data documentation, risk controls, evaluation methodology, results, and change history.
Article 12, record-keeping	Can the team reconstruct relevant events and the system's operation over its lifetime?	Automatic logs, timestamps, system version, inputs and outputs where appropriate, tool or retrieval events, operator or reviewer actions, and monitoring records.
Article 14, human oversight	What can a human understand, monitor, override, or stop, and when must they intervene?	Reviewer guidance, escalation rules, override logs, intervention tests, sampled decisions, reviewer training, and evidence that the system does not silently defeat oversight.
Article 15, accuracy, robustness, and cybersecurity	Does the system perform as intended and remain dependable under foreseeable variation, misuse, and attack?	Accuracy and quality metrics, adversarial and edge-case tests, robustness results, security tests, failure analysis, thresholds, regressions, and release decisions.

The official AI Act Service Desk explains Article 11 as requiring technical documentation before a high-risk system is placed on the market or put into service, kept up to date, and prepared clearly enough for authorities and notified bodies to assess compliance. Article 12 requires high-risk systems to technically allow automatic recording of events over the system's lifetime, with logging appropriate to the intended purpose and relevant to traceability and post-market monitoring. The Commission's AI Act overview provides the broader risk-based framework and current implementation timeline. Treat the official text and competent legal advice as authoritative. The Service Desk's summaries are explicitly non-binding.

Build an evidence chain from requirement to release decision

A reviewer should be able to follow one line from an obligation or product requirement to the test that checks it and the decision that followed. A practical chain looks like this:

State the expectation. “The assistant must not provide personalised credit eligibility decisions from postcode or other prohibited proxies.”
Turn it into scenarios. Include direct requests, indirect requests, role-play, multilingual variants, incomplete context, and adversarial attempts to bypass the policy.
Define the pass condition. Record the expected refusal or safe response, the metric or rubric, and the threshold. State who owns the threshold.
Run it against a named version. Preserve the model, prompt, retrieval, tool, policy, dataset, and evaluation configuration.
Review the result. Send difficult or flagged cases to a qualified reviewer. Record the verdict, rationale, and any disagreement with an automated judge.
Decide what happens next. Link failures to a fix, accepted residual risk, blocked release, or escalation. Do not silently overwrite a failed run.
Check production evidence. Use monitoring and relevant logs to confirm whether the control holds after release and whether new failure patterns require another evaluation.

This chain is what makes “we tested it” useful. It preserves the expectation, method, result, and accountable decision together.

A worked example: a high-stakes banking assistant

Consider an assistant that answers customer questions about banking products and routes users to support. It handles multiple languages, depends on a knowledge base, and changes when the model, prompt, policy, or source content changes.

The team defines a release record for assistant-2026.10.3:

Purpose and boundary: answer product questions and explain next steps; do not make credit decisions or give personalised financial advice.
Risk scenarios: prompt extraction, requests for out-of-scope advice, attempts to elicit group-based lending decisions, outdated product information, unsafe tool use, and multilingual policy failures.
Test assets: representative customer scenarios, synthetic adversarial variants, policy-specific metrics, and a reviewer sample.
Release gate: every scenario category must meet its threshold; any high-severity safety failure blocks release until reviewed.
Traceability: each result records the assistant version, model and prompt, scenario, response, metric output, reviewer verdict where used, and release decision.
Post-release loop: production monitoring groups new failure patterns, links incidents to the affected version, and triggers a targeted regression suite.

The point is not to claim that this record alone proves compliance. It gives the organisation a defensible way to show how it translated its intended purpose and risk controls into repeatable checks, how humans reviewed difficult cases, and how it responded when evidence changed.

Galtea's public AI evaluation product page describes the operational pieces that support this workflow: synthetic datasets, custom metrics and thresholds, traces, version comparisons, human reviews, CI/CD evaluation gates, and production monitors. It also says Galtea can provide evaluation and monitoring data and traceability to support internal reviews and evidence requirements. That is support for the evidence process, not a substitute for the organisation's legal analysis, technical documentation, quality system, or conformity assessment.

Galtea's ABANCA case study gives a concrete example of the pattern. It describes specification-driven test generation, policy-calibrated judges, pre-release evaluation gating, production monitoring, and a per-release auditable record. The case study reports 2M+ customers, a 71% reduction in evaluation cost per cycle, and zero production incidents since deployment. Those are ABANCA case-study claims, not general results or guarantees.

The evidence checklist

Use this as a starting point for a system-specific review. Mark each item as present, partial, or missing, and assign an owner.

System and documentation

☐ System name, unique identifier, version, intended purpose, users, and operating context
☐ Provider or deployer role, relevant suppliers, and system classification rationale
☐ Architecture, model, prompt, retrieval, tools, dependencies, and configuration
☐ Instructions for use, known limitations, foreseeable misuse, and prohibited uses
☐ Current technical documentation with an owner and last-updated date
☐ Change log showing what changed, when, why, and whether re-evaluation was required

Risk, data, and controls

☐ Risk register linked to mitigations and test scenarios
☐ Data and scenario provenance, quality checks, coverage limits, and privacy controls
☐ Bias and discrimination checks appropriate to the use case
☐ Safety, security, robustness, and misuse scenarios
☐ Human oversight design, intervention points, reviewer instructions, and escalation paths

Evaluation and release

☐ Evaluation suite version, environment, test date, and configuration
☐ Metrics, rubrics, thresholds, and the owner of each quality decision
☐ Representative, edge-case, adversarial, multilingual, and regression scenarios as relevant
☐ Raw or reproducible results, not only a summary score
☐ Human review sample, reviewer identity or role, verdict, rationale, and disagreements
☐ Release decision, approver, exceptions, accepted residual risk, and linked remediation

Logs, monitoring, and incidents

☐ Automatic logging capability appropriate to the system's intended purpose
☐ Version, timestamp, input, output, retrieval or tool events, and relevant user or operator actions
☐ Retention, access, privacy, security, and deletion controls for logs
☐ Production monitoring with alert criteria and an owner
☐ Incident, complaint, malfunction, and corrective-action records
☐ Evidence that monitoring findings feed back into risk review and targeted re-evaluation

FAQs

Is an evaluation report the same as EU AI Act technical documentation?

No. An evaluation report is one input to a broader technical documentation set. Article 11 requires documentation that covers the information necessary to assess a high-risk system's compliance, with the minimum elements in Annex IV. Your legal, compliance, and engineering teams must decide what the complete file contains for the system and role in scope.

Does Article 12 mean a team must store every AI interaction forever?

Article 12 requires high-risk AI systems to technically allow automatic recording of events over the system's lifetime, with logging capabilities appropriate to the intended purpose and relevant to traceability and post-market monitoring. It does not turn every possible data point into an unconditional instruction to retain personal data forever. Define the events, retention, access, privacy, and deletion controls with your legal and data-protection teams.

Do tests and traces prove compliance?

No. They make important parts of the system's behaviour and change history easier to inspect. Compliance depends on the applicable requirements, system classification, role, documentation, controls, governance, and assessment process. A platform can help collect and connect evidence; it cannot make the legal determination for you.

What should happen when a release fails an evaluation?

Keep the failed result. Link it to the scenario, affected version, investigation, remediation, retest, and release decision. If the team accepts residual risk, record who approved that decision and why. Replacing a failed result with a later pass removes part of the history a reviewer may need.

How often should a high-stakes AI system be re-evaluated?

Re-evaluate when the risk, intended purpose, model, prompt, retrieval source, policy, tool, data, or deployment context changes, and at a cadence appropriate to the system's risk and monitoring signals. The right trigger is the system and its controls, not an arbitrary calendar interval.

Where does Galtea fit?

Galtea helps teams generate and run repeatable evaluation scenarios, define metrics and thresholds, compare versions, collect traces, route difficult cases to human reviewers, gate changes in CI/CD, and monitor production behaviour. Those capabilities can support a connected evidence process. They do not replace legal advice, the organisation's technical documentation, its quality management system, or a conformity assessment where one is required.

Connect the evidence to the way your team works

If your team is deciding how to turn AI requirements into repeatable tests, reviewable results, and production follow-up, request a free AI governance review with Galtea. The review is designed to map the tools, policies, and records you have today, then identify where evidence is difficult to demonstrate.