Sector · Manufacturing
Rules · 2026-10-12 · 5 min read
Germany seals software liability rules ahead of the EU deadline
Germany has adopted new product liability rules that treat software and AI as products, implementing the EU directive nearly a year early. The regime makes it easier for injured parties to prove defects and obtain evidence.
A liability regime built for software
Germany has adopted a new product liability law that treats software and AI systems as products, implementing the EU's Product Liability Directive nearly a year before the transposition deadline [1]. The law enters into force on 9 December 2026 and applies to products placed on the market from that date [1].
Liability is strict: a manufacturer is liable for defects that cause death, personal injury, damage to property not used exclusively for professional purposes, and destruction or corruption of data not used for professional purposes [2]. The regime explicitly includes software, even when supplied on its own [2].
For anyone who builds or sells software, it's a bit like the day a rental car company decides to hold you liable for what the car does after you've handed back the keys. The product might change after you shipped it, but under certain conditions you're still on the hook.
Courts can order evidence to be handed over
The new law gives courts the power to order defendants to disclose relevant evidence, and it shifts part of the burden of proof to the defendant in certain circumstances [1]. That makes it easier for a claimant to get at the facts.
Under Article 9 of the directive, a court can order a defendant or a third party to disclose evidence when the claimant has presented facts and evidence sufficient to support the plausibility of the claim, and has shown that the defendant or the third party is in control of that evidence [2]. The court weighs the interests and protects trade secrets and confidential information.
Article 10 gives claimants relief from the burden of proof when it is excessively difficult to prove a defect or a causal link, given the technical or scientific complexity [2]. The court can presume that a defect exists, or that it caused the damage, if the claimant establishes that the product is defective or that the damage was caused by an obvious malfunction during normal use.
What a defect is, and when software has one
A product is defective when it does not provide the safety that a person is entitled to expect, taking into account all circumstances [2]. For software, a defect can arise from the design, from errors in the code, or from a lack of updates that were reasonably expected [2].
Say a bank's credit-scoring software approves a loan that an updated version would have declined, and the borrower later defaults. If someone is injured because of that loan decision, the question is whether the software provided the safety a person was entitled to expect, and whether the bank should have updated it.
The regime does not make the manufacturer liable for everything. There are defences: if the defect did not exist when the product was placed on the market, if the state of scientific and technical knowledge at the time did not enable the defect to be discovered, or if the defect is due to compliance with mandatory regulations, the manufacturer is not liable [2].
Germany is first, the directive applies across the EU
Germany is the first EU member state to transpose the directive [1]. The directive itself was adopted on 13 November 2024 and member states must transpose it by 9 December 2027, with the rules applying to products placed on the market from 9 December 2026 [2].
The Swedish government published a draft bill in August 2026 proposing that Sweden's new Product Liability Act should also enter into force on 9 December 2026 [3]. Other member states are expected to follow.
Showing which version ran, and when
If a court orders you to hand over evidence about which version of your software was running on a given day, and what it did, the question is whether you kept a record that holds up.
Version control systems like Git keep a history of code changes, but they are built for collaboration, not for evidence. A developer with access can rewrite history, and proving in court that a particular version was the one running on a certain device at a certain time is harder than it sounds.
Here, the thing to seal is each release: the build fingerprint, the release notes and the test results. Seal it when you cut the release, and seal each deployment event when a version is rolled out to production or to a device.
Sealing takes a fingerprint of the record, not the record itself, so the release history and deployment logs stay in your systems. The fingerprint goes to WitniumChain through the REST API, the SDK or the MCP server, and you get a witness ID back. When a court or an insurer asks which version ran on 15 March, anyone you share the deployment record with can calculate the fingerprint again and check that it matches the sealed one. Change a single character in the record and it won't match.
What it shows is that the record of which version was released, tested and deployed is exactly what was recorded at the time. What it doesn't show is that the version was free of defects, or that it was the version that should have been running. Those are different questions.
How it would work
- At release, your build pipeline seals a record of the version (commit hash, build number, timestamp and test summary).
- At deployment, your deployment system seals a record of which version went where, and when.
- When asked, you produce the deployment record and the witness ID. The person checking it calculates the fingerprint of the record you've given them and compares it with the sealed fingerprint. If it matches, the record hasn't changed since the day it was sealed.
What this means for you
If you build or sell software that will be placed on the EU market after 9 December 2026, these questions are worth asking now:
- Could we show which version of our software was running on a specific device on a specific day?
- Do we have a record of when each version was tested, and what the results were?
- If a court ordered us to disclose that record, would we be confident it hasn't been altered since the day in question?
- Who in our organisation could change that record, and would a change show up?
The new regime makes it easier for claimants to get evidence and shifts part of the burden of proof. The side that kept a clear, unchanged record starts a step ahead.
What to watch
9 December 2026: Germany's new Product Liability Act enters into force, and Sweden's proposed act is expected to do the same [1][3]. The rules apply to products placed on the market from that date.
9 December 2027: Deadline for all EU member states to transpose Directive (EU) 2024/2853 [2].
Sources
- [1]Germany adopts new product liability rules to combat cyber risks, Pinsent Masons, 2024-12-20
- [2]Directive (EU) 2024/2853 on liability for defective products, EUR-Lex, 2024-11-13
- [3]Lagrådsremiss: En ny produktansvarslag, Regeringen, 2026-08-27