What AI Clauses Does Your MSA Need in 2026?
AI Law · Contract Risk
What AI Clauses Does Your MSA Need in 2026?
Enterprise legal teams are redlining MSAs with AI liability requirements that standard templates were never designed to handle. Here are the 8 clauses that separate a defensible AI contract from a liability transfer to the vendor.
1
Why your standard MSA falls short
PLD reform · EU AI Act warranties · enterprise redlines
2
8 AI clauses your MSA must include
Click each for rationale + sample language
3
MSA AI clause checklist
8-item interactive · coverage score
4
Get your MSA reviewed
WCR Legal · AI contract risk
5
Common questions
PLD · training data · liability caps
!
No AI clauses = PLD default applies
Manufacturer liability · December 2026
The standard SaaS MSA was drafted for a world where the software did what it was programmed to do. AI systems do not work that way — their outputs are probabilistic, their accuracy varies by input, and their liability profile under both the revised Product Liability Directive and the EU AI Act is categorically different from traditional software. Enterprise procurement and legal teams know this. They are adding AI-specific redlines to every SaaS contract involving AI-generated outputs, AI-assisted decisions, and AI model components. The question is whether your MSA reflects the current legal landscape or exposes you to uncapped liability by default. AI Risk & Liability services from WCR Legal cover MSA drafting, redline review, and AI liability framework design for SaaS companies with EU exposure.
Product Liability Directive — December 2026
Absence of AI-specific liability clauses in your MSA means PLD manufacturer liability applies by default — without any contractual protection. Since December 2026, AI software is explicitly covered by the revised Product Liability Directive. Where no contractual liability allocation exists, courts will apply PLD manufacturer standards to the provider of the AI system — including defect liability for outputs that cause harm to users.
Section 1
Why Your Standard MSA Falls Short
Three legal developments in 2025–2026 have made the standard SaaS MSA structurally inadequate for AI product delivery. Each creates a specific contractual gap that enterprise clients are now filling through aggressive redlines.
Three Gaps the Standard MSA Doesn’t Cover
PLD reform · EU AI Act warranties · enterprise risk transfer
2025–2026
1
December 2026 · PLD reform
AI software is now a “product” under the revised Product Liability Directive
The revised PLD, applying from December 2026, explicitly includes AI systems and software within the definition of “product.” This means that a provider of an AI system can be held liable as a manufacturer for defects in the AI product that cause harm — including harms caused by inaccurate outputs, unexpected model behaviour, and outputs that deviate from documented intended use. The standard MSA disclaimer of “software provided as-is” was designed for deterministic software and does not map cleanly onto PLD manufacturer liability. Without AI-specific clauses addressing output accuracy, intended use boundaries, and liability allocation, the default PLD framework applies in its most unfavourable form for the provider.
2
August 2026 · EU AI Act enforcement
EU AI Act creates compliance warranties that must be contractually anchored
From August 2026, providers of high-risk AI systems are subject to mandatory obligations under Articles 9–17 of the EU AI Act. Enterprise clients — particularly in regulated industries — are requiring providers to give contractual warranties of EU AI Act compliance as a condition of contract execution. Without these warranties in your MSA, you face two problems simultaneously: enterprise clients insert their own (often broader) warranty language in redlines, and you have no contractual mechanism to update compliance warranties as the law evolves. An MSA AI compliance warranty clause lets you define the scope, update mechanism, and limitation of compliance representations on your terms.
3
Active trend · Enterprise procurement
Enterprise clients are systematically transferring AI risk to vendors through redlines
Since 2024, enterprise procurement teams — particularly in financial services, healthcare, and professional services — have adopted AI-specific contract schedules and redlines. Common insertions include: unlimited indemnities for AI output errors, training data warranties covering all client data processed by the AI model, 24-hour incident notification requirements, unilateral termination rights for model changes, and AI liability caps set at multiples of annual fees rather than standard 12-month fee caps. If your MSA has no AI clauses, enterprise legal teams fill the gap with their own language — drafted in their client’s interest, not yours.
Section 2
8 AI Clauses Your MSA Must Include
Each clause below addresses a specific AI liability exposure. Click to expand for the rationale, drafting notes, and sample contractual language you can adapt. These are provider-favourable starting positions — enterprise redlines will push back, but starting from a drafted position is always better than starting from a gap.
1
IP · Output Rights
AI Output Ownership
Who owns AI-generated outputs · downstream IP rights
+
IP assignment
Downstream rights
Ownership of AI outputs is not automatically clear under EU copyright law — outputs generated without sufficient human creative contribution may not qualify for copyright protection at all, leaving a gap in the client’s IP chain. Providers who retain any rights to outputs create enterprise procurement blockers. Clients in regulated industries also need to know whether the provider can use their outputs for model improvement. This clause assigns outputs to the client on generation and removes any provider residual rights. See our analysis of who owns AI outputs under major provider terms for background.
Sample language (provider-favourable)
“All outputs, responses and content generated by the AI System in response to Client inputs (“Outputs”) are assigned to Client upon generation to the extent assignable under applicable law. Provider retains no proprietary rights in Outputs. Provider may retain anonymised, aggregated statistical data derived from usage patterns solely for service improvement purposes, provided such data cannot be used to reconstruct individual Outputs or identify Client.”
Drafting note: Distinguish between assignment of Outputs (to client) and retention of usage data (to provider). Enterprise clients will push for complete data separation — decide your position on aggregated analytics before negotiation.
2
Liability · PLD Protection
Accuracy Disclaimer
Factual errors in outputs · verification responsibility
+
PLD risk mitigation
Verification duty
Under the revised PLD, a defective AI output that causes damage could trigger manufacturer liability. An accuracy disclaimer does not eliminate PLD liability — but it establishes the contractual framework for what the client understood about output reliability, which is relevant to PLD defect assessment and to contributory negligence arguments. It also defines the verification duty, which is the client’s obligation to check AI outputs before acting on them in material decisions.
Sample language (provider-favourable)
“Provider does not warrant the accuracy, completeness, currency or fitness for purpose of AI-generated Outputs. Outputs may contain errors, omissions or content that does not reflect current facts or law. Client assumes sole responsibility for verifying the accuracy of Outputs before relying on them for any material purpose, including but not limited to legal, financial, medical, or operational decisions.”
Drafting note: Enterprise clients will resist the phrase “sole responsibility.” A workable compromise is “primary responsibility” with a mutual obligation that Provider maintains output quality within documented performance parameters.
3
EU AI Act · Article 26
Human Oversight Acknowledgement
Deployer oversight obligation · AI-assisted decisions
+
Article 26(2) deployer
Decision liability
Under Article 26(2) of the EU AI Act, deployers (enterprise clients using your AI system) are responsible for implementing human oversight measures. Contractually anchoring this obligation in your MSA serves two purposes: (1) it makes the client’s deployer obligation explicit, reducing your exposure for decisions taken without human review, and (2) it creates a contractual record that you disclosed the human oversight requirement, relevant to PLD defect claims. Without this clause, providers risk being held responsible for decisions that the law explicitly assigns to the deployer.
Sample language (provider-favourable)
“Client acknowledges that: (a) the AI System is designed to assist, not replace, human judgment; (b) material decisions based on AI Outputs require human review by a qualified person before implementation; and (c) Client, as deployer under Regulation (EU) 2024/1689, is responsible for implementing appropriate human oversight measures in accordance with Article 26 thereof.”
Drafting note: Sub-clause (c) is important — it explicitly designates the client as the deployer and puts Article 26 obligations on record. Enterprise clients in regulated sectors may request deletion of (c); consider whether to hold firm based on your Annex III classification.
4
EU AI Act · Warranty
EU AI Act Compliance Warranty
Provider compliance representation · update mechanism
+
Enterprise blocker without this
Article 16 · Article 26
Enterprise legal teams are increasingly inserting standalone EU AI Act compliance warranties. If you do not provide your own, you accept theirs — which typically includes a broader warranty, an ongoing compliance obligation without carve-outs, and a termination right for any breach. Your own clause lets you define the scope (as of the Effective Date), the applicable version of the regulation, the update mechanism (notice obligation), and the carve-out for changes in law after signing. See our AI governance service for underlying compliance infrastructure.
Sample language (provider-favourable)
“Provider warrants that, as of the Effective Date, the AI System complies with the applicable requirements of Regulation (EU) 2024/1689 (‘EU AI Act’) applicable to providers of [high-risk / limited-risk] AI systems. Provider will notify Client within 30 days of becoming aware of any material change to the AI System’s compliance status. This warranty does not cover requirements that become applicable after the Effective Date unless Provider has expressly agreed to an updated compliance schedule.”
Drafting note: The bracketed risk classification must reflect your actual classification analysis. Do not insert “high-risk” without having conducted a formal Annex III classification exercise — it creates an admission. See our self-classification risk guide.
5
Data · Model Training
Training Data Prohibition
Client data not used for model training · consent requirement
+
Enterprise deal-breaker without this
GDPR data processing
This is the highest-frequency redline from enterprise clients in 2025–2026. Clients with GDPR obligations, trade secrets, or confidential operational data will not execute an MSA that does not expressly prohibit use of their data for model training. Absence of this clause triggers a presumption that training use is permitted, which is commercially and legally untenable for regulated clients. The clause should cover training, fine-tuning, reinforcement learning, and any other model improvement use of client data — and should require affirmative written consent for any exception.
Sample language (provider-favourable)
“Provider shall not use Client Data or Client Outputs for training, fine-tuning, reinforcement learning, benchmarking or otherwise improving any AI model, foundation model or AI system, without Client’s prior written consent. This restriction applies regardless of whether Client Data has been anonymised, aggregated or pseudonymised, unless Provider can demonstrate that re-identification of Client is technically impossible.”
Drafting note: The “technically impossible” standard for anonymisation is deliberately high. If you rely on anonymised data for model improvement, negotiate a lower standard upfront (e.g. “de-identified in accordance with ISO 29101”) rather than accepting the default.
6
Operations · Article 73
AI Incident Notification
Material malfunction notification · 72-hour window
+
Article 73 serious incident
Operational continuity
Article 73 of the EU AI Act requires providers of high-risk AI systems to report serious incidents to market surveillance authorities within defined timeframes. Enterprise clients are mirroring this obligation contractually — requiring notification of any material AI system malfunction that affects their data or operations. Without your own incident clause, you accept the client’s notification provision, which may impose tighter timelines, broader scope (all malfunctions, not just serious incidents), and specific remediation obligations. The 72-hour window in the sample language aligns with the GDPR data breach notification standard, which enterprise clients find familiar.
Sample language (provider-favourable)
“Provider shall notify Client within 72 hours of becoming aware of any material malfunction of the AI System that has or is reasonably likely to have an adverse effect on Client’s data, operations or compliance obligations (‘AI Incident’). Notice shall include: (a) a description of the malfunction; (b) the data and operations affected; (c) immediate mitigation steps taken; and (d) estimated timeline for resolution. Provider shall provide a written post-incident report within 14 days.”
Drafting note: Define “material malfunction” with a threshold (e.g. output quality degradation exceeding X% against baseline, system unavailability exceeding Y hours) to avoid a notification obligation for every minor issue. Enterprise clients will resist a threshold — this is a key negotiation point.
7
Model Updates · Output Quality
Model Change Notice
30-day notice for material model changes · output quality impact
+
Output continuity
Unilateral change risk
AI providers routinely update the underlying models that power their products — improving performance in some dimensions while changing behaviour in others. Enterprise clients with production workflows built on specific model outputs need advance notice of material changes to test, adapt, and obtain internal approvals before the change goes live. Without a model change notice clause, you have contractual freedom to update your model without notice, but at the cost of enterprise relationships and potential claims for output quality degradation. See our analysis of AI provider terms change risk for how this plays out across the stack.
Sample language (provider-favourable)
“Provider shall give Client not less than 30 days’ prior written notice before making any material change to the AI model version, architecture or training methodology that Provider reasonably anticipates may affect the quality, nature or consistency of Outputs (‘Material Model Change’). Provider shall include in such notice a description of the expected change in output characteristics and any required changes to Client’s integration or workflows. Security patches and minor version updates that do not affect output quality are excluded from this requirement.”
Drafting note: The security patch exception is important — without it, emergency security fixes require 30 days notice, which is operationally unworkable. Enterprise clients will request a right to terminate or freeze at the previous model version during the notice period; consider whether to offer a version-lock option as a commercial differentiator.
8
Liability · Cap Structure
AI-Specific Liability Cap
Output liability ceiling · 12-month fee reference
+
Uncapped risk without this
PLD interaction
The general MSA liability cap (typically 12 months’ fees) often excludes IP claims or covers only direct damages. AI output claims can be much larger — a financial services client relying on an AI credit recommendation that turns out to be systematically wrong could argue losses in multiples of the SaaS fees paid. An AI-specific liability cap addresses output-generated claims separately from general service claims, maintains the 12-month fee reference, and carves out PLD claims that cannot be contractually limited under mandatory law. Without a specific AI liability cap, the general cap may be challenged as inapplicable to AI output claims.
Sample language (provider-favourable)
“Provider’s total aggregate liability to Client arising from or in connection with AI-generated Outputs, including claims based on inaccuracy, incompleteness or reliance on Outputs, shall not exceed the total fees paid by Client to Provider in the 12 months immediately preceding the event giving rise to the claim. This cap applies notwithstanding any other provision of this Agreement, except to the extent liability cannot be limited under the Product Liability Directive (EU) 2024/2853 or other mandatory applicable law.”
Drafting note: The mandatory law carve-out for PLD is legally required — PLD liability cannot be contractually excluded under Article 14. Include it explicitly to demonstrate awareness of the PLD framework; enterprise clients will add it if you do not.
Section 3
Does Your MSA Already Include These?
Mark the clauses your current MSA contains. Your score reflects how exposed you are to enterprise redlines and uncapped AI liability under the revised PLD and EU AI Act.
MSA AI Clause Coverage Check
Click each clause to mark as present in your current MSA
0 / 8
AI Output Ownership clause
Explicitly assigns outputs to client on generation · removes provider residual IP claims
Clause 1
Accuracy Disclaimer with verification duty
Limits warranty on output accuracy · assigns client verification obligation before reliance
Clause 2
Human Oversight Acknowledgement
Client acknowledges Article 26 deployer obligation · material decisions require human review
Clause 3
EU AI Act Compliance Warranty
Provider warrants EU AI Act compliance as of Effective Date · includes update mechanism and carve-out
Clause 4
Training Data Prohibition
Client data not used for any model training or improvement without prior written consent
Clause 5
AI Incident Notification (72-hour)
Material malfunction notification · defined scope · post-incident report obligation
Clause 6
Model Change Notice (30 days)
Advance notice of material model changes · security patch exception · output impact description
Clause 7
AI-Specific Liability Cap
Output liability capped at 12-month fees · PLD mandatory law carve-out included
Clause 8
MSA gaps identified? WCR Legal reviews existing MSAs, drafts AI-specific addenda, and negotiates enterprise redlines for SaaS companies with EU exposure. Our AI Risk & Liability service covers the full contract risk framework.
Book an MSA review →
Frequently Asked Questions
AI MSA clauses 2026
1
Does the revised PLD apply to B2B SaaS contracts, or only consumer products?
+
The revised Product Liability Directive applies to damage caused by defective products, including AI software, and covers claims by both consumers and businesses that suffer physical or psychological harm, property damage, or data loss as a result of the defect. For B2B SaaS, the most relevant scenario is where an enterprise client’s employees or end-users suffer harm from reliance on a defective AI output — for example, a medical practitioner who follows an AI recommendation that causes patient harm. The employer may have a claim against the AI provider under PLD. Pure economic loss claims between businesses are generally outside PLD scope but may be addressed by the proposed AI Liability Directive (separate from PLD, still in legislative process). The MSA liability framework must address both PLD (mandatory, cannot be contracted out) and economic loss (fully negotiable).
2
Our enterprise clients are inserting unlimited AI indemnities. How do we push back?
+
Unlimited AI indemnities are increasingly common in enterprise redlines from regulated sectors (financial services, healthcare, legal). The push-back strategy depends on why the client is asking for unlimited liability: if it is a reflexive procurement position, a well-structured AI-specific liability cap (Clause 8 above) that includes a PLD carve-out and a multiplier of annual fees (rather than a flat 12-month cap) often resolves the issue. If it is driven by regulatory compliance requirements on the client’s side (e.g. FCA operational resilience requirements for financial services firms), you need to understand the specific regulation driving the request and design a liability structure that satisfies it without being unlimited. Our AI Risk & Liability team handles this negotiation regularly across different regulated sectors.
3
Do we need separate AI clauses or can we update our existing limitation of liability clause?
+
For SaaS companies where AI is a primary product feature rather than an ancillary function, a separate AI addendum or AI schedule to the MSA is generally preferable to amending the general limitation of liability clause. The reasons are practical: AI obligations (training data, model changes, incident notification, human oversight) are sufficiently distinct from general SaaS obligations that embedding them in a general liability clause creates ambiguity. A standalone AI schedule also makes it easier to update as the legal framework evolves (EU AI Act implementing acts, Digital Omnibus changes) without reopening the core MSA. For companies where AI is a minor feature, targeted amendments to the limitation of liability and data processing clauses may be sufficient. The right approach depends on your product architecture and client mix.
4
Does the EU AI Act compliance warranty need to be updated every time the regulation changes?
+
If drafted correctly, the EU AI Act compliance warranty does not need to be updated every time the regulation changes — the Effective Date carve-out (warranting compliance as of signing, not on an ongoing basis) combined with a notification obligation for material compliance changes gives you a workable framework. However, the August 2026 enforcement deadline for high-risk AI obligations means that any warranty given before August 2026 that covers high-risk AI compliance will have a different scope than one given after that date. If you are in the process of achieving compliance, consider a warranty that covers a compliance roadmap with milestones rather than a current-state warranty that you cannot yet satisfy. Enterprise clients in regulated sectors may insist on ongoing compliance warranties — the negotiation is about the update mechanism, notification timelines, and remediation process rather than the existence of the warranty itself.
5
We use a third-party AI API (e.g. OpenAI, Anthropic). Do these clauses still apply to us as provider?
+
Yes — and this is one of the most common gaps in MSAs for companies built on third-party AI APIs. When you integrate a third-party AI API into your product and sell the resulting product to enterprise clients, you are the provider of the AI-powered product in the eyes of your client. Your client does not have a contractual relationship with OpenAI or Anthropic — they have a relationship with you. This means all 8 clauses above apply to your MSA with your client, even if your underlying AI capability comes from a third-party API. Separately, you should ensure your terms with the AI API provider (OpenAI, Anthropic, etc.) do not create gaps relative to what you promise your clients — particularly on training data, incident notification, and model change notice. See our analysis of AI provider terms change risk for how API provider terms interact with your downstream contracts.
Get Your MSA AI-Ready Before the Next Enterprise Redline
WCR Legal reviews existing MSAs, drafts AI-specific schedules, and negotiates enterprise redlines for SaaS companies with EU exposure. Our AI Risk & Liability service covers the full contract risk framework from PLD to EU AI Act compliance warranties.
Post Comment