Software becomes a product in 90 days, and the *evidence rules* change with it

What changes on 9 December

On 9 December 2026, software stops being just code and becomes a product under EU law. The new Product Liability Directive treats standalone software, AI systems included, the same way it treats a faulty toaster: if it causes harm, the maker is strictly liable ^[1].

Liability is strict means you don't have to prove negligence, only that the product was defective and caused the harm. It 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. A broken laptop at home counts; a broken server at the office doesn't ^[1].

The directive also introduces two things that make litigation more pointed. Courts can order defendants to hand over relevant evidence, and claimants get burden-of-proof relief when it's too difficult for them to prove that a product was defective or that the defect caused the harm ^[1]. Think of it like this: if your breadbox at home suddenly catches fire, you don't need to bring a forensics lab to court. The directive shifts some of that weight.

Evidence disclosure and burden-of-proof relief

Under the old rules, a claimant had to prove three things: the product was defective, they suffered damage and the defect caused the damage. The new directive keeps that structure but adds relief where the proof is genuinely hard to come by ^[1].

Burden-of-proof relief works like this. If a claimant shows it's excessively difficult to prove a defect or causation, and they provide evidence that reasonably supports the existence of a defect or causal link, a court can assume the defect or causation unless the defendant proves otherwise ^[1]. It's a presumption, not a free pass, but it matters.

Evidence disclosure is the other half. Courts may order a defendant to disclose relevant evidence that the claimant cannot reasonably obtain themselves. The evidence must be necessary and proportionate, and courts can protect confidential information ^[1]. So if a question turns on which software version was running on a given day, or what the logs show, the defendant may be ordered to produce it.

What counts as a defect in software

A product is defective if it doesn't provide the safety a person is entitled to expect, taking into account things like its presentation, its reasonably expected use and the time it was placed on the market ^[1]. For software, that's less obvious than it sounds.

A car with no brakes is defective. A piece of software with a bug that causes data loss might be, depending on what it was sold to do and what the user reasonably expected. The directive doesn't define 'defect' in a way that makes software easy to judge, and case law will take years to settle.

What's clear is that software updates don't restart the clock. Liability attaches to the version placed on the market, and later patches don't make the earlier version disappear ^[1].

Who is liable

The manufacturer is liable. If the manufacturer isn't in the EU, the importer is. If neither can be identified, the supplier can be held liable unless they identify the manufacturer or importer within a month ^[1].

That matters for anyone who resells, white-labels or integrates software. If you're the one who brought it to market in the EU and the maker is in California, you're on the hook.

What this means for you

If you build, sell or deploy software in the EU, here are three questions worth asking now.

First, could you show which version of your software was running on a given day? Version control tells you what the code was. Deployment logs tell you when it went out. If a court orders you to disclose that, do you have it in a form that holds up?

Second, do your logs show what the software did? Not just errors, but decisions, inputs, outputs and the actions that followed. Article 12 of the AI Act already asks high-risk AI systems for automatic logging ^[3]. The liability directive doesn't require logs, but if something goes wrong, logs are often the only way to show what happened.

Third, how do you protect those records from being questioned later? A log you can quietly edit is a diary. A log you can prove hasn't changed is evidence. Access controls and monitoring are the foundation. An independent check goes further.

How a digital witness helps

Here, the thing to seal is each software release and each deployment event. Sealing takes a fingerprint of the release—build fingerprint, release notes, test results—and records it on a chain where any later change would show. The release itself stays with you. So does the deployment log.

When a court orders disclosure, or when a claimant questions which version ran, you calculate the fingerprint again. If it matches, the record is exactly what it was on the day you sealed it. Change a single character in a release note and it won't match.

Anyone you share the record with can check it the same way, without having to trust you. That's the point of a neutral witness: less to trust, more to check.

What it doesn't do is prove the software was free of defects, or that the deployment was lawful. It shows that the record of what was released, and when, hasn't changed.

Your system sends a fingerprint of each release to WitniumChain through the REST API, the SDK or the MCP server, and gets a witness ID back. The first 2,000 witnesses a month are free. Read the documentation to see how it fits into a build pipeline.

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 which version went where and when.
3. When questioned, calculate the fingerprint again and compare it with the sealed one.

What to watch

The directive applies to products placed on the market after 9 December 2026 ^[1]. In Sweden, the government's draft bill proposes that a new Product Liability Act enter into force on the same date ^[2]. Member States have until then to transpose it.

Watch for case law. The directive is principles-based, and how courts apply 'defect' to software, and when they grant burden-of-proof relief, will take years to settle. The first rulings will set the tone.

If you build software that could cause harm—medical devices, autonomous systems, financial models, anything that makes decisions about people—the safe bet is to assume a court will one day ask what your software did, which version it was and whether you can prove it.