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. Disclosure Orders and Trade Secret Protection 3. Rebuttable Presumptions: How SWT3 Defeats Them 4. Continuous Liability and Post-Deployment Changes 5. Liability Defense Evidence Mapping 6. Procedure Cards 7. AI Act Interaction 8. Quick Reference 9. Quick Start 10. 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.
- Cybersecurity update failures constitute defects. A manufacturer that fails to supply necessary software updates or upgrades to address cybersecurity vulnerabilities is liable for resulting harm. This extends the obligation beyond initial deployment to the entire product lifecycle.
- Continuous liability for over-the-air updates (Article 7(2)(e)). Defectiveness is assessed at the moment the product "left the control of the manufacturer." For AI systems that receive model updates, fine-tuning, or adapter changes post-deployment, the manufacturer retains control -- and liability -- through the update channel. Every model update restarts the liability clock.
- Learning and feature acquisition change the defectiveness assessment (Article 7(2)). Courts must consider capabilities an AI system acquires after market placement, interconnection effects with other products, and cybersecurity requirements when assessing defectiveness. An AI system that was safe at deployment can become defective through drift, feature acquisition, or environmental changes.
- Open-source exemption is narrow. Free and open-source software is exempt from the Directive, but only if it is not developed or provided as part of a commercial activity. Companies using open-weight models (e.g., Llama, Qwen, Mistral) in commercial products do not benefit from this exemption -- the commercial deployment brings the entire system into scope.
2. Disclosure Orders and Trade Secret Protection
The single most consequential provision for AI providers is the disclosure obligation. When a claimant has presented facts and evidence that "sufficiently support the plausibility" of a claim, a national court may order the manufacturer to disclose relevant technical documentation -- including algorithms, training data, and product monitoring records.
Failure to comply with a disclosure order triggers an automatic presumption of defect under Article 10(2)(a). The manufacturer loses the case not on the merits, but on the procedural consequence of non-disclosure. This creates a fundamental tension for AI providers: disclose your model internals and risk trade secret leakage, or refuse disclosure and lose the case by default.
The Trade Secret Dilemma
Three procedural protections exist under the Directive's national transpositions, but each has significant limitations:
- Trade Secrets Act classification: Courts may classify disclosed information under trade secret protections with criminal sanctions for misuse. However, the opposing party still gains access to the information, and proving unlawful subsequent use is difficult in practice.
- In-camera proceedings: Defendants may provide redacted evidence to opposing parties while courts receive unredacted versions. This eliminates disclosure risk, but requires voluntary consent of both parties -- opposing counsel will rarely agree when redacted portions are decisive.
- Public exclusion: Courts may exclude public attendance, but this applies only to oral hearings. Written submissions are not covered. Protection remains incomplete.
Leading law firms have noted that "in some instances, deliberately accepting a loss in litigation may even carry less risk than a broad leakage of confidential information." This is the strategic reality AI providers face.
How SWT3 Resolves the Dilemma
SWT3 witness anchors provide a fourth option that existing procedural protections do not: prove system state cryptographically without disclosing the underlying data.
- Model state without model weights:
AI-MDL.1anchors contain a hash of the model artifact. The hash proves exactly which model version was active at the time of an alleged incident. A court can verify the hash matches the validated version without the provider ever disclosing the weights themselves. - Inference provenance without input/output data:
AI-INF.1anchors contain hashes of the input and output. The hash proves the specific inference occurred with specific data, without disclosing the actual prompt or response. If a claimant produces the allegedly harmful output, the hash can be verified against the anchor. - Training data attestation without training data:
AI-BASE.1anchors establish a cryptographic baseline of the training configuration. The baseline proves the training data set that produced the model, without disclosing the data itself. - Monitoring activity without monitoring results:
AI-DRIFT.1andAI-AUDIT.1anchors prove that monitoring was active and at what frequency, without disclosing the specific metrics or findings. The existence and cadence of monitoring is the defense -- not the raw telemetry.
This transforms the disclosure dynamic. Instead of choosing between "disclose trade secrets" and "lose the case," the provider can produce cryptographic evidence that satisfies the court's evidentiary needs while preserving proprietary information. The evidence is independently verifiable -- it does not require the court or the opposing party to trust the provider's systems.
SWT3 anchors are structured to survive disclosure proceedings: they prove that a control was active, when it was active, and what state the system was in -- without revealing how the system works. Hashes are one-way functions. The court gets proof of state; the provider keeps its intellectual property.
3. Rebuttable Presumptions: How SWT3 Defeats Them
The Directive introduces three rebuttable presumptions that shift the burden of proof to the manufacturer. Each creates a different evidentiary challenge. SWT3 provides specific evidence to rebut each one.
Failure to Disclose Presumes Defect
If a manufacturer fails to comply with a court-ordered disclosure, the product is presumed defective. This is the "disclose or lose" provision.
SWT3 rebuttal: Produce the witness anchor chain covering the incident period. Anchors contain hashes, timestamps, and procedure identifiers -- structured evidence that satisfies disclosure requirements without exposing proprietary internals. The provider complies with the disclosure order by producing verifiable evidence, defeating the presumption without trade secret risk.
Non-Compliance with Safety Requirements Presumes Defect
If the product does not comply with mandatory safety requirements (including AI Act obligations), it is presumed defective. AI Act Articles 15 (accuracy, robustness, cybersecurity) and 13 (transparency) are directly incorporated as safety benchmarks.
SWT3 rebuttal: AI-PERF.1 (performance validation), AI-ROBUST.1 (adversarial testing), AI-TRANS.1 (transparency events), and AI-EXPL.1 (explainability) anchors demonstrate ongoing compliance with the AI Act requirements that the PLD treats as safety benchmarks. The anchors are timestamped and continuous -- they prove compliance was active at the time of the alleged incident, not just at initial deployment.
Scientific Complexity Creates Presumption of Causation
For technically complex products (which AI systems inherently are), where a claimant shows it is "likely" the product was defective and caused the damage, the court may presume both defect and causation. This is the most aggressive presumption -- it effectively reverses the burden for all AI liability claims.
SWT3 rebuttal: AI-INF.1 per-inference anchors provide the granularity needed to break the causation chain. The provider can show exactly what model version processed the allegedly harmful input, what the system's validated state was at that moment (via AI-MDL.1), and whether the output fell within validated parameters. Instead of arguing in the abstract that AI is complex, the provider produces specific, per-event evidence that addresses the specific alleged harm.
4. Continuous Liability and Post-Deployment Changes
The Directive fundamentally changes when liability attaches for AI systems. Under the old 1985 regime, a product was assessed for defectiveness at the time it left the factory. For AI systems that learn, update, and drift, this static snapshot is inadequate. The new Directive addresses this through three mechanisms.
Over-the-Air Updates Extend Liability (Article 7(2)(e))
If the manufacturer retains the ability to update the product after deployment -- which is true for virtually all AI systems -- defectiveness is assessed at the moment the product "left the control of the manufacturer." Since the update channel means the manufacturer never fully relinquishes control, liability is continuous.
SWT3 evidence: AI-MDL.2 version governance anchors create an immutable record of every model update, fine-tuning event, and adapter change. Each version anchor links to the previous version, establishing a complete lineage chain. If an update introduces a defect, the provider can identify exactly which version change caused the regression and when it was deployed.
Learning and Feature Acquisition (Article 7(2))
Courts must consider capabilities an AI system acquires after market placement when assessing defectiveness. A model that was safe at deployment can become defective through training on new data, reinforcement learning updates, or environmental changes that shift its behavior outside validated parameters.
SWT3 evidence: AI-DRIFT.1 anchors prove statistical monitoring was active throughout the post-deployment period. AI-BASE.1 baseline anchors establish the validated state at deployment, and subsequent baseline anchors capture any drift from that state. The combination proves the provider was monitoring for post-deployment behavioral changes and can identify when (or whether) the system deviated from its validated baseline.
Cybersecurity Update Obligations
Failure to supply necessary security updates constitutes a product defect under the Directive. For AI systems, this extends beyond traditional software patches to include updates addressing adversarial vulnerabilities, data poisoning mitigations, and prompt injection defenses.
SWT3 evidence: AI-ROBUST.1 anchors witness adversarial testing events. A continuous chain of robustness testing anchors demonstrates the provider maintained cybersecurity vigilance throughout the product lifecycle, not just at initial deployment. Gaps in the testing cadence are visible in the anchor timeline and should be addressed proactively.
5. 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 |
6. 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.
7. 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.
8. 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. |
9. 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.
10. References
- Directive (EU) 2024/2853 -- EUR-Lex official text
- Freshfields -- PLD Key Implications for Software and AI
- Freshfields -- How the PLD Turns AI Act Compliance into Liability
- Freshfields -- Disclosure Obligations: Balancing Evidentiary Hardship and Trade Secret Protection
- Reed Smith -- PLD Implications for Software, Digital Products, and Cybersecurity
- Product Law Perspectives -- Analysis and Commentary
- EU AI Act Conformity Assessment Guide
- EU AI Act Omnibus Amendment Update
- EN 18286 AI QMS Crosswalk
- Cryptographic AI Evidence Quickstart