The new product liability rules make software a *provable* problem

A receipt for every version

Engineers have versioned code for decades. You tag a release, push it to production and move on. It's a workflow built for collaboration and rollback, not for a courtroom three years later. From 9 December 2026, that changes. Under the EU's new product liability rules, standalone software becomes a product, AI systems included, and the person injured by it gets a stronger hand ^[1].

Think of it like a car recall. When a brake fails, the manufacturer has to show which parts were fitted, when and in which models. Software has never worked that way. A build artefact might sit in a repository somewhere, or it might not. Deployment logs might tell you what went out the door last Tuesday, or they might have been rotated out to save disk space. The new rules don't care. If someone gets hurt and your software is the reason, you may need to show what it did.

Strict liability, whether it's a robot or a spreadsheet

The 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]. Liability is strict, meaning fault doesn't have to be shown. A defect is enough. Software that makes decisions about people, controls physical systems or handles their data now sits in the same legal category as a faulty kettle.

That's a shift. Until now, product liability in the EU has largely meant physical goods. A few member states extended it to software in their own laws, but most didn't ^[1]. From December 2026, every EU member state will treat software the same way.

Courts can ask for your records

Article 8 of the directive gives courts the power to order a defendant to disclose relevant evidence, including about possible defects, when the claimant has presented facts and evidence sufficient to support the plausibility of the claim ^[1]. Article 9 goes further: if the defendant destroys, withholds or fails to provide that evidence, the court can presume the relevant fact to be proven ^[1].

In other words, if you can't show what your software did, or which version was running, the court can assume the claimant's version of events is correct. That's not a fine. It's the case.

Burden of proof can shift

The directive also introduces burden-of-proof relief. If the technical or scientific complexity makes it excessively difficult for the claimant to prove a causal link between the defect and the damage, the court can presume causation if the claimant shows the product is defective and the damage is of a kind typically caused by such a defect ^[1].

For AI systems, that's worth reading twice. If a model's decision leads to harm, and the claimant can show the model had a defect, the court might presume the defect caused the harm, unless the defendant proves otherwise. The defendant is the one with access to the training data, the model weights and the logs. The claimant has a hospital bill and a screenshot.

What version, and when

Version control tells you what changed between commits. It doesn't tell you what was running in production at 14:32 on a Tuesday in April two years ago. Deployment logs might, if they still exist and nobody has edited them since. A container registry might have the image, if it wasn't pruned. An incident report might mention the version number, if someone wrote one.

That's the gap. You need a record that links a specific software artefact to a specific time and, ideally, a specific event. Git tags and CI/CD pipelines get you halfway there. The rest is about keeping a record you can show later, in a form a court will accept.

Sealing releases and deployments

Here, the thing to seal is each software release and each deployment event. A release fingerprint captures the build artefact, the release notes and the test results. A deployment record captures when a version was pushed to production, which environment and which configuration. Sealing takes a fingerprint of each record, not the code itself, so the repository and the artefacts stay where they are.

When a question comes up later, you calculate the fingerprint again. If it matches the sealed one, the record hasn't changed since the day it was sealed. Change a single line in a release note and the fingerprint won't match. That's the point: it shows the record is the one written at the time, and you can share it with an auditor, an insurer or a court without anyone having to take your word for it.

You seal at two moments: when a release is tagged, and when it's deployed. The sealed record includes the build fingerprint, the release version, the timestamp and, if you want, a link to the Git commit. Anyone you share it with later can check it against the chain, using the witness ID and the verification link, and see that nothing has been quietly edited in the meantime.

What it doesn't do is prove the software was defect-free, or that the right version was deployed. It shows which version existed, when it was released and when it went live. Whether it worked as intended is another question, and one for testing, monitoring and incident response. A digital witness is a receipt, not a warranty.

You can start by sealing releases as part of your CI/CD pipeline, with one call to the REST API or the SDK at the point where a build is tagged. Deployments can be sealed the same way, as each environment is updated. The content stays in your systems; the fingerprint goes to WitniumChain, and you get a witness ID back. To check it later, you—or anyone you share the record with—calculate the fingerprint again, fetch the sealed one with the witness ID and compare them. If they match, the record is unchanged. The first 2,000 witnesses a month are free, and the documentation has examples in five languages.

How it would work

1. At release, seal the build fingerprint, version and release notes.
2. At deployment, seal the deployment event with the version and environment.
3. When questioned, share the record and the witness ID so anyone can check it.

What this means for you

If you build, sell or deploy software that reaches end users or businesses after 9 December 2026, here are three questions to ask now:

• Could we show which version of our software was running on a given day, in a form that would hold up if it were challenged?
• Do we keep deployment records, and if so, for how long and in what format?
• If a court ordered us to hand over evidence about a defect, what would we actually be able to provide?

The directive applies to products placed on the market from 9 December 2026 ^[1]. Sweden's proposed Product Liability Act is expected to enter into force on the same date ^[2]. That gives you about eight months to decide how you'll answer those questions, and to put the systems in place that let you answer them with something other than a shrug.

The law doesn't say you have to seal your releases. It says you may have to prove what your software did, and that courts can draw conclusions if you can't. A sealed release history is one way to close that gap, and it's easier to start now than to wish you had when the question lands on your desk.

What to watch

The EU's Product Liability Directive must be transposed into national law by 9 December 2026 ^[1]. In Sweden, the government's draft bill was sent to the Council on Legislation in August 2026 and is expected to be adopted in time for the deadline ^[2]. Other member states are following similar timelines.

The AI Act's requirements for high-risk systems, including logging under Article 12, apply from 2 December 2027 for systems listed in Annex III and from 2 August 2028 for systems in Annex I ^[3]. High-risk AI that is also a product under the new liability rules will need to meet both sets of requirements.