AI Liability and Product Liability Guide (EU PLD 2024)

When an AI system or AI agent causes harm, the question of who pays is now answered mainly by product liability law, not by an AI-specific liability regime. In the EU, the new Product Liability Directive (EU) 2024/2853 brings software and AI systems explicitly within strict, no-fault liability for products placed on the market from 9 December 2026, while the proposed AI Liability Directive has been withdrawn. The UK and the US rely on existing product liability, negligence and consumer protection law. This guide explains who is covered, what the new rules require, the current status in each jurisdiction, and what security and engineering teams must change in how they build, update, log and govern AI systems, including agents that act through non-human identities. It is written for security leaders, AI platform owners and counsel.

Key takeaways

Software is a product. Directive (EU) 2024/2853 defines product to include software and digital manufacturing files, and the Commission states that applications, operating systems and AI systems are all covered.
Cybersecurity is a defect question. Article 7(2)(f) makes safety-relevant cybersecurity requirements a factor in deciding whether a product is defective, so a missed patch can become a liability claim.
Control after release matters. Manufacturers cannot rely on the "defect arose later" defence where the cause is software, an update, a missing safety update or a related service still within their control (Article 11(2)).
The AI Liability Directive is gone. The Commission announced its withdrawal in the 2025 work programme and the withdrawal was published in the Official Journal on 6 October 2025.
Evidence wins or loses cases. Courts can order disclosure and presume defect or causation where a defendant does not disclose or where technical complexity makes proof excessively difficult, so audit trails for agents are now a legal asset.

Scope: who and what is covered

The Product Liability Directive (PLD) replaces Council Directive 85/374/EEC. It was adopted on 23 October 2024 and entered into force on 8 December 2024. It gives any natural person who suffers damage caused by a defective product a right to compensation (Article 5). Liability is strict: the claimant does not have to prove fault, only defect, damage and causal link (Article 10(1)).

What counts as a product

Software: Article 4(1) lists software alongside electricity, raw materials and digital manufacturing files. Recital 13 treats software as a product regardless of how it is supplied, but excludes pure information such as media files, e-books or mere source code.
Components: any tangible or intangible item, raw material or related service integrated into or inter-connected with a product (Article 4(4)). A third-party model, plugin or library integrated into your product is a component.
Related services: digital services integrated into or inter-connected with a product such that the product cannot perform one of its functions without them (Article 4(3)), for example a cloud inference service a device depends on.
Free and open-source software: excluded when developed or supplied outside a commercial activity (Article 2(2)). Recital 14 explains that supply for a price, or for personal data used beyond security, compatibility or interoperability, can bring it into scope. A commercial product that integrates open-source code remains in scope.

Who can be liable

Economic operator	When liable (Article 8)	AI example
Manufacturer	Always, for its defective product (8(1)(a)); includes those who present themselves as manufacturer (4(10))	Vendor of an AI-enabled medical triage app or an agent platform
Component manufacturer	Where its defective component, integrated under the product manufacturer's control, caused the defect (8(1)(b))	Supplier of a fine-tuned model or safety classifier embedded in the product
Importer, authorised representative, fulfilment service provider	Where the manufacturer is established outside the EU (8(1)(c))	EU importer of a non-EU robot with on-board AI
Substantial modifier	Treated as manufacturer when it substantially modifies a product outside the manufacturer's control and makes it available (8(2))	Integrator who retrains or re-purposes a model so its risk profile changes
Distributor and online platform	Only if no EU operator is identified and they fail to name one within one month of a request (8(3), 8(4))	Marketplace listing an AI device from an unidentifiable seller

What damage is covered

Article 6 covers death and personal injury, including medically recognised damage to psychological health; damage to property other than the defective product itself, excluding property used exclusively for professional purposes; and destruction or corruption of data not used for professional purposes. Pure business-to-business losses and professional data are therefore outside the PLD and remain a matter for contract and national tort law, which matters for enterprise AI deployments.

Key obligations

