Who Is Liable When Your AI Makes a Wrong Decision? Mapping Responsibility Across the Supply Chain
AI Law · Liability & Risk
Who Is Liable When Your AI Makes a Wrong Decision?
Mapping responsibility across the AI supply chain — from foundation model to end user — under EU AI Act, revised PLD, and common law.
1
The AI supply chain: four roles
Foundation · Provider · Deployer · User
2
Your exposure by role
Select your role · see exact liability
3
Three scenarios: who pays?
HR · Medical · Credit scoring
4
How to protect your position
9-item checklist · contractual + technical
5
Common questions
Contracts · PLD · fine-tuning · timeline
!
Fine-tuning = becoming provider
Article 25 · full obligation set applies
An AI tool rejects a loan application. A medical AI misreads a scan. An automated HR system screens out the wrong candidate. Someone is harmed — and someone is liable. But who? The company that trained the model? The SaaS vendor that packaged it? The enterprise that deployed it? The employee who clicked approve? This is the defining legal challenge of enterprise AI adoption. The answer depends on your position in the supply chain, how you’ve structured your contracts, and whether you’ve mapped your obligations under the EU AI Act and the revised Product Liability Directive. Our AI Risk & Liability practice helps companies at every layer understand — and limit — their exposure before something goes wrong.
Section 1
The AI Supply Chain: Four Roles, Four Liability Positions
Every AI deployment involves at least two layers and often four. Each layer carries distinct legal obligations — and distinct risk of being held responsible when the system fails. A single company can hold more than one role simultaneously.
AI Liability Supply Chain
Foundation · Provider · Deployer · End User
EU AI Act Art. 3
1
Foundation Layer
Foundation Model Provider
Contractually Limited
OpenAI, Anthropic, Mistral, Google. Train and host the base model. Liability capped contractually — typically $100 or one month’s fees — via ToS and API agreements. Not classified as AI provider under EU AI Act for general-purpose use; GPAI rules (Articles 51–56) apply instead. PLD exposure remains a live risk where model defects originate in training data or architecture.
2
Product Layer
SaaS Builder / AI Provider
Highest Exposure
Takes a foundation model, wraps it into a product, and places it on the market. EU AI Act Articles 9–17: technical documentation, risk management, data governance, human oversight design, conformity assessment. Under the revised PLD (from December 2026): treated as manufacturer — strict liability for AI outputs as product defects, no proof of fault required.
3
Deployment Layer
Enterprise Deployer
Conditional Exposure
Puts the AI system to work in a specific business context. Article 26 obligations: human oversight, use within intended purpose, monitoring, transparency to affected persons. If the deployer substantially modifies the system, Article 25 reclassifies them as provider — with full Articles 9–17 obligations. National employment, finance, and discrimination law applies independently.
4
Use Layer
End User
Professional Duty
The individual acting on the AI output. Meaningful human oversight is required under EU AI Act — rubber-stamping AI decisions without genuine review creates professional liability exposure. In regulated sectors (medicine, law, finance), professional duty of care applies independently of AI involvement. “The algorithm decided” is not a defence to professional negligence.
Section 2
What Is Your Role? Select to See Your Exposure
Your legal exposure is not determined by what your AI does — it is determined by where you sit in the supply chain and what obligations attach to that position. Select your role below.
Liability Exposure by Role
Select your position in the AI supply chain
Foundation Model Provider
SaaS Builder / AI Provider
Enterprise Deployer
Multiple Roles
Foundation Model Provider
OpenAI, Anthropic, Google, Mistral — and companies replicating this model with proprietary training
Your Liability Exposure
Contractual liability cap: typically $100 or one month’s fees via standard ToS — enforceability under EU law has not yet been tested in court
GPAI obligations (Articles 51–56): technical documentation, copyright compliance, systemic risk assessment for models over 10¹&sup5; FLOPs training compute
PLD component defect risk: if model outputs are treated as a defective product component, you may be in the strict liability chain even behind a downstream provider
Usage policy violation: if API terms prohibit high-risk deployments and a downstream builder uses the model for them anyway, that policy creates causation evidence useful in your defence
What Protects You
Broad ToS liability exclusions — limitation clauses, indemnity exclusions, consequential damages waivers
Usage policies prohibiting high-risk deployments without disclosure — breaks causation chain between your model and downstream harm
GPAI compliance documentation: technical docs, transparency reports, model cards establish a due diligence defence
US governing law + arbitration clause in ToS reduces EU court exposure significantly
Overall Assessment
Foundation model providers currently enjoy the strongest contractual protection in the supply chain — but the cap has not been tested in EU courts and PLD strict liability for component defects remains a live risk. The primary risk vector is GPAI systemic risk obligations for large models.
SaaS Builder / AI Provider
Any company that places an AI system on the market or into service under its own name
Your Liability Exposure
EU AI Act Articles 9–17: risk management system, data governance, technical documentation (Annex IV), incident logging, human oversight design, conformity assessment — all mandatory for Annex III high-risk systems
PLD from December 2026: treated as manufacturer. AI software is a “product.” Defects in model outputs, training data, or design trigger strict liability without proof of fault
Annex III classification: HR, credit, education, law enforcement, medical device, critical infrastructure use cases require full conformity from August 2026
Contractual gap risk: if your MSA lacks AI-specific clauses, deployers will push all liability upstream on a breach-of-implied-warranty theory
What Protects You
Article 11 technical documentation + Annex IV compliance: both a legal obligation and your primary defence against negligence claims in litigation
AI-specific MSA clauses: output accuracy disclaimers, liability caps, human oversight obligations pushed contractually to deployers
Intended purpose documentation: narrowing permitted use cases limits your exposure to out-of-scope deployments
72-hour incident logging capability + post-incident reporting: demonstrates good faith and limits punitive exposure
Overall Assessment — Highest Exposure
SaaS builders carry the heaviest combined exposure: EU AI Act provider obligations plus PLD manufacturer status from December 2026. Compliance documentation is not just a regulatory requirement — it is your primary litigation defence. See our AI Risk & Liability practice for a provider-specific assessment.
Enterprise Deployer
Any company using a third-party AI system in a professional context — HR, finance, legal, operations
Your Liability Exposure
Article 26 EU AI Act: you must implement human oversight, ensure use within intended purpose, monitor the system, and maintain logs — failure is a direct regulatory violation, not just a contract issue
Article 25 reclassification: if you substantially modify the system — change its purpose, retrain on your data, alter risk parameters — you become the provider with full Articles 9–17 obligations
Discrimination and employment law: deploying AI in HR, performance, or compensation decisions creates direct liability under national law independent of EU AI Act
GDPR Article 22: automated decisions affecting individuals require human review on request — non-compliance creates data protection liability alongside AI liability
What Protects You
Deploy strictly within intended purpose: out-of-scope use voids provider liability warranties and shifts responsibility entirely to you
Documented human oversight process: written protocol showing human review of high-stakes AI outputs is your primary defence against regulatory and civil claims
AI-specific vendor contract: EU AI Act compliance warranty, indemnification for provider obligations, clear “intended purpose” scope — see AI MSA clause guidance
Avoid modification triggers: do not fine-tune on sensitive data, do not change the risk classification, do not expand use cases beyond vendor documentation
Overall Assessment
Deployers often underestimate their exposure because they are not building the AI — but Article 25 reclassification and Article 26 direct obligations mean “we just use the tool” is no longer a defence. The critical question: does your deployment stay within intended purpose and is your human oversight genuine, not ceremonial?
Multiple Roles Simultaneously
Companies that build, deploy, and sometimes train — the most common situation for integrated AI teams
Your Cumulative Exposure
Full stack obligations: GPAI compliance (if using foundation APIs), EU AI Act Articles 9–17 as provider, Article 26 as deployer of your own system — all simultaneously
PLD double exposure: as both the manufacturer of your AI product and the deployer who puts it into users’ hands, you sit at both ends of the strict liability chain
Internal development risk: fine-tuning a foundation model on customer data may trigger Article 25 reclassification across your entire deployment base without a deliberate decision to become a “provider”
Contract gap: upstream API caps limit your recovery from foundation providers while downstream contracts expose you to customer losses — the gap between both caps is your unhedged exposure
What You Must Do
Formal role analysis: document which legal entity holds which role — do not assume it follows org chart lines. The deploying entity is often best separated from the providing entity
Layered contract architecture: foundation API terms → your provider MSA → your deployer MSA — each layer passes appropriate liability downstream while capping what you absorb
Unified compliance programme: a single EU AI Act team covering both provider obligations (documentation, risk management) and deployer obligations (oversight, monitoring) — siloed compliance creates gap risk
AI liability insurance: multi-role position is the hardest to insure — carriers now require role documentation before issuing AI liability cover
Overall Assessment — Maximum Complexity
Most integrated AI companies hold multiple roles without realising it and accumulate obligations without having designed for them. The solution is not to stop building — it is to structure deliberately. Our AI Risk & Liability team specialises in exactly this role-mapping analysis.
Section 3
Three Scenarios: Who Pays?
Abstract frameworks become concrete when someone is harmed. Here is how liability actually distributes across three common enterprise AI failure cases under the current framework.
01
HR Tech · Annex III High-Risk
AI HR Tool Wrongly Rejects a Candidate
A SaaS-based AI CV screening tool ranks a qualified candidate as low-priority based on training data patterns that correlate with protected characteristics. The candidate is not interviewed and sues.
Foundation
ToS cap likely holds. GPAI documentation may show the model was not intended for HR screening without bias auditing — usage policy violation by SaaS builder shifts fault upward.
Provider
Annex III: CV screening is explicitly high-risk. No conformity assessment + no bias audit = direct regulatory liability. PLD: AI output is a defective product from December 2026.
Deployer
Article 26: failed to implement human oversight of automated rejections. Discrimination liability runs directly against the employer under national employment law regardless of who built the AI.
HR Team
Rubber-stamping AI outputs without review may create personal professional liability. GDPR Article 22 right to human review was not provided.
Primary Liability
Joint exposure: SaaS provider (EU AI Act + PLD) and deploying employer (discrimination law + Article 26). Foundation model largely protected unless usage policy was violated.
02
Medical AI · Annex III High-Risk
AI Medical Tool Produces a Wrong Diagnosis
A hospital uses an AI-assisted radiology tool to flag potential tumours. The system misses a malignancy. The patient’s treatment is delayed four months. They sue the hospital, the vendor, and the radiologist.
Foundation
Medical AI often uses proprietary models, not bare foundation APIs. If a GPAI API is used, ToS typically prohibits unsupervised clinical diagnosis — provides a causation break.
Vendor
Annex III high-risk. Articles 9–17 apply. PLD strict liability: no fault needed. MDR (Medical Device Regulation) may apply concurrently, compounding exposure.
Hospital
Article 26 deployer obligations. If documented human review protocol existed and was genuinely followed, deployer liability is substantially reduced. Paper processes that are bypassed in practice are not protection.
Radiologist
Professional duty of care applies independently of AI. Relying on AI without independent clinical judgment is professional negligence in most EU jurisdictions. AI does not transfer professional responsibility.
Primary Liability
Three-way exposure: vendor (PLD + EU AI Act), hospital (Article 26 + institutional negligence), radiologist (professional negligence). Proportions depend on whether human oversight was genuine.
03
FinTech · Annex III High-Risk
AI Credit Scoring Denies a Loan Without Explanation
A fintech lender uses an AI model to reject a small business loan. The applicant receives no explanation. The model used proxies that correlate with ethnicity. They file a regulatory complaint and a GDPR Article 22 claim.
Foundation
Third-party credit scoring API ToS likely disclaims regulatory compliance liability — but training data bias liability remains a developing area with no settled law yet.
Model Provider
Credit scoring is Annex III high-risk. Full EU AI Act obligations apply. PLD strict liability for defective output. Failure to provide explainability capabilities creates both regulatory and contract exposure.
Fintech Lender
GDPR Article 22: automated credit decision requires explanation and right to human review — direct data protection violation. Financial services model risk governance (FCA, BaFin) applies independently.
Loan Officer
Eliminating human review to cut costs removes the oversight defence and concentrates liability on the institution. “The algorithm decided” is not an answer to a GDPR Article 22 request for explanation.
Primary Liability
The deploying fintech faces the most immediate exposure: GDPR enforcement, financial regulatory action, and discrimination law — all running concurrently. Neither “the AI decided” nor “our vendor did it” is a complete defence.
Not sure which role applies to your company? WCR Legal provides formal role-mapping analyses under EU AI Act — the document enterprise procurement teams are increasingly requesting before contract execution.
Get a Liability Assessment →
Section 4
How to Protect Your Position
Liability exposure is not fixed — it is determined by what you have done before the AI makes its wrong decision. These nine measures directly reduce your risk profile across all supply chain roles.
AI Liability Protection Checklist
9 measures · contractual + technical + governance
0 / 9
✓
AI-specific liability cap in all vendor and customer contracts
Standard limitation clauses do not cover AI output liability. An explicit AI clause capping liability per incorrect output or per incident is required — see AI MSA clause guidance.
Contract
✓
EU AI Act compliance warranty from upstream AI vendors
Your vendor must warrant that their system complies with EU AI Act obligations applicable to providers. Without this warranty, you absorb the compliance risk contractually even as a deployer.
Contract
✓
Indemnification for AI provider reclassification (Article 25)
If your vendor’s intended purpose is ambiguous and you are reclassified as provider under Article 25, your contract must require the vendor to indemnify you for the compliance costs and liability exposure that result.
Contract
✓
Human oversight mechanism documented and operational
Not a checkbox — an actual process where a human reviews AI outputs before they affect a person. Documentation of this process (who reviews, what criteria, what escalation path) is your primary defence under Articles 14 and 26.
Technical
✓
Incident logging with 72-hour notification capability
EU AI Act requires serious incident notification within 72 hours. If your system cannot generate the required log data and summary in that window, you are in breach before the incident even resolves.
Technical
✓
Technical documentation meeting Article 11 and Annex IV
For high-risk providers, this is both a legal obligation and your litigation evidence. A court or regulator will ask for it; not having it eliminates your due diligence defence entirely.
Technical
✓
Formal role clarity analysis (provider vs deployer determination)
A written legal analysis mapping each AI system to your EU AI Act role — updated every time you fine-tune, integrate, or substantially expand a use case. See the provider vs deployer guide.
Governance
✓
Annex III self-classification reviewed and documented
If your system falls in or near a high-risk category, the classification decision must be documented with legal reasoning under Article 6(3). Undocumented self-classification is the most common enforcement risk for SaaS AI companies.
Governance
✓
AI incident response plan tested and assigned to named owners
When an AI makes a wrong decision that harms someone, the first 72 hours determine whether a manageable incident becomes a regulatory enforcement action. A tested plan with named owners, legal contact, and pre-drafted notifications is not optional for high-risk deployments.
Governance
Section 5
Common Questions
AI Liability — Frequently Asked
5 questions · click to expand
1
If the AI system belongs to my vendor, can I be held liable for what it does?
▼
Yes — as an enterprise deployer, you face direct obligations under EU AI Act Article 26: you must implement human oversight, ensure use within intended purpose, and monitor outputs. Separately, employment law, GDPR Article 22, and financial services regulation create liability frameworks that operate entirely independently of who owns the AI. “It was my vendor’s system” is a factor in apportioning liability between you and the vendor — it is not a complete defence against the person harmed.
2
What is the difference between EU AI Act liability and PLD liability?
▼
The EU AI Act is a regulatory framework: it sets obligations and creates enforcement powers (fines up to €30M or 6% of global turnover, market withdrawal) but does not itself create private rights of action for individuals harmed by AI. The revised Product Liability Directive (applying from December 2026) creates strict civil liability: individuals can sue for damages caused by defective AI software without proving fault. In practice, an AI failure will typically trigger both: regulatory investigation under EU AI Act and civil litigation under PLD. Non-compliance with EU AI Act obligations will be used as evidence of a product defect in PLD proceedings.
3
Can a liability cap in my contract actually limit what I owe if someone is seriously harmed?
▼
Contractual liability caps work between contracting parties — they can limit what your enterprise customer can recover from you in a breach of contract claim. They do not protect you against: (1) regulatory fines under EU AI Act; (2) third-party tort claims from individuals harmed by the AI — they are not party to your contract; (3) PLD strict liability claims, which cannot be contractually excluded against consumers or in cases of personal injury. A well-drafted AI liability cap in your MSA is essential — but it addresses only a portion of your total exposure.
4
We fine-tune models on client data. Does that make us the AI provider under EU AI Act?
▼
Potentially, yes. Article 25 provides that a deployer who substantially modifies a high-risk AI system is reclassified as provider and must comply with Articles 9–17. Fine-tuning on client data that changes the system’s risk profile, performance characteristics, or intended use case is the clearest example of substantial modification. The test is not technical complexity — it is whether the modification meaningfully changes how the system behaves in ways that affect the risk level. See our provider vs deployer analysis for the full Article 25 test.
5
When does the AI liability framework actually come into force?
▼
The timeline has multiple layers. EU AI Act prohibited practices applied from February 2025. GPAI obligations (foundation model providers) applied from August 2025. High-risk AI system obligations under Annex III apply from August 2026 — the most significant deadline for enterprise SaaS. The revised Product Liability Directive applies to AI software placed on the market from December 2026. National laws (employment discrimination, GDPR Article 22, financial services regulation) already apply now — AI does not create an exemption from existing legal frameworks.
The question is not whether your AI will make a wrong decision.
It is whether you will have documented, contracted, and governed your way out of primary liability when it does. WCR Legal advises SaaS providers, enterprise deployers, and multi-role AI companies on EU AI Act compliance, PLD readiness, and AI liability structuring.
Post Comment