Most of us are not negotiating with frontier model providers. We are dealing with the SaaS vendors we already use, who are now adding AI features to products we bought before any of this existed. The instinct is to bolt those features on with a short AI addendum and move on. That instinct is what creates most of the downstream problems.
Laura Frederick hosted Laura Belmont, General Counsel at The Suite, and Tiffany Bui Le Tourneau, a partner at Apogee Law, for a working session on AI addendum drafting. Both panelists have lived this from the vendor side and the customer side, and they brought the kind of pointed, drafting-level perspective that only comes from negotiating these documents in the wild. Their willingness to play vendor and customer roles on the same provision made the exposure visible from both directions.
The conversation walked through three boilerplate AI addendum provisions that look reasonable at first glance and fall apart the moment you read them carefully. Order of precedence, scope and change management, and the data use, confidentiality, and liability cross-references all came in for serious pressure testing.
Here are our top ten takeaways from the speakers' comments during the webinar:
An AI addendum is not a DPA, even if it looks like one. We are used to addenda that address a discrete subject and govern over the base agreement on that subject. AI is not a discrete subject. It is woven into the product, the data, the outputs, and the risk allocation. Treating the addendum as a standalone document we can ship in two days creates exactly the conflicts the base agreement was carefully drafted to avoid.
Decide the layering before you draft anything. Is the addendum supplementing the base agreement, carving out from it, or overriding it? That choice has to be made upfront and documented at the provision level, not buried in a generic "in the event of conflict" clause. Without that work, you can lock yourself out of overriding the addendum on ordering documents later.
"Subject matter hereof" is not a control mechanism. It sounds like one. It is not. When the subject matter is something as diffuse as AI, the formula generates more disputes than it resolves. Replace it with explicit references to specific provisions in the base agreement that the addendum overrides, supplements, or leaves alone.
Define AI services with a layered model. Recommendation engines and document summarizers carry different risks than tools that train on customer data and modify model weights. A single definition that treats them the same drags either the vendor or the customer into a deal they should not have signed. Distinguish application-layer features from model-layer behavior in the definitions and tie the obligations and caps to that distinction.
Generic "material change" language gives the vendor everything. "Reasonable notice of material changes" lets the vendor decide what counts as material and how much notice is reasonable. If you only have one shot at this provision, spend it specifying the kinds of changes you actually care about. Changes to security posture, training behavior, performance thresholds, or the underlying model provider are the ones that move risk.
If all you can get is notice, build other levers. Notice without a termination right or a product-level toggle is decorative. The harder work is making sure the customer can act on the notice. A termination right tied to specific change categories, or a contractual obligation that the vendor maintain a training opt-out at the product level, gives the notice provision something to do.
Customer data needs a new definition once AI is in the picture. The pre-AI definition typically covers what the customer uploaded. AI products pull from connectors, integrations, and prompts, and they produce outputs that derive from customer inputs. Walk through the actual data flow with the product team and write the definition to match it.
Cross-referencing the base agreement's data use rights is how vendors authorize training by accident. Almost every SaaS agreement permits the vendor to use customer content to provide the services and improve the product. Those rights, read broadly, authorize training. If the addendum is supposed to restrict training, it has to do so explicitly, not by referring back to the rights it is trying to limit.
The third-party model provider is a confidentiality problem you have to name. When the vendor routes customer data to an LLM provider, the vendor is disclosing confidential information to a third party. Either that disclosure is an authorized subprocessing arrangement with tightly drawn carve-outs or it is a breach. The addendum has to pick one and specify the conditions.
Standard SaaS risk allocation does not survive the move to AI. Unlimited IP indemnity and unlimited confidentiality liability assume the vendor controls outputs and data flow. With probabilistic outputs and third-party model providers, neither is true. Differentiated caps and clearer carve-outs are not vendor-friendly drafting. They are the honest accounting of where the risk actually sits.
Subscribe to Stay in the Loop
Our weekly newsletter rounds up upcoming How to Contract webinars and recaps like this one. Subscribe now to get the practical drafting insights in your inbox, whether you caught the live session or not.
