PLD 2024/2853 Software Defect Presumption: How AI & SaaS Systems Create Liability Under New EU Rules

Post #2 in the sota.io EU Product Liability Directive Series

One of the most consequential changes in Directive (EU) 2024/2853 is not the expansion of "product" to cover software — it is what happens once a claimant gets to court. The old 1985 directive placed a heavy burden on injured parties to prove that a specific product was defective, that it caused the damage, and that the defect existed when the product left the manufacturer. For physical goods with simple failure modes, this was manageable. For a SaaS platform with millions of lines of code, distributed infrastructure, and AI components, that burden of proof was nearly impossible to discharge.

The new directive changes this calculus fundamentally through a set of rebuttable presumptions that shift evidential weight toward software providers and away from injured claimants.

Why the Old Burden of Proof Protected Software Providers

Under the 1985 directive, a claimant suing over a defective software product faced a nearly insurmountable evidentiary challenge:

1. Identify the specific defect — which line of code, which configuration, which edge case caused the harm
2. Prove the defect existed when the software was deployed — not that it appeared later through a separate update
3. Link that defect causally to the damage — through a chain of events that may have involved user error, network issues, third-party integrations, or unpredictable AI outputs

In practice, this meant that product liability claims against software providers almost never succeeded in EU courts. The information asymmetry was enormous: the developer held all the source code, logs, and technical documentation. The claimant had a malfunctioning application and mounting damages.

The Three Presumption Mechanisms in PLD 2024/2853

The new directive introduces three situations in which defectiveness is presumed — meaning the claimant does not need to prove it directly. The burden then shifts to the software provider to rebut the presumption.

1. Abnormal Product Behavior

If a claimant can show that the product behaved in a way that is not consistent with what a person is entitled to expect from that type of product, defectiveness is presumed. The claimant does not need to identify the technical root cause. They need only demonstrate that the product failed to perform as expected — a standard substantially easier to meet than identifying the defective code.

For SaaS platforms, this creates a significant shift. A claimant who can show that a platform returned incorrect financial calculations, misclassified a medical image, or deleted user data without authorization can trigger the presumption without understanding why the software failed.

Practical implication: Your product's stated purpose and marketing materials become evidence against you. If you promise reliable document processing and documents are corrupted, expected behavior provides the baseline against which abnormality is measured.

2. Technical Complexity and Information Asymmetry

The directive explicitly addresses the situation where it would be excessively difficult for a claimant to prove defectiveness due to the technical or scientific complexity of the product. In such cases, a claimant who can demonstrate that the product caused damage and that the product was involved in the causal chain can have defectiveness presumed.

This provision was written with AI systems in mind. When a large language model generates harmful content, an autonomous vehicle makes a dangerous maneuver, or a credit-scoring algorithm denies a loan incorrectly, tracing the defect to a specific training data point, architectural choice, or inference-time failure is technically complex beyond what a non-expert claimant could reasonably manage.

The directive's answer: if the complexity itself shields the developer from accountability, the law removes that shield.

Practical implication: Complexity is no longer a defense. The more opaque your system, the more likely a court will apply the information-asymmetry presumption. This creates a direct incentive to invest in explainability, audit logs, and decision traceability.

3. Information Disclosure Obligations

The directive imposes mandatory information disclosure requirements on defendants in product liability proceedings. Software providers must produce:

• Technical documentation about the product's design and function
• Security and update records covering the period when the alleged defect was active
• Internal testing, quality assurance, and incident documentation
• Any technical risk assessments conducted prior to deployment

Courts may draw adverse inferences if a defendant fails to produce requested documentation without adequate justification. This is structurally similar to disclosure duties in common law jurisdictions but new for most EU member states, which traditionally gave defendants stronger protections against compelled evidence production.

Practical implication: Your internal documentation practices matter now in ways they never did before. Inadequate logging, missing security test records, or incomplete incident reports are no longer just engineering discipline failures — they become legal exposure.

AI Systems: A Special Liability Landscape

AI-powered software sits at the intersection of multiple liability regimes under EU 2024/2853.

The Learning Problem

Traditional products are manufactured in a fixed state. A defective brake pad has the same defect throughout its lifecycle. AI systems that learn from operational data change their behavior over time. A model that was safe at deployment may develop unsafe patterns after fine-tuning on production data, after distribution shift alters its input domain, or after an adversarial attack corrupts its outputs.

The directive resolves this through a lifecycle defectiveness standard: a product is defective if it does not provide the safety a person is entitled to expect, taking into account all circumstances including the presentation of the product, the use to which it could reasonably be put, and the time when the product was put into circulation or when the service containing software was supplied.

For continuously updated AI systems, "time of supply" is effectively ongoing. This means a SaaS provider whose AI model causes harm due to behavioral drift after deployment cannot straightforwardly claim the defect postdates the original deployment.

The Autonomy Problem

When an AI system makes a decision that causes harm, identifying whose decision it was becomes legally contested. The directive holds the manufacturer — which for an AI-powered SaaS is typically the software provider — liable for defects in the product, including the AI components embedded in it.

If you use a third-party foundation model embedded in your product, you remain liable for harms caused by that model's defective behavior unless you can show the defect was caused by the component supplier's instructions and you complied with those instructions. Relying on an LLM API without independently validating outputs for your specific use case creates liability exposure that your supplier contracts may not protect you from.

