12 August 2026

EU Product Liability Rules for AI and Software Products

Reza Khosravi
No items found.

Table of Contents

What to Expect and Who Should Read This

This guide explains how the revised EU Product Liability Directive (PLD) brings AI systems, software products, and digital services into the scope of European liability law.

Who should read: CTOs, product managers, compliance officers, legal teams, AI developers, and SaaS vendors selling into the EU.

You will learn: scope, key changes in the 2024 update, what counts as a defect, and how to prepare for compliance.

Overview of the Revised EU Product Liability Directive

The Product Liability Directive was updated in 2024 to reflect the realities of AI, software, and connected products. It modernizes consumer protection rules to include cybersecurity and digital performance issues.

You can read the European Parliament’s briefing here: Revised Product Liability Directive — European Parliament.

Scope; What Products Are Covered

The revised directive covers:

  • Tangible goods with embedded software
  • Standalone software, including SaaS platforms
  • AI models and services deployed in products or via API
  • Digital updates, patches, and feature upgrades
  • These changes ensure that liability extends beyond traditional hardware to the full digital product lifecycle.

Key Changes in the 2024 Update

  • Explicit inclusion of AI and software as “products” under EU law.
  • Cybersecurity defects recognized — unpatched vulnerabilities or insecure configurations can trigger liability.
  • Lower burden of proof for consumers in complex tech cases, especially involving AI algorithms.
  • Extended claim periods to reflect long product lifespans and delayed defect discovery.

How Liability Works for AI and Software Products

Who can be liable: manufacturers, developers, importers, and distributors.

What counts as a defect:

  • Unsafe or unpredictable AI behavior
  • Failure to address known vulnerabilities in a timely manner
  • Breaches of security obligations under laws like the Cyber Resilience Act
  • This means technical debt in security or ignored vulnerability reports can carry direct legal consequences.

Practical Compliance Steps for AI and Software Teams

  1. Implement secure-by-design processes to prevent vulnerabilities from entering production — see CISA Secure by Design principles.
  2. Maintain a Software Bill of Materials (SBOM) for each release. The OWASP CycloneDX standard is widely accepted for this purpose.
  3. Document AI system lifecycle — including training data sources, testing, bias mitigation, and performance monitoring.
  4. Align with other EU cybersecurity laws, including the Cyber Resilience Act and NIS2 Directive, to avoid overlapping compliance gaps.
  5. Create defensible documentation — keep evidence of design reviews, security testing, and vulnerability patching.

Enforcement and Penalties

Under the revised PLD, companies can be required to compensate for:

  • Physical or property damage caused by defective AI or software
  • Financial losses stemming from security defects
  • Harm from failure to meet cybersecurity or safety obligations
  • Non-compliance risks not only compensation claims but also market restrictions and reputational harm.

DevArmor’s Role in Helping You Prepare

DevArmor enables software and AI teams to automate compliance evidence collection — from SBOM generation to secure design reviews — so that proof of due diligence is always available if challenged under PLD or related EU laws.

Frequently Asked Questions

Does the PLD apply to open-source software?

Non-commercial open-source projects are generally exempt, but commercial distributions or integrations can be subject to liability.

Are SaaS companies liable under PLD?

Yes. SaaS services and platforms are included when marketed to EU users.

How does the PLD interact with the CRA?

The CRA sets security requirements, and the PLD enforces liability if those requirements are not met, leading to harm.

What counts as a “defect” in AI behavior?

Unintended actions, unsafe outputs, or failures to mitigate known risks in AI decision-making.

Conclusion

The revised PLD reflects a broader vision of product safety — one that includes AI and software security. Preparing now, with secure-by-design engineering, SBOM tracking, and documented compliance, reduces legal exposure and builds trust.

‍

‍

External sources used in this article:

‍

Table of Contents

Subscribe