Most of us learned to draft technology contracts when the underlying product was deterministic. The same inputs produced the same outputs, the failure modes were finite, and a strong vendor-side disclaimer was a viable strategy. AI platforms broke that model. The clauses we copied over from SaaS templates look reasonable in isolation but fail to address the actual risks the technology creates, and the regulatory exposure that follows is real.
That gap was the focus of a recent How to Contract webinar hosted by Laura Frederick and featuring Arohi Kashyap, Partner at Kashyap Partners. Arohi works across California and India on tech and startup matters and spends a lot of her practice inside exactly these AI platform contracts. Her perspective made the conversation especially useful because she has watched the same SaaS-era drafting habits create the same downstream problems across dozens of deals.
The conversation walked through six specific provisions in a vendor's contract with its AI platform customer. We covered AI use disclosures, AI generated content labeling, end user opt out rights, consent and protections for minors, transparency obligations to end users, and warranty disclaimers for probabilistic outputs. Across all six, the same themes kept surfacing around what does and does not translate from SaaS, what vendors can and cannot disclaim, and how to build provisions that actually work in operation.
Here are our top ten takeaways from the speakers' comments during the webinar:
Recognize the SaaS template problem at the start. Most bad AI contract drafting traces to a SaaS template that got repurposed. The deterministic versus probabilistic distinction is not academic. It changes what every clause has to do. Starting from a SaaS form means we should expect to rewrite more than we replace.
Disclaiming a regulatory obligation does not eliminate it. Vendors that draft "vendor undertakes no obligation" language into AI contracts often think they have solved their compliance problem. They have not. The regulator will come back to whoever has the actual statutory obligation, contract language notwithstanding. We should draft as if the regulator is going to read the contract, because they often do.
Customers cannot fulfill obligations that require system knowledge they do not have. Pushing AI disclosure, labeling, or transparency obligations onto the customer creates a paper compliance regime that fails in practice. The party with the system knowledge has to provide what the other party needs in order to comply. We have to negotiate for that information flow, not accept "you handle it" as the answer.
Define what "AI content" means before drafting a label. Fully AI generated, AI assisted, AI summarized, AI modified, and deep fake content are different categories with different labeling needs. A clause that does not distinguish them is a placeholder, not a real provision. Tie the labeling obligation to the party that controls the point of generation for each category.
Use the five-part framework for opt out provisions. Identify who has the right, what is being opted out of, how to exercise it, when it has to be exercised, and what happens afterward. Generic SaaS opt out language is missing at least three of those. We can add them in five sentences and avoid the regulatory ambiguity later.
Layer your consent provisions to match the AI data flow. AI use of data includes training, biometric processing, voice analysis, automated decision making, and downstream third party use. Consent to "use of the service" does not cover any of that. Each layer needs its own consent and its own opt out, or the consent is not informed enough to hold up.
Do not hardcode an age of consent into a multi-jurisdiction contract. Promising no users under thirteen works for COPPA but breaks in jurisdictions with higher thresholds. Tie the representation to applicable law, or pick an age high enough to cover the jurisdictions you care about. Hardcoding thirteen everywhere creates breach exposure the customer did not intend.
AI compliance is a moving target, so build update mechanisms into your clauses. Promising compliance with "all applicable AI transparency laws" is an overcommitment when the laws are changing constantly. Specify the standard the party will meet, build in a notice and change mechanism for legal updates, and avoid "applicable law" as an undefined catch-all.
"Sole discretion" language does not bind a regulator. Drafting "in vendor's sole discretion" gives the vendor cover with the counterparty but not with the regulator. We should be skeptical of provisions that look strong against the other side of the deal but do nothing against the body that actually enforces the underlying obligation.
Pair what you can do with what you cannot do. This was the theme that ran across every clause. Saying only what you will not do or only what you can do leaves the other side guessing. Drawing the box clearly, both the inside and the outside, is what makes the contract usable in operation rather than just on paper.
Subscribe to Stay in the Loop
Whether you joined this webinar live or are catching the recap, our weekly newsletter keeps you current on upcoming How to Contract events and the kind of practical drafting analysis you read here. Subscribe now so the next set of insights lands in your inbox.
