EU Product Liability Directive 2024: Why Software and AI Systems Are Now Strictly Liable Products

The Legal Revolution That Quietly Arrived in November 2024

For sixty years, EU product liability law operated under a principle that seemed obvious: only physical products could be “defective products” capable of triggering strict liability. Software, digital services, and AI systems — being intangible — sat outside this framework. If a software failure caused harm, victims had to prove negligence, breach of contract, or other fault-based theories. The evidentiary burden was high, and most claims failed.

Directive 2024/2853, published in the Official Journal of the European Union on November 18, 2024, ends that era. The new Product Liability Directive explicitly extends strict liability to software, including software delivered as a service (SaaS), and to AI systems. As analyzed by Gibson Dunn, Goodwin Law, and Pinsent Masons, the directive makes three structural changes that every software and AI provider serving EU markets must understand before December 2026.

Change 1 — Software is a “product.” Under the new directive, software is explicitly classified as a product regardless of how it is delivered. A SaaS platform, a mobile application, a cloud-hosted AI model, an embedded firmware update — all qualify. The delivery mechanism (download, subscription, API access) is irrelevant to the classification.

Change 2 — Strict liability, not negligence. Product liability under the directive is strict: the claimant does not need to prove that the defendant was careless, reckless, or negligent. The claimant needs to prove only that: (a) the product was defective (did not provide the safety that users legitimately expected), (b) the defect caused the damage, and (c) the damage occurred. This is an immense shift in litigation economics: cases that previously failed for lack of evidence of negligence now succeed on defect + causation alone.

Change 3 — Evidential burden shift. The directive introduces a disclosure obligation and an evidential burden shift: when a claimant establishes a prima facie case that a product was defective, the defendant must disclose relevant technical documentation. Courts may draw adverse inferences if documentation is not produced. For AI systems specifically, the directive allows courts to presume defectiveness if the provider cannot explain the AI system’s decision-making in a way that allows the claimant to assess whether a defect caused the harm.

Who Is Liable Under the New Framework

The directive adopts a supply-chain liability model that differs significantly from the US product liability framework. Understanding who can be held liable is essential for structuring contracts, insurance, and indemnification chains.

The manufacturer — typically the software developer or AI model provider — is the primary liable party. If the software produces an output that causes harm, the developer bears strict liability.

The importer — an EU-based entity that imports software or AI products developed outside the EU for distribution in the EU market — is liable as if it were the manufacturer. This provision directly targets non-EU SaaS providers that sell to EU customers through EU-based distributors or subsidiaries.

The distributor — an entity in the supply chain that sells or distributes the product to end users — is liable if the manufacturer or importer cannot be identified within one month of a claim, or if the manufacturer is established outside the EU with no EU importer.

The authorized representative — any EU-based entity that accepts responsibility for a non-EU manufacturer’s compliance with EU law — bears liability equivalent to the manufacturer. This provision creates significant risk for EU entities that serve as regulatory representatives for non-EU software companies.

For AI supply chains — where a foundation model provider, a fine-tuning layer, an application developer, and a deployment platform may all be involved — the directive establishes joint and several liability among entities in the supply chain. The claimant can sue any or all of them; they sort out contribution among themselves.

What SaaS Providers and AI Developers Should Do Now

The December 2026 transposition deadline creates an 18-month window that is substantially shorter than it appears for organizations that need to restructure contracts, update technical documentation, and renegotiate insurance coverage.

1. Conduct a Product Defect Risk Assessment for Your Core Software

The directive defines a “defective product” as one that does not provide the safety that persons generally are entitled to expect. For software, this translates to: does the product perform in the way that users could reasonably expect based on its marketing, documentation, and typical use cases? Conduct a structured risk assessment for each product in your portfolio against three scenarios: (a) foreseeable misuse — if a user uses the software in a way that the documentation does not explicitly recommend but that a reasonable person might attempt, does the software produce harmful outcomes? (b) output accuracy — if the software produces incorrect outputs (an AI diagnosis tool that gives a wrong recommendation, a credit scoring tool that makes an error), what is the probability and severity of harm? (c) security failures — if the software is breached or manipulated to produce defective outputs, who bears liability for the resulting harm? This assessment creates the factual basis for structuring your product liability insurance policy and identifying which products require the most urgent contract revision.