The PLD sets no compliance duties like the EU AI Act; its obligations are the safety standard a product must meet and the evidence rules when it fails.

Defectiveness: the factors a court considers

A product is defective if it does not provide the safety a person is entitled to expect or that Union or national law requires (Article 7(1)). Article 7(2) lists the factors, several of which target AI directly.

Article 7(2) factor	What it means for AI systems	Engineering evidence to keep
(a) presentation, labelling, instructions	Instructions for use, stated limitations and warnings define expected safety	Versioned model cards, user documentation, in-product disclosures
(b) reasonably foreseeable use	Includes foreseeable misuse such as prompt injection by users or third parties	Threat models, abuse case testing, red team results
(c) ability to continue to learn or acquire new features after release	Self-learning and post-release capability changes are judged as part of the product	Model version history, evaluation results per release, drift monitoring
(d) effect of other products used together, including through inter-connection	Tool integrations and agent-to-agent calls are in scope	Integration inventory, tool permission scopes, interface tests
(e) moment of placing on market or leaving manufacturer's control	Products updated continuously stay under control longer	Release and update records
(f) safety requirements, including safety-relevant cybersecurity requirements	Non-compliance with, for example, Cyber Resilience Act or AI Act requirements weighs towards defect	Conformity evidence, vulnerability handling records
(g) recalls or other interventions	Regulator or self-initiated recalls are relevant	Incident and recall log
(h) specific needs of intended users	Products for children or vulnerable users must meet a higher expectation	User group analysis, safeguards per audience
(i) products whose purpose is to prevent damage	A security or safety AI that fails at its job can be defective for that reason alone	Detection efficacy testing

Article 7(3) protects manufacturers from the argument that a better product or a later update proves the earlier one was defective.

Disclosure and presumptions

Disclosure (Article 9): where a claimant presents facts and evidence sufficient to support the plausibility of the claim, the court can order the defendant to disclose relevant evidence, subject to necessity, proportionality and protection of trade secrets. Courts can require it in an accessible and understandable form.
Presumed defect (Article 10(2)): where the defendant fails to disclose, where the product does not comply with mandatory safety requirements, or where damage was caused by an obvious malfunction during reasonably foreseeable use.
Presumed causation (Article 10(3)): where the product is defective and the damage is of a kind typically consistent with that defect.
Complexity presumption (Article 10(4)): where the claimant faces excessive difficulties, in particular due to technical or scientific complexity, and shows that defect or causation is likely. This is the provision most relevant to opaque models.
Rebuttal (Article 10(5)): all presumptions can be rebutted, which is where good logs, evaluations and records earn their keep.

Defences and limits

Later defect (Article 11(1)(c)): not available where the defect is due to a related service, software including updates, a lack of updates needed for safety, or a substantial modification, while within the manufacturer's control (Article 11(2)).
Development risk (Article 11(1)(e)): the state of scientific and technical knowledge could not reveal the defect. Member States may keep or, under conditions, introduce measures that remove this defence for specific product categories (Article 18).
No contractual exclusion (Article 15): liability to the injured person cannot be limited or excluded by contract.
Joint and several liability (Article 12): several operators can be liable for the same damage; a manufacturer integrating software from a micro or small enterprise may waive recourse by contract (Article 12(2)).
Time limits: three years from awareness of damage, defect and liable operator (Article 16); claims expire ten years after placing on the market or after a substantial modification, extended to 25 years for latent personal injury (Article 17).

Timeline and current status

Status as checked on official sources on 24 October 2026. National implementing laws may differ in detail, so check the measure in each Member State where you sell.

