Core claim: Under the revised Product Liability Directive (EU) 2024/2853, software you place on the market — standalone, embedded, or delivered as SaaS — becomes a “product” that can trigger strict, no-fault liability if it is defective, and the directive shifts real evidentiary weight onto the manufacturer: refuse or fail to disclose the technical evidence a court asks for, and defectiveness is presumed against you.

What changed: code stopped being exempt

For forty years, EU product liability ran on Directive 85/374/EEC, written for tangible goods — a defective toaster, a faulty brake caliper. Software sat in a grey zone: courts and regulators disagreed on whether code, on its own, was a “product” at all, and claimants often had to fall back on national contract or general tort law, which is slower and puts more of the evidentiary burden on the injured party.

Directive (EU) 2024/2853 closes that gap directly. It brings software — including AI systems, and regardless of how it is supplied: on a device, via the cloud, or as SaaS — inside the definition of “product,” alongside digital manufacturing files and digital services that are integral to a product’s operation. Compensable “damage” is widened too, to include destruction or corruption of data, alongside the traditional categories of death, personal injury and property damage. One carve-out matters for a company like ours: free and open-source software stays outside the directive’s scope as long as it is not supplied in the course of a commercial activity. The directive was adopted in 2024; member states must transpose it into national law, and it starts applying to products placed on the market or put into service, by 9 December 2026 — products already on the market before that date stay under the old 1985 regime.

The evidentiary shift: disclosure, or a presumption against you

The part of the directive that should worry engineering leaders more than marketing leaders is not the widened product definition — it is what happens when a claim is filed. The claimant still formally carries the burden of proving defectiveness, damage and causation. But the directive gives national courts a lever that changes the practical burden considerably: if a court orders a manufacturer to disclose “necessary and proportionate” evidence about how the product was built and controlled, and the manufacturer does not comply, the product’s defectiveness is presumed. The same presumption can apply where the claimant shows an obvious malfunction under normal use, or non-compliance with applicable safety requirements. The manufacturer keeps the right to rebut the presumption — but rebuttal requires exactly the kind of evidence that prompted the disclosure order in the first place.

Translate that into a software delivery process: a court, an insurer, or a counterparty’s due-diligence team can ask “show us how this system was built, tested and monitored,” and a team that cannot produce that record does not get to argue the point — the record’s absence argues for them, against them, by default. This is where article 1’s premise closes the loop: provenance evidence — who wrote a given change, what review it passed, what tests it ran against, recorded at the time it happened — is precisely the kind of documentation that answers a disclosure order instead of losing to a presumption.

Why “we’ll deal with it later” doesn’t work here

Product liability defenses under the directive include the familiar “development risk” defense — that the defect could not have been discovered given the state of scientific and technical knowledge at the time the product was placed on the market. That defense is inherently time-stamped: it depends on being able to show what was known, and what was checked, at that moment — not what a team can reconstruct or argue eighteen months after an incident. A retrofitted changelog, a set of recollections in a postmortem, or “we’re pretty sure we reviewed that” is not the same evidentiary category as a contemporaneous, tamper-evident record of the development process. Regulators, insurers and courts are converging on the same expectation from different directions — the Product Liability Directive from the civil-liability side, the Cyber Resilience Act (EU) 2024/2847 from the technical-documentation side — and none of them can be satisfied retroactively.

For a codebase with meaningful AI-authored content, the stakes compound: an AI system embedded in, or constituting, a product falls inside the directive’s product definition too, and “we don’t know which parts of this were AI-generated or how they were reviewed” is the single weakest possible answer to a disclosure order under a strict-liability regime.

Software has left the legal grey zone. From 9 December 2026, a defect in code you shipped is a products case, not just a contracts case — and the deciding factor is increasingly not what happened, but what you can show happened.

This closes the loop from article 1, “Who wrote your code? The provenance gap in AI-built software”: the provenance gap it describes is exactly the evidence gap this directive turns into a legal liability, not just an awkward question from a buyer.

Sources