Belgium adds software and AI to product liability, with stricter evidence rules

The rule

Belgium has introduced a bill to transpose the EU's new Product Liability Directive ^[1]. The directive, (EU) 2024/2853, updates the rules on who pays when a defective product causes harm. It treats standalone software and AI systems as products for the first time, and it makes it easier for the person harmed to get at the evidence ^[2].

The directive must be implemented by 9 December 2026. In Sweden, the government has proposed that a new Product Liability Act enter into force on that date ^[3].

It's like extending the rules that apply when a toaster sets the kitchen on fire to software that makes a wrong decision: strict liability, no need to prove fault, and the injured party gets help reaching the proof.

What counts as a product

Under the new rules, a product is any movable, and that now explicitly includes electricity and standalone software ^[2]. An AI system falls within that definition. Liability is strict: the injured party does not need to show that the manufacturer was negligent, only that the product was defective and caused the harm.

The directive covers death, personal injury, damage to property not used exclusively for professional purposes, and destruction or corruption of data not used for professional purposes ^[2]. A company that loses data in a cyberattack because of a flaw in a software product it bought cannot claim under product liability. A person whose photo library is corrupted can.

The evidence rules

The directive gives courts new powers to order the defendant to hand over relevant evidence, and it shifts the burden of proof in three situations ^[2].

First, if the claimant shows that it is excessively difficult to prove a defect because of the product's technical or scientific complexity, the court can presume the defect exists unless the defendant proves otherwise. Second, if the claimant cannot access evidence that the defendant controls, and the court considers the evidence relevant, it can order disclosure. Third, if the defendant fails to comply with a disclosure order without good reason, the court can presume the missing evidence would have supported the claimant's case.

Those rules matter when software is involved. The injured party rarely has access to the source code, the training data, the decision logs or the version history. The directive puts the question on the table: can the defendant show what the software did on the day in question, and which version was running?

When it applies

The directive applies to products placed on the market after 9 December 2026 ^[2]. For software sold as a service, or updated over the air, the question of when it was placed on the market is less straightforward than it is for a physical object sold in a shop. The directive does not settle that question, so expect guidance.

How a digital witness fits here

Here, the thing to seal is each software release and each deployment event. A release is a build fingerprint, release notes and test results. A deployment event is a record that version X was deployed to system Y at time Z.

Sealing takes a fingerprint, not the data, so the build and its notes never leave your systems. Anyone you share the record with can later check that it's the one written at the time of the release.

WitniumChain does that with one call to the REST API, the SDK or the MCP server. The first 2,000 witnesses a month are free. The content stays with you.

What it shows is that a release record and its deployment log existed at that time, unchanged since. What it doesn't show is that the version was free of defects, or that it was the version actually running.

In a liability case, the question is often which version was live when the harm occurred. If you can show an unchanged deployment log from that day, the conversation is shorter. If you cannot, the claimant's expert gets more room to argue.

How it would work

1. At release, your build pipeline calls the API and seals the build fingerprint, release notes and test results.
2. At deployment, your deployment tool seals a record that version X went live on system Y at time Z.
3. Months later, if questioned, you share the sealed deployment log. The other side checks the fingerprint and sees that it matches what was sealed.

What this means for you

If you build or sell software that will reach the market after 9 December 2026, the new rules apply to you. Here are three questions to ask now:

• Can we show which version of our software was running on a given system on a given day?
• If a claimant's expert asked for our decision logs, deployment records or training data manifests, could we hand them over in a form that shows they haven't been edited?
• Do our version control and deployment systems keep records that would hold up if a court ordered disclosure?

The directive does not say how you keep those records. It just says the claimant can ask for them, and that a court can draw inferences if you cannot produce them.

What to watch

Belgium's bill is one of the first national implementations. Expect more in the coming months, and expect guidance on when software as a service is placed on the market.

In Sweden, the government's proposed Product Liability Act is at the Council on Legislation stage. If it follows the usual process, it will be adopted in time for the 9 December 2026 deadline ^[3].

The deadline is 253 days away. If your software could cause the kind of harm the directive covers, the time to decide how you will keep version and deployment records is before someone asks for them.