# Liability for failing AI: the revised PLD

[Skip to content](#lm-inhoud)Network/[NL](/en/aansprakelijkheid-bij-falende-ai-de-impact-van-de-herziene-pld)EN[Hubhub.llmnet.nlCompare models on task, language, cost and licence.](https://hub.llmnet.nl/en/)[Communitycommunity.llmnet.nlPrompt techniques, patterns and system prompts.](https://community.llmnet.nl/en/)[APIapi.llmnet.nlLLMs in production: rate limits, routing, structured output.](https://api.llmnet.nl/en/)[Consultancyconsultancy.llmnet.nlRolling out AI in an organisation, pilot to production.](https://consultancy.llmnet.nl/en/)[Newsnieuws.llmnet.nlAI developments, explained for the Netherlands.](https://nieuws.llmnet.nl/en/)[Benchmarkbenchmark.llmnet.nlMeasure AI quality yourself, on your own tasks.](https://benchmark.llmnet.nl/en/)[Careersvacatures.llmnet.nlAI roles, salaries and career paths in the Netherlands.](https://vacatures.llmnet.nl/en/)[Learnleren.llmnet.nlAI concepts in plain language, beginner to builder.](https://leren.llmnet.nl/en/)[Guidegids.llmnet.nlRun AI privately on your own Mac, PC, NAS or home server.](https://gids.llmnet.nl/en/)[Directorydirectory.llmnet.nlMapping the AI ecosystem: tools, models, companies.](https://directory.llmnet.nl/en/)[Radarradar.llmnet.nlSignals from X, research and communities for indie developers.](https://radar.llmnet.nl/en/)[Appsapps.llmnet.nlReviews of AI apps and open-source repos, with tips for builders.](https://apps.llmnet.nl/en/)[llmnet.nl — main site](https://llmnet.nl/en/)[](https://x.com/intent/post?url=https%3A%2F%2Fnieuws.llmnet.nl%2Fen%2Faansprakelijkheid-bij-falende-ai-de-impact-van-de-herziene-pld&text=Liability%20for%20failing%20AI%3A%20the%20revised%20PLD)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fnieuws.llmnet.nl%2Fen%2Faansprakelijkheid-bij-falende-ai-de-impact-van-de-herziene-pld)[](https://www.reddit.com/submit?url=https%3A%2F%2Fnieuws.llmnet.nl%2Fen%2Faansprakelijkheid-bij-falende-ai-de-impact-van-de-herziene-pld&title=Liability%20for%20failing%20AI%3A%20the%20revised%20PLD)[](#)[](https://x.com/intent/post?url=https%3A%2F%2Fnieuws.llmnet.nl%2Fen%2Faansprakelijkheid-bij-falende-ai-de-impact-van-de-herziene-pld&text=Liability%20for%20failing%20AI%3A%20the%20revised%20PLD)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fnieuws.llmnet.nl%2Fen%2Faansprakelijkheid-bij-falende-ai-de-impact-van-de-herziene-pld)[](https://www.reddit.com/submit?url=https%3A%2F%2Fnieuws.llmnet.nl%2Fen%2Faansprakelijkheid-bij-falende-ai-de-impact-van-de-herziene-pld&title=Liability%20for%20failing%20AI%3A%20the%20revised%20PLD)[](#)

 
# Liability for failing AI: the impact of the revised PLD

 By Ivo Donker — compiled with AI support (Claude & Gemini)

 Liability for damage caused by software and autonomous systems is undergoing a fundamental shift. Where the discussion around European regulation long focused on market access and prior conformity assessments, the revised Product Liability Directive (abbreviated as PLD) determines what happens when a system actually fails in practice and causes material or non-material damage. In [the explanation of the EU AI Act](https://nieuws.llmnet.nl/en/eu-ai-act-uitleg) the timeline of safety requirements and risk categories takes center stage; the revised PLD is the private-law counterpart that gives victims a concrete right of action against developers, integrators and importers.

 The classic 1985 directive assumed tangible, industrial goods such as defective brake cables or exploding boilers. In the modernized directive, software — including self-learning algorithms, embedded models and cloud-based AI services — is explicitly equated with a product. Strict liability (liability without fault) therefore now applies directly to software errors, training errors and inadequate model updates. In this article we analyze the legal mechanisms, the reversal of the burden of proof and the direct consequences for the technical architecture of AI applications.

 
## From physical product to software and autonomous systems

 Under the original product liability law, claimants in cases of software-related damage consistently ran into the definition of a 'product'. In many member states, damage caused by pure software was not handled through strict liability but through general tort law. That placed the full burden of proving fault and negligence on the injured party. The revised directive draws a definitive line under this: software qualifies unambiguously as a product, regardless of whether it is recorded on a physical carrier, delivered as source code, or runs as an API service (Software-as-a-Service).

 This status also applies when the software makes decisions autonomously or adjusts its operation after it has been put into use through continuous training loops. When a machine learning model starts to behave differently after rollout in an operational environment because of new data flows, the manufacturer or integrator remains responsible for safeguarding safety. The scope is not limited to purely physical injury or property damage; the destruction or irreparable corruption of data and serious harm to psychological health (provided it is medically established) now also fall explicitly within the concept of recoverable damage.

 For organizations this means the operational phase of a model carries as much risk as the initial release. A model that met all benchmarks at delivery but develops unsafe behavior through concept drift or adversarial manipulation can lead directly to civil liability for the party that retained control over the product.

 
## The causal 'black box' problem and the reversal of the burden of proof

 The biggest obstacle for injured parties in AI damage cases is the asymmetric knowledge advantage of the technology supplier, combined with the inherent opacity of deep neural networks. In practice, an injured consumer or organization can rarely show which specific weights, prompt injections or missing validation layers led to an incorrect decision. To prevent this from creating a legal vacuum in which claims are hopeless from the outset, the revised PLD introduces two powerful procedural instruments: a duty to disclose information and a rebuttable presumption of defect and causation.

 When a claimant makes it plausible that they suffered damage and that the AI system was involved, but cannot prove the exact defect because of excessive technical complexity, the court can order the defendant to disclose relevant internal documentation and logs. If the defendant refuses to provide this data, or cannot show that it met the applicable safety and monitoring requirements, the presumption of causation takes effect. The court then automatically assumes that the system was defective and that this defect caused the damage, unless the manufacturer proves otherwise.

 To understand how organizations mitigate these liability risks operationally, [the guide to the AI Act in practice](https://nieuws.llmnet.nl/en/ai-act-in-de-praktijk-wat-bedrijven-in-2026-concreet-moeten-doen) shows which concrete measures companies must take to meet the statutory documentation obligations. Under the revised directive, the absence of robust logging is a direct litigation risk.

 
## Liability chains: from foundation model to end application

 AI applications are almost never built from scratch. A typical stack consists of an underlying foundation model, a hosting infrastructure, an orchestration layer (such as a RAG pipeline) and an industry-specific user interface. The revised PLD sets out who within this chain counts as the liable party when the end product fails.

 
 
 
 
 Role in the AI chain | 
 Primary PLD responsibility | 
 Critical liability risk | 
 

 
 
 
 Model provider (base model) | 
 Safety of the base architecture and data filtering | 
 Latent vulnerabilities and undocumented model instability | 
 

 
 System integrator / fine-tuner | 
 Substantial modification and end-product integration | 
 Loss of alignment after domain-specific training or RAG | 
 

 
 EU importer / authorized representative | 
 Liable in the case of non-EU manufacturers | 
 Full strict liability without direct influence on the source code | 
 

 
 Operator / deployer | 
 Use within established safety limits | 
 Careless supervision or use outside the operational design parameters | 
 

 
 
 

 The main rule is that the party that substantially modifies a system (for example through fine-tuning or by connecting autonomous tools with decision-making authority) is legally regarded as the manufacturer of the resulting product. If an integrator embeds a general language model in an automated medical triage system or a financial advice platform, that party cannot hide behind the supplier of the base model when damage occurs.

 When non-European suppliers deliver services without an establishment inside the European Union, full strict liability automatically shifts to the European importer or the official authorized representative. This forces European integrators into rigorous due diligence when selecting components.

 
## The development risk defense under pressure

 Traditionally, product liability law contains the so-called development risk defense: a manufacturer is not liable if the state of scientific and technical knowledge at the time the product was put into circulation made it impossible to discover the defect. In the context of probabilistic, non-deterministic AI models, this defense was heavily contested.

 Under the revised directive, the application of this defense to AI systems has been considerably narrowed. A manufacturer can no longer invoke the unpredictability of a neural network as an excuse for failing output. Since hallucinations, bias and vulnerability to prompt manipulation are known properties of this architecture, incidents that follow from them fall within the foreseeable risk profile of the product. Manufacturers must show that they applied the state of the art in evaluation, monitoring and fallback mechanisms.

 Formal technical frameworks play a decisive role here. See [the file on AI standards and ISO standardization](https://nieuws.llmnet.nl/en/ai-standaarden-en-iso-normering) for the standards (such as ISO/IEC 42001 and CEN/CENELEC standards) that determine what courts in practice regard as the applicable 'state of the art' in liability assessments.

 
## Interaction between the AI Act and the Product Liability Directive

 The EU AI Act and the revised PLD function as a pair within European digital law, but they serve a fundamentally different purpose. The AI Act is a public-law instrument aimed at market access, risk management and supervision by national authorities. A manufacturer that violates the AI Act risks administrative fines and a market ban, but the AI Act itself does not arrange compensation for individual victims.

 The revised PLD is the private-law complement: it governs civil compensation for damage suffered. There is, however, a direct evidentiary bridge between the two instruments. When a deployer or integrator can show that an AI system did not meet the fundamental requirements of the AI Act (such as mandatory data quality, risk assessments, logging or human oversight), this immediately gives the civil court a strong presumption that the product was defective within the meaning of the PLD.

 Conformity with the AI Act, on the other hand, offers no absolute immunity from civil claims. A system can formally meet all market access requirements and still show a defect in a specific real-world scenario that leads to liability as soon as damage occurs.

 
## Contractual effects and indemnities in practice

 Because strict liability under the PLD is mandatory law in favor of consumers and injured parties, suppliers cannot contractually exclude this liability toward the outside world. This has led to a radical restructuring of business contracts (B2B) within the technology sector.

 Integrators and software companies shift the financial risk of potential claims to suppliers and model providers through strict indemnity clauses, capped liabilities and specific Service Level Agreements (SLAs). To assess how organizations record this allocation of risk watertight, the analysis of [vendor contracts for AI](https://consultancy.llmnet.nl/en/vendorcontracten-voor-ai-waar-je-op-toetst) offers concrete guidance for formulating liability limits and warranties when buying in external model capacity.

 In practice we see that established model suppliers explicitly exclude any warranty on the factual accuracy of generated output. As a result, the liability risk of a failing system rests almost entirely on the party that implements the model in an operational workflow without adequate validation steps.

 
## Technical measures for auditability and log management

 To prevent an organization from being confronted with the judicial presumption of causation in a liability claim, setting up a robust logging and traceability architecture is necessary. Reconstructing the exact state of a model, the context passed to it and the input it received afterward is the only effective defense against claims.

 A compliant logging architecture must record at least the following components immutably:

 
 
- The exact version and model parameters (including temperature, top-p and system prompts) that were active during inference.
 
- The full context payload, including the specific document fragments injected through retrieval-augmented generation (RAG).
 
- The results of automated validation filters (guardrails) before and after the model call.
 
- Any intervention or approval by a human supervisor (human-in-the-loop).
 

 The configuration below shows a functional schema for an audit log event payload that meets the traceability requirements under the revised directive:

 {
 "event_id": "evt_20260819_9481a",
 "timestamp": "2026-08-19T17:22:04.118Z",
 "system_identifier": "triagesysteem-medisch-v2.4",
 "model_provider": "local-hosted-inference",
 "model_version_hash": "sha256:d8b74c83e29f01a3",
 "inference_parameters": {
 "temperature": 0.0,
 "seed": 42
 },
 "retrieval_context": {
 "source_dataset_id": "protocol-nl-2026-v3",
 "chunk_references": ["doc_883_p12", "doc_902_p4"]
 },
 "guardrail_evaluations": {
 "input_safety_passed": true,
 "output_toxicity_score": 0.002,
 "factual_consistency_score": 0.984
 },
 "human_override": {
 "reviewed_by_user_id": "usr_dr_8829",
 "override_action": "none"
 }
}

 
## Outlook on enforcement and case law

 The implementation of the revised Product Liability Directive marks the end of the noncommittal experimental stage for AI applications in production environments. Where software developers were historically used to far-reaching contractual disclaimers ("as is" delivery without liability for consequential damage), the European strict liability regime forces the same quality assurance and product safety that applies to the medical and automotive industries.

 For organizations that design, integrate or deploy AI systems, the center of gravity of risk management shifts from purely administrative compliance to measurable, technical robustness. Anyone who cannot show which data fed the model, how guardrails functioned and which checks were carried out automatically bears the heavy burden of the statutory presumption of defect when damage occurs. In the coming years, judicial review through test cases and civil damage claims will determine exactly where the limits lie of what may be expected of a reasonably acting AI developer.