Software becomes a product in December: what that means for liability

A toaster and a chatbot walk into court

For decades, product liability covered things you could drop on your foot. If a toaster caught fire or a bike brake failed, the injured person could sue the manufacturer under strict liability rules: no need to show that anyone was negligent, just that the product was defective and caused harm.

Software sat outside that framework, treated as a service or intellectual property rather than a thing. That ends on 9 December 2026. Under Directive (EU) 2024/2853, standalone software—chatbots, risk models, navigation apps, AI systems and all the rest—becomes a product ^[1]. The strict liability that applies to the toaster now applies to the code.

It's a bit like saying the mains plug and the firmware inside it are equally a product. Both can cause harm, both can be defective, and from December the law treats them the same way.

What counts as a defect, and what counts as damage

A product is defective if 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 ^[2]. That definition has been around since 1985; applying it to software is new.

The Directive covers death and personal injury, damage to property not used exclusively for professional purposes, and loss or corruption of data not used for professional purposes ^[2]. A robot vacuum that burns down a flat is covered. One that wipes a company's customer database probably isn't, unless the database also contained personal files.

Liability is strict, but not absolute. There are defences: the defect didn't exist when the product was placed on the market, the defect is due to compliance with a mandatory regulation, the state of scientific and technical knowledge at the time couldn't have allowed the defect to be discovered, or—for component suppliers—the defect is attributable to the design of the product into which the component was fitted ^[2].

The evidence rules tilt the balance

In the old regime, the injured party had to prove what the product did, that it was defective and that the defect caused the harm. With software, especially AI, that can be nearly impossible from the outside.

The new Directive makes it easier in two ways. First, under certain conditions a court can order the defendant—or in some cases a third party—to hand over relevant evidence, even if it contains trade secrets ^[3]. Second, there are provisions on presumption: if the injured party shows that the product is likely defective or that the defect likely caused the damage, and proving it is excessively difficult because of technical or scientific complexity, the court can presume the link ^[3].

That doesn't mean every claim succeeds, but it does mean manufacturers can't hide behind complexity. If the question is what version of the software was running when something went wrong, or what data the model was trained on, the manufacturer may be ordered to show it.

What this means for you

If you make, import or sell software that reaches the EU market, three questions are worth asking now.

First, do you know which version of your software was deployed where, and when? Version control tracks what you build; product liability asks what actually ran.

Second, can you show what your software did on a given day? Logs are useful, but a log the defendant keeps is easier to challenge than one that can be checked independently.

Third, if a court ordered you to hand over evidence about a version from two years ago, could you do it? In a dispute, the side without records starts on the back foot.

How a digital witness fits here

This is a case where a digital witness fits well. The thing to seal is each release: the build fingerprint, the release notes and the test results. Seal it when the release is cut, and seal each deployment event when a version goes live.

Sealing takes a fingerprint of the record, not the record itself, so nothing leaves your systems. The fingerprint is posted to WitniumChain, and you get a witness ID back. Anyone you share the release record with—an auditor, a notified body, an insurer or a court—can check that it's the one sealed on that day by calculating the fingerprint again and comparing it with the sealed one. A single changed character and the fingerprints won't match.

What it shows: that a release and its deployment record existed at that time, unchanged since. What it doesn't show: that the version was free of defects, or that it met any particular standard. It's a record of what was shipped, not a verdict on whether it was safe.

You start with the REST API, the SDK or the MCP server. The content stays with you, and the first 2,000 witnesses a month are free. Read the docs.

How it would work

1. At release, your build pipeline sends the fingerprint of the release package to WitniumChain and logs the witness ID with the release.
2. At deployment, the deployment script seals a record of which version went live, where and when.
3. When someone questions what ran on a given day, you show the sealed deployment record and the release it points to. They check the fingerprints.

What to watch

The Directive applies to products placed on the market from 9 December 2026 ^[1]. In Sweden, the government's draft bill proposed that a new Product Liability Act enter into force on that date ^[4]. Check your jurisdiction for how the Directive is being transposed.

For AI systems that also fall under the AI Act, remember that the high-risk requirements for Annex III systems apply from 2 December 2027, a few days before this Directive. If a system is both high-risk AI and a product under this Directive, both sets of rules apply.

The Commission is required to review the Directive's application to software by 9 December 2031, and may propose further rules if needed ^[1]. Until then, the rules are as written: software is a product, and liability follows.