Compensation and AI regulation serve different functions
Directive (EU) 2024/2853 and Regulation (EU) 2024/1689 address different legal questions. The Product Liability Directive concerns compensation for specified damage caused by defective products. The AI Act establishes a regulatory framework for AI systems, certain AI practices and general-purpose AI models, with obligations depending on the relevant category and actor. Compliance with one does not automatically answer the other's conditions. The AI product liability framework focuses on the compensation analysis.
Both instruments can matter to an AI-enabled product incident. A regulatory requirement may help explain expected safety, while a compensation claim still needs the relevant harm and causal connection. Conversely, a product liability investigation may identify a safety issue without first establishing a particular AI Act infringement. Keep the source, legal function and conditions of each proposition clear rather than treating AI regulation as one undifferentiated rulebook.
Their scope is organised differently
The Product Liability Directive includes software within its product definition and addresses relevant components, related services and economic operators. Its focus is not limited to products carrying an AI label. Ordinary software, physical goods and mixed products can all require analysis. An AI application must still be connected to the relevant product and supply facts, rather than assumed to fall into a special automatic liability category.
The AI Act distinguishes systems, models and actors through its own definitions. Its risk-based framework contains different requirements for different situations. A high-risk classification under that Regulation is not itself proof that a product is defective under Article 7 of the Product Liability Directive. Nor does the absence of that classification establish the safety of every AI product. Product defectiveness remains a separate contextual assessment.
Provider and manufacturer are not interchangeable
The AI Act defines provider and deployer roles and addresses responsibilities along the AI value chain. The Product Liability Directive defines manufacturer and identifies other potentially liable operators in Article 8. The same organisation can occupy roles under both instruments, but the conclusions require separate analysis. A commercial title or compliance document should not silently substitute one statutory definition for another.
For example, a model supplier, application developer and device manufacturer may each contribute to one operational system. Which is an AI Act provider for a particular obligation does not automatically decide which manufactured the allegedly defective product or component. Preserve development, branding, integration and supply records. The analysis of potentially liable AI actors explains how those facts relate to the Directive's responsibility rules.
Regulatory findings can be relevant evidence
Article 7's defectiveness assessment includes relevant product safety requirements. Under Article 10, defectiveness is rebuttably presumed where the claimant demonstrates non-compliance with mandatory product safety requirements intended to protect against the risk of the damage suffered. This is a specific connection between the requirement and the harm. It is not a general rule that any administrative infringement proves all elements of a compensation claim.
Identify the exact requirement, whether it applied to the system and actor at the relevant time, and which risk it was intended to address. A paperwork issue and a failure of a safety function may have different evidential significance. Even when a presumption applies, it is rebuttable and the other necessary elements require attention. A successful conformity assessment is likewise relevant evidence rather than a universal immunity from product liability.
Harm categories remain important
Article 6 of the Product Liability Directive specifies injury, property and data damage categories with exclusions. Bias, discrimination, loss of opportunity or dissatisfaction does not automatically satisfy those categories. The AI Act's concern with fundamental rights can therefore be broader than the harm addressed by this particular compensation framework. Other law may provide different routes, but those conditions should be explained separately.
An unsafe AI-enabled product may cause personal injury, while an unfair automated decision may raise a discrimination issue without the same Article 6 damage. These examples illustrate the need to identify the actual harm rather than infer a remedy from the seriousness of the concern. Evidence of breach, damage and causation belongs in separate parts of the assessment, even where some records are relevant to more than one issue.
Check each instrument's dates and current text
The corrected Product Liability Directive applies to products placed on the market or put into service after 8 December 2026. National transposition is due by 9 December 2026, and national implementing law must be checked. The AI Act has its own phased application and current legislative text. Do not copy the Directive's product date into the AI Act analysis or assume every AI obligation commenced together.
A proposal concerning AI liability is also distinct from these enacted instruments and must not be described as adopted law without an official final act. For an investigation, keep separate records of product scope, actor roles, applicable requirements, alleged defect, covered harm and causal evidence. This allows regulatory and compensation questions to inform one another while preserving the legal conditions that decide each issue.
When using an official source, record whether it is an operative provision, recital, guidance document or proposal. A recital can help explain purpose but should not be presented as a substitute for the enacted conditions. A Commission summary likewise supports orientation without replacing the actual legal text.
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.