Limitation of Liability in AI Contracts: What to Negotiate

In an AI services contract, the limitation of liability clause sets the most a provider will pay if something goes wrong, and lists the kinds of loss it will not pay for at all. What you can negotiate is the size and basis of the cap, the exclusions that could empty it of value, and the carve-outs (data breach, confidentiality, intellectual property, misconduct) that should sit outside it. Read the clause as a map of who carries which risk, not as boilerplate to skim.

Key takeaways

• The cap is the headline term, but its basis (fees paid or payable, per claim or in total) decides whether it means anything in practice.
• Exclusions for indirect and consequential loss can remove exactly the damages an AI error is most likely to cause, so read them against your real use case.
• Data breach, confidentiality, intellectual property claims and wilful misconduct usually belong outside the ordinary cap, or under a separate higher one.
• Liability follows control: the clearer the contract is about who configures, who approves and who operates, the easier it is to see who answers for what.
• Ask for the clause early, discuss it in plain terms, and have counsel review the final text. This article is general information, not legal advice.

What does a limitation of liability clause actually do?

Every service contract allocates risk. The limitation of liability clause is where that allocation becomes numbers and lists. It usually does three things: it caps the total the provider can owe you, it excludes certain categories of loss entirely, and it names exceptions where the cap or exclusions do not apply.

It does not decide whether the provider is at fault. Fault, breach and remedies are handled elsewhere in the agreement. The clause only limits how far the consequences travel once a claim succeeds. That is why two providers with similar service descriptions can carry very different risk for you.

It also does not replace operational controls. A strong clause on paper is a poor substitute for approval boundaries, narrow permissions and logs that show what an agent did. If you want the operational side, the guide to running a permission review for your AI agents covers it step by step.

The most useful question to hold in mind while reading is simple.

A cap is a statement about risk, so ask which risks it was written for.

How do liability caps work, and what is a reasonable basis?

A cap is normally expressed in one of three ways: a fixed sum, a multiple of the fees, or the fees paid or payable over a defined period. Each behaves differently, and the differences matter more than the headline.

Check these points:

• Basis: fees paid is lower early in the relationship, because little has been paid yet. Fees payable over the full term is steadier. Ask which one the draft uses.
• Period: a cap tied to a recent period of fees shrinks if you scale down or run a small first engagement.
• Aggregate or per claim: an aggregate cap is a single pool for the whole relationship. A per-claim cap resets, which favors you if incidents are possible more than once.
• Mutuality: a cap that limits the provider but leaves your liability open is a one-sided term worth questioning.
• Relation to exposure: a small pilot with small fees can produce a cap far below what the agent could touch if it had access to customer records or outbound email.

That last point is the core tension. Fees measure what you pay for the service. Exposure measures what the service can affect. An agent that drafts internal notes has low exposure. An agent that can send messages to customers or update records has more. Match the discussion of the cap to the role, not to the invoice. The scoping logic behind this is covered in what to put in an AI agent statement of work.

Which exclusions matter most in an AI contract?

Most providers exclude indirect, incidental and consequential loss, often alongside lost profits, lost revenue and damage to reputation. In ordinary software this is routine. In AI work it deserves a second look, because a wrong output typically causes loss of exactly that kind: a lost deal, a delayed shipment, a reputational cost after a wrong message to a customer.

You will rarely remove these exclusions entirely. You can, however, ask for specific narrowing, such as stating that the cost of correcting data, re-sending communications, and notifying affected people counts as direct loss.

Other exclusions and disclaimers to read closely:

• Output disclaimers: statements that outputs may be inaccurate and that you are responsible for reviewing them. Reasonable in principle, but the contract should say which outputs need human review and who does it.
• Third-party model providers: many AI services run on models from other companies. Clauses that disclaim all responsibility for those models leave a gap. Ask what the provider owes you when the underlying model fails or changes.
• Customer-caused loss: exclusions for loss caused by your instructions, data or configuration are fair. They become unfair if the provider designed the configuration.
• Service changes: check whether the provider can alter behavior without notice, and what happens to liability when it does.

The OWASP list of risks for language model applications is a useful neutral reference for the kinds of failures that happen in practice, including prompt injection and excessive agency. Reading it helps you decide which failures you want the contract to address.

What should sit outside the cap?

Carve-outs are the exceptions that make a cap fair. Some are close to standard, some are negotiated, and some are replaced by a separate higher limit, often called a super-cap.