2. Update Your SaaS Terms of Service and Liability Caps Before December 2026

Contractual liability caps — standard provisions in SaaS agreements that limit liability to annual subscription fees or specific dollar amounts — remain enforceable between businesses in the EU. However, these caps only limit liability for contractual claims; they do not eliminate liability under the product liability directive. A business customer harmed by defective software can bring a claim under the directive that bypasses the contractual liability cap entirely, using the directive’s strict liability framework rather than the contractual negligence framework. Review each of your standard SaaS agreements to understand how your contractual liability exposure interacts with the directive’s non-waivable minimum rights. Update your terms to explicitly address AI-generated outputs, to require customers to maintain appropriate human oversight for high-stakes use cases, and to document the safety expectations your product is designed to meet.

3. Build Technical Documentation That Can Withstand Judicial Disclosure

The directive’s evidential burden shift creates a direct incentive for software providers to maintain comprehensive technical documentation — because courts can draw adverse inferences when documentation is not produced. Minimum documentation requirements include: a technical specification of the software’s intended purpose and performance envelope; a description of known limitations, failure modes, and out-of-scope use cases; a record of safety testing and quality assurance processes; version control records showing what changed between releases; and, for AI systems, documentation of training data sources, model architecture, and validation testing. As noted by Outlex AI in its analysis of the directive’s AI implications, AI providers face a specific disclosure challenge: courts may presume defectiveness if they cannot explain the AI’s decision-making process in terms that allow a claimant to assess causation. Build explainability documentation into your AI release process now.

4. Restructure Indemnification Chains in Software Supply Agreements

If you are a software distributor, reseller, or platform that deploys third-party software or AI components in products you sell to EU customers, you now have potential liability exposure for defects in those third-party components — even if the defect originated upstream. The directive’s joint and several liability framework means that an EU customer can sue you directly without first pursuing the component manufacturer. Revise your upstream software supply agreements to include explicit indemnification obligations from component providers, requiring them to cover liability arising from product defects in their components, and to maintain adequate product liability insurance. Also revise your downstream customer agreements to establish clear documentation of your reliance on upstream components — this evidence matters for contribution proceedings when multiple parties are jointly liable.

5. Review Your Product Liability Insurance Policy for Software and AI Coverage

Most product liability insurance policies were written with physical goods in mind and contain explicit exclusions for software, digital services, and professional services. With the December 2026 transposition making software strict liability legally operative across the EU, any product liability policy that excludes software coverage will leave your organization uninsured against the directive’s claims. Engage your insurance broker now to obtain a rider or replacement policy that explicitly covers: software product defects; AI-generated output errors; third-party software component defects for which you may bear joint liability; and claims arising from evidential burden-shift proceedings under the directive. Pricing for this coverage is still being established by the EU insurance market — organizations that move early will likely secure better terms than those that wait until the market matures post-December 2026.

The Antitrust Question (and the Broader Signal)

The Product Liability Directive’s extension to software and AI arrives alongside the EU AI Act, the Data Act, the Cyber Resilience Act, and the Digital Services Act — a coordinated stack of digital regulation that collectively imposes product-quality, security, safety, and liability obligations on digital product providers that did not exist five years ago.

The combined effect of these instruments is to import the regulatory expectations of the physical product economy into the digital economy. A medical device manufacturer has always faced strict liability, regulatory approval requirements, post-market surveillance obligations, and product recall authority. The EU is now applying equivalent expectations to AI systems used in healthcare, financial services, and other high-stakes domains.

For non-EU software companies, this is not primarily a compliance challenge — it is a market access condition. Operating in the EU market after December 2026 without product liability coverage, without adequate technical documentation, and without structured indemnification chains is not just legally risky: it is a business model that depends on customers not asserting their legal rights. Given the EU’s enforcement track record on GDPR, that is not a durable business model.

Frequently Asked Questions

Sources & Further Reading

• EU Product Liability Directive: Responding to Software, AI, and Complex Supply Chains — Gibson Dunn
• Product Liability Directive 2026: Software and AI — Outlex AI
• AI Liability, Defective Products, and the Directive — Gaming Tech Law
• Revised EU Product Liability Regime Expands AI/Software Providers — Pinsent Masons
• EU Updates Its Product Liability Regime — Goodwin Law