Liability Waivers in GaaS Contracts: What They Actually Cover (and What They Quietly Don't)

Table of Contents

• Why GaaS Waivers Read Differently Than SaaS Waivers
• The Anatomy of a GaaS Liability Clause
• The Liability Cap: What "Fees Paid" Actually Means for an Agent
• The Indirect-Damages Disclaimer Is the Real Fight
• Carve-Outs: The Clauses That Survive the Waiver
• Indemnification vs. Limitation: Two Different Levers
• The "Human Oversight" Trapdoor
• What a Buyer Should Negotiate Instead of Accepting
• Insights Most People Overlook
• References

Why GaaS Waivers Read Differently Than SaaS Waivers

Lift the limitation-of-liability section out of a standard SaaS agreement and drop it into a GaaS contract, and at first glance nothing looks wrong. Same fee-based cap, same exclusion of consequential damages, same carve-outs for confidentiality and IP. That's exactly the problem. The boilerplate was written for software that recommends, not software that acts.

A SaaS tool surfaces an answer; a human decides what to do with it. When a dashboard shows the wrong number, the chain of causation between the vendor's product and the buyer's loss is long and contestable -- there were three humans and a quarterly review between the bug and the bad decision. An agent collapses that chain. When an autonomous procurement agent places a $40,000 order at the wrong supplier, or a support agent issues 900 refunds it shouldn't have, the product is the action. There's no human checkpoint to blame, because removing the human checkpoint was the value proposition you paid for.

Vendors know this. So the liability waiver in a mature GaaS contract is doing quiet, deliberate work: it's trying to preserve the SaaS-era risk allocation -- vendor caps at fees, buyer absorbs the rest -- in a product category where the buyer has handed over far more agency. The waiver isn't lying to you. It's just betting you'll read it as if the agent were a smarter spreadsheet. This tension sits at the center of who's liable when an agent makes a costly mistake, and the waiver is where that question gets answered before any mistake happens.

The Anatomy of a GaaS Liability Clause

A typical GaaS liability section has five moving parts, and they interact:

1. The limitation of liability (the cap). A dollar ceiling on what the vendor can owe you -- usually expressed as a multiple of fees paid over some lookback period.
2. The exclusion of damage types. Language disclaiming "indirect, incidental, consequential, special, or punitive" damages, plus often lost profits, lost data, and business interruption.
3. The carve-outs. A list of liabilities that escape both the cap and the exclusions -- typically IP infringement, breach of confidentiality, and the vendor's gross negligence or willful misconduct.
4. The indemnification obligations. A separate promise by one party to cover the other's losses from specified third-party claims.
5. The warranty disclaimers. The "AS IS," "no warranty of fitness," and crucially the "non-deterministic output" language vendors now insert specifically for AI.

People skim the cap and the carve-outs and stop. But the real allocation of risk lives in how the exclusion of damage types interacts with what an agent failure actually costs. That interaction is where buyers get surprised.

The Liability Cap: What "Fees Paid" Actually Means for an Agent

The cap is usually phrased as "the total fees paid in the twelve months preceding the claim." In SaaS, that produces a roughly stable, predictable ceiling -- you pay a known annual subscription, so the cap is knowable in advance.

Per-outcome and per-task GaaS pricing breaks that intuition. If you're paying $2 per resolved support ticket, and the agent goes haywire for one afternoon and mishandles the tickets that triggered a $300,000 compliance exposure, your cap might be computed against the fees for that workload -- a few hundred dollars. Some contracts narrow it further to "fees paid for the specific service that gave rise to the claim," which in a per-outcome model can be almost nothing. You can lose six figures and recover lunch money.

Worse, the cheaper and more granular the pricing, the lower the cap, even though cheaper agents are often the ones running with the least oversight. The economics and the liability move in opposite directions from where your intuition points. When you evaluate GaaS pricing, the agent economics of error coverage should be part of the same conversation -- a $2 task that can trigger a $200,000 loss is not actually a $2 task.

A practical fix: negotiate the cap as a fixed dollar floor (e.g., "the greater of fees paid or $250,000") rather than a pure fee multiple. Vendors resist, but the fixed floor is the single most important number in the whole section for a per-outcome buyer.

The Indirect-Damages Disclaimer Is the Real Fight

Here's the clause that quietly does the most damage, and the one buyers most often wave through: the exclusion of "indirect, consequential, and special damages, including lost profits."

In traditional commercial contracts, that exclusion is reasonable -- it stops a vendor from being on the hook for some unforeseeable downstream catastrophe. But think about what an agent's failures actually produce. A misfiring sales agent doesn't damage your servers (direct); it loses you a deal (lost profits -- excluded). A data-handling agent that leaks records doesn't break your software (direct); it triggers regulatory fines and breach-notification costs (consequential -- excluded). A scheduling agent that double-books your field technicians doesn't corrupt a file (direct); it causes missed-SLA penalties and churned customers (consequential -- excluded).

Notice the pattern: the harms that agents are uniquely capable of causing tend to fall squarely inside the excluded categories. The disclaimer that looks like standard housekeeping is, for an autonomous actor, a near-total shield. Legal commentators have flagged this mismatch as one of the under-examined risks in AI agent procurement, and the American Bar Association's work on AI and contract liability notes that off-the-shelf limitation language frequently fails to map to how AI systems actually cause loss.

The negotiation move here isn't to delete the exclusion -- no vendor will agree to unlimited consequential liability. It's to pull specific, foreseeable agent harms out of the exclusion and into the carve-out list: regulatory fines caused by the agent's documented malfunction, breach-notification costs, contractual penalties the agent's actions directly triggered. You're not asking for everything. You're asking for the handful of consequences that are predictable precisely because you deployed an agent.

Carve-Outs: The Clauses That Survive the Waiver

Carve-outs are the liabilities that escape the cap and the damage exclusions -- the things the vendor will own no matter what. Standard carve-outs include IP infringement, breach of confidentiality, data-protection violations, and gross negligence or willful misconduct. For a GaaS buyer, three additions are worth fighting for:

Security and breach carve-outs. Agents operate with credentials and tool access, which makes them a live attack surface -- a theme explored in depth in agents with credentials: the new enterprise attack surface. If a vendor's agent gets prompt-injected and exfiltrates your data, you want the resulting losses outside the cap, not subject to a one-month-fees ceiling.

"Unauthorized action" carve-outs. If the agent takes an action outside its agreed scope -- spends beyond a limit, accesses systems it wasn't permissioned for, executes a tool it was contractually barred from -- that should sit outside the standard cap. This is the contractual mirror of scoped permissions and least-privilege design: the contract should reward the vendor for honoring the boundaries and penalize it for blowing through them.

Gross negligence that's actually defined. "Gross negligence" is famously slippery. In a GaaS context, push to define it concretely: deploying a model version without the agreed evaluation gates, disabling a kill switch, ignoring a logged anomaly the monitoring was contractually required to catch. Vague carve-outs are carve-outs the vendor's lawyers will argue away.

One caution: gross-negligence and willful-misconduct carve-outs are often uncapped, which sounds great for the buyer until you're the vendor. If you're a GaaS provider reading this, an uncapped carve-out that's also vaguely defined is an existential risk, not a concession.

Indemnification vs. Limitation: Two Different Levers

Buyers conflate these constantly. The limitation of liability governs what one party owes the other for direct disputes between them. Indemnification governs what one party owes the other for third-party claims -- a customer sues you because the agent defamed them, a regulator comes after you because the agent processed data unlawfully.

In GaaS, indemnification is where some of the most consequential negotiation happens, because third parties are exactly who an autonomous agent tends to harm. The agent interacts with your customers, your suppliers, your regulators -- not just with you. So the question "if your agent gets us sued, who pays the lawyers and the judgment?" is often more financially material than the direct-liability cap.

The vendor's instinct is to indemnify only for IP infringement (their model trained on something it shouldn't have) and nothing else. A sophisticated buyer pushes for indemnification covering third-party claims arising from the agent's actions within its authorized scope -- because if the agent did what the vendor designed it to do and a third party was harmed, that's the vendor's design risk, not yours. Where the boundary sits between "authorized scope" and "you told it to do that" is genuinely contested, and it overlaps heavily with the legal gray zone of autonomous agent actions. Get that boundary defined in writing or you'll relitigate it during a crisis.