Jurisdiction	Instrument	Status
EU	Product Liability Directive (EU) 2024/2853	Adopted 23 October 2024; in force 8 December 2024; transposition deadline 9 December 2026 (Article 22); applies to products placed on the market or put into service after 9 December 2026 (Article 2(1)); Directive 85/374/EEC repealed with effect from 9 December 2026 but continues to apply to earlier products (Article 21); Commission evaluation by 9 December 2030 (Article 20)
EU	AI Liability Directive proposal, 2022/0303(COD)	Proposed 28 September 2022 (rebuttable presumption of causality and disclosure for high-risk AI); withdrawal announced in the Commission 2025 work programme, COM(2025) 45; withdrawal published as C/2025/5423 on 6 October 2025. No formal replacement proposed
UK (Great Britain)	Consumer Protection Act 1987, Part I	In force. Strict liability for defective products with section 4 defences, including the state of scientific and technical knowledge defence (s4(1)(e)). Whether standalone software is a "product" is not settled by the Act. The Law Commission published a discussion paper, Artificial Intelligence and the Law, on 31 July 2025, noting that existing frameworks may struggle to allocate responsibility for autonomous systems; it proposed no reforms
US	State product liability, negligence and consumer protection law; FTC Act	No federal AI liability statute. The FTC's Operation AI Comply (25 September 2024) took action over deceptive AI claims, with then Chair Lina Khan stating that "there is no AI exemption from the laws on the books"

Because the PLD applies by placing-on-market date, one AI product line may sit under two regimes either side of 9 December 2026. With the AILD withdrawn, fault-based AI claims stay under national tort law.

Liability for an AI output does not need new law at all. In the Air Canada Chatbot Ruling 2024, the airline was held responsible for the wrong answer its customer service chatbot gave, and could not treat the bot as a separate legal entity responsible for its own statements.

Enforcement and penalties

The PLD has no regulator and no fines. Enforcement is through civil claims for compensation in national courts, and Article 19 requires Member States to publish final judgments of appeal and highest courts, with the Commission maintaining a public database, so case law will become visible over time. Exposure therefore comes from:

Compensation awards: material losses and, where national law allows, non-material losses (Article 6(2)), with no contractual cap (Article 15).
Collective actions: claims can be brought by persons acting on behalf of injured persons (Article 5(2)).
Adverse presumptions: failing to disclose evidence leads to a presumption of defect, so weak record keeping becomes a loss in court rather than a fine.
Regulatory overlap: non-compliance found under the EU AI Act, the Cyber Resilience Act or product safety law feeds directly into the defect assessment and the Article 10(2)(b) presumption. See the EU AI Act Compliance Guide and the EU Cyber Resilience Act Guide.

What it means for AI agents and non-human identities

AI agents act through API keys, OAuth tokens, service accounts and workload identities. When an agent causes harm, the questions a court will ask under Articles 7 and 10 map closely onto identity and access controls.

Liability question	Identity and security control that answers it	Framework reference
Was the harmful action within the product's reasonably foreseeable use?	Least-privilege tool scopes and documented agent permissions	NIST SP 800-53 AC-6; CSF 2.0 GV.OC-03
Which agent, model version and credential performed the action?	Unique identity per agent, no shared keys, signed and attributable actions	SP 800-53 IA-9, AU-10, AU-12
Was the defect caused by a component or integration?	Inventory of models, tools and MCP servers with supplier records	SP 800-53 SR-3, SR-6; CSF 2.0 GV.SC-05
Did a safety update exist and was it applied?	Flaw remediation and controlled release of model and prompt changes	SP 800-53 SI-2, CM-3
Could the system be stopped once it misbehaved?	Kill switch, token revocation and containment playbooks	SP 800-53 IR-6; CSF 2.0 RS.MA-01

Shared credentials destroy attribution: if several agents use one API key, you cannot show which one acted, which weakens rebuttal of a presumption. See the AI Agent Authorisation Guide.
Logs are disclosure material: an Article 9 order may require tool calls, prompts, retrieved context and approvals to be produced in understandable form. Design audit trails for that audience. See the AI Agent Audit Trails for Regulators Guide.
Substantial modification by deployers: an organisation that retrains, re-purposes or wires an agent into high-impact tools outside the vendor's control may become the manufacturer under Article 8(2).
Human approval steps: documented human-in-the-loop gates for high-impact actions support both the foreseeable-use argument and Article 7(2)(h). See the Human-in-the-Loop for AI Agents Guide.

