Skip to content

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