The Double Exposure. EU AI Act and the Revised Product Liability Directive in 2026.

From 2 August 2026, any enterprise deploying a high-risk AI system in the EU is bound by the operator obligations of Regulation (EU) 2024/1689. From 9 December 2026, any enterprise that placed a commercially supplied AI system on the EU market faces the civil liability regime of Directive (EU) 2024/2853. Neither instrument alone defines the full exposure. Together, they do. This analysis maps the interaction between them at the article level.

Section 1. Two regimes, one deployment.

The EU AI Act and the revised Product Liability Directive were negotiated separately, adopted separately, and are enforced by different authorities. The AI Act is a regulation enforced by national market surveillance authorities and the AI Office at the Commission. The PLD is a directive transposed into national law and enforced through civil litigation in member state courts. They have different drafting traditions, different enforcement mechanisms, and different remedial outcomes.

They share scope when an AI system is both subject to governance obligations under the AI Act and placed on the EU market commercially under the PLD product definition. For most enterprise AI deployments in 2026, both conditions are met. The system being deployed is a high-risk AI system within the meaning of Annex III of the AI Act. The system was supplied commercially and therefore meets the PLD product definition under Article 4(1). The same deployment event brings both regimes into play.

The correct frame for understanding the double exposure is not "which instrument applies" but "how do they interact when both apply." The answer has three dimensions: the activation calendar, the scope overlap, and the evidentiary bridge.

Section 2. The AI Act activation calendar.

Regulation (EU) 2024/1689 entered into force on 1 August 2024. It applies in stages. The first stage, covering prohibited practices under Chapter II, entered into application on 2 February 2025. General-purpose AI model obligations under Chapter V entered into application on 2 August 2025. The stage that matters for deployers of high-risk AI systems is the entry into application of Chapter III, which occurs on 2 August 2026.

On 2 August 2026, three categories of obligation become binding on deployers.

Article 26(1) requires deployers to use high-risk AI systems in accordance with the instructions for use provided by the provider, and to implement the technical and organisational measures needed to ensure compliance with those instructions. This is not a passive obligation. A deployer who does not know what the instructions for use say, or who operates outside them, is in breach on day one.

Article 26(2) requires deployers to assign human oversight to a natural person with the competence and authority to understand the system's outputs, to override them where necessary, and to halt the system where required. The oversight function must be staffed: naming a role is insufficient if the person filling it lacks training or access.

Article 26(5) requires deployers to report any serious incident, or any malfunctioning that constitutes a serious incident, to the provider and to the relevant market surveillance authority without undue delay. The post-market monitoring obligation is live from the same date.

Article 27, which requires qualifying deployers to conduct a Fundamental Rights Impact Assessment before first deployment, enters into application on the same date. The qualifying categories are: public bodies or entities providing public services; deployers of creditworthiness or insurance risk assessment systems; and deployers of systems whose outputs affect access to essential services. For a detailed FRIA walkthrough, see our Article 27 analysis and the 90-day FRIA countdown checklist.

The full high-risk regime, including conformity assessment obligations and the EU database registration requirements, enters into application on 9 December 2026 for most high-risk systems. Systems embedded in regulated products face a deferred date of 2 August 2027.

Article 99 sets the penalty tiers. Breaches of Article 26 operator obligations fall within the second tier: fines up to EUR 15 million or 3 percent of worldwide annual turnover, whichever is higher. Supervisors are instructed to take SME economic viability into account in penalty calculations under Article 99(6).

Section 3. The PLD activation calendar.

Directive (EU) 2024/2853 was adopted by the European Parliament and the Council on 23 October 2024 and published in the Official Journal on 18 November 2024. It entered into force on 8 December 2024. The transposition deadline for member states is 9 December 2026. Upon transposition by a member state, Council Directive 85/374/EEC is repealed in that state.

