AI Safety Testing as Liability Evidence

EU Directive-level explanationUpdated 16 October 2026By ProductLiability.help editorial desk

Tests are evidence of safety, rather than a legal verdict

AI safety testing can help show how a product behaved, which risks were considered and whether the alleged failure was foreseeable or reproducible. A passing test does not automatically defeat a product liability claim, and a failed test does not automatically establish liability. Directive (EU) 2024/2853 still requires the relevant product, safety defect, covered damage and causal connection. The AI product liability framework connects those elements with the evidence.

The most useful test answers a defined question about the actual incident or safety expectation. A general capability benchmark may say little about how an application handles missing sensor data, dangerous commands or an unusual but foreseeable user action. Describe the risk being tested and why the chosen scenario measures it. This makes the result easier to interpret than an unexplained overall score.

Match the tested system to the supplied system

Record the model version, application build, configuration, tools, retrieval data and operating environment used in the test. A result from an earlier release may not describe the product involved in an incident. A later corrected release may answer whether a remedy helps without proving how the original system behaved. Keep the relationship between tested and deployed versions explicit.

Also record whether the test used the real interface and safeguards. Testing a model directly can isolate model behaviour but omit application filters, instructions or conversions. Testing only the complete system may conceal which component introduced the unsafe behaviour. Both approaches can be useful if their limits are described. The investigation should avoid comparing results from materially different configurations as though they were measurements of the same product.

Use scenarios tied to foreseeable safety

Article 7 assesses all relevant circumstances, including presentation, foreseeable use, learning, interoperability and safety requirements. Test selection can therefore consider how the product was represented and the environments in which it was foreseeably used. Include relevant error conditions and interactions, rather than only ideal examples demonstrating the intended feature. A narrow successful demonstration may not address a failure occurring under ordinary operating conditions.

Where users are expected to review outputs, test the actual review process. Can the operator see the relevant warning, understand uncertainty and intervene before a harmful action? A theoretical human override may differ from an operational safeguard under time pressure. Preserve how the test represented user capabilities and available information. These details help assess the evidence without assuming that all user groups or settings are identical.

Preserve methods as well as results

Keep the test plan, selection criteria, inputs, raw outputs, scoring method and analyst decisions. Record repeat runs and variability where relevant. An unexplained pass label can conceal a changed threshold, excluded case or manual correction. Retain unsuccessful tests and unresolved issues along with successful results. Their significance depends on the actual risk and release decisions, not on whether they look favourable to one side.

Where later experiments investigate an incident, distinguish original event records from reconstructed scenarios. Document assumptions, unavailable data and changes made for safe testing. A reproduction can support a proposed mechanism, but its strength depends on the match to the original conditions. Failure to reproduce a probabilistic output does not necessarily prove that the event did not occur. Incident logs may provide the missing connection between controlled tests and the real deployment.

Connect evaluation to the legal issues

Testing can support an allegation that a product lacked expected safety, or support a different explanation. A test showing an erroneous output must still be connected to covered Article 6 harm and causation. The fact that a risk existed does not prove that it caused the particular damage. Likewise, an incident outside a test's scope does not establish that the tested safety feature failed.

Article 10's presumptions are conditional and rebuttable. Its non-compliance route concerns mandatory product safety requirements intended to protect against the risk of the damage suffered, not every failed internal benchmark. Its complexity mechanism requires the specified excessive difficulties and likelihood despite disclosure. Describe which test evidence addresses which condition, rather than treating a benchmark score as an automatic shift of the entire burden of proof.

Disclosure, confidentiality and dates

Article 9 provides for necessary and proportionate disclosure of relevant evidence in proceedings when its conditions are met, with confidentiality safeguards. Testing records may be relevant, but that does not create an unrestricted right to every training dataset or proprietary document. Preserve the identity and location of existing records and describe any missing material. Do not imply that an internal testing checklist is itself a universal statutory recordkeeping obligation.

The corrected Directive's product scope begins after 8 December 2026, while transposition is due by 9 December 2026. Check the applicable national framework and relevant product dates. A reliable testing record shows what was tested, why, how and with what limitations. Its practical value comes from explaining the safety mechanism and competing hypotheses, while leaving the legal conclusions to the full evidence and applicable rules.

Version the test report itself. If a result was reclassified after further analysis, retain the earlier classification, reason for revision and person making the decision. A transparent revision history helps readers distinguish a legitimate methodological correction from an unexplained change in the evidence.

Records that help the review

Use the following as a practical starting point. Select and preserve records appropriate to the product, incident and applicable procedure.

Incident-time model, application and configuration identifiers
Relevant inputs, outputs and decision records
Supplier roles and change-control history

Independent educational information at EU Directive level. National implementing law and procedure require separate review.

Primary sources and legal scope

This page explains the EU Directive framework. Check national implementing law, the corrected temporal scope and relevant procedure before applying it to a case.

Source register: corrected scope verified 16 October 2026. Article references identify the legal basis. No qualified legal review or national implementation status is claimed.