Rules · 2026-10-10 · 5 min read
Software becomes a product: Europe's strict liability change
From 9 December 2026, standalone software and AI systems fall under the EU's new Product Liability Directive. The rules introduce strict liability for personal injury, property damage and data loss, along with new obligations to disclose evidence.
What changes on 9 December 2026
Software has existed for decades, but liability for it has mostly been a matter of contract. That changes in December.
Directive (EU) 2024/2853 on liability for defective products makes standalone software a product, just like a washing machine or a toy [1]. AI systems, whether embedded or standalone, fall explicitly within the definition. For anything placed on the market after 9 December 2026, strict liability applies: the injured person does not have to prove fault, only that the product was defective, that they suffered harm and that the defect caused the harm.
Think of it like a faulty brake on a bicycle. You don't have to show that the manufacturer was careless; you show that the brake didn't work as it should have, and that it caused you to fall. The same reasoning now covers software.
The directive covers death and personal injury, damage to property not used exclusively for professional purposes, and destruction or corruption of data not used exclusively for professional purposes [1]. If your customer's factory system goes down and costs them a week's production, that is not covered. If your app corrupts a consumer's family photos, it is.
Who is liable
The manufacturer is the first in line. If the manufacturer is outside the EU, the importer takes the same responsibility [1]. In some cases, distributors and online platforms can also be held liable, for example when the manufacturer cannot be identified.
Standalone software counts as manufactured when it is developed, and it is placed on the market when it is made available [1]. A security patch pushed to a device already in use is not a new product, but a completely new version might be.
The directive also addresses AI's particular challenges. Software can change its behaviour over time through learning or updates, and several parties may contribute to a single AI system. The directive says that if a defect arises from such changes, and the manufacturer had a duty to monitor or control those changes, they remain liable [1].
The evidence rules
Liability turns on proof. The injured person must show three things: the product was defective, they suffered damage, and the defect caused the damage. That has always been difficult when the product is software and the manufacturer holds all the information.
Two new rules tilt the balance.
First, courts can order the defendant to disclose relevant evidence [1]. The directive sets conditions: the claimant must already have presented facts and evidence that support the plausibility of the claim, and they must have shown that they cannot reasonably obtain the evidence themselves. The court must also weigh proportionality, protecting trade secrets and confidential information where appropriate.
Second, in certain cases, the claimant gets what the directive calls evidential relief [1]. If the defendant has superior knowledge or means of proof and does not comply with a disclosure order, or if proving causation is excessively difficult because of the technical complexity of the product, the court may presume the defect or the causal link, provided the claimant has shown it is likely. That shifts the burden: the defendant must then prove the product was not defective, or that the defect did not cause the harm.
For software, that means you may be asked to show what your system did on a given day. If the claimant has made a plausible case and you cannot or will not provide the evidence, a court may simply assume the defect existed.
What a digital witness does here
The thing to seal is each release: the build fingerprint, the release notes and the test results. Seal it when you cut the release. If you deploy to customer systems, seal each deployment event as well: which version went where, and when.
WitniumChain takes a fingerprint of the record, not the record itself, so the details stay in your systems. When a court or a claimant asks which version was running on a particular device on a particular day, you can show the sealed release record and the deployment log. Anyone you share them with can check that they haven't changed since they were sealed, even by someone with administrator rights.
It doesn't show that the version was free of defects. That is a separate question. What it does is give you a record of what you shipped and when, in a form that is hard to argue with later.
How it would work
- At release, your build pipeline sends a fingerprint of the release package and its metadata to WitniumChain and gets a witness ID back.
- At deployment, the same happens: a fingerprint of the deployment event (version, device identifier, timestamp) is sealed.
- When the question arises, you provide the records and the witness IDs. The other party calculates the fingerprints and checks them against what was sealed.
Your system sends the fingerprint through the REST API, the SDK or the MCP server. The content never leaves your infrastructure. The first 2,000 witnesses a month are free. Read the docs.
What this means for you
If you build or sell software in the EU, or to EU customers, ask yourself:
- Could we show which version of our software was running on a given device on a given day?
- Where do we keep release notes, test results and deployment records, and could we produce them unchanged a year later?
- If a court asked us to disclose evidence about a defect, what would we hand over, and in what form?
- Do we have a process for monitoring behaviour changes in AI systems we have placed on the market?
The directive does not say how to keep your records. It says you may be ordered to disclose them, and that refusal or inability to do so can go against you. Deciding now what to seal, and sealing it as you go, is simpler than reconstructing it under time pressure when someone has been harmed.
What to watch
9 December 2026: deadline for member states to transpose the directive into national law [1]. In Sweden, the government has proposed a new Product Liability Act to enter into force on that date [2].
Sources
- Directive (EU) 2024/2853 of the European Parliament and of the Council on liability for defective products, 23 October 2024, https://eur-lex.europa.eu/eli/dir/2024/2853/oj
- En ny produktansvarslag (A new Product Liability Act), Government of Sweden, draft bill (lagrådsremiss), August 2026, https://www.regeringen.se/rattsliga-dokument/lagradsremiss/2026/08/en-ny-produktansvarslag/
- Time to prepare: Europe's product liability changes and what they mean for Australian manufacturers, Clayton Utz, September 2026, https://www.claytonutz.com/insights/2026/september/time-to-prepare-europe-s-product-liability-changes-and-what-they-mean-for-australian-manufacturers
Sources
- [1]Directive (EU) 2024/2853 on liability for defective products, European Parliament and Council, 2024-10-23
- [2]En ny produktansvarslag, Government of Sweden, 2026-08
- [3]Time to prepare: Europe's product liability changes and what they mean for Australian manufacturers, Clayton Utz, 2026-09