The new regime applies to products placed on the market or put into service after the transposition deadline in each member state. Products placed on the market before the deadline remain subject to the old rules, including the old directive's narrower product definition and higher claimant burden of proof.

The alignment of the PLD transposition deadline with the AI Act's full high-risk regime entry into application, both landing on 9 December 2026, is not incidental. The European legislature explicitly framed the two instruments as complementary parts of a coherent European AI liability framework. The European Commission's 2022 impact assessment accompanying the original AI Liability Directive proposal acknowledged that the revised PLD and the AI-specific liability rules were designed to close the same set of gaps together.

Member state transposition progress as of April 2026 is uneven. No member state has enacted final transposing legislation. Several, including Germany and France, have begun internal consultation on transposition measures, but published drafts are not yet available. Ireland and the Netherlands have published preliminary government analyses of the directive's scope. The December 2026 deadline is binding under EU law; late transposition does not delay the directive's effect, which may be directly effective in some provisions against state actors after the deadline passes even without national implementing law.

Section 4. How AI software became a product under EU law.

The 1985 Product Liability Directive was drafted in an analogue world. Article 2 defined product as all movables. Software was treated as intangible in most member state courts and therefore outside the scope of the directive. Claimants whose losses arose from defective software were left to national tort law, which typically required proof of fault, a substantially higher bar.

Article 4(1) of Directive (EU) 2024/2853 closes that gap explicitly. It defines product to mean "any movable item, even if integrated in another movable item or in an immovable item, as well as electricity, digital manufacturing files and software." The word software is in the definition without qualification. Recital 12 extends the analysis: the definition covers AI systems whether they are delivered as standalone products, embedded in physical goods, provided as cloud-hosted services, or distributed as applications over a network.

The distinction between embedded AI and standalone AI has no effect on in-scope status under the new directive. An AI model embedded in a medical device is a product. A standalone large language model API is a product. A cloud-hosted AI agent with tool access is a product. What determines scope is commercialisation, not delivery format.

The AI-as-a-service framing does create one operational complexity. Article 4(4) of the directive addresses related services that are provided as part of a commercial arrangement and have a direct connection to a product's safety. An AI provider who offers continued fine-tuning, monitoring, or model update services as part of a commercial contract may see those services drawn into the product liability analysis if they affect the system's outputs. A deployer who contractually receives model updates without the ability to test or reject them has a stronger argument that the provider, not the deployer, is responsible for any defect introduced by an update.

Section 5. The rebuttable presumption of defect.

The provision that changes the litigation calculus most materially is Article 10 of Directive (EU) 2024/2853. It addresses a structural problem with AI liability litigation: the claimant often cannot access the technical evidence needed to prove that the AI system was defective, because that evidence is held by the defendant.

Article 10(2) provides that defectiveness shall be presumed where any of five conditions is met. The five conditions are: the defendant has failed to comply with the disclosure obligation in Article 9; the claimant has demonstrated that the product does not comply with mandatory product safety requirements; the damage has been caused by an obvious malfunction of the product during normal use or storage; the product was recalled for safety reasons; and the claimant demonstrates non-compliance with applicable legal standards designed to protect against the type of damage suffered.

The second and fifth conditions are the ones that create the direct link to AI Act compliance. "Mandatory product safety requirements" in EU law include the obligations imposed by the AI Act on providers and deployers of high-risk AI systems. A claimant who demonstrates, through a supervisory decision or through documentary evidence, that a deployer was not in compliance with Article 26 of the AI Act at the time an incident occurred has met the condition for a defectiveness presumption under Article 10(2) of the PLD.

Article 10(3) addresses the causal link separately. Where a claimant faces excessive difficulty in proving that a product defect caused the damage suffered, the causal link shall be presumed if the defect appears capable of causing the type of damage suffered, having regard to the circumstances of the case.

