The finished device and its AI must be examined together
AI embedded in a physical product can be relevant to product liability when its behaviour affects the product's expected safety and causes covered damage. The software may be a component while the finished device is itself a product. Neither classification makes liability automatic. The AI product liability framework explains how to connect the product, safety issue, responsible operator, harm and evidence under Directive (EU) 2024/2853.
Examples include software guiding a robot, interpreting a sensor or adapting a device's operation. The relevant failure might originate in the model, its integration, a physical component or their interaction. A device branded AI-enabled should therefore be investigated as an operating arrangement. Identifying the model without the hardware state, or examining the hardware without its software version, can miss the actual incident conditions.
Identify every safety-relevant layer
Record the product model, serial number and hardware revision. Link them to firmware, AI model, application code and configuration present when the incident occurred. A manufacturer's current software download may not match the version installed on the affected device. Preserve release and update evidence before ordinary maintenance overwrites the history. Where the device relies on a remote capability, record the relevant service and connection state.
Follow the path from input to action. A sensor measurement might be filtered, interpreted by a model, converted by control logic and executed by a motor. Safety can depend on interlocks, mechanical limits and human intervention at several stages. The absence of one safeguard cannot be assessed sensibly without understanding what the other layers were supposed to do and what actually happened during the event.
Expected safety includes foreseeable interaction
Article 7 considers all relevant circumstances, including presentation, instructions, reasonably foreseeable use, learning behaviour and the foreseeable effects of other products used together. For an embedded system, those circumstances can include the operating environment, user capabilities, expected maintenance and how the AI interacts with the device's physical limits. A warning is relevant evidence, rather than a substitute for the complete safety assessment.
A device may follow its control algorithm exactly and still raise a safety question. Conversely, a surprising movement does not establish a defect if another supported explanation accounts for it. Preserve the physical condition, installation records and external influences alongside model evidence. The analysis of unexpected AI output explains why an unusual result must be connected to a legally relevant safety failure and harm.
Map manufacturers and components
Article 8 addresses the manufacturer of a defective finished product and a defective component manufacturer where integration or interconnection within the manufacturer's control caused the product to be defective. The final manufacturer's responsibility can include damage caused by such a component. That rule does not make every upstream software supplier liable, because the component's defect and causal contribution still require examination.
Determine who supplied the model, who integrated it, who manufactured the device and under whose name the finished product was marketed. Contracts and interface specifications can help explain design responsibility. Article 11's component exemption can matter where the product's defectiveness is attributable to its design or the instructions given by the finished-product manufacturer. A role map should therefore retain both technical responsibility and the evidence supporting the statutory classification.
Learning and updates extend the investigation
An embedded AI system may change through local learning, a downloaded model or a remote configuration. Article 7 expressly includes the effect of continued learning or acquiring features after supply. Article 11 limits reliance on a later-arising-defect exemption for specified matters within manufacturer control, including software and necessary safety updates. Neither provision means every later change creates liability.
Preserve update permissions, installed versions, adaptation settings and the last known safe configuration. Establish whether the incident behaviour existed before a change or appeared afterwards. Where reverting the device is necessary for safety, document the original state as far as practicable without endangering anyone. A rollback that removes the symptom may identify a useful lead, but can leave unresolved whether the problem originated in the model, configuration or interaction with hardware.
Covered damage and the physical product distinction
Article 6 covers specified personal injury, property damage and data damage categories, with exclusions. Damage to the defective product itself is excluded. The exclusion also addresses a product damaged by a defective component integrated or interconnected by its manufacturer or within its control. Therefore, destruction of the device containing an allegedly defective AI component is not automatically a recoverable property claim under this Directive.
Damage to separate property or a person's injury requires its own factual and legal analysis. The corrected product scope starts after 8 December 2026, distinct from the 9 December 2026 transposition deadline. Article 10's proof rules and conditional presumptions remain applicable. An investigation should preserve physical evidence and digital records together, while avoiding a conclusion that either the AI label or the visible damage alone proves responsibility.
A physical inspection and a software investigation should share one event chronology. A broken sensor discovered after an impact may be a cause, a consequence or an unrelated condition. Similarly, a diagnostic fault recorded after shutdown might describe the response to the incident rather than its origin. Time-stamped observations and preserved uncertainty prevent either team from treating its first finding as the complete explanation.
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.