Germany seals software liability rules ahead of the EU deadline

A product, not just code

For decades, a broken toaster could land you in court. A broken piece of software, not so much. That changes in a few months.

Germany's draft Product Liability Act, sent to the Council of State in August 2026, treats freestanding software as a product ^[1]. The EU directive it transposes, Directive (EU) 2024/2853, does the same ^[2]. Software that reaches the market after 9 December 2026 falls under strict liability rules that were built for physical goods.

AI systems count as software, so they're in. A defect in a credit-scoring model, a medical decision tool or a chatbot can trigger liability if it causes the kind of damage the directive covers.

What the law covers

Liability is strict, which means the claimant doesn't have to show that the manufacturer was careless, just that the product was defective and caused damage ^[1]. The damage has to be one of three kinds: death or personal injury, damage to property not used exclusively for professional purposes, or destruction or corruption of data not used for professional purposes ^[2].

That last bit matters. If your AI corrupts a customer's holiday photos, the directive applies. If it corrupts a client's invoicing database that the client uses only for work, it probably doesn't.

Manufacturers are liable, and so are importers when the manufacturer is outside the EU. Under some conditions, distributors can also be on the hook ^[1].

Evidence that shifts the burden

The directive has two provisions that tilt the playing field towards claimants. First, courts can order the defendant to hand over relevant evidence, subject to safeguards for trade secrets and confidential information ^[2]. Second, when the claimant shows that it's likely the product was defective and that the defect caused the damage, and when the technical or scientific complexity makes it hard to prove either, courts must assume the defect or the causal link is there, unless the defendant shows otherwise ^[2].

In other words, if you build software and someone sues, you may be the one who has to show what your software did on a given day. A log you can quietly edit won't help much if the other side questions it.

When versions matter

Say a robot mower injures someone in 2028 and the question is which software version it was running. The manufacturer says it was version 2.3, which had a patch for the edge-detection bug. The claimant's engineer says the logs suggest 2.2. The case turns on which version it was, what it contained and when it was deployed.

Version control was built for collaboration, not for evidence. Git keeps a history, but the people who can commit to a repository can also rewrite it. When a court asks for the deployment record, the question is whether you can show it's the one written on the day, not one tidied up later.

How a digital witness fits here

Here, the thing to seal is each release and each deployment event. At release, you seal a fingerprint of the build, the release notes and the test results. At deployment, you seal a record of which version went where and when. The fingerprint, not the software itself, goes to <a href="/signup">WitniumChain</a>.

If it's questioned a year later, anyone you share the record with can calculate the fingerprint again and check that it matches. Change a single character in the release notes and it won't match. The record shows that this version existed at that time, unchanged since.

What it doesn't show is that the version was free of defects. Liability turns on whether the product was defective and caused damage, and a sealed record doesn't settle that. What it does is give you a checkable answer to the question of which version ran, so the dispute can move on to whether that version had a defect.

Your system sends the fingerprint through the <a href="/docs">REST API, the SDK or the MCP server</a>, and gets a witness ID back. The content stays with you. The first 2,000 witnesses a month are free.

How it would work

1. At release: seal the build fingerprint, release notes and test results.
2. At deployment: seal a record of which version went where and when.
3. If questioned: calculate the fingerprint again and compare it with the sealed one.

What this means for you

If you build, sell or import software that will reach the market after 9 December 2026, here are four questions for this week:

• Could you show which version of your software was running on a given device on a given day?
• Do your deployment logs stay with you, or with a cloud provider whose terms let them delete records after a year?
• If a court ordered you to hand over evidence about a version, would you have it, and could you show it hasn't changed?
• Does your organisation treat software releases the way it treats physical product batches, with a documented trail?

The directive doesn't prescribe how you keep records. It just says you may have to show them, and that complexity doesn't excuse you from proving your case.

What to watch

Germany's draft still has to pass the Bundestag, but the August 2026 referral to the Council of State suggests the timeline is on track. Other member states have until 9 December 2026 to transpose the directive ^[2].

The UK has its own Product Liability Act from 1987, which the Law Commission reviewed in 2022. That review didn't recommend treating software as a product, but it did suggest updating the rules for digital goods. Whether the UK follows the EU's line is still open.

For manufacturers, the date to put in the diary is 9 December 2026. That's when software placed on the market starts carrying the same liability as a hairdryer.