The presumptions are rebuttable, not irrebuttable. A defendant who can demonstrate through technical documentation how the system operates, what testing it underwent, that it met the applicable standards at the time it was placed on the market, and that the claimant's harm had a different cause, can defeat the presumption. The practical effect is not that defendants automatically lose. It is that defendants without documentation automatically face a shifted burden they cannot discharge.

Article 9 of the directive provides the complementary disclosure mechanism: where a claimant has presented facts and evidence sufficient to make a product liability claim plausible, the court may order the defendant to disclose relevant evidence within the defendant's control. The evidence subject to disclosure includes technical documentation, design specifications, test results, and post-market surveillance records. The strategic inference for AI providers is direct: a structured, well-maintained technical file is the evidentiary asset that PLD litigation will be fought over.

Section 6. Expanded damage categories.

Article 4(6) of Directive (EU) 2024/2853 defines compensable damage in four categories. The first two, death or personal injury and damage to or destruction of private property above a EUR 1,000 threshold, existed in the old directive. The last two are new.

The third category is destruction or corruption of data or digital files not used exclusively for professional purposes. An AI agent that corrupts a user's personal financial records, destroys stored documents through faulty tool execution, or overwrites user data through an erroneous write action has caused compensable damage under the new directive. The exclusion of data used exclusively for professional purposes limits the category's application in purely enterprise B2B contexts, but consumer-facing and mixed-use AI deployments carry full exposure.

The fourth category is medically recognised psychological harm. This category is directly relevant to AI systems that produce outputs causing documented distress: a model that generates harmful content, produces false information about an identifiable person, or facilitates harassment through autonomous outputs may have caused psychological harm within the scope of the directive. The requirement for medical recognition means that self-reported distress without clinical assessment is unlikely to found a claim. Documented clinical harm is the threshold.

The damage categories should be read against the AI system's failure modes, not against the categories used in internal risk assessments. An agentic AI system with tool access that can send emails, execute payments, write files, and make calls to external APIs has a data corruption exposure that a read-only language model does not. The mapping exercise between failure modes and compensable damage categories is the first step in a PLD exposure analysis.

The EUR 1,000 property damage threshold applies only to the property damage category. It does not cap personal injury, data loss, or psychological harm claims. It is a design choice that limits small-claims mass litigation for minor property incidents, not a ceiling on serious losses.

Section 7. The provider versus deployer split.

The AI Act and the PLD each divide liability between parties in the supply chain, but they do so along different axes. The table below maps the primary duty-bearer at each point of exposure.

The critical observation from the table is that the regimes converge on the deployer at the Article 10 rebuttable presumption trigger. If the deployer is in breach of Article 26 of the AI Act, a claimant may use that breach to invoke the PLD defectiveness presumption. The deployer's non-compliance with a regulatory obligation becomes the foundation for a private law damages claim. This is the interaction point that most commentary has failed to trace through to its operational consequence.

Section 8. A scenario walkthrough.

The following scenario is constructed to illustrate how both regimes operate simultaneously on a single AI failure event. The facts are representative of a class of deployment that is common in 2026.

The deployment. A regulated lender operating across three EU member states deploys an autonomous credit-scoring AI agent. The agent ingests applicant financial data, accesses external credit bureau APIs as a tool, generates a credit score, and automatically issues a lending decision without mandatory human review for applications below a set credit threshold. The agent is a high-risk AI system under Annex III, point 5(b) of the AI Act, which covers systems used to evaluate the creditworthiness of natural persons. The provider is a US-headquartered fintech that markets the agent under a commercial SaaS contract and has designated an EU authorised representative.

The incident. The agent misclassifies an applicant due to a data processing error in the credit bureau API integration, issuing an automatic rejection. The applicant, a self-employed individual in the Netherlands, is refused a business loan that was critical to a commercial opportunity with a six-week window. The opportunity expires before a manual review can be completed. The applicant suffers documented financial loss of EUR 47,000. A psychiatrist subsequently documents that the erroneous rejection triggered a clinically significant depressive episode lasting three months.

