Software Is Now a Product: Europe’s New Liability Rules Reach AI, Updates and Data
Europe’s revised Product Liability Directive makes software – including AI systems – a product for liability purposes. Security decisions made after release can now matter as much as the original design.
Directive (EU) 2024/2853 was published on 18 November 2024. It replaces a liability framework written for a world of primarily physical products with rules designed for connected products, software, artificial intelligence and data-dependent services.
Member States must transpose the directive by 9 December 2026. The new regime applies to products placed on the market or put into service after that date.
The headline is simple: software can be a product. The operational consequences are not.
Liability is not limited to faulty hardware
The definition of a product now includes software, whether it is embedded in a device or supplied separately. Applications and AI systems can fall within scope. Digital manufacturing files that control machinery or enable a physical item to be produced are also included.
The directive does not make every software defect automatically compensable. A claimant must still establish damage, defectiveness and a causal relationship, subject to the directive’s rules on evidence and presumptions. But the old assumption that intangible code sits outside product liability is no longer safe.
Damage can include death, personal injury, damage to property and destruction or corruption of data that is not used exclusively for professional purposes. The cost of recovering or restoring data may therefore become part of a claim in qualifying circumstances.
A product can become defective after release
Modern products are not finished when they leave the factory. They receive updates, depend on cloud services and change behaviour through new software or data.
The revised directive recognises that reality. Where software updates, upgrades or related services remain under the manufacturer’s control, defects introduced—or left uncorrected—after release may affect liability.
Cybersecurity is relevant to the assessment of defectiveness. A product may not provide the safety a person is entitled to expect if known vulnerabilities are ignored, security updates are missing, or mandatory safety requirements are not met.
This creates a direct connection between vulnerability management and product liability. A security backlog is no longer only an operational-risk metric. It may become evidence about whether the product remained adequately safe.
AI complicates the evidence
AI systems can be difficult to examine because behaviour depends on models, data, configuration and the surrounding service. Claimants may not have access to the technical evidence needed to explain how a defect caused damage.
The directive provides mechanisms for courts to order disclosure of relevant evidence and introduces rebuttable presumptions in specified circumstances, including cases involving technical or scientific complexity. It does not remove the need for proof, but it can shift the practical balance when essential evidence sits entirely with the manufacturer.
For AI providers, documentation needs to connect model design, validation, deployment conditions, monitoring and change control. A collection of disconnected compliance documents will be less useful than a traceable safety case.
Open source is treated carefully
Free and open-source software developed or supplied outside a commercial activity is excluded. That does not create a universal open-source exemption. If a manufacturer integrates open-source software into a commercial product, responsibility for the resulting product remains with the relevant economic operator.
The practical lesson is to understand provenance and integration. A component inventory should show where software came from, who controls updates, how vulnerabilities are monitored and how the component affects product safety.
What manufacturers should prepare
Before the December 2026 transition, organisations should:
- Identify software, AI systems, digital manufacturing files and related services sold into the EU.
- Map which post-market updates and dependencies remain under organisational control.
- Connect vulnerability handling to product-safety and legal escalation.
- Preserve design, testing, release and incident evidence for the product lifecycle.
- Review supplier and component agreements for access to defect and security information.
- Document substantial modifications and the party responsible for them.
- Test whether customer-facing claims match the product’s real support and safety lifecycle.
Security becomes part of the product promise
The directive does not turn every outage or breach into strict liability. It does make it much harder to separate product safety from software maintenance, security support and operational control.
For connected products, the product is no longer just what was shipped. It is the hardware, code, updates and controlled services that continue to determine whether the product is safe.
Official sources
- Directive (EU) 2024/2853 on liability for defective products
- EUR-Lex summary: Defective products—liability
This article provides general information and is not legal advice.
Continue the series: European National Cyber & Digital Law Series index
