How AI fits product liability
AI product liability concerns responsibility for covered harm caused by a defective product involving artificial intelligence. It is not a rule that every inaccurate answer, unfair result or failed deployment creates a compensation claim. The investigation must identify the relevant product, applicable law, expected safety, harm, causal connection and responsible economic operator. Those questions remain separate even when the technology is difficult to explain or several businesses contribute to one system.
Directive (EU) 2024/2853 provides a modern EU framework that expressly includes software and addresses digital components, learning behaviour and evidence difficulties. It is an important reference point rather than a worldwide code for every AI dispute. National implementing law and procedure remain necessary for an operational national assessment. Other contractual, consumer, negligence, discrimination or data protection rules may address different situations and remedies, subject to their own conditions.
Identify the product before identifying the defendant
An AI-enabled arrangement can contain a model, inference software, application code, external data, interfaces and physical components. The relevant product might be standalone software, a component or the finished device incorporating it. Article 4's product definition includes software, while its component definition can include intangible items and related services integrated into or interconnected with a product. Describe the actual supplied arrangement instead of relying on a marketing label.
The distinction between an AI model and an AI system matters because the same model can appear in applications with different functions, safeguards and foreseeable uses. A model producing a suggestion for review is not operationally identical to an application converting its output into an automatic command. Identify the layer implicated in the alleged defect and preserve the versions and settings of surrounding layers that might explain the event.
An AI subscription or hosted endpoint does not justify assuming that software is outside the product framework. Equally, the presence of software does not turn every activity performed with it into a product. Record what was supplied, its function, the supply relationship and any related physical item. Classification is the starting point for the analysis, rather than a conclusion that a supplier must compensate someone whenever the software disappoints.
Keep the legal dates separate
The corrected Article 2(1) applies the Directive to products placed on the market or put into service after 8 December 2026. This wording reflects the Official Journal corrigendum published on 7 May 2026. National transposition is due by 9 December 2026. The product-scope date and transposition deadline perform different functions and should not be merged into one general statement about when every AI claim changes.
Record first supply, putting into service, later modifications, updates, the incident and discovery of harm separately. An accident after December 2026 does not automatically bring an older product under the new Directive. Nor should every model update be assumed to restart product dates or legal periods. If substantial modification is relevant, assess its statutory conditions and control history. Check national legislation and transitional rules before describing the position in a particular Member State.
Defectiveness is an expected-safety assessment
Article 7 asks whether the product provides the safety a person is entitled to expect or that applicable Union or national law requires. All relevant circumstances matter, including presentation, instructions, foreseeable use, learning behaviour, interaction with other products and relevant safety requirements. A product can operate according to its chosen objective while still raising a safety issue. Conversely, an erroneous result does not necessarily establish a legal safety defect.
The analysis of unexpected AI output separates a surprising result from a supported allegation about safety. Define what happened and why it may be unsafe in the product's actual context. A wrong answer in an entertainment application and a wrong instruction controlling a device cannot be assessed merely by observing that both were inaccurate. Identify foreseeable users, operating conditions, warnings and safeguards, including whether human intervention was practical before harm occurred.
The existence of a safer later product, update or upgrade does not alone establish defectiveness of the earlier one. A recall or corrective action can provide relevant evidence, but the reason for that action and its relationship to the incident still need examination. Preserve technical limitations and competing explanations rather than treating either an improvement or a compliance document as a complete legal answer.
Learning and updates extend the factual inquiry
Article 7 expressly includes the effect of a product's ability to continue learning or acquire features after supply. Distinguish local adaptation from supplier-released model changes and from ordinary probabilistic variability. The system can produce different outputs without learning, while application instructions or retrieval data can change behaviour without changing model weights. A useful investigation identifies the actual state transition and the evidence supporting it.
The model update analysis examines release identity, rollout and manufacturer control. Article 4 defines that control through specified authorised activities and the ability to supply software updates or upgrades. Article 11 limits the later-arising-defect exemption for listed matters within control, including software and missing updates necessary to maintain safety. These provisions affect the analysis without making every later software problem the manufacturer's automatic responsibility.
Identify the harm independently of the error
Article 6 covers death or personal injury, including medically recognised psychological damage, certain property damage and destruction or corruption of data not used for professional purposes. Its exclusions include the defective product itself, specified component-related product damage and property used exclusively for professional purposes. Data used for professional purposes is outside the listed data category. These boundaries should be checked before discussing compensation under this framework.
Bias, discrimination, offence, subscription disappointment and a lost commercial opportunity do not automatically meet those damage categories. Other legislation may address such concerns. Where an AI output allegedly caused injury or property damage, follow the pathway through decisions, interventions and physical or digital effects. A population-level performance disparity or a chronology showing that a loss followed an output does not alone establish the cause of the particular harm.
Map responsibility through actual activities
Article 8 identifies manufacturers of defective products and, under its conditions, defective component manufacturers and other supply-chain operators. An application developer, model supplier and device manufacturer may occupy different positions. The actor mapping for defective AI explains why branding, development, integration, supply route and modification history matter more than an informal title such as technology partner.
The AI Act's provider and deployer categories must not automatically be substituted for the Product Liability Directive's manufacturer categories. Regulation (EU) 2024/1689 has a separate regulatory function and its own definitions, obligations and application rules. Compliance with it does not guarantee immunity from compensation claims; an infringement does not automatically prove covered harm and causation. Identify the precise requirement and legal role under each instrument.
Evidence and presumptions remain structured
Article 10 starts with proof of defectiveness, damage and causal link. Its presumptions are conditional and rebuttable. They address specified disclosure failures, relevant mandatory safety non-compliance, obvious malfunction, typical damage and excessive proof difficulties. The complexity mechanism requires the statutory conditions, including the relevant likelihood despite disclosure. Calling AI a black box does not automatically reverse every burden or decide a claim.
Article 9 provides for necessary and proportionate disclosure of relevant evidence in proceedings where its conditions are met, with safeguards for confidentiality. Preserve incident-time inputs and outputs, model and application identifiers, configuration, change approvals and safety testing. The AI investigation checklist helps organise these records and distinguish established facts, hypotheses and missing information. A sound assessment explains the alleged mechanism while remaining open to evidence supporting a different cause.
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
AI Act compliance and product-liability compensation involve different legal questions. Neither label replaces the other's conditions.
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.