Software Becomes a Product Under Europe's New Liability Rules

Europe's product liability regime was built for a world of tangible goods: a faulty valve, a defective batch of medicine, a machine that fails in service. The revised EU Product Liability Directive replaces that framework with one that expressly treats software and AI-enabled systems as products. Member states must transpose it into national law by 9 December 2026, and defects in code, in updates and in the digital services bundled with a device will then trigger liability on the same footing as a hardware fault.

The change is significant, but it is not primarily a change in the liability standard. The more demanding shift is evidentiary. Companies will be expected to reconstruct how a product was designed, changed and maintained years after the fact, and courts will be able to order them to hand over the record. The deadline is less about new contract clauses than about whether the organisation can produce a coherent account of its own software.

What the directive brings into scope

The existing regime, adopted in the 1980s, assumed that a product was a movable physical item. The revised directive abandons that assumption. Software is treated as a product irrespective of the mode of its supply, and AI-enabled systems fall within the same definition. Where a manufacturer retains control after the product has been placed on the market — through updates, upgrades or continuous learning — that ongoing involvement is relevant to whether the product is defective.

A defect therefore no longer has to be a flaw present at the moment of sale. An update that introduces a vulnerability, a model that behaves differently after retraining, or a digital service integrated into a physical device can all become the subject of a claim. So can the failure to supply a security update the manufacturer had committed to provide. The directive also extends to components, so a supplier whose software is embedded in another product is not automatically insulated.

The definition of defect remains familiar: a product is defective when it does not provide the safety a person is entitled to expect, taking into account all the circumstances. What has changed is the list of circumstances a court may consider, which now includes the effect on the product of any ability to continue to learn or acquire new features after it has been placed on the market. For software and AI systems, that makes the post-market phase central rather than incidental.

Disclosure, presumptions and the evidentiary burden

Strict liability has always been softened by proof problems. A claimant must show a defect, damage and a causal link, and in complex technical cases that is often where claims fail. The revised directive addresses this through two mechanisms that matter more than the liability standard itself.

The first is disclosure. Courts can order a manufacturer to disclose relevant evidence, including technical documentation, where a claimant has presented plausible arguments and the claim appears well founded. The order must be proportionate and confidentiality protections apply, but the direction of travel is clear: internal records become discoverable material in the litigation.

The second is presumption. Where a claimant faces excessive difficulty in proving a defect or causation — for example because of the product's technical or scientific complexity — a court may presume the existence of a defect or the causal link. The same applies where a manufacturer fails to comply with a disclosure obligation. Presumptions are rebuttable, but rebutting them requires exactly the kind of documentation the disclosure mechanism is designed to reach.

Read together, these provisions change the practical allocation of risk. A company with well-kept records can contest a presumption with evidence of testing, review and remediation. A company without them may find that the absence of a record is itself treated as supporting the claim. Documentation becomes a defensive asset rather than an administrative overhead.

The operator chain beyond the manufacturer

The directive also widens the circle of potential defendants. Where a manufacturer is established outside the EU, an importer, authorised representative or fulfilment service provider can be treated as the responsible economic operator. Fulfilment service providers — the businesses that store, package and dispatch goods for online sellers — are expressly included, reflecting the reality of cross-border e-commerce.

For distributors and platforms, this creates diligence obligations that a contractual indemnity alone does not satisfy. Knowing who the manufacturer is, where it is established and whether an EU representative has been appointed becomes a compliance question with direct liability consequences. A supplier that cannot be identified turns the intermediary into the point of attachment for a claim.

Preparing before December 2026

The transposition deadline gives organisations a fixed point to work towards, but the underlying work is operational rather than legislative. A few priorities follow from the structure of the new regime.

• Align versioning across teams. Model versions, release versions and configuration states should be recorded so that an engineer can reconstruct what a product contained on a given date.
• Keep update and maintenance logs. Records of what was changed, when and why are the core of any post-market defence, particularly where the manufacturer retains control of the product.
• Retain testing and incident histories. Test results, known-issue registers, security advisories and incident reports should be kept for periods that match the directive's limitation and long-stop rules rather than defaulting to routine deletion.
• Map the operator chain. Identify which entity is the manufacturer for each product, whether an EU representative is in place, and which intermediaries could be exposed if the manufacturer is outside the EU.
• Treat disclosure as a design requirement. If a court can order production of technical records, those records should be intelligible to someone outside the engineering team, indexed and retrievable.

Retention periods deserve particular attention. The directive sets long limitation and long-stop periods, and national implementations will vary in detail. Data retention policies built around short operational cycles may not survive contact with a claim brought years after a product was withdrawn.

Interlock with the AI Act and the Cyber Resilience Act

The Product Liability Directive does not operate alone. The AI Act imposes documentation, risk management and post-market monitoring duties on providers of certain AI systems. The Cyber Resilience Act adds vulnerability handling, security update and reporting obligations for products with digital elements. Each regime generates records and reporting duties on its own timeline.

The temptation is to build separate compliance workstreams for each instrument. That approach tends to produce overlapping evidence sets that disagree with one another, which is precisely what a claimant will exploit. A single evidence architecture — one register of versions, one incident log, one documentation repository mapped to all three regimes — is more defensible than parallel silos.

Consistency of statements matters as much as the records themselves. If a technical file prepared for one regime describes a product's behaviour differently from a disclosure produced in litigation, the discrepancy becomes the story.

Conclusion

The revised directive does not invent a new theory of liability. It extends a familiar one to products whose behaviour changes over time, and it gives courts tools to reach the records that explain that behaviour. The organisations most exposed after December 2026 will not necessarily be those with the most complex software; they will be those that cannot explain, with evidence, how their software came to be in the state it was in. Preparing for that question is a legal task and an engineering one, and it is best started now.