Can you show which *software version* ran when someone got hurt?

What the directive says

The EU's Product Liability Directive was updated in October 2024 ^[1]. For the first time, standalone software counts as a product, AI systems included. The directive brings strict liability: if the product is defective and causes harm, the manufacturer is liable without the injured person having to prove fault ^[2].

It covers death and personal injury, damage to property not used exclusively for professional purposes, and destruction or corruption of data not used for professional purposes. Property and data used for business are out ^[2]. So a robot mower that injures a pedestrian in a park is covered; a warehouse robot that damages a pallet is not.

The directive applies to products placed on the market after 9 December 2026 ^[2]. Sweden's government has proposed a new Product Liability Act that mirrors the directive, with the same date ^[3].

Who is liable

Liability rests with the manufacturer, the importer into the EU, or in some cases the distributor. The injured person can claim against any of them ^[2]. That is why knowing where you sit in the supply chain matters.

Small Print Legal, a legal tech firm that builds compliance tools, has just launched a free online assessment for the directive ^[4]. You answer a few questions about your product and your role, and the tool tells you whether the directive applies, who in your supply chain will be affected, and what to consider next. It is aimed at software makers, AI developers and hardware manufacturers who embed software.

Think of it as a smoke alarm for product liability: it doesn't put out the fire, but it tells you whether there is one.

Evidence and burden of proof

The directive makes it easier for the injured person to get evidence. Courts can order the defendant, under certain conditions, to disclose relevant evidence, even when that evidence is confidential or a trade secret ^[2]. If the defendant fails to comply, the court may presume that the product was defective or caused the damage ^[2].

The burden of proof is also lighter for the claimant in some situations. If the product is complex or the evidence is hard to get, the court can presume a defect or a causal link when the claimant shows that the product malfunctioned ^[2].

So the question for anyone who builds or sells software is no longer just whether a version was defective, but whether you can show which version was running, what it did, and when. A court or an insurer may ask, and saying "we think it was version 2.3" a year after the event is not a strong start.

What this means for you

If you develop, import or distribute software that will reach the market after 9 December 2026, here are three questions to ask now:

• Does your software fall under the directive, and if so, where do you sit in the supply chain?
• Could you show, a year from now, which version of your software was running on a given device on a given day?
• If a court asked for your deployment logs, versioning records or configuration history, could you hand them over in a form that holds up?

The Small Print Legal tool answers the first question. The second and third are operational, and they are worth sorting out before the date arrives.

How a digital witness fits here

The thing to seal is each software release and each deployment event: the build fingerprint, the release notes, the test results and the deployment timestamp. Sealing takes a fingerprint of the record, not the record itself, so the data stays with you.

Seal at two points: when a release is cut, and when it is deployed to a device or a server. If someone is injured and a claim is filed months later, you can show which version was running and that the deployment record is exactly what was written at the time.

Anyone you share the record with—an insurer, a notified body, a court—can check the fingerprint and see that nothing has changed, even by someone with administrator rights. A digital witness does not prove that the software was free of defects, or that it caused or did not cause the harm. It shows that the record you are relying on is the one that existed on the day in question.

You can start with WitniumChain through the REST API, the SDK or the MCP server. The content never leaves your systems. The first 2,000 witnesses a month are free. Read the docs to see how it fits your build pipeline.

How it would work

1. Your build system sends a fingerprint of each release (build hash, release notes, test summary) to WitniumChain and gets a witness ID back.
2. Your deployment tool sends a fingerprint of each deployment event (device ID, version, timestamp) and gets another witness ID.
3. When a claim comes in, you pull the records, recalculate the fingerprints and share them with the insurer or the court. If the fingerprints match, the records are unchanged.

What to watch

The Product Liability Directive applies from 9 December 2026 ^[2]. Sweden's proposed Product Liability Act has the same date ^[3]. Between now and then, other member states will transpose the directive into national law, so check your own jurisdiction's timeline.

If you build medical devices, machinery or other regulated products that embed software, also watch the Medical Device Regulation, the Machinery Regulation and the Cyber Resilience Act, all of which have overlapping requirements and different dates.

Small Print Legal's tool is live now at smallprint.legal ^[4]. It takes a few minutes and gives you a clear answer on whether the directive applies to you.