The AI Liability Directive was withdrawn: what *the Product Liability Directive* does instead

What happened to the AI Liability Directive

In February 2022, the European Commission proposed a directive on adapting non-contractual civil liability rules to artificial intelligence ^[1]. It would have introduced special liability rules for AI systems, including a presumption of causality when certain conditions were met and a duty to disclose evidence. It was meant to sit alongside the AI Act.

In early 2025, the Commission withdrew the proposal ^[1]. It will not become law. The stated reason was to avoid regulatory duplication: the new Product Liability Directive, adopted in November 2024, already covers AI systems and software ^[2].

That leaves the Product Liability Directive as the main EU instrument for claims over AI-related harm, alongside national fault-based liability rules.

What the Product Liability Directive does

The directive makes software a product. That includes standalone software and AI systems ^[2]. Liability is strict, meaning the claimant does not have to prove fault, only that the product was defective and caused damage ^[3].

It covers death and personal injury, damage to property not used exclusively for professional purposes, and destruction or corruption of data not used exclusively for professional purposes ^[3]. A phone that catches fire is covered. A server used only for business is not.

Think of it like a car recall. The manufacturer is liable if a defect in the brakes causes a crash, whether or not anyone was careless. Under the directive, the same applies to software: if a defect in a medical AI causes harm to a patient, the maker can be held liable, even if the hospital followed the instructions.

The evidence rules

The directive has two parts that make it easier for claimants to get at the evidence.

First, courts can order a defendant to disclose relevant evidence, if the claimant has presented facts and evidence sufficient to support the plausibility of the claim and has specified the evidence with a sufficient degree of precision ^[4]. The defendant can refuse if disclosure would mean revealing trade secrets, but the court can draw adverse inferences from that refusal ^[4].

Second, the burden of proof can shift. If the court finds it excessively difficult for the claimant to prove a defect or a causal link, and the defendant has failed to comply with a disclosure order or has not provided critical information that is not accessible to the claimant, the court may presume the defect or the causal link to be established ^[4].

In short: if you make software, keep records. If you cannot show what your software did, a court may assume it did what the claimant says it did.

What this means for you

If you build or sell software, AI systems included, ask yourself these questions before 9 December 2026:

• Could we show which version of our software was running on a given day?
• Could we show what a specific instance of the software did: what input it received, what decision it made and what output it produced?
• If a court ordered us to disclose those records, could we produce them in a form that holds up, or would we be arguing about whether the logs have been edited?
• Do we have a process for sealing releases, logs and decisions as they happen, so we can later prove they have not changed?

The directive does not say you must keep logs or seal them, but it gives courts the power to draw inferences when you cannot produce evidence. A sealed log is harder to challenge than one you could have edited yesterday.

How a digital witness fits here

Say a medical AI suggests a dose and a patient is harmed. The hospital has the log, but the manufacturer questions whether it is the original. The hospital's word is not enough, because it kept the log itself.

Here, the thing to seal is each decision record as it is written to the log: the patient reference, the model version, the input values and the suggested dose. Sealing takes a fingerprint of the record, not the record itself, so the data never leaves the hospital's systems. If the decision is questioned a year later, anyone the hospital shares the record with can check that it is the one written on the day, by calculating the fingerprint again and comparing it with the sealed one.

A digital witness like WitniumChain makes that straightforward. The hospital's system sends the fingerprint to the chain through the REST API, the SDK or the MCP server, and gets a witness ID back. The record stays in the hospital's database. To verify, the recipient calculates the fingerprint of the record the hospital provides and checks it against the sealed fingerprint using the witness ID. A match means the record has not changed. Change a single character and it will not match.

What the witness shows is that the record is exactly what was written at that time. What it does not do is prove that the decision was correct, that the model was free of defects or that the log is complete. It also does not replace access control, monitoring or your existing quality and safety processes. It is one part of showing, later, what your software actually did.

You can start with the documentation, and the first 2,000 witnesses a month are free.

What to watch

9 December 2026 is the deadline for Member States to transpose the directive ^[2]. In Sweden, the government published a draft bill in August 2026 proposing that a new Product Liability Act enter into force on that date ^[5].

The directive applies to products placed on the market after 9 December 2026 ^[2]. If you release software before that date, the old rules apply. If you release it after, the new ones do.

For AI systems, this sits alongside the AI Act's requirements. High-risk systems under Annex III must log events from 2 December 2027 ^[6]. Logging and sealing are separate questions, but they point in the same direction: when something goes wrong, you will need to show what happened.