Compliance steps

Classify your role per product: manufacturer, component supplier, importer, substantial modifier or deployer. Record it for every AI product and integration, and for each EU market.
Inventory placing-on-market dates: identify which releases fall after 9 December 2026 and therefore under the new regime, including major model updates that may be substantial modifications.
Map the Article 7(2) factors to evidence: for each product, name the document or system that proves instructions, foreseeable use testing, learning behaviour, interconnection and cybersecurity compliance.
Set update and patch obligations: define how long safety and security updates will be provided, because a missing safety update within your control removes a defence. Align with Cyber Resilience Act support periods where applicable.
Build disclosure-ready logging: retain agent identity, model version, tool calls and approvals for at least the limitation periods that matter to you, with integrity protection. Pilot an internal "disclosure drill" on a past incident to test that records can be produced in readable form.
Revisit supplier contracts: liability to injured persons cannot be excluded, but recourse between operators can be allocated. Require model and tool suppliers to provide evidence, update commitments and cooperation clauses. See the Third-Party AI Risk Guide.
Test and roll back: stage model and prompt changes through evaluation gates and pilot rings, keep the previous version deployable, and record the decision to release or roll back.

Decision guidance

Building vs buying: if you integrate a third-party model and sell the result, you are the manufacturer of the final product and the supplier is a component manufacturer. If you only use an AI tool internally, the PLD mainly governs claims against your vendor, and your own exposure to third parties sits in negligence and contract.
Configure vs modify: configuration within the vendor's documented options is lower risk; retraining or changing intended purpose may cross the substantial modification threshold. Get legal sign-off before such changes in consumer-facing products.
Small vs large organisations: a small software supplier should negotiate the Article 12(2) recourse waiver where it applies; a large manufacturer should expect to carry joint and several liability and invest in supplier evidence rather than indemnities alone.

Detection and measurement

Percentage of in-scope AI products with a documented role, market date and Article 7(2) evidence map.
Percentage of agents with a unique identity and no shared credentials.
Median time from a safety-relevant vulnerability to a released update for AI products.
Percentage of high-impact agent actions with a complete, integrity-protected audit record.
Time to produce a readable evidence pack in a disclosure drill.
Number of AI incidents or complaints reviewed for liability exposure per quarter. See the AI Incident Reporting Guide.

Common failure patterns

Assuming software is outside product liability: teams still treat SaaS and models as services. The PLD and the Commission state otherwise for products placed on the market after 9 December 2026.
Relying on terms and conditions: disclaimers in user terms do not limit liability to injured persons under Article 15.
Logs nobody can read: raw traces without agent identity, model version and context cannot rebut a presumption or satisfy a disclosure order.
Ending updates silently: stopping safety updates for a product still in use removes the later-defect defence where updates were within your control.
Planning around the AI Liability Directive: programmes built for the AILD's presumptions need re-basing on the PLD and national tort law after the October 2025 withdrawal.

Practitioner checklist

Record your Article 8 role and the placing-on-market date for every AI product sold in the EU.
Map each Article 7(2) factor to an owner and a named evidence source.
Publish a support and security update period for each AI product and track adherence.
Give every AI agent its own identity and scoped credentials; remove shared keys.
Log agent actions with identity, model version, tool, input context and approver, with integrity protection.
Run a disclosure drill on one past AI incident each year.
Define the substantial modification threshold for internal retraining and require legal review above it.
Update supplier contracts for evidence, updates and recourse; confirm insurance cover for software and AI.
Track national transposition measures in each EU market and UK and US developments.

Standards and references

This guide summarises AI and product liability rules in the EU, UK and US and is not legal advice. Related NHI Mgmt Group resources: AI Governance Guide · EU AI Act Compliance Guide · Global AI Regulation Map · AI Agent Identity Security Buyer's Guide · CISO Personal Liability Guide

AI Liability and Product Liability Guide: Who Pays When AI Causes Harm