PLD 2024/2853 & EU AI Act: The Double Liability Framework for AI Systems
Post #1435 in the sota.io EU Product Liability & AI Compliance Series
AI-enabled SaaS platforms face a compliance challenge that is new in the history of EU regulation: two overlapping legal frameworks with different enforcement mechanisms, different liability standards, and different timelines applying to the same product simultaneously.
The EU AI Act (Regulation 2024/1689) creates a public-law framework — regulatory obligations, audits, market withdrawals, and administrative fines up to €35 million or 7% of global annual turnover. The EU Product Liability Directive (2024/2853) creates a private-law framework — civil liability claims from end users and businesses for damages caused by defective AI products, without any fault requirement.
If your SaaS platform uses AI to make decisions that affect users — credit scoring, medical triage, content moderation, recruitment, fraud detection — you are operating inside both frameworks simultaneously. Compliance with the AI Act does not shield you from PLD civil claims. PLD compliance does not satisfy AI Act obligations. They are cumulative, not alternatives.
This guide maps the intersection zone, explains where the two regimes overlap, diverge, and amplify each other, and provides a practical checklist for SaaS providers building AI-enabled services.
The Two Frameworks at a Glance
EU AI Act (Regulation 2024/1689)
The AI Act creates a risk-tiered regulatory regime. For high-risk AI systems (Annex III), it imposes mandatory obligations on providers — the organisations that develop or commission AI systems and place them on the market:
- Art. 9: Risk management system covering known and foreseeable risks throughout the lifecycle
- Art. 10: Data governance requirements for training, validation, and testing datasets
- Art. 11: Technical documentation (Annex IV) maintained and updated
- Art. 13: Transparency and instructions for deployers
- Art. 14: Human oversight measures designed into the system
- Art. 15: Accuracy, robustness, and cybersecurity standards
- Art. 16: Full obligations package including conformity assessment and CE marking
- Art. 73: Serious incident reporting to national market surveillance authorities
- Art. 99: Penalties for non-compliance
For deployers (organisations using AI systems in professional contexts), Art. 26 applies: risk monitoring, human oversight implementation, data logging, and cooperation with providers for incident investigation.
Full application date: 2 August 2026 for high-risk AI systems in Annex III.
EU Product Liability Directive (2024/2853)
PLD 2024/2853, which replaces the 1985 Directive, explicitly includes software and AI systems as products subject to strict liability. No proof of fault is required. Key provisions:
- Software products: Code, applications, and digital services are products when placed on the market or put into service for remuneration (or in exchange for personal data)
- AI-specific presumption: When it is excessively difficult for the claimant to prove defectiveness due to the technical complexity of an AI system, a court may shift the burden of proof to the defendant
- Damage categories: Personal injury, property damage, psychological harm, and critically — destruction or corruption of data (subject to a €1,000 threshold deductible)
- Causal link: Claimants need only prove plausibility of causation; full proof is not required where technical complexity makes this unreasonably difficult
- Economic operators: Liability extends to manufacturers, importers, authorised representatives, and — where the manufacturer is outside the EU — the first importer in the EU
Transposition deadline: 9 December 2026.
The Intersection Zone: Where Both Regimes Apply
1. High-Risk AI Systems Under Annex III
The AI Act's Annex III lists AI systems in areas including:
- Biometric identification and categorisation
- Critical infrastructure management
- Education and vocational training (access decisions)
- Employment and HR (recruitment, performance evaluation, task allocation)
- Access to essential private services and public benefits (credit, insurance)
- Law enforcement (risk assessment, evidence analysis)
- Migration and asylum (automated decisions)
- Justice administration
For any SaaS platform providing these capabilities, both regimes apply fully:
| Scenario | AI Act | PLD |
|---|---|---|
| Credit scoring platform makes wrong rejection | Art. 9–16 obligations, audit trail | Civil claim for economic damage |
| HR tool misclassifies candidates on protected grounds | Art. 10 data governance + Art. 14 human oversight | Psychological harm claim |
| Fraud detection blocks legitimate transaction | Art. 13 transparency requirement | Property/economic damage |
| Medical decision-support gives dangerous advice | Art. 9 risk management | Personal injury claim |
2. The Provider-Deployer Split
One of the most significant differences between the two regimes is how they assign responsibility along the supply chain.
Under the AI Act, the provider (developer) bears most technical obligations. The deployer (SaaS customer) bears operational obligations under Art. 26 — monitoring, human oversight, and following the provider's instructions. But if a deployer significantly modifies an AI system or deploys it outside its intended purpose, the deployer becomes a provider for the modified system.
Under PLD, the "economic operator" placing the product on the market is liable. For B2B SaaS, this typically means the platform provider. But joint liability is possible where both the platform and the enterprise customer contributed to the defect through deployment choices.
The compliance gap this creates: A SaaS provider that is AI Act-compliant (CE mark, technical documentation, Art. 9–16 obligations met) is NOT automatically shielded from PLD civil claims. The AI Act compliance framework is regulatory — it does not constitute a PLD defence.
3. Incident Reporting vs. Damage Claims: Different Clocks
When an AI system causes harm, the two frameworks impose different response timelines:
AI Act Art. 73 (Serious Incidents):
- Definition: an incident resulting in death, serious harm to health, significant disruption to critical infrastructure, property damage, or serious fundamental rights violations
- Initial notification to national authority: specific timelines published in implementing regulations
- Follow-up report: within timeframes set by the authority
PLD Claims:
- Limitation period: 3 years from the date the claimant became aware of the damage, the defect, and the identity of the economic operator
- Long-stop period: 15 years from placing on market (25 years for latent personal injury)
- Disclosure obligations: courts may order defendants to disclose technical documentation relevant to the claim
Key tension: An AI Act serious incident report — which documents defects and damages in detail — becomes discoverable evidence in PLD civil proceedings. Filing a thorough Art. 73 report is the correct regulatory response; it also creates a document trail that claimants can use in civil litigation. Do not let this tension prevent proper incident reporting — non-reporting is a much greater liability risk than honest disclosure.
The AI Liability Directive: The Missing Third Layer
The European Commission proposed the AI Liability Directive (AILD) in 2022 to harmonise civil claims for AI harms across member states. As of 2026, the AILD has not been adopted — negotiations in the Council and Parliament stalled over the burden-of-proof shifting provisions.
This has a practical consequence: PLD 2024/2853 is the operative civil liability framework for AI harms in the EU until the AILD (if ever) passes. Do not rely on the AILD framework in your legal analysis.
Practical Implementation: The Double-Compliance Architecture
For SaaS providers operating AI systems that fall within AI Act Annex III scope, the following architecture satisfies both regimes simultaneously:
Layer 1: AI Act Technical Compliance (Public Law)
| Requirement | What to Implement |
|---|---|
| Art. 9 Risk Management | Documented risk register, risk mitigation measures, continuous monitoring |
| Art. 10 Data Governance | Training data provenance records, bias testing documentation |
| Art. 11 Technical Docs | Annex IV documentation package, version-controlled |
| Art. 13 Transparency | Deployer-facing instructions, capability/limitation disclosures |
| Art. 14 Human Oversight | Override mechanisms, escalation paths, human review triggers |
| Art. 15 Accuracy/Robustness | Performance benchmarks, adversarial testing reports |
| Art. 16 Conformity | Conformity assessment, EU declaration of conformity, CE marking |
| Art. 73 Incident Reporting | Incident detection pipeline, authority notification procedures |
Layer 2: PLD Damage Prevention (Civil Law)
| Risk | Mitigation |
|---|---|
| Defect claims | Robust QA, documented testing, clear version changelog |
| Causation evidence | Immutable audit logs of AI decisions and their inputs |
| Information asymmetry burden shift | Proactive technical documentation accessible to claimants |
| Data loss/corruption | Backup, integrity checks, documented recovery procedures |
| Joint liability with deployers | Deployer contracts defining scope of permitted use |
Layer 3: Cross-Regime Coordination
The two frameworks require coordination at the incident response level:
- Triage: Determine whether an incident triggers AI Act Art. 73 reporting AND constitutes potential PLD damage
- Legal privilege: Route PLD civil assessment through legal counsel (privilege-protected); AI Act regulatory reporting is separate
- Documentation: Maintain Art. 11 technical documentation in a form that is complete for regulatory purposes but reviewed for PLD discovery risk before filing
- Customer contracts: Deployer agreements should specify permitted use scope, modification restrictions, and liability allocation consistent with both frameworks
Timeline Pressure: Two Deadlines, One Platform
Now → August 2026 (62 days): AI Act Annex III full application
December 2026 (190 days): PLD transposition deadline (member states)
August 2, 2026 is the hard deadline for AI Act Annex III compliance. Non-compliant high-risk AI systems placed on the market after this date face withdrawal orders and fines under Art. 99.
December 9, 2026 is when member states must have transposed PLD 2024/2853 into national law. Until then, the 1985 PLD applies — it does NOT cover software. If your AI system causes damage before December 2026, the old PLD (no software liability) may apply. After December 2026, new PLD strict liability applies.
This creates a narrow window: a SaaS platform that achieves AI Act compliance by August 2026 gains four months of operation where regulatory compliance is met but PLD civil liability is not yet fully in force for software defects. Do not interpret this as permission to defer PLD-readiness — civil claims filed after December 2026 will apply the new directive to all ongoing AI system deployments.
The Presumption Asymmetry Problem
One of the most consequential provisions of PLD 2024/2853 for AI providers is the technical complexity presumption: where a claimant cannot reasonably establish defectiveness due to the technical complexity of an AI system, the burden shifts to the defendant to disprove defectiveness.
This is the legal equivalent of an asymmetric information problem that regulators intended to solve. AI systems make decisions through processes that are opaque to users — they cannot easily prove why the AI made a specific output. Under the 1985 PLD, this opacity benefited defendants. Under PLD 2024/2853, it is a liability amplifier.
The AI Act Art. 13 requirement (transparency and provision of information to deployers) and Art. 14 (human oversight) are partially responsive to this: they require providers to document system capabilities and limitations, and to ensure deployers can interpret outputs. Organisations that implement Art. 13 and 14 comprehensively are building a PLD defence simultaneously — they can demonstrate the system was not defective because it performed within its documented parameters.
Compliance Checklist: SaaS AI Provider (Pre-August 2026)
AI Act (High-Risk, Annex III)
- Determine if your AI system falls within Annex III scope
- Classify your role: provider, deployer, or both
- Appoint EU Authorised Representative if provider is non-EU
- Complete Annex IV technical documentation
- Implement Art. 9 risk management system
- Validate training/validation data under Art. 10
- Design Art. 14 human oversight mechanisms
- Conduct conformity assessment under Art. 43
- Register in EU AI database under Art. 49 (where required)
- Establish Art. 73 serious incident reporting pipeline
PLD (Pre-December 2026 Preparation)
- Map AI system outputs to PLD damage categories (personal injury, property damage, data destruction, psychological harm)
- Implement immutable AI decision audit logging
- Establish QA documentation chain demonstrating testing methodology
- Review deployer contracts for permitted-use scope and liability allocation
- Assess whether data-handling practices prevent "data corruption" claims
- Prepare technical documentation disclosure protocol for potential civil proceedings
Cross-Regime
- Establish incident triage protocol distinguishing Art. 73 regulatory incidents from PLD civil events
- Separate legal-privilege channels for civil liability analysis from regulatory reporting
- Train product and legal teams on the interaction between frameworks
Conclusion
The EU AI Act and PLD 2024/2853 are not competing frameworks — they are complementary layers of a comprehensive EU AI governance architecture. The AI Act ensures your AI system is built and deployed responsibly. The PLD ensures that when it fails, those harmed have a viable remedy.
For SaaS providers, the practical implication is that full AI Act compliance is necessary but not sufficient for risk management. A CE-marked, Annex-IV-documented, Art. 73-reporting AI system can still generate PLD civil claims. The good news: the documentation disciplines that AI Act compliance requires — technical documentation, test records, decision logs, deployer guidance — are exactly the materials that reduce PLD litigation risk. Building them once to AI Act standards serves both purposes.
Next in this series: EU PLD 2024/2853 Finale — the complete SaaS legal risk checklist and December 2026 transposition timeline for all EU member states.
EU-Native Hosting
Ready to move to EU-sovereign infrastructure?
sota.io is a German-hosted PaaS — no CLOUD Act exposure, no US jurisdiction, full GDPR compliance by design. Deploy your first app in minutes.