In our first blog post in this series – found here – we described how AI changes the way traditional SaaS contracts should be understood. In this post, we turn to the next challenge: determining how risk in those legacy SaaS agreements is likely allocated in the AI context and how that risk should be treated.
A Critical Truth
Traditional SaaS risk-allocation tools require a fresh analysis when systems generate content and change over time. Customers may need to rethink risk tolerance and mitigation strategies as vendors roll out AI functionality under existing agreements. Timing matters here – it may only be possible to renegotiate these risk-allocation provisions at contract renewal or entry into a new order form. Until then, organizations need to understand the risk allocation as it stands.
Stop Negotiating Accuracy Warranties
A common mistake in AI contracting is requiring warranties that vendors cannot realistically provide.
Traditional SaaS warranties focus on conformity to documentation because software generally produces predictable results. Generative AI systems operate differently. Documentation frequently describes capabilities rather than outcomes. The same prompt may produce different responses from the same system. A documentation warranty still matters for what the service is described to do, but it rarely reaches the accuracy of any particular output.
Rather than focusing on accuracy warranties, organizations should look to obtain measurable commitments regarding:
- Performance thresholds
- Testing procedures, including the test data and metrics used to measure performance
- Retesting following material model changes
- Meaningful remedies when performance degrades
Rebalance the Input and Output Warranties
As we noted in Part 1, customers are frequently asked to provide broad warranties regarding everything they submit to AI systems, while the vendor may give no comparable assurance about outputs. Customers can narrow that asymmetry from both sides. On the input side, the warranty should cover only content the customer itself submits, not information an AI feature retrieves on its own from connected systems, and any customer indemnity should be limited to third-party claims arising from a breach of that warranty. On the vendor side, an accuracy warranty is unlikely for the reasons above, but customers can ask the vendor to warrant that it has the rights needed to use the models and training data on which the service relies. A vendor that builds on a third-party model may limit that warranty to its own models and data and pass through the model provider’s commitments. The output indemnity discussed below can then address third-party infringement claims arising from outputs.
The Importance of Model Version Pinning
Many organizations diligently evaluate a product during procurement and then assume the evaluated system remains relatively stable with only incremental improvements over time until a major update occurs. That assumption may no longer be valid in the AI SaaS context.
AI systems evolve continuously. Vendors frequently update models, architectures and service capabilities. Contractual commitments become difficult to enforce if the tested system is no longer the system being used. A vendor’s ability to commit is also limited where the service runs on a third-party foundation model, because a model provider can retire older models on its own schedule. One major provider, for example, gives customers with active deployments at least 60 days’ notice before retiring a publicly released model, and requires that partner-operated cloud platforms offering its models set their own retirement schedules.
Version pinning (the right to keep using a tested model version for a defined period), material change notification requirements and model-specific commitments increasingly function as foundational risk-management terms. They can help ensure that the evolution of the system does not outpace the contractual rights and obligations of the parties.
Indemnities Require a New Framework
Generative AI introduces categories of claims beyond those that traditional SaaS infringement indemnities were designed to address. Organizations should separately evaluate the need for vendor indemnification for:
- Infringement claims involving the software itself
- Infringement claims involving generated outputs
- Confidentiality-related claims
- Privacy and security claims
The traditional “software infringement” indemnity typically addresses only the first of these categories. Where a vendor offers an output indemnity, its conditions deserve close reading: At least one major provider conditions its output indemnity for certain services on the customer having implemented required mitigations, such as content filters, and requires the customer to demonstrate that compliance when it tenders a claim. These conditions can severely limit the scope of protection the indemnity provides.
Where Indemnity Coverage Disappears
Even historically robust indemnity language can become ineffective if exclusions are drafted too broadly.
Common exclusions are:
- Unauthorized modifications
- Unapproved combinations
- Failure to update
- Prompt misuse
- Acceptable use policy violations
In practice, most real-world deployments involve integrations, customizations and evolving workflows, so these exclusions may swallow the indemnity itself and leave the customer with little to no coverage against third-party claims. Organizations should evaluate whether exclusions are tied to conduct they can reasonably control and identify.
The Hidden Limitation of Liability Problem
Lawyers frequently focus on liability caps. In AI transactions, damages exclusions may be even more important.
Many AI-related harms manifest as:
- Lost business opportunities
- Lost profits
- Business interruption
- Competitive harm
- Remediation expenses following disclosures or incidents
If consequential damages are excluded, the liability cap may never become relevant because the underlying claim is barred before the cap is reached. This is a real challenge because technology contracts customarily exclude consequential damages. One approach is to name specific categories of loss that might otherwise be considered consequential (for example, the costs of investigating and remediating a security incident) and to treat them expressly as direct damages subject to the cap.
Organizations should pay particular attention to carve-outs from the damages exclusion, the liability cap or both, and to separate liability caps, for:
- Data security incidents
- Confidentiality breaches
- Privacy obligations
- Indemnification obligations
- Willful misconduct and gross negligence
Organizations should also evaluate how each of these legacy provisions operates as AI functionality is added to the service and evolves.
When the Fees Behind the Cap Stop Tracking the Risk
Liability caps are commonly measured by the fees paid or payable in the 12 months before the claim (or before the event giving rise to it), and some agreements count only the fees under the order form or for the service that gave rise to the claim. Either formula treats the fees as a rough proxy for the value at risk; from the vendor’s side, the formula keeps exposure in proportion to revenue. AI functionality can widen the gap between the fees and the risk in two ways.
First, as in the CRM vendor example in Part 1, an AI feature may be activated by a routine product update, with no new agreement negotiated. The feature may also come at no additional charge. If the cap counts only the fees under the order form or for the service that gave rise to the claim and the AI feature is treated as outside that order form or as a separate service carrying little or no fee, a claim arising from it may face a cap at or near zero. Even if the feature is part of the subscribed service, a feature offered at no additional charge can add risk without adding to the fees that set the cap.
Second, where AI functionality is priced by consumption and those fees count toward the cap, the fees in the 12-month look-back, and with them the cap, rise and fall with usage, so the protection available may depend on usage in the 12 months before the claim or the underlying event rather than on the size of the loss. (We will address consumption pricing in Part 3.)
Customers should consider a fixed-dollar floor so that the cap is the greater of a stated dollar amount and the fees-based amount. They should also consider measuring the cap on the fees under the whole agreement rather than a single order form. If the cap remains tied to an order form or service, the agreement should treat AI features added without a new order form as part of the order form or service to which the cap refers.
Key Takeaway
Many organizations are attempting to fit AI risk into traditional SaaS risk-allocation models. That approach only works if the warranties, indemnities, exclusions and liability structures have been reevaluated in light of (a) how AI systems actually operate, (b) the technological controls in place to mitigate the risks that remain in the contract and (c) the overall risk tolerance of the customer. The goal is not simply to consider and negotiate AI terms. The goal is to consider and negotiate AI consequences that the parties can accept as reasonable.