The AI Act dimension. The national market surveillance authority in the Netherlands receives a report from the applicant. An investigation establishes that the deployer had not implemented the human oversight requirement of Article 26(2) for applications below the threshold level. The deployer's oversight register named a compliance officer but that officer had not received training on the system's outputs and had no technical access to override decisions. A supervisory finding of Article 26(2) non-compliance is issued. The deployer faces a fine in the EUR 8 million range under Article 99.

The PLD dimension. The applicant initiates a civil claim in a Dutch court against both the US fintech provider (through its EU authorised representative) and the lender deployer, seeking EUR 47,000 in financial loss and damages for psychological harm. The applicant's lawyers point to the supervisory finding of Article 26(2) non-compliance as meeting the Article 10(2) trigger condition: the deployer has failed to comply with a mandatory product safety requirement. The Dutch court holds that the defectiveness presumption is engaged as against the deployer. The deployer must now rebut it by demonstrating either that the system was not defective or that the harm had a different cause.

Separately, the claimant applies under Article 9 for disclosure of the provider's technical file, including the credit bureau API integration documentation and the test results for the threshold-level decision pathway. The court orders disclosure, subject to proportionality review and redaction of unrelated trade secrets. The disclosed documents reveal that the API integration was not independently tested by the provider for the input data formats used in the deployer's specific market.

The insurance dimension. The deployer's cyber policy contains an AI activity endorsement excluding autonomous financial decision-making from coverage. The deployer's professional indemnity policy excludes product liability claims by endorsement added at the 2025 renewal. The deployer is uninsured for the PLD claim. The deployer's contractual indemnity from the provider covers only claims arising from defects in the base model, not defects arising from the API integration with the deployer's credit bureau configuration. The deployer pays the claim and the fine from its own balance sheet.

This scenario is not a prediction of a specific case. It is a structural illustration of how the two regimes interact in a realistic deployment context. The deployer's Article 26(2) breach becomes the PLD Article 10(2) trigger. The supervisory proceeding and the civil claim run concurrently, each using overlapping evidence. The insurance gaps compound the financial exposure. The contractual indemnity does not cover the ground the deployer assumed it did.

Section 9. Insurance market response.

The insurance market's response to the double exposure is bifurcating along a specialist-generalist axis. The two categories are moving in opposite directions.

Specialist carriers who entered the AI liability market early are actively writing meaningful limits across the scope of both regimes. Munich Re's aiSure product is the most cited example in the European reinsurance market, offering coverage structures that explicitly contemplate AI Act regulatory exposure and PLD civil liability as concurrent risks. HSB (Hartford Steam Boiler), operating through its specialty technology division, is writing AI product liability with coverage that addresses data corruption claims, reflecting the PLD's expanded damage categories. Armilla, operating in a Chaucer coverholder arrangement at Lloyd's, has built underwriting criteria around AI governance documentation, meaning that an operator with a structured Article 26 file and a conformity assessment record receives meaningfully better terms than one without.

AIUC, the AI Underwriting Consortium whose AIUC-1 Standard was published in July 2025, is referenced by a growing number of specialist carriers as the underwriting framework against which AI system compliance is assessed. Testudo and Counterpart are writing directors-and-officers adjacent AI liability, covering regulatory enforcement exposure under the AI Act alongside civil claims. Corgi is active in the SME segment with modular AI liability products that address both regulatory and civil exposure at smaller premium points.

Generalist carriers are moving in the opposite direction. AIG, W.R. Berkley, and Great American have each tightened their treatment of AI activity exposure through endorsement revisions at 2025 and 2026 renewals, adding exclusions or sublimits for autonomous AI decision-making, for claims arising from AI-generated outputs, and for losses arising from AI systems subject to regulatory investigation. These endorsements do not require an explicit AI Act finding to trigger: the language typically refers to systems that take autonomous action on behalf of the insured without human approval, which describes a wide class of agentic deployments.

