Does the EU Product Liability Directive apply to software and AI?

Yes. The revised Directive expressly brings software within the definition of a product, including standalone software, AI systems, and digital services integrated into a product's operation. That is the central change from the previous regime, which was drafted around physical goods and left software liability to national law and contract.

Do claimants have to prove the vendor was negligent?

No. Product liability under the Directive is no-fault: a claimant proves a defect, damage, and a causal link between them. Whether the vendor was careful, followed its own process, or met an industry standard is not the question. That is the core difference from a negligence claim and the reason contractual limitation clauses do not neutralise it.

Can a security patch or model update create liability?

It can. The Directive contemplates that a manufacturer retaining control over a product after it is placed on the market — through updates, machine learning, or connected services — remains responsible for defects arising from those changes, and for failing to supply security updates where doing so was within its control.

Does this apply to a US company with no EU entity?

It can reach you indirectly. The regime is built so that an injured person in the EU always has a defendant established in the EU — an importer, an authorised representative, or a fulfilment service provider. In practice that party will look upstream to the vendor for indemnity, which is why the exposure typically arrives through your reseller or distribution contract rather than through direct service of process.

EU Product Liability Directive: Software and AI as Products 2026

Why This Is a Different Animal From the AI Act

The AI Act is regulatory: it tells you how to build and document a system, and a regulator enforces it. The Product Liability Directive is a private right of action. It does not care whether your system is high-risk, whether you filed a conformity assessment, or whether you are inside its scope at all. It cares whether a person suffered damage from a product that was defective — and it lets that person sue.

That distinction matters for budgeting. AI Act work produces documentation that satisfies an authority. PLD exposure is satisfied by insurance, indemnity allocation, and the ability to prove your system was not defective years after the fact. Those are different workstreams, and the second one is usually unstaffed.

What Actually Changed

Software is a product

The old regime was written for physical goods, and whether software qualified was a live argument in most member states. The revised Directive removes the argument: software — including operating systems, applications, firmware, and AI systems — is within scope whether it is supplied on a device, downloaded, or accessed remotely.

Defect is broader than 'it crashed'

Assessment of defectiveness accounts for the effect of learning capabilities after deployment, the effect of other products that can reasonably be expected to interact with it, cybersecurity requirements, and the moment the product left the manufacturer's control. A system that behaves unsafely because it kept learning is not automatically excused.

Compensable damage now includes data loss

Alongside death, personal injury, and property damage, the revised regime recognises destruction or corruption of data that is not used for professional purposes. For a consumer-facing application, that materially widens what a claimant can point to as harm.

Disclosure obligations with teeth

Courts can order a defendant to disclose relevant evidence about the product. If the defendant fails to comply, the product is presumed defective. For an opaque model, that is the practical centre of gravity of the whole regime.

Presumptions for technical complexity

Where a claimant faces excessive difficulty proving defectiveness or causation because of technical or scientific complexity, and has shown the claim is likely, the burden can shift. AI systems are the paradigm case the drafters had in mind.

The chain has more defendants

Manufacturers, importers, authorised representatives, fulfilment service providers, and — where a product is substantially modified — the modifier can all be targets. The design goal is that a claimant in the EU always has someone established in the EU to sue.

The Part US Vendors Underestimate

A US SaaS company with no European entity often concludes it is out of reach. That is usually wrong in effect, if not in form. The exposure arrives through the commercial chain:

Your EU reseller or importer becomes the defendant and then turns to your reseller agreement for indemnity. Whether you owe them anything is decided by a contract you wrote before this regime existed.
Your enterprise customers push the risk down in procurement. The practical first contact most vendors have with the PLD is a redline demanding uncapped product-liability indemnity, not a lawsuit.
Liability caps do not travel. A no-fault statutory claim brought by an injured third party is not bounded by the limitation clause in your subscription agreement, because that third party never signed it.
Your insurance may not follow the definition. Tech E&O and general liability policies were underwritten when software was not a product; confirm whether your policy responds to a statutory product-liability claim over model output.

Where the Defect Argument Gets Won or Lost

Because the disclosure presumption punishes opacity, the vendors who fare best are the ones who can produce a coherent record on demand: what the system was trained and tested on, what safety constraints were in place, what the product told users about its limits, what changed in each update, and when. A vendor who can answer those questions is arguing about defectiveness. A vendor who cannot is arguing against a presumption that it was defective — a materially worse position, and one that is decided by records you either kept or did not.

A Practical Checklist

None of this requires an EU entity to start. Most of it is contract and records work you control unilaterally.

Map which of your products reach EU users, through which importer, reseller, or marketplace— Essential

Read your reseller and distribution agreements for who absorbs a statutory product-liability claim— Essential

Confirm in writing whether your E&O and general liability policies respond to software product-liability claims— Essential

Keep a durable, retrievable record of model versions, training and evaluation data provenance, and safety testing— Evidence

Version and archive your user-facing documentation — what you claimed the product could do is part of the defect analysis— Evidence

Define and document a security-update commitment and support window per product— Post-sale

Treat substantial modification by a customer or integrator as a contractual event with allocated responsibility— Contract

Run disclosure-readiness as a drill: could you produce this record within a court deadline?— Operational

What you claim publicly is part of the defect record

Product pages, capability claims, and disclosure language are the first artefacts pulled in any product-liability analysis. RatedWithAI scans your public properties for the compliance and claim gaps that create exposure. Start with a free scan.

Scan Your Site for Free →

Frequently Asked Questions

Is this the same thing as the AI Liability Directive?

No, and the distinction matters. The revised Product Liability Directive is the no-fault regime covering defective products, and software is now expressly inside it. A separate proposal aimed at fault-based AI claims followed a different and far less settled path. Plan around the product-liability regime; treat anything fault-based as a moving target.

Does open-source software fall within scope?

Free and open-source software developed or supplied outside a commercial activity is treated differently from software supplied in the course of business. Once you monetise it — through support, a hosted edition, or bundling into a paid product — you are supplying it commercially, and the analysis changes.

Can we contract out of it?

Not as against an injured claimant. The regime is protective and does not let a manufacturer limit or exclude its liability toward the injured person. What you can do is allocate the risk between commercial parties through indemnities and insurance, which is why the contract review is urgent even though the liability itself is not waivable.

How far back can a claim reach?

The regime pairs a limitation period running from when the claimant knew or should have known of the damage, defect, and liable party with a long-stop expiry measured from when the product was placed on the market — extended for latent personal injury. For software that is continuously updated, when the clock starts is itself contested, which is another reason version records matter.

We are B2B only. Does that put us outside it?

Not reliably. The damage that counts is suffered by a natural person, and your B2B software can injure an employee of your customer or corrupt an individual's personal data. Selling only to businesses controls who your counterparty is, not who your product can harm.

Where standard policies stop responding to claims over model output.

AI Agent Contract Liability for Businesses 2026

When an autonomous agent binds you, and who absorbs the result.

Reading what a vendor's indemnity actually covers before you rely on it.

EU AI Act Open Source Exemption 2026

Where the open-source carve-out holds and where monetisation ends it.