Can an AI System Be a Defective Product?

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

The short answer

An AI system can fall within a product liability framework when the relevant software qualifies as a product and does not provide the safety legally expected of it. Calling a system artificial intelligence does not establish either defectiveness or liability. Directive (EU) 2024/2853 expressly includes software in its product definition. Its compensation rules still require a relevant product, covered damage, an appropriate economic operator and a causal connection. The AI product liability framework explains how these questions fit together.

The corrected 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 the applicable national legislation must be checked. A later accident involving an older release does not by itself select the new regime. Record when the relevant software or finished product was supplied, rather than using only the date when an output became controversial.

Identify the software before describing the defect

An AI feature can involve model weights, inference software, an application interface, external data and a physical device. The relevant product might be the application, a software component or the assembled device. Model and application names are useful starting points, but their legal significance depends on the actual development and supply arrangements. A developer may supply a component while another company supplies the final product incorporating it.

Do not assume that every statement generated by software becomes a separate product. Equally, a subscription or remote delivery arrangement does not resolve the classification merely because the supplier calls it a service. Describe what was supplied, which functions it performed and how it interacted with the affected person or property. The distinction between an AI model and an AI system helps identify the unit whose safety is being investigated.

Defectiveness concerns safety, rather than every error

Article 7 assesses the safety a person is entitled to expect or that applicable Union or national law requires. Relevant circumstances include presentation, instructions, reasonably foreseeable use, interoperability and the effect of continued learning. A model that gives an inaccurate answer has not necessarily created an unsafe product. Conversely, software can work according to its programmed objective while exposing users to a safety risk inconsistent with the circumstances.

For example, an AI controller might rank navigation routes correctly according to its chosen metric while failing to account for a foreseeable collision risk. The investigation would need to examine the intended operating environment, protective measures, warnings and actual causal mechanism. A claim that the software was innovative, probabilistic or imperfect cannot replace that analysis. Neither can an allegation that any undesirable output must prove a defect.

Separate covered harm from disappointment

Article 6 identifies compensable damage categories, including death or personal injury, medically recognised psychological damage, certain property damage, and destruction or corruption of data not used for professional purposes. It contains exclusions that matter in software incidents. Damage to the defective product itself is excluded, as is damage to property used exclusively for professional purposes. Data used for professional purposes falls outside the listed data category.

A failed business recommendation, lost subscription value or unfair ranking therefore does not automatically become covered damage under this Directive. Other contractual, consumer, discrimination or data protection rules may be relevant, but each has its own conditions. Where an AI output allegedly leads to injury, identify the injury and the pathway from software behaviour to that injury. The existence of an error and a later loss, without that connection, is insufficient.

Identify responsibility and preserve uncertainty

Article 8 identifies potentially liable economic operators. The software manufacturer, a component manufacturer and the finished-product manufacturer can raise different questions. A business described as an AI provider under the AI Act is not automatically the manufacturer liable under the Product Liability Directive. The investigation needs the development, branding, integration and supply facts relevant to the particular legal role.

Article 10 begins with proof of defectiveness, damage and causation. Its presumptions are conditional and rebuttable. Technical complexity can matter where the claimant faces excessive difficulties despite disclosure and demonstrates the relevant likelihood, but simply calling an AI system a black box does not remove the statutory conditions. Preserve competing explanations, such as faulty sensor data, application configuration, installation error or later changes, alongside the suspected model behaviour.

What makes an investigation useful?

Keep the deployed model identifier, application release, configuration and incident timestamp together. Preserve original inputs and outputs where lawful, including transformations applied before a user saw them. Record the safety measures that were enabled, which party controlled them and whether human intervention occurred. An archived supplier description can show what the product was presented as doing, but must be connected to the version actually involved.

A useful conclusion identifies what is known, what remains uncertain and which evidence could resolve the uncertainty. It does not infer liability from the AI label or dismiss an incident because the system behaved probabilistically. Product classification, expected safety, covered damage and causation remain distinct questions. That separation makes both a possible defect and a possible alternative explanation easier to assess under the applicable law.

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.