Audience: AI product managers, general counsel, product liability attorneys, insurance risk teams, EU compliance officers, and AI system providers deploying in the EU single market.
Status: Directive 2024/2853 adopted. Member states must transpose into national law by December 9, 2026 (4 months). Applies to products placed on the market after transposition. AI systems and standalone software are explicitly classified as \"products.\" AI providers are treated as manufacturers. The standalone AI Liability Directive was withdrawn in October 2025 -- this is the primary EU liability mechanism for AI.
Contents
1. What the Directive Changes for AI 2. Liability Defense Evidence Mapping 3. Procedure Cards 4. AI Act Interaction 5. Quick Reference 6. Quick Start 7. References1. What the Directive Changes for AI
Directive 2024/2853 replaces the 1985 Product Liability Directive and fundamentally changes the liability landscape for AI systems. The core changes:
- Standalone software and AI systems are now \"products\" under EU product liability law. This is the first time software alone -- without physical embodiment -- triggers strict product liability across the single market.
- AI providers are treated as manufacturers with strict liability. There is no need for a claimant to prove negligence. The provider is liable for defective products regardless of fault.
- AI acting in an unpredictable manner is NOT a defense. The provider bears the risk of emergent behavior, hallucinations, and outputs that deviate from intended function. Complexity and opacity do not absolve liability.
- Burden of proof eased for claimants. The Directive introduces disclosure obligations on providers and rebuttable presumptions of defect and causation. If a provider fails to disclose relevant technical information, a court may presume the product was defective.
- Joint and several liability for AI components. If AI is embedded in a product, both the AI provider and the product manufacturer are liable. Component suppliers cannot hide behind the integrator.
- The AI Liability Directive was withdrawn. The European Commission withdrew the proposed AI Liability Directive in October 2025. This Product Liability Directive is the only EU-level AI liability mechanism. There is no separate, AI-specific civil liability regime.
- Creates the private right of action the AI Act does not provide. The AI Act imposes administrative fines for non-compliance but does not grant individuals the right to sue for damages. The PLD fills that gap -- injured parties can bring civil claims for compensation.
2. Liability Defense Evidence Mapping
Each row maps a liability risk to the SWT3 procedures that generate defense evidence. The key insight: liability defense is about contemporaneous evidence -- proving what controls were active at the time of the allegedly harmful inference, not what was documented months later.
| Liability Risk | SWT3 Procedure | What It Proves | Defense Value |
|---|---|---|---|
| Product was safe at time of placement | AI-PERF.1 + AI-ROBUST.1 |
Performance validated, adversarial testing passed | Contemporaneous evidence of pre-deployment validation |
| Defect did not exist when placed on market | AI-MDL.1 + AI-SBOM.1 |
Model hash verified, component inventory complete | Proves exact model version and composition at time of deployment |
| Risk management was adequate | AI-SAFE.1 + AI-DRIFT.1 |
Safe state capability, drift monitored | Demonstrates ongoing risk management, not just point-in-time |
| Post-market monitoring was active | AI-AUDIT.1 + AI-INCIDENT.1 |
Audit log integrity, incidents classified | Proves continuous monitoring and incident response capability |
| Transparency obligations met | AI-TRANS.1 + AI-EXPL.1 |
Disclosure events, explanation methods | Fulfills disclosure obligations, counters rebuttable presumption |
| Inference-level traceability | AI-INF.1 |
Model/input/output hash per inference | Traces specific allegedly defective output to exact model state |
| Lifecycle documented | AI-LCM.1 |
Lifecycle stage, version, chain linkage | Complete provenance from development through deployment |
| Supply chain verified | AI-SBOM.1 + AI-SUPPLY.1 |
Component inventory, supply chain integrity | Identifies third-party components for joint liability allocation |
3. Procedure Cards
Defect Tracing
In a liability claim, the claimant must show the product was defective. The provider can defend by showing the exact state of the AI system at the time of the allegedly harmful inference.
AI-INF.1 provides per-inference provenance -- model hash, input hash, output hash -- creating an immutable record of exactly what the system did. AI-MDL.1 proves which model version was active, linking the inference to a validated model artifact.
Together, these procedures answer the core liability question: was the system operating as designed and validated when the allegedly harmful output was produced?
For any claimed incident, pull the AI-INF.1 anchor closest to the incident timestamp. The model hash in that anchor links to the validated model version via AI-MDL.1. If the model hash matches the validated version, the defense is that the system was operating within its validated parameters. If the model hash does not match, investigate whether an unauthorized update occurred.
Pre-Market Safety Evidence
Article 7 of the Directive defines \"defect\" as a product that does not provide the safety a person is entitled to expect. Proving the product was safe when placed on the market is a core defense.
AI-PERF.1 witnesses performance validation results -- accuracy, precision, recall, and domain-specific metrics. AI-ROBUST.1 witnesses adversarial robustness testing, proving the system was tested against known attack vectors and edge cases before deployment.
These anchors establish the safety baseline: the product met defined performance criteria and survived adversarial testing before market placement.
Verify that testing anchors predate market placement. A single pre-launch test is insufficient -- testing cadence should be documented across development iterations. Look for a chain of AI-PERF.1 anchors showing iterative validation, not just a final sign-off.
Post-Market Monitoring
The Directive expects providers to maintain ongoing monitoring after market placement. A product can become defective through degradation, data drift, or environmental changes -- and the provider remains liable.
AI-DRIFT.1 proves statistical monitoring was active by witnessing drift detection events with threshold configurations. AI-SAFE.1 proves risk mitigation capability existed by witnessing safe state transitions and fallback mechanisms.
Together, they demonstrate the provider did not deploy and abandon -- monitoring was continuous and mitigation was available.
Continuous AI-DRIFT.1 anchors prove monitoring was not abandoned after deployment. Gaps in monitoring cadence weaken the defense significantly. If there is a 30-day gap in drift monitoring followed by an incident, the provider will struggle to argue adequate post-market surveillance.
Conformity Evidence Package -- Portable Liability Defense Bundle
SWT3-SPEC Section 24 defines the Conformity Evidence Package (CEP) -- a self-contained, cryptographically verified evidence bundle designed for portability across jurisdictions, assessors, and legal proceedings.
The CEP includes all relevant anchors for a given period, Merkle proofs linking individual anchors to daily rollups, and a package hash proving the bundle has not been modified since export. This is the artifact a litigation team would produce in discovery.
In litigation, export the CEP covering the incident period. Package hash verification and fingerprint spot-checks establish evidence integrity without requiring the opposing party to trust the provider's infrastructure. The evidence is self-verifying.
4. AI Act Interaction
The Product Liability Directive and the AI Act are complementary instruments, not duplicative ones. They create two distinct enforcement channels for the same AI system:
- AI Act: Administrative fines for non-compliance with regulatory requirements -- up to 35M EUR or 7% of global turnover. Enforced by national market surveillance authorities. No individual right to compensation.
- Product Liability Directive: Private civil claims for actual harm caused by a defective AI product. Enforced through national courts. Injured parties seek monetary compensation for damages suffered.
An organization can be fined under the AI Act AND sued under the PLD for the same AI system. AI Act non-compliance may also strengthen the claimant's case under the PLD by establishing that the provider failed to meet regulatory safety expectations.
AI Act conformity evidence -- documented via SWT3 witness anchors -- directly supports PLD defense. The same anchors that demonstrate regulatory compliance also demonstrate the product met safety expectations at the time of placement and throughout its lifecycle.
For detailed AI Act evidence mapping, see the EU AI Act Conformity Assessment and Omnibus Amendment Update guides.
5. Quick Reference
From a Product Liability Attorney's Perspective
| Question | Answer |
|---|---|
| Can the claimant force us to disclose technical details? | Yes. The Directive grants courts the power to order disclosure. Failure to disclose triggers a rebuttable presumption of defect. SWT3 anchors provide structured disclosure without exposing proprietary model internals -- hashes prove state without revealing weights. |
| Is \"state of the art\" still a defense? | Yes, but significantly narrowed. Article 11 retains the development risk defense, but courts will expect evidence that the provider followed current best practices. SWT3 procedures map to recognized standards (NIST AI RMF, ISO 42001, EU AI Act), establishing best-practice alignment. |
| How do we prove the defect arose after market placement? | AI-INF.1 anchors provide timestamped, hash-verified records of model state at each inference. Compare the model hash at the time of the incident against the validated model hash at deployment (AI-MDL.1). If they diverge, investigate post-deployment changes. |
| What about third-party AI components? | Joint and several liability applies. AI-SBOM.1 identifies all third-party components. AI-SUPPLY.1 witnesses supply chain integrity. These anchors support contribution claims against component suppliers by proving exactly which component was present and active. |
| What is the limitation period? | The Directive sets a 3-year limitation period from when the claimant knew (or should have known) of the damage, defect, and identity of the manufacturer. An absolute long-stop period of 25 years applies for latent personal injury. Anchor retention policies should account for these periods. |
| Does the Directive apply to AI-as-a-Service? | Yes. The Directive explicitly covers \"related services\" that are integrated into or interconnected with the product. SaaS-delivered AI that is part of a product's functionality falls within scope. The SaaS provider is treated as a manufacturer for the software component. |
6. Quick Start
Python
pip install swt3-ai
TypeScript
npm install @tenova/swt3-ai
Minimal Witness Example (Python)
from swt3_ai import SWT3Witnesswitness = SWT3Witness( api_key=\"your-api-key\", tenant_id=\"your-tenant-id\")# Witness an inference -- creates AI-INF.1 anchoranchor = witness.witness_inference( model_id=\"gpt-4o\", input_text=\"user prompt\", output_text=\"model response\")
For full integration guides, see the Cryptographic AI Evidence Quickstart.