Software and Product Liability: What Changes Under the New EU Rules

A car part and a spreadsheet are now the same thing

Under the old rules, a brake disc was a product and a piece of software was not. From 9 December 2026, they are both products, at least in the eyes of product liability law. That is the main shift in the new EU Product Liability Directive, and it matters to anyone who builds, sells or runs software ^[1].

The directive is explicit: standalone software, including AI systems, is a product ^[1]. If that software causes personal injury, damage to property not used exclusively for professional purposes, or destruction or corruption of data not used for professional purposes, the producer can be held strictly liable. Strict liability means the injured party does not have to prove fault, only that the product was defective and caused the damage ^[1].

In Sweden, the government proposed in August 2026 that a new Product Liability Act transpose the directive, entering into force on 9 December 2026 ^[2]. The rules apply to products placed on the market after that date.

What the rules cover

The directive covers three types of damage: death or personal injury, damage to property not used exclusively for professional purposes, and destruction or corruption of data not used exclusively for professional purposes ^[1].

That last one is new. If your software corrupts a customer's family photos, that is covered. If it corrupts a company's invoicing database, it is not, because the data was used for professional purposes. The line is clear: this is consumer protection, not a rule for business-to-business disputes over pure financial loss.

The directive also introduces rules about evidence. Courts can, under certain conditions, order a defendant to disclose relevant evidence, and if the evidence is particularly complex or the defendant holds it exclusively, the burden of proof can shift ^[1]. That makes it harder for a producer to say nothing and wait for the claim to collapse.

What this means for producers

Say someone is injured and they claim your software was at fault. You may need to show which version was running at the time, what it did and what it contained. That is harder than it sounds, especially if the incident happened months or years earlier.

Version control systems keep a history of the code, but they were built for collaboration, not for evidence. A Git commit log shows what was checked in, not what was deployed or when it ran. A deployment log can be edited by the same people who wrote it. If the log has been changed, quietly or not, you have a problem before the case has even started.

The law does not say how you must keep records, only that you may have to produce them when something goes wrong. So the practical question is this: if a court or an insurer wanted to know what your software did on a particular day, could you show it?

How a digital witness fits here

In this case, the thing to seal is each release and each deployment event. That means the build fingerprint, the release notes, the test results and a record of when and where each version was deployed. The fingerprint is taken of the record, not of the entire codebase, so the code itself never leaves your systems.

Sealing happens at release and at deployment. When a release is ready, you send a fingerprint of the release package and its metadata to WitniumChain through the REST API, the SDK or the MCP server, and you get a witness ID back. When the release is deployed, you seal a record of the deployment event: the version, the environment, the timestamp and the person who approved it.

Months or years later, if someone asks which version ran on 15 March 2027, you calculate the fingerprint of your deployment record again and check it against the sealed one. If it matches, the record is exactly what was written on that day. Change a single character and it will not match.

Anyone you share the record with can check it the same way: customers, insurers, notified bodies and, if it comes to it, a court. They do not have to trust you, because the check is independent. The first 2,000 witnesses a month are free, and fuller instructions are in the documentation.

How it would work

1. At each release, seal the build fingerprint, release notes and test results.
2. At each deployment, seal a record of the version, environment and approver.
3. When questioned, share the record and let anyone check that it has not changed.

What a digital witness does not do

It shows that a record existed at a given time and has not changed since. It does not show that the version was free of defects, that it was the right version to deploy or that it performed as intended. Those are separate questions, and they still rest on testing, quality assurance and documentation.

A sealed deployment record is not a defence on its own. It is a baseline: proof that the record you are relying on is the one you wrote at the time, not one you polished afterwards.

What this means for you

If you build or sell software, here are three questions worth asking now:

• Could you show which version of your software was running on a given day, and what it contained?
• If a customer or a court wanted to see your deployment history, would your records hold up to scrutiny?
• Who in your organisation can edit the records that would matter in a product liability claim, and would a change show up?

The law does not require a particular method, but it does require you to be able to produce the evidence. Starting now, before something goes wrong, is easier than trying to reconstruct it later.

What to watch

The deadline is 9 December 2026 for products placed on the market after that date ^[2]. If you release software, embedded or standalone, that is the date to mark. Between now and then, the implementing acts and guidance will flesh out the details, so it is worth following what the European Commission publishes on product liability and AI.

For software that also qualifies as a high-risk AI system under Annex III of the AI Act, the logging requirements in Article 12 apply from 2 December 2027 ^[3]. Those are different rules with a different purpose, but they point in the same direction: you will need to show what your system did, and the records need to hold up.