Common candidates:

• Wilful misconduct and gross negligence: usually not capped, and many legal systems do not allow them to be capped anyway.
• Confidentiality breach: if the agent holds your internal knowledge, a leak is the central risk. Ask that it sit outside the ordinary cap or under a higher one.
• Data protection and security incidents: obligations under privacy law, including Brazil's LGPD and the EU GDPR, can create costs the ordinary cap was never sized for. Where the data lives also matters, see AI data residency for business.
• Intellectual property indemnity: if a third party claims that the delivered work or outputs infringe their rights, who defends and pays? Providers often offer this for their own materials but not for your inputs.
• Fraud and legal violations: generally not excludable.

A practical compromise is a tiered structure: an ordinary cap for general service failures, a higher cap for data and confidentiality incidents, and no cap for misconduct. If a provider refuses any tiering, ask them to explain which specific risk they cannot price. The answer is informative.

Regulation also shapes what is negotiable. If your use of AI falls under a regime such as the EU AI Act, some duties cannot be contracted away, and the allocation between provider and deployer matters.

An illustrative scenario: three clauses, one incident

This scenario is illustrative, not a real case. A services company has an agent that drafts replies to supplier queries and, after human approval, sends them. One day the agent uses an outdated delivery policy and a reply goes out that commits the company to terms it did not intend. A supplier acts on it and the company bears the cost.

Clause A caps liability at a small fraction of a recent fee period, excludes all consequential loss, and says outputs are the customer's responsibility. The provider owes almost nothing, and the cost lands on the company.

Clause B has the same cap but states that the customer approves outbound messages and the provider maintains the knowledge base. Here the question becomes factual: was the outdated policy a maintenance failure, or did an approver pass it through? The contract at least points to the right evidence, such as change records and approval logs.

Clause C adds a defined duty to keep the agent's knowledge sources current, a notice process for incidents, and a higher limit for failures in that duty. This does not make the provider liable for every mistake, but it matches responsibility to control.

The lesson: the allocation of duties in the contract often matters more than the number in the cap. Operational clarity makes liability clauses workable.

A step-by-step plan for negotiating the clause

Use this order to keep the conversation practical.

• Describe the role and its reach. Write down what the agent can read, write and send, and which actions need approval. This is your exposure statement.
• Rank the failures you fear. Typically: data exposure, wrong external communication, wrong record changes, downtime in a key process.
• Ask for the draft clause early, before commercial terms are settled, so liability is not squeezed in at the end.
• Check the cap basis, period, and whether it is aggregate or per claim.
• Read the exclusions against your ranked failures. Mark any failure that falls inside an exclusion.
• Propose carve-outs or a higher limit for the failures that matter most, with a reason tied to the role.
• Align duties: make sure responsibilities for configuration, approval, monitoring and incident notice are written in the scope document, not only in the liability clause.
• Check how your insurance responds. A broker can tell you what is covered and what the contract must support. See insurance for AI agent mistakes.
• Set a review point. When the agent gains new access or the engagement grows, revisit the clause. The same applies at renewal.
• Have counsel review the final text before signing.

How Be Human approaches the problem

Be Human defines one useful role per first engagement, with the memory, tools, permissions and approval boundaries that role needs, and writes them into the scope so responsibilities are visible. Managed operations then include monitoring, recurring evaluations, permission review and incident response, which produce the records that make liability conversations factual. Liability terms are set in the contract and are best raised during scoping, when the role and its reach are being defined.

Frequently asked questions

Is a liability cap negotiable with an AI provider? Often yes, at least in part. Providers rarely remove a cap, but they may adjust its basis, add a higher limit for data and confidentiality incidents, or add carve-outs. Negotiation works best when you tie each request to a specific risk in the role.

Should the cap be higher for AI than for ordinary software? It should reflect what the system can affect, not the category of technology. An agent with access to customer data or outbound channels justifies more attention than one confined to internal drafts. Describe the reach of the role and let that guide the discussion.

Does the provider answer for failures in the underlying model? That depends on the contract. Many providers disclaim responsibility for third-party models, so ask what they owe you if a model fails, changes or is withdrawn, and what their own duties are around testing and monitoring.

Who is responsible when an agent takes a wrong action? The contract should say who configures, who approves and who operates. Where a human approves actions, responsibility often shares between approver and operator. Clear approval boundaries and logs make it possible to establish what happened and who controlled which step.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.