The "Human Oversight" Trapdoor

The cleverest waiver mechanism in modern GaaS contracts isn't in the liability section at all. It's in the obligations and acceptable-use sections, and it works by transferring duties to you so the liability section never has to do as much lifting.

Watch for language like: "Customer is responsible for reviewing Agent outputs before acting on them," or "Customer shall maintain appropriate human oversight," or "Customer acknowledges Outputs are probabilistic and may contain errors." Each of these is a trapdoor. The moment a loss occurs, the vendor's first argument isn't "our cap protects us" -- it's "you breached your obligation to supervise, so this is your fault before we even reach the cap."

This is rational drafting, and some of it is legally required. The EU's AI Act, for instance, imposes genuine human-oversight obligations on certain high-risk systems, and vendors reasonably want the contract to reflect that those duties are shared. The European Commission's overview of the AI Act makes clear that human oversight is a structural requirement, not just a contractual nicety. But there's a contradiction buyers should name out loud: you bought an autonomous agent precisely so you wouldn't have to review every action. A clause requiring you to review every action before you rely on it quietly unwinds the product you paid for -- and re-prices the risk onto your side of the table.

The honest negotiation is about calibration. Some oversight obligation is fair. A blanket "review everything" obligation attached to a product marketed as "fully autonomous" is the vendor wanting it both ways. Make the oversight obligation proportional to the agent's autonomy level and the stakes of its actions, and tie it to specific controls (spend limits, approval thresholds for high-value actions) rather than a vague duty to watch.

