AI Liability: Who Is Liable When AI Causes Harm?¶
Purpose
Scenario-based liability mapping covering the EU Product Liability Directive (PLD 2024/2853), agentic AI actions, vendor LLM faults, and HITL failures — with the internal controls that reduce exposure.
1. Regulatory Context¶
The EU Product Liability Directive 2024/2853 ([so-41]) entered into force on 9 December 2024 and must be transposed into national law by 9 December 2026. It explicitly covers software and AI systems as "products", replacing the 1985 directive that predated digital products.
Key changes from the 1985 PLD:
| Old PLD (1985) | New PLD 2024/2853 |
|---|---|
| Covered tangible products only | Covers software, AI systems, digital services |
| Claimant must identify exact defect | Disclosure obligation: defendants must provide evidence |
| No provision for autonomous systems | Addresses damage caused by autonomous/agentic systems |
| Strict product defect standard | Adds "reasonably foreseeable misuse" as defect criterion |
When does PLD apply?
PLD applies when an AI system is placed on the market or put into service and causes personal injury, property damage, or data loss. It does not replace contract law or employment law — these continue to apply alongside PLD.
2. Liability Scenarios¶
Scenario Matrix¶
| Scenario | Deployer exposure | Provider/Vendor exposure | Key evidence to hold |
|---|---|---|---|
| A — Faulty vendor LLM output | Low (if vendor contract covers it) | High (provider is manufacturer under PLD) | Vendor SLA, API version log, vendor liability clause |
| B — Your own fine-tuned/trained model | High — you are the manufacturer | N/A | Model Card, training data provenance, Validation Report |
| C — Agentic AI (Mode 4-5) causes harm | High — deployer controls system design | Medium (if vendor model caused the action) | Mode assignment justification, Hard Boundaries, human oversight logs |
| D — HITL approval of wrong decision | Shared — human approved the output | Low | Audit log of human approval, training records, override capability |
| E — RAG system retrieves outdated/wrong info | High — deployer controls retrieval | Low | Data governance log, freshness monitoring, knowledge source version |
Scenario A: Faulty Vendor LLM Output¶
When you call a third-party LLM API and the model outputs factually wrong, harmful, or discriminatory content:
- PLD treats the model provider as manufacturer; you are the downstream deployer
- Your liability is reduced if you can show you implemented reasonable input/output controls
- Protect yourself: vendor liability clause in contract; API version pinning; input validation; output filtering; refusal logging
Scenario B: Your Own Model or Fine-Tuned System¶
When you train or fine-tune a model yourself (typical in Type B projects):
- You are the manufacturer under PLD — full strict liability applies
- Defect = model produces unreasonably dangerous output given its intended use
- Protect yourself: Validation Report with bias audit; Golden Set test coverage; documented Hard Boundaries; Model Card with known limitations; monitoring with drift detection
Scenario C: Agentic AI Taking Autonomous Actions (Mode 4–5)¶
When an AI agent executes real-world actions (sends emails, places orders, modifies files) without per-action human approval:
- PLD considers deployer liable for the system design that allowed autonomous action
- "Reasonably foreseeable misuse" standard applies to unexpected downstream effects
- Protect yourself: Mode assignment documented in Objective Card; Hard Boundaries restrict irreversible actions; human oversight logs capture scope; automated stop-rules active
Mode 4–5 liability exposure is highest
Autonomous AI operating without per-action oversight is where PLD exposure is greatest. Ensure Hard Boundaries explicitly block actions above a defined reversibility threshold, and that the Mode Transition Protocol was followed (Gate evidence).
Scenario D: Human-in-the-Loop Approves Wrong Decision¶
When a human approves an AI recommendation that turns out to be harmful:
- Human professional liability applies alongside PLD (e.g. medical, financial, legal domains)
- PLD still covers the AI system if the output was defective — human approval does not extinguish product liability
- Protect yourself: Training records showing humans understood AI limitations; documented that override capability was available and functional; audit log of approvals with context shown to the approver
Scenario E: RAG System Retrieves Outdated or Incorrect Information¶
When a retrieval-augmented system surfaces outdated knowledge that leads to harmful advice:
- Deployer controls the retrieval pipeline and is liable for its freshness/accuracy
- Outdated information retrieved from a controlled knowledge base = product defect
- Protect yourself: Knowledge source version log; TTL / freshness monitoring; documented data governance sign-off per knowledge source (see Data Engineering exit criteria in the AI Lifecycle)
3. Defensive Evidence Pack per Risk Level¶
Minimal Risk¶
- Objective Card with Hard Boundaries
- Basic output logging (retain ≥ 3 months)
Limited Risk¶
All above, plus:
- Model Card or Technical Model Card
- Vendor SLA with liability clause
- Fairness Check result (Validation Report §5)
High Risk¶
All above, plus:
- Full Validation Report signed by Guardian
- Bias audit at quantitative threshold (≤ 5% group difference)
- Mode assignment justification (Gate 1 evidence)
- Human oversight protocol documented and tested
- Post-market monitoring active (Art. 72 EU AI Act)
- Incident response plan tested
- SBOM for ML pipeline (see Model Governance §7)
4. PLD and the AI Act: Overlapping Obligations¶
The EU AI Act and PLD are complementary, not duplicative:
| Obligation | EU AI Act | PLD 2024/2853 |
|---|---|---|
| Scope trigger | Risk classification (High, Limited…) | Product placed on market causing damage |
| Liability type | Administrative fines + supervisory | Civil compensation to harmed parties |
| Disclosure burden | Provider must document system | Court can order defendant to disclose evidence |
| High Risk overlap | Art. 9–17 technical requirements | Compliance with AI Act is evidence against defect claim |
Compliance as a liability shield
EU AI Act compliance documentation (Validation Report, Technical Model Card, monitoring logs) is directly usable as evidence in PLD proceedings. A project that passed all Gate Reviews has a strong evidentiary position.
5. Liability Checklist¶
AI Liability Checklist
- Vendor contract includes AI liability clause (Scenario A)
- API version pinned and output filtering active (Scenario A)
- Model Card / Technical Model Card current and signed (Scenario B)
- Mode assignment justified in Gate evidence; Hard Boundaries documented (Scenario C)
- Human oversight logs retained ≥ 12 months for High Risk (Scenario D)
- Knowledge source freshness monitored and versioned (Scenario E)
- Defensive evidence pack complete per risk level (§3)
- PLD transposition date (9 December 2026) in compliance calendar
6. Related Modules¶
- EU AI Act
- Risk Management & Compliance
- Ethical Guidelines
- Incident Response
- Model Governance
- Third-Party Model Governance