Software becomes a product: what the *new product liability rules* mean for AI

A toast machine is a product. So is your code.

For decades, a toaster that caught fire was a product liability case, but the software that runs a trading algorithm wasn't. That changes on 9 December 2026.

The EU's revised Product Liability Directive now expressly covers software, standalone and embedded, and it treats AI systems the same way ^[1]. If it reaches the market after that date and causes harm through a defect, the maker faces strict liability: no need to prove they were negligent, just that the product was defective and caused the damage.

For anyone building or selling AI, the new rules reshape the ground between engineering and the law. Version control was built for collaboration. Under product liability, it also becomes your first line of evidence.

What the directive covers

The revised directive covers death and personal injury, damage to property not used exclusively for professional purposes, and destruction or corruption of data not used for professional purposes ^[1]. So a defective navigation system that damages a private car is covered; one that damages a taxi used solely for work is not.

Liability is strict. A claimant does not have to show that the manufacturer was careless, only that the product was defective, that they suffered harm and that the defect caused it ^[1].

For software and AI, a defect can be a bug, a failure to update against a known vulnerability, or inadequate instructions ^[1]. The directive says a product is defective when it doesn't provide the safety a person is entitled to expect, taking into account how it was presented, its reasonably expected use and when it was placed on the market ^[1].

The burden shifts

Product liability cases have always turned on evidence, and the new directive makes that evidence easier to get.

First, courts can order a defendant to disclose relevant evidence, as long as the order is proportionate and protects trade secrets and confidential information ^[1]. A claimant who has shown that the product was defective and that they were harmed can ask the court to require the manufacturer to hand over technical documentation, test results or records showing which version was in use.

Second, the burden of proof can shift. If a claimant shows it is excessively difficult to prove a defect or a causal link, and shows the product likely caused the harm, a court can presume the defect or the link existed, unless the defendant proves otherwise ^[1]. That puts the onus on the maker to show what the software did, and when.

For an AI system, that often means logs, decision records and version histories. When you keep those, and when you can't show they haven't been edited, the other side's lawyer will point that out.

What Sweden is doing

Sweden's government proposed a new Product Liability Act in August 2026, replacing the 1992 law, to transpose the directive ^[2]. The draft bill follows the directive closely: software counts as a product, strict liability applies and the new rules on evidence disclosure and burden-shifting are included.

The proposed act is planned to enter into force on 9 December 2026, the same date the directive requires Member States to apply the new rules ^[2]. Until then, the current law applies, and software is not expressly a product under it.

What this means for you

If you build, sell or deploy software that will reach the market after 9 December 2026, here are three questions worth asking now.

First, can you show which version of your software was running on a given day, and what it contained? Version control tells you what was committed. It doesn't always tell you what was deployed, or prove that a release file is the one from six months ago.

Second, if something goes wrong and you're asked for evidence, what records exist and where are they kept? Logs, decision records, test results and deployment histories matter, but only if they can be trusted. A log your own team can edit is easier to challenge than one where a change would show.

Third, who in your organisation knows that the rules have changed? Engineers, product managers, legal and compliance all need to understand that software is now a product, and that liability follows.

Sealing versions as you release them

This is a case where a digital witness fits well, because the question it answers is exactly the one product liability raises: which version existed, when, and has it changed?

The thing to seal is each software release as it is built: the build fingerprint, the release notes, the test results and, for AI systems, the model version and configuration. When a release is deployed, that event can be sealed too, linking the version to a time and, if wanted, a device or customer.

Sealing takes a fingerprint of the record, not the data itself, so the release files and logs stay on your systems. The fingerprint goes to WitniumChain through the REST API, the SDK or the MCP server, and you get a witness ID back. Later, if a version is questioned, anyone you share the record with can recalculate the fingerprint and check that it matches the sealed one. Change a single byte and it won't match.

What it shows is that the release record and the deployment event existed at that time, unchanged since. What it doesn't do is prove that the version was free of defects, or that it was the version actually running in a particular case. Those are separate questions, but having a checkable release history shortens the conversation.

How it would work

1. At release, your build pipeline sends a fingerprint of the release package, notes and test summary to WitniumChain and logs the witness ID.
2. At deployment, a fingerprint of the deployment event (version, target, timestamp) is sealed and linked to the release.
3. When someone questions which version ran, you share the release record and the witness ID. They check the fingerprint and see it hasn't changed since the day it was sealed.

The first 2,000 witnesses a month are free. The documentation is at witniumchain.com/docs.

What to watch

9 December 2026 is the date to put in the calendar. After that, every software release that reaches the market falls under the new rules.

The AI Act's safety requirements for high-risk systems will also apply from 2 August 2027 for new systems and 2 August 2030 for existing ones ^[3]. For manufacturers whose AI is both high-risk under the AI Act and a product under the liability directive, the safety case built for one increasingly overlaps with the legal exposure under the other.

The question is less whether the rules apply than whether you can show, when it matters, what your software did.