What a Buyer Should Negotiate Instead of Accepting

If you take nothing else from this, take the checklist. In rough priority order for a GaaS buyer:

• Set a fixed-dollar liability floor, not just a fee multiple -- critical under per-outcome pricing where fees can be trivially small relative to potential loss.
• Carve out foreseeable agent-specific consequential harms -- regulatory fines, breach-notification costs, contractual penalties directly caused by a documented malfunction.
• Add an "unauthorized action" carve-out so the agent exceeding its agreed scope escapes the standard cap.
• Demand audit logs and define them contractually. You cannot litigate a liability claim you can't reconstruct; this is the bridge to audit logs regulators will demand from GaaS vendors. Make log retention, completeness, and accessibility a contractual obligation, not a feature promise.
• Define gross negligence with examples, including disabled kill switches and skipped evaluation gates.
• Calibrate the human-oversight obligation to the agent's autonomy level instead of accepting a blanket "review everything" duty.
• Confirm the indemnity covers in-scope third-party harms, not just IP infringement.
• Ask whether the vendor carries errors-and-omissions or AI-specific insurance, and whether their cap is backed by real coverage or is just a number on paper. A vendor whose cap exceeds their insurance is offering you a promise they may not be able to keep.

None of these are exotic. They're the standard moves of any competent commercial-contracts lawyer, applied to a product whose risk profile the boilerplate wasn't written for. Bring counsel who understands both contract law and how agents actually fail -- that combination is still rare, and it's worth paying for.

Insights Most People Overlook

1. The liability cap and the insurance limit are different numbers, and the gap is your problem. Buyers negotiate the cap as if it guarantees recovery. It doesn't -- it guarantees the maximum the vendor will agree to owe. If the vendor is a thinly capitalized startup whose E&O policy tops out at $1M and your negotiated cap is $5M, that extra $4M is theoretical. Ask for proof of insurance and check whether the policy even covers autonomous-agent errors; many standard tech E&O policies have AI exclusions, which connects directly to the insurance market for agent errors and omissions.

2. "Non-deterministic output" disclaimers are quietly becoming the new "AS IS," and they're stronger. Vendors have started inserting language stating that agent outputs are inherently probabilistic and cannot be guaranteed. On its face it's just honest. But it also pre-emptively reframes every agent error as an expected, disclaimed characteristic rather than a defect -- which makes warranty and negligence claims much harder to bring. If the contract says errors are a feature of the technology, you've conceded that errors aren't breaches.

3. The waiver you should worry about most is the one in the sub-processor's contract. Your GaaS vendor likely runs on a foundation model and third-party tools, each with its own liability waiver flowing upstream. When the vendor caps their liability to you, part of the reason is that their liability from the model provider is capped to them. You're at the end of a chain of waivers, and the losses pool at the bottom -- with you. This is the third-party agent risk problem expressed in contract terms.

4. Per-outcome pricing creates a perverse incentive in the liability math. The vendor earns more when the agent does more autonomous work, but the standard fee-based cap means their exposure per action stays tiny relative to the value -- and the risk -- of that action. The pricing model and the liability model are misaligned by design, and only the buyer feels it. A genuinely aligned contract would scale the liability cap with the value of the actions the agent is authorized to take, not with the fees collected.

5. Most "agent made a mistake" disputes will never reach the liability clause -- they'll die on causation. Before any cap or carve-out matters, you have to prove the agent caused the loss. With a non-deterministic system whose decision path is hard to reconstruct, that's brutally difficult, which is why audit logs and explainability aren't compliance niceties -- they're the evidentiary foundation that makes the entire liability section enforceable in the first place. A perfect carve-out is worthless if you can't prove what the agent did.

References

• American Bar Association -- Business Law Today (AI and contract liability commentary)
• European Commission -- Regulatory Framework on Artificial Intelligence (AI Act overview)