EU Product Liability for Software: The Engineering Evidence Checklist

The revised EU Product Liability Directive expressly treats software, including AI systems and software supplied as a service, as products. It applies to products placed on the market or put into service after 9 December 2026. Engineering teams should preserve evidence that connects intended use, foreseeable misuse, security, tests, releases, incidents, updates, and user communication.

Liability is a legal determination, so use counsel for case-specific advice. Engineering's job is to make the product history explainable and retrievable. This guide addresses that evidence system, not litigation strategy.

What changes for software teams?

What belongs in a software evidence chain?

Build traceability from a safety-relevant requirement to its implementation, verification, release, telemetry, and corrective action. Evidence should show what the team knew, what it decided, who approved it, and what users were told at that time.

• Dated intended-use, user-group, operating-environment, and foreseeable-misuse assumptions.
• Architecture decisions, threat models, hazard analysis, access-control rules, and dependency inventory.
• Reproducible test results, review records, known limitations, residual risks, and release approvals.
• Incident reports, support tickets, update decisions, rollout metrics, notices, and end-of-support records.

How much evidence is enough?

More logs are not automatically better. Preserve decision-grade evidence with provenance, access controls, retention, and a clear link to the shipped version. A data lake full of unverifiable screenshots and mutable dashboards is weak evidence and a privacy burden.

• Use immutable build identifiers and connect them to source, artifacts, dependencies, configuration, and tests.
• Record why a failed test was waived and who accepted the residual risk.
• Test whether an independent reviewer can reconstruct one release without tribal knowledge.

Which operational practices reduce product risk?

Treat post-release maintenance as part of product safety. Monitor relevant failures and vulnerabilities, triage them against affected versions, ship corrective updates, verify adoption, and communicate material residual risk.

• Define security and safety ownership for the supported life of the product.
• Keep rollback, feature-disable, customer-notification, and evidence-preservation runbooks.
• Apply the same controls to AI model, prompt, policy, and dataset changes that can alter behavior.

A 30-day evidence-readiness plan

1. Map safety-relevant products, deployments, actors, users, and post-9-December-2026 releases.
2. Choose one release and reconstruct its requirement-to-production evidence chain.
3. Close missing build provenance, test retention, approval, incident, and update records.
4. Define retention, legal hold, privacy, access, and disclosure-export procedures with counsel.
5. Automate evidence capture in CI/CD and service operations instead of relying on manual archives.
6. Run a mock evidence request and remediate every answer that depends on one employee's memory.

Primary sources

1. Directive (EU) 2024/2853. Official text of the revised Product Liability Directive
2. European Commission defective-products page. Official policy overview for consumers and businesses