The Opacity Problem

AI systems present a fundamental documentation challenge: neural networks often cannot explain why they produced a specific output. The directive's information disclosure obligations require defendants to produce technical documentation explaining the product's design. For a neural network, this documentation may exist (training data, architecture, evaluation results) without explaining the specific inference that caused harm.

Courts will need to develop standards for what constitutes adequate technical documentation of AI behavior. In the interim, developers who invest in interpretability tooling, output monitoring, and behavioral testing create stronger legal defenses than those who deploy opaque models with minimal instrumentation.

The Development Risk Defense: Narrowed for Software

The 1985 directive included a "development risk" defense: a manufacturer could avoid liability if the state of scientific and technical knowledge at the time the product was put into circulation was not such that the defect could have been discovered. EU member states had the option to exclude this defense, but most retained it.

The new directive retains the development risk defense but narrows its application significantly for software and AI. The defense is unavailable in specific circumstances:

• Where the defect was discoverable through standard industry testing practices
• Where the manufacturer had internal evidence suggesting a potential defect and chose not to investigate
• Where the defect relates to known categories of AI failure modes (bias, adversarial vulnerabilities, distribution shift)

The practical effect: software providers cannot claim that they could not have known about defects in areas where the industry has established testing methodologies. If your AI system produces biased outputs and published research on bias testing in your domain existed before deployment, the development risk defense is likely unavailable.

Damage Scope: Beyond Physical Injury

The 1985 directive covered death, personal injury, and property damage (above a minimum threshold). The new directive adds:

Loss and corruption of data — damage to data that is not used exclusively for professional purposes is now compensable as product damage. For a SaaS application that processes personal documents, photos, or records, a data loss incident is now a product liability event, not merely a contractual one.

Medically recognized psychological harm — where a software defect causes documented psychological damage (for example, an algorithmic content recommendation system contributing to documented harm), that damage is compensable.

These additions mean product liability exposure can arise from categories of harm that were previously addressed only through contract, data protection law, or separate tort claims. A single incident may now be subject to simultaneous claims under PLD 2024/2853, GDPR, NIS2, and applicable national tort law.

What the Presumptions Mean for Your Legal Strategy

Build for Presumption Rebuttal

Every presumption in PLD 2024/2853 is rebuttable. The presumptions shift the burden — they do not create strict liability without any defense. Your legal strategy should be built around the evidence you can produce to rebut each presumption:

Documentation Architecture Matters

The disclosure obligations make your internal technical documentation a legal asset. Consider:

• Immutable audit logs for AI decisions affecting users
• Version-controlled specification documents that establish expected behavior at deployment
• Continuous security testing records that document when issues were discovered and remediated
• Incident reports that distinguish between user-reported defects and confirmed product defects

Third-Party Component Liability

If your SaaS uses third-party AI models, APIs, or infrastructure components that contribute to a defect, you have a contribution claim against those suppliers — but only if you can demonstrate you complied with their integration instructions and the defect originated in their component. Maintain records of:

• Vendor technical specifications at time of integration
• Your compliance with documented integration requirements
• Monitoring results showing the third-party component's behavior over time

Timeline and Jurisdictional Considerations

PLD 2024/2853 applies when:

• The product was manufactured or the service was supplied by a business established in the EU
• The damaged person is in the EU
• The product was distributed or the service was supplied in the EU market

Transposition deadline is December 9, 2026. After that date, each EU member state's implementation may differ in procedural details — some may choose more claimant-friendly presumption rules, others may impose additional documentation requirements on AI providers.

Limitation periods: claimants generally have three years from when they knew or should have known about the damage, the defect, and the identity of the liable party. A separate long-stop period extinguishes claims fifteen years after the product was put into circulation, with an exception for harm that manifests with a long latency period.

For SaaS services delivered continuously, the limitation clock may restart with each service delivery event — a point that will require judicial clarification as PLD 2024/2853 is litigated in national courts.

Immediate Action Items for SaaS & AI Providers

Before December 9, 2026:

1. Audit your AI components — identify which elements of your system make autonomous decisions that could harm users or third parties
2. Map your documentation gaps — where would you struggle to produce evidence rebutting each presumption?
3. Review your supplier contracts — do they include indemnification clauses for product defects in third-party components?
4. Assess your logging infrastructure — can you reconstruct what your system did, when, and why for any point in the past three years?
5. Update your product liability insurance — traditional CGL policies may not cover software product defects; specialist tech E&O or product liability cover may be required

In the next six months:

• Implement behavioral monitoring for AI components with anomaly detection
• Establish a technical documentation standard that addresses legal disclosure requirements
• Conduct a PLD 2024/2853 gap analysis as part of your compliance roadmap
• Review your terms of service — contractual limitations on liability may conflict with mandatory PLD rights that cannot be excluded by contract

Next in This Series

The next post covers data loss and privacy liability under PLD 2024/2853 — how the directive's coverage of data corruption as compensable damage intersects with GDPR, and what dual-exposure means for your data handling architecture.

PLD 2024/2853 is in transposition. The presumptions and disclosure obligations described here are based on the directive text published in the Official Journal of the European Union on November 18, 2024. Member state implementations may vary. Consult qualified EU legal counsel for advice applicable to your specific situation.