RatedWithAI

RatedWithAI

Accessibility scanner

AI Copyright & LiabilitySeptember 13, 2026

AI IP Indemnities: The Carve-Outs That Decide Whether Yours Pays

Almost every serious model provider now advertises copyright indemnification, and almost every buyer treats it as a settled risk. The clause is real. So is the list of conditions underneath it, and the conditions describe the exact way most teams actually use these models.

Output only
Covers claims about generated content, not training-data suits
Conditional
Filters on, no tuning, paid tier, prompt notice
Often capped
Read the liability cap and the indemnity as one clause

What an Output Indemnity Is Actually Promising

An AI output indemnity is a promise about one narrow event: a third party asserts that something the model generated for you infringes their copyright, and the vendor steps in to defend and pay. It is the same shape as the IP indemnities that have existed in enterprise software for decades, pointed at a new artifact.

What it is not is a position on the underlying legal question. The unresolved fights over whether training on copyrighted works is fair use are claims brought against model providers by rightsholders. Your indemnity does not resolve them, does not make you a party to them, and does not cover you if a rightsholder ever decides to name downstream users in a theory of their own. Buying an indemnity is buying a defence budget for a specific claim type, not buying certainty about the technology.

The Five Carve-Outs That Do the Real Work

The tier condition

Free, trial, evaluation, and sometimes self-serve tiers are commonly outside the covered services. Teams prototype on a free key, ship, and never re-check which credential production runs on. The indemnity follows the contract, not the intention.

The filter condition

Vendors condition cover on you leaving their copyright and safety filters enabled and not attempting to circumvent them. Anything that looks like defeating a guardrail — jailbreak prompting, stripping refusals, routing around a moderation endpoint — is the cleanest way to lose the clause.

The input condition

If you supplied the infringing material — a reference image, a pasted article, a style prompt naming a living artist, a retrieved document you had no licence to — the vendor is not indemnifying your input. Retrieval-augmented systems make this the most under-appreciated exclusion of the five.

The modification condition

Fine-tuning, continued pre-training, and in some terms even certain adapter setups move the deployment outside the covered service. The output is now partly a function of data the vendor never saw, and standard terms decline that risk.

The process condition

Prompt written notice, sole control of the defence, reasonable cooperation, and no settlement or admission without consent. These read as boilerplate until someone answers a demand letter directly and hands the vendor a reason to decline.

The Cap Is Part of the Indemnity

An indemnity clause and a limitation-of-liability clause are usually drafted pages apart and read separately, which is how a team ends up describing itself as "fully indemnified" while the practical ceiling is twelve months of API spend. Check three things: whether IP indemnity is carved out of the general cap, whether it has a separate supercap, and whether defence costs count against the cap or sit outside it. A cover that pays defence costs inside a fees-based cap can be exhausted before the first substantive motion.

The Back-to-Back Problem for SaaS Builders

If you resell AI output — a generated marketing asset, a drafted contract, a produced image — your customers will eventually ask for the same indemnity you were given. The trap is that your product lets them do things your upstream terms exclude. Any feature that accepts user-uploaded reference material, exposes a tuned model, or offers a free tier creates a slice of usage where you are indemnifying and nobody is indemnifying you.

The fix is not usually a bigger promise or a smaller one. It is aligning three artifacts: your upstream terms, your own terms of service, and the product controls that make the conditions true by default. If your vendor requires filters on, your product should not have a toggle that turns them off. If uploads are excluded, your customer terms should place uploaded material in the customer's own warranty.

Indemnity Review Checklist

1. Establish the Real Scope
  • Confirm the indemnity is output-side, and record in writing that training-data claims are not covered
  • List which SKUs, tiers, endpoints, and API keys fall inside the covered service definition
  • Check whether fine-tuned, distilled, or self-hosted deployments are inside or outside
  • Identify whether third-party models served through the vendor carry the same cover
2. Test the Conditions Against Production
  • Verify no environment runs on a free or evaluation credential
  • Confirm no service disables, downgrades, or routes around the vendor's filters
  • Map every path where user or retrieved content enters a prompt — each is an input-side exposure
  • Document who receives a claim notice and how fast it reaches the vendor
3. Price the Cover
  • Read the limitation-of-liability clause alongside the indemnity, not separately
  • Determine whether defence costs erode the cap
  • Ask whether an uncapped or supercapped IP indemnity is available at your spend level
  • Check the insurance position — media and technology E&O policies treat AI output claims unevenly
4. Align Your Downstream Promise
  • Mirror upstream conditions into your customer terms rather than inventing new ones
  • Put customer-supplied material into the customer's warranty and indemnity
  • Remove product controls that let a customer break a condition you rely on
  • Re-review after any model swap; the new provider's carve-outs will not match the old ones

Your terms page is the first thing a claimant reads

Before anyone reaches your contract, they read what your site says about how the AI works, what it was trained on, and what you promise about the output. RatedWithAI scans your public pages and reports the claims you are making without meaning to.

Scan Your Site for Free →

Frequently Asked Questions

We use three model providers behind one feature. Whose indemnity applies?

Whichever one generated the output in the claim — which means you need per-request provenance. Teams that route dynamically between providers for cost or latency frequently cannot say six months later which model produced a specific asset. Log the provider, model version, and whether filters were enabled on every generation you publish or hand to a customer. Without that record the indemnity is unenforceable in practice even where it applies on paper.

Does an indemnity help with trademark or right-of-publicity claims?

Often not. Many AI indemnities are drafted as copyright indemnities specifically, and a claim that generated content infringes a mark or uses someone's likeness sits outside that wording. Given how much AI output touches brand names, product imagery, and human likenesses, check whether your clause says copyright or says intellectual property, because the difference is not cosmetic.

Is a self-hosted open-weight model indemnified?

Almost never. Open-weight licences typically disclaim warranties and offer no indemnity at all, and the commercial-use conditions in those licences are their own compliance surface. Choosing an open-weight model is choosing to self-insure the output risk, which can be entirely reasonable — it just needs to be a decision someone made rather than a gap someone discovered.

What should a small team do this week?

Two hours of work: pull the actual current terms for each provider you call in production, confirm which credential and tier each environment uses, and write a one-page note recording what is covered, what is excluded, and what the cap is. Most of the exposure we see is not a bad clause — it is a good clause that nobody has read since the evaluation phase, applied to a product that has changed since.

Related Guides