PLD 2024/2853 and AI : the December 9, 2026 burden-shift nobody is talking about

What the PLD does

The PLD modernizes the EU's 1985 Product Liability Directive (85/374/EEC) for the AI era. Three changes matter most for AI :

1. Software is a product. Article 4 of 2024/2853 defines "product" to explicitly include "software", removing the long-standing argument that software wasn't covered by the original PLD. AI systems are software ; they are products under the PLD.
2. Presumption of defect. Article 10 introduces a presumption of defect in several circumstances, including where the claimant has "manifestly excessive" difficulty proving defectiveness because of technical or scientific complexity. AI systems with non-deterministic outputs are paradigmatic of "technical and scientific complexity."
3. Burden of disclosure shifts to the producer. Article 9 requires the producer (the manufacturer, importer, authorized representative, or fulfilment service provider) to disclose relevant evidence in their control when a claimant presents facts and evidence sufficient to support the plausibility of the claim. The presumption of defect biases toward the claimant ; the disclosure obligation makes it operational.

What "burden of disclosure" means for AI evidence

Under the prior 1985 Directive, a claimant alleging harm from a defective product had to prove the defect, the harm, and the causal link. In practice this meant claimants against software vendors lost — there was no way for a claimant outside the vendor's organization to prove a software defect.

Under the 2024 Directive, the claimant who can plausibly allege AI-related harm triggers the producer's disclosure obligation. The producer has to hand over the relevant evidence — typically logs, model documentation, training-data references, oversight records. If the producer refuses or cannot produce them, Article 10 presumes defect.

The strategic consequence : the producer's evidence layer is directly load-bearing in a PLD claim. An evidence layer that cannot produce a complete record of which AI decision was made, when, with what input, with what oversight, is an evidence layer that creates a presumption of defect against the producer.

The five evidentiary asymmetries the PLD creates

Asymmetry 1 — the claimant doesn't need to be a technical expert

The 1985 Directive effectively required claimants to retain forensic engineers. Under 2024/2853, a claimant alleging an AI decision caused harm (a hiring rejection, a credit denial, a benefits termination) need only present plausible facts ; the evidentiary fight then happens on the producer's side. This lowers the cost of bringing a claim ; expect higher volume.

Asymmetry 2 — your evidence is now adversarial

The producer who chose to record AI decisions in a vendor-database- backed system, and who must now hand those records over to a claimant's legal team, is in a difficult position. They are relying on a third-party vendor to produce evidence that the producer is legally obligated to disclose. If the vendor is slow, contests, or fails to produce, the producer can't satisfy Article 9, and presumption of defect may apply.

Asymmetry 3 — the claimant can challenge integrity

A claimant's lawyer who knows the AI Act will ask the producer's counsel : "how do we know these oversight events weren't created after my client filed the complaint ?" If the producer's answer is "we trust our IAM and our database timestamps", the claimant can argue that the records are not contemporaneous, and the court may treat the records skeptically.

Asymmetry 4 — the producer is on the hook even if the AI vendor isn't EU

The PLD's territorial scope follows the place of harm. A US-based AI vendor whose model produced an output used by an EU deployer who harmed an EU resident — the EU deployer is the producer in the PLD chain, and the deployer's evidence layer is the one being tested. The deployer cannot pass blame upstream to the US vendor's logs the deployer never controlled.

Asymmetry 5 — settlement pressure favors the claimant

In civil law jurisdictions where the PLD applies, the cost of defending a claim under presumption-of-defect is high enough that settlement is often the rational choice for the producer. The claimant's lawyer knows this. Expect settlement-demand letters that quote the PLD presumption directly.

The producer's defense pattern under the PLD

The defense pattern that survives the PLD's disclosure and presumption logic looks like this :

1. Show, in writing, that the AI inference was made at a specific time, with a specific input, by a specific model version — bound by cryptographic signature, anchored to a third-party timestamping authority.
2. Show that the human oversight intervention is cryptographically bound to that specific inference — not joined by a database foreign key the claimant could allege was edited.
3. Show that the records have not been modified since they were produced — by handing the claimant's expert a verifier they can run independently.
4. Show that the model version itself is identifiable by hash — so the claimant cannot allege a different model was used at the time.
5. Show, if the case goes to a contested hearing, that a regulator with the same evidence would reach the same verdict. The verifier the producer uses must match the verifier the regulator uses — which is why an open-source verifier matters.

None of this defense works if the producer's evidence layer is a proprietary vendor dashboard that cannot be inspected by the claimant or the court. The defense works when the evidence is a bundle the claimant's expert can verify independently.

What this means for AI Act program budgeting in 2026

The August 2, 2026 AI Act deadline is the budget driver for compliance programs. The December 9, 2026 PLD deadline is the budget driver for risk-management and legal programs — and in most enterprises, those budgets are bigger.

A reasonable test for any AI Act evidence vendor your organization is evaluating in 2026 :

• Can the vendor's records be disclosed to a claimant or court in a form an independent expert can verify ?
• Does verification require the vendor's cooperation, API key, or continued operation as a going concern ?
• If the vendor goes bankrupt, is acquired, or rotates a signing key in 2027, what happens to evidence covering decisions made in 2026 ?
• If a claimant alleges the records were modified after the complaint was filed, what evidence can the producer present to rebut that allegation ?

An AI evidence vendor that answers "trust our dashboard" to those questions is not a vendor that survives PLD litigation. An AI evidence vendor whose verifier runs in the claimant's expert's browser, against an Apache-2.0 verification library the expert can audit, on a bundle that's cryptographically anchored to an eIDAS-qualified timestamping authority — that vendor's evidence survives a contested hearing.

CarveTrace was built to survive this hearing. The verifier at verify.carvetrace.com runs in any browser, no account, no CarveTrace involvement. The verification libraries are open-source. The bundles anchor to RFC 3161 TSAs and optionally to Bitcoin via OpenTimestamps. If you want to see what the defense pattern looks like in practice, drop the sample CV-screening bundle into the verifier and read the dossier on the AI override. That is a contested-hearing-ready record.