AI indemnification has become one of the most actively negotiated areas in technology contracts, and the old indemnity templates were never built for it. With SaaS, the market had settled on IP infringement tied to delivered code. AI introduces output infringement, training data claims, hallucination-driven harm, and data subject claims that the standard language does not anticipate, and the case law does not exist yet, so the drafting has to carry the weight.
Matt Kohel, Partner at Saul Ewing, hosted this How to Contract session and ran it as a working clinic. Jade Hamilton, Senior Legal Counsel at Mariner, took the customer perspective, and John Pavolotsky, Partner at Stoel Rives, took the vendor perspective. Splitting the room that way pressure tested every piece of language from both sides of the table at once, which is what made their advice usable rather than theoretical.
The conversation walked through three drafting puzzles. Vendor IP indemnity for AI outputs, customer indemnity for misuse and data subject claims, and output-specific indemnity paired with custom model ownership at termination. Along the way they covered allocating risk by who actually controls it, the definitions that quietly decide coverage, the acceptable use policy traps, and what happens to your data and models when the contract ends.
Here are our top ten takeaways from the speakers' comments during the webinar:
Anchor the whole negotiation in who controls the risk. The oldest principle in risk allocation still governs AI, where the party best able to control a risk is usually the right one to bear it. The work is figuring out what the vendor can actually control, since AI makes that murkier than it used to be. Remember that indemnity is a contractual remedy, so a vendor can decline a risk it does not want, and you should plan for that rather than assume coverage.
Build your protection as a continuum, not a single clause. The indemnity is one piece, vendor diligence is another, and insurance is the third, and you need all three in view at once. An uncapped indemnity is worthless if the vendor cannot pay it, so confirm there is money or coverage behind the promise. Always read the indemnity together with the limitation of liability, because the next paragraph usually caps everything you just won at the fees paid.
Make the coverage match the risks AI actually creates. Traditional IP indemnity covered discrete infringement tied to delivered code, and that is no longer the whole picture. Output infringement, training data claims, hallucination-driven harm, defamation, and data subject claims all sit outside the standard template. Widen the lens past the IP vector so the provision tracks the harms your use case can really produce.
Watch how "authorized use in accordance with documentation" can swallow the protection. That phrase sounds fair until you notice the vendor controls the documentation and can tighten it later. Documentation is often defined broadly enough to mean anything the vendor has ever said or provided. Tie the indemnity to clear, stable terms so the carve-out cannot quietly eat the coverage you negotiated.
Push for output coverage instead of accepting a blanket output carve-out. A provision that excludes any output generated by the services leaves you exposed on the very thing you bought the tool to produce. You do not fully control what the model returns, and the vendor's own features and models shape it. Ask the vendor to stand behind outputs and carve out only the narrow case where you intentionally prompted for infringing content.
Treat definitions as where the real risk lives. Customer data described only as data you submit misses data that is accessed, provided by an end user, or pulled in through a pipeline. End user can sweep in affiliates and make you responsible for a wider group than you expect. Even "claims" needs a definition, since you do not want to owe a defense the moment a regulator asks a question.
Tame the "as in effect from time to time" language. Letting an acceptable use policy change at will hands the vendor control and pushes the monitoring burden onto you. Tie any change to a material-change notice through the contract's notice provision and attach a real objection right. Check where that notice actually lands, because a legal notice routed to a dozen operations staff is one nobody reads in time.
Sort the privacy risk through the controller and processor lens. As the controller, you carry the risk so long as the vendor follows your documented instructions, and the analysis only shifts if the vendor deviates or suffers a data incident. This principle predates AI and already lives in your data processing agreement. The newer work is provenance, so understand what you put in and where usage-data carve-outs let the vendor train on it.
Settle data and model rights before termination, not at the eleventh hour. A business adopts AI to produce outputs it can keep using, so own the output or secure a license to keep using it after the contract ends. Spell out data return and deletion up front with assurances or audit rights, rather than relying on a written-instruction requirement you have to remember to trigger. Pull your data in a usable format at regular intervals during the term, because the last day is too late to start asking.
Tie every position to the use case and explain your reasoning. Cutting and pasting a canned answer from a toolkit is the fastest path to a bad provision, so understand why this deal differs from the last one. Saying something is not market standard, or that company policy forbids it, does not move a negotiation. Explaining why a position protects your client does, and it builds the credibility you need on the harder asks.
Subscribe to Stay in the Loop
Want more of this kind of practical drafting guidance? Our weekly newsletter brings you upcoming How to Contract webinars and recaps of the sessions you missed. Subscribe now so the next set of takeaways lands in your inbox.