The Lloyd's coverholder layer provides the middle ground. Several Lloyd's coverholders are building hybrid products that combine a base layer of technology professional liability with an AI rider addressing PLD-style product defect claims. The coverage terms vary significantly between coverholders, and the interaction between the base layer and the AI rider in the event of a concurrent claim is not uniformly resolved in the policy language. Deployers buying through this layer should request coverage confirmation in writing for a scenario matching the structure of Section 8 of this article.

The practical implication for AI deployers in 2026 is that standard renewal of existing cyber and professional indemnity cover does not maintain the insurance position they held in 2024. The coverage has narrowed through endorsement. The exposure has broadened through the two activation calendars. The gap between them has widened at each renewal cycle since 2024.

Section 10. What to file before 9 December 2026.

The operator who waits for both instruments to be fully in application before beginning documentation assembly will be building under adversarial conditions. The documentation that rebuts the Article 10 presumption in civil litigation is the same documentation that demonstrates Article 26 compliance in a supervisory inquiry. It should be assembled once, structured for both purposes, and maintained continuously from the point of deployment.

The AI Act operator file. Five documents should exist as a minimum for any high-risk AI deployment operating from 2 August 2026:

1. A risk record, documenting the risk classification analysis, the applicable provisions of Annex III, and the residual risks accepted at the point of deployment.
2. An oversight register, naming the qualified human supervisor by role, documenting their training, and setting out their override authority and access.
3. An instructions-for-use map, showing where the deployment sits relative to the provider's stated operational boundaries, and identifying any areas where the deployment approaches or tests those boundaries.
4. A logging schedule, aligned to the Article 12 data retention requirements and specifying how logs will be stored, secured, and made available to authorities upon request.
5. An incident protocol, specifying the procedure for identifying, classifying, and reporting serious incidents under Article 26(5), including internal escalation paths and the authority's notification channel.

The PLD evidentiary file. The following additional records are structurally important for PLD defence:

1. Technical documentation of the system as supplied by the provider, including the conformity assessment report where one is required, and the declaration of conformity.
2. A record of any modifications made to the system after receipt, including fine-tuning, system prompt changes at scale, tool integrations, and changes to the deployment context or user population.
3. Post-market monitoring records, documenting the cadence of performance review, any anomalies identified, and the actions taken in response. This is the record that demonstrates the system was not defective at the time of an incident.
4. A supply chain record, documenting the provider's contractual obligations regarding system updates, notification of safety-relevant changes, and cooperation in the event of a regulatory inquiry or civil claim.
5. An insurance confirmation record, documenting which policies are in force, the AI activity coverage terms, and the written confirmation requested from any ambiguous coverholder product regarding the Section 8 scenario structure.

The combined operator file can be maintained in a single structured folder with a cover sheet indexing both the AI Act compliance evidence and the PLD evidentiary content. The cover sheet is the document that demonstrates, in the first pages of any supervisory inquiry or disclosure request, that the operator treated both instruments as binding simultaneously.

Section 11. Frequently asked questions.

Related reading

For the foundational analysis of the revised Product Liability Directive as a standalone instrument, including the defect standard, the damage categories, and the disclosure mechanism in full, see our PLD 2024 briefing on this site.

For the full Article 26 operator obligations guide, including the five minimum documents and the human oversight design standard, see the 2026 compliance guide to EU AI Act operator obligations.

For the FRIA requirement under Article 27, which enters into application on the same date as Article 26 for qualifying deployers, see the Article 27 FRIA guide and the 90-day countdown checklist.

For the multi-party liability chain analysis, covering when a deployer becomes the provider under Article 25 and how joint and several liability operates in practice, see the provider-deployer liability chain briefing.

For a current view of which carriers are writing meaningful AI product liability limits and how coverage terms compare across the market, see the Carrier Comparison Matrix at agentinsured.eu.