Bias and product liability ask different questions
AI bias can be relevant to product safety, but bias or discrimination alone does not automatically establish damage covered by Directive (EU) 2024/2853. The Directive addresses specified harm caused by defective products. Equality, data protection, consumer and AI Act rules can address different risks and remedies. The AI product liability framework explains why product classification, safety, damage and causation must be examined independently.
Bias can describe unequal error rates, unrepresentative training data, systematic measurement problems or decisions disadvantaging particular groups. An investigation should identify the specific phenomenon instead of using the term as a conclusion. The technical finding may support a safety question, a discrimination issue, both or neither, depending on the product and context. A statistical disparity does not alone identify the legal claim or the remedy.
Establish the product and affected function
Identify the application, model, version and decision in which the disparity appeared. A biased output could arise from training, input collection, application thresholds, human interpretation or an interaction among these layers. Preserve the relevant pipeline and population. A general report about the model's behaviour may not describe the deployed configuration or the particular product function involved in the event.
For example, an AI-enabled device might perform less safely for users whose characteristics were poorly represented in testing. That raises a different product liability inquiry from an unfair ranking causing only an unsuccessful business opportunity. Both situations deserve accurate analysis, but they should not be forced into the same compensation category. The product's presentation, foreseeable users and operating conditions provide the context for assessing expected safety.
Bias may inform the defectiveness assessment
Article 7 considers all relevant circumstances, including reasonably foreseeable use, presentation, relevant safety requirements and the specific needs of the group for whose use a product is intended. Evidence that a product performs unsafely for foreseeable users can therefore matter. The question remains whether the product provided the legally expected safety, rather than whether every group received identical performance on every possible measure.
Keep the metric, dataset, sample size and testing conditions with any claimed disparity. An average score can conceal an important safety difference, while a small apparent difference may have another explanation. Testing should examine the product's actual risk and intended environment. The safety-testing evidence guide explains how evaluation records can support or challenge an alleged defect without treating any single performance figure as decisive.
Covered harm must be identified separately
Article 6 includes death or personal injury, including medically recognised damage to psychological health, certain property damage and destruction or corruption of data not used for professional purposes. Its property and data exclusions remain important. Being treated unfairly, receiving an offensive answer or experiencing ordinary distress is not automatically one of those specified damage categories. Medically recognised psychological damage requires more than simply relabelling dissatisfaction.
A claimant alleging covered injury must still connect it to the product's defectiveness. A performance disparity across a population does not by itself prove the cause of an individual injury. Preserve the actual inputs, outputs, decisions and resulting events, alongside comparative evidence. Other legislation may provide remedies for discrimination or fundamental-rights infringements without the same product liability harm categories, but those routes require their own legal analysis.
The AI Act does not replace the compensation test
Regulation (EU) 2024/1689 includes requirements concerning data governance and bias for relevant high-risk AI systems. Its obligations depend on the system's classification, actor, provision and applicable dates. Do not assume that every AI product is high-risk or that every bias allegation establishes a breach. An AI Act compliance finding and a Product Liability Directive compensation claim answer different legal questions.
Article 10 provides a rebuttable defectiveness presumption for demonstrated non-compliance with mandatory product safety requirements intended to protect against the risk of the damage suffered. A general assertion of unfairness or regulatory non-compliance does not establish that condition. Identify the precise applicable requirement and the risk it addresses. Other proof conditions, including damage and causal connection, continue to require separate attention.
Preserve evidence without creating new distortions
Evaluation data can include sensitive personal information. Preserve only through lawful and appropriate processes, while keeping documentation sufficient to understand how tests were performed. Record missing demographic information and proxy assumptions rather than inventing categories. An analysis that silently excludes difficult cases may obscure the very safety difference being investigated. Retain methodological limitations alongside headline findings.
The corrected Directive concerns products placed on the market or put into service after 8 December 2026, with national transposition due by 9 December 2026. National implementing law must be checked. A useful assessment explains the alleged bias, its safety relevance, the actual harm and the supported causal pathway. It neither dismisses discrimination concerns nor assumes that this particular product liability framework compensates every unfair outcome.
Comparative evidence should also distinguish differences in exposure from differences in product behaviour. If one group encountered a more demanding operating environment, that may affect the interpretation without removing the safety concern. Preserve the conditions and explain the comparison. An accurate analysis can recognise an important disparity while remaining cautious about its mechanism, magnitude and connection to the particular alleged injury.
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.
- Directive (EU) 2024/2853, consolidated text: Articles 2, 4, 6, 7, 8, 9, 10, 11 ↗
- Official Journal corrigendum, 7 May 2026: Article 2(1) ↗
Source register: corrected scope verified 16 October 2026. Article references identify the legal basis. No qualified legal review or national implementation status is claimed.