Software becomes a product: the new EU product liability rules explained

A car and a chatbot, treated the same way

Product liability has long been about physical things: a faulty brake, a sharp edge on a toy, a battery that catches fire. From 9 December 2026, software joins that list. Under the EU's revised Product Liability Directive, a piece of software can be a defective product in the same way a faulty toaster can ^[1].

It's like saying the brakes and the navigation system on your car now carry the same legal weight. If the brakes fail and you crash, the manufacturer is liable. If the software fails and you crash, the same rule applies.

The directive explicitly mentions AI systems. That means a model that screens loan applications, a chatbot that gives the wrong medical advice or a robot mower that injures someone can all trigger strict liability ^[1]. The person harmed doesn't have to prove the manufacturer was negligent, only that the product was defective and caused the harm.

In Sweden, the government published a draft bill in August 2026 proposing a new Product Liability Act to transpose the directive, with entry into force on 9 December 2026 ^[2]. The wording is almost certain to change before it becomes law, but the core is clear: software is in.

What strict liability means

Strict liability is a short conversation. The claimant shows three things: the product was defective, they suffered harm and the defect caused the harm. They don't have to show the manufacturer made a mistake or knew about the problem.

The directive covers death and personal injury, damage to property not used exclusively for professional purposes, and destruction or corruption of data not used exclusively for professional purposes ^[1]. A broken laptop at home is covered. A broken server in a data centre is not, unless it also causes personal injury.

That last bit catches people out. If a hospital's AI system fails and a patient is injured, that's covered. If a company's billing software corrupts a customer's files, that's covered, provided the files were personal. If it corrupts another company's files used for business, it isn't, unless national law says otherwise.

The directive sets a floor, not a ceiling. Member states can go further and cover purely commercial harm ^[1].

Evidence and burden of proof

Two provisions make it easier for claimants to get what they need.

First, courts can order defendants to disclose relevant evidence, even where that evidence contains trade secrets or confidential business information ^[1]. Say a claimant argues that a model made a biased decision. The court can order the defendant to hand over documentation about the training data or the model's parameters. That's a significant shift.

Second, in certain conditions the burden of proof can be reversed or eased. If the defendant doesn't comply with a disclosure order, or if establishing a defect or causal link is excessively difficult because of the technical or scientific complexity of the product, the court can presume the defect or the causal link exists, unless the defendant proves otherwise ^[1].

It's like being asked to prove a seatbelt was faulty after a crash, when the car manufacturer won't let you examine the seatbelt. The directive says the court can assume it was faulty unless the manufacturer proves it wasn't.

What counts as defective

A product is defective when it doesn't provide the safety a person is entitled to expect, taking into account all circumstances ^[1]. For software, that includes what it was meant to do, how it was presented, the reasonably foreseeable use or misuse of it and the moment it was placed on the market.

An AI system trained on biased data that discriminates could be defective. A chatbot that gives dangerously wrong medical advice could be defective. A software update that introduces a security flaw could be defective, even if the original version was fine.

The directive also says that digital manufacturing files, such as those for 3D printing, count as products ^[1]. If you distribute a file that makes something unsafe, you can be liable for the physical thing it produces.

Who is liable, and when

The manufacturer of the final product is liable, and in some cases the manufacturer of a component. If the manufacturer is outside the EU and has no authorised representative here, the importer is liable. If neither can be identified, any supplier in the chain can be held liable unless they identify their own supplier within a month ^[1].

Liability attaches when the product is placed on the market, not when the harm occurs. For software that means the version that was running at the time. If a bug is patched in a later release but the user hasn't updated, the question is whether the version they had was defective when it was released.

Manufacturers have defences. If the defect didn't exist when the product was placed on the market, or if it was due to compliance with a binding legal requirement, they aren't liable. If the state of scientific and technical knowledge at the time couldn't have detected the defect, that's a defence too, though member states can choose not to allow it ^[1].

Sealing your software history

When software is a product, being able to show which version ran on a given day and what it contained can matter in court.

The thing to seal is each release: the build fingerprint, the release notes and the test results, sealed when the release is made. Then, each deployment event, sealed when it happens. That way you have a record, unchanged since it was created, of what was deployed where and when.

Sealing takes a fingerprint of the record, not the record itself, so the release history never leaves your systems. Anyone you share it with can check the fingerprint against the sealed one. If it matches, the record hasn't changed. Change a single character and it won't match.

A digital witness doesn't show that the version was free of defects or that the deployment was correct. It shows that the record of what was deployed, and when, is the one written at the time. That matters when someone questions it later, and you want your own evidence, not just a log your organisation could have edited.

You can seal releases and deployments as part of your build pipeline, with WitniumChain's REST API, SDK or MCP server. The record stays with you, only the fingerprint is sealed. The first 2,000 witnesses a month are free. Read the docs.

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 was deployed, where and when.
3. To check, calculate the fingerprint of the record again and compare it with the sealed one.

What this means for you

If you build or sell software that will be placed on the EU market after 9 December 2026, here are five questions worth asking now:

• Could you show which version of your software was running on a given day, unchanged since release?
• Do your release notes and test results make it clear what each version was meant to do and what was tested?
• If a court ordered you to disclose training data, model parameters or decision logs, do you have them in a form you can hand over without rewriting them first?
• Are your terms of use and documentation clear about what the software is for, and what it isn't?
• Do you have liability insurance that covers software as a product, and have you told your insurer about AI components?

What to watch

The Swedish draft bill is with the legislative council. The final wording will be published when the bill goes to the Riksdag, likely in late 2026. Once enacted, the law will apply to products placed on the market from 9 December 2026.

Member states have until 9 December 2026 to transpose the directive ^[1]. Implementation details will vary, especially on whether purely commercial harm is covered and whether the development risk defence is allowed.

For high-risk AI systems under the AI Act, the logging requirements in Article 12 apply from 2 December 2027 for Annex III systems ^[3]. The two regimes overlap: the AI Act says what to log, the Product Liability Directive says the logs can be ordered disclosed and that their absence can shift the burden of proof.