What changes on 9 December: software becomes a product

Software is now a product

Until recently, product liability meant physical things: a faulty brake, a defective battery, a contaminated medicine. Software was generally not covered. That changes on 9 December 2026.

Directive (EU) 2024/2853 on liability for defective products explicitly includes standalone software and AI systems in the definition of a product ^[1]. For anything placed on the market after that date, the same strict liability rules apply whether the product is a robot arm or the software that controls it.

The directive is already in force. Member states have until 9 December 2026 to transpose it into national law, and it applies to products placed on the market from that date ^[1]. In Sweden, the government proposed a new Product Liability Act in August 2026, with the intention that it enter into force on 9 December 2026 ^[4]. Until the Riksdag decides, the Swedish law remains a proposal.

What is covered

Liability is strict. The injured party does not need to prove fault, only that the product was defective, that they suffered damage and that the defect caused the damage ^[2].

The directive covers three kinds of damage ^[2]:

• death and personal injury,
• damage to an item of property other than the defective product itself, provided the item is of a type ordinarily intended for private use or consumption and was mainly used by the injured person for their own private use or consumption,
• loss or corruption of data not exclusively used for professional purposes.

Property damage below €500 is not covered, and neither is damage to property used exclusively for professional purposes. That means a company's servers, production equipment or business files are not covered, but a private person's car, phone or holiday photos are ^[2].

The directive does not introduce a cap on damages. National law decides that. Sweden's proposed law follows the same structure ^[4].

Disclosure of evidence and presumptions

Two features of the directive make it easier for someone claiming damage to prove their case.

First, courts can order the defendant to disclose relevant evidence, including information about the product's design, the algorithms used and the data it was trained on ^[3]. The defendant can object if disclosure would reveal trade secrets, but the court can inspect the evidence in camera and decide whether it is relevant ^[3].

Second, the directive allows courts to presume a defect or a causal link in certain situations. For example, if the defendant fails to comply with an order to disclose evidence, the court may presume the product was defective or that the defect caused the damage ^[3]. Another presumption applies when the product obviously malfunctioned in normal use ^[3].

These rules matter for anyone who builds or sells software. If something goes wrong and someone is injured, the burden is no longer simply on the injured party to prove everything. The defendant may have to produce evidence, and the absence of that evidence can work against them.

The version question

When software counts as a product, version history becomes evidence.

Say a piece of software is alleged to have caused an injury, or to have corrupted a private person's data. The questions a court or an investigator will ask include: which version was running at the time? What did that version contain? When was it released, and what had changed since the previous version? Was it the version intended to be running, or had something else been deployed?

If you cannot answer those questions with documentary evidence, the presumptions in the directive start to matter. A court may presume the product was defective if you fail to produce the evidence it ordered ^[3].

Version control systems keep a history of code changes, but they do not prove which build was running in production on a given day, or that the release notes and test results you produce a year later are the ones that existed at the time. Build logs can be edited, and deployment records kept in a database controlled by the same organisation are easy to challenge.

How a digital witness would work here

The thing to seal is each release and each deployment.

At release, seal the build fingerprint, the release notes and the test results. At deployment, seal a record of what was deployed, where and when. The fingerprint is sent to WitniumChain, not the code or the logs, so nothing proprietary leaves your systems. You get a witness ID back, and that ID can later be used to check that the record hasn't changed.

Say a court asks which version was running on 15 March 2027. You produce the sealed deployment record showing that version 3.2.1 was deployed to production on 14 March at 09:15, and the sealed release for version 3.2.1 with its notes and test results. Anyone you share those records with can calculate the fingerprints again and see that they match what was sealed at the time. If they don't match, something has changed.

The witness doesn't show that the version was free of defects, or that it was deployed correctly. It shows that the records you produce now are the ones that existed when they were sealed, so there is less room to argue that you wrote them after the event.

Sealing deployment records becomes part of your build pipeline. Each time a release goes to production, a fingerprint goes to WitniumChain through the REST API or the SDK, automatically. The content stays with you. If a court later orders disclosure, the records you hand over are the ones you sealed on the day, and the other side can check that for themselves.

Start with the REST API or the SDK. The first 2,000 witnesses a month are free.

How it would work

1. At release, send a fingerprint of the build, the notes and the test results through the REST API or the SDK.
2. At deployment, send a fingerprint of the deployment record.
3. When questioned, produce the records and let the other side check the fingerprints.

What this means for you

If you build, sell or operate software that will be on the market after 9 December 2026, ask:

• Could we show which version of our software was running in production on a given day?
• Do we keep release notes, build records and test results in a way that would hold up if questioned a year later?
• If a court ordered us to disclose our deployment history, could we produce it, and would it be credible?
• Are we documenting software updates and patches, and can we show when each one was deployed?

The directive treats software as a product. The practical consequence is that version history, release records and deployment logs move from the engineering department to the domain of evidence.

What to watch

Sweden's proposed Product Liability Act is with the Riksdag. Once decided, it will enter into force on 9 December 2026 ^[4]. The directive itself is already in force across the EU ^[1].

For high-risk AI systems under the AI Act, additional logging and documentation duties apply from 2 December 2027 for systems in Annex III and from 2 August 2028 for general-purpose AI systems in Annex I with systemic risk. Those rules sit alongside product liability and are separate from it.