AI vendor contracts keep getting drafted like SaaS contracts, and the seams are starting to show. Models drift. Vendors swap underlying providers. Documentation goes stale the day it is delivered. The boilerplate that worked for static software produces a contract that looks fine on signing and falls apart the first time something material changes.
How to Contract hosted a drafting webinar with Laura Frederick, Laura Belmont, General Counsel at The L Suite (which includes Tech GC), and Matt Kohel, Partner at Saul Ewing in Baltimore, who leads the firm's AI team. Laura Belmont brings the in-house customer lens shaped by years of contracting through the AI buildout. Matt brings the vendor-side product counsel perspective and the IP and privacy specialty that puts him close to where these provisions get tested in practice. The format put each of them across from a sample AI provision Claude had drafted and asked them to redline it from their respective sides of the table.
The conversation moved through three specific provisions, model documentation requirements, risk assessment cooperation, and model update and replacement, and surfaced the same pattern in each one. Vendor-friendly boilerplate that reads as reasonable creates exactly the disputes both sides claim to want to avoid. The fix is more specific drafting, not more aggressive drafting.
Here are our top ten takeaways from the speakers' comments during the webinar:
Drop "reasonable" for "thoughtful" where you can. The suggestion to swap "reasonable" for "thoughtful" in AI provisions is more than wordplay. "Reasonable" gets resolved in dispute. "Thoughtful" forces both sides to actually think about what is being asked at the drafting table. The word change moves the conversation earlier in the lifecycle, which is the only time it is cheap to have it.
The flow-down constraint is real, and customers should respect it. Vendors building on top of frontier models cannot promise transparency they do not have. Pushing for full visibility into upstream weights, training data, and fine-tuning techniques wastes leverage. Focus instead on what the vendor itself controls, which is the bigger lever anyway. We can be more aggressive about performance commitments, data handling, and integration architecture because those sit inside the vendor's actual responsibility.
Define documentation by named categories, not by adjectives. "Reasonable documentation" is a fight you will have later. Model cards, benchmarking results, accuracy testing data, bias testing, and a boundary or data flow diagram are categories you can name today. If you do not know what to name for your use case, run the question through an AI tool. The vendor probably has a list anyway.
Trigger documentation updates off the model, not off the document. What you actually care about is the underlying tool changing. The documentation is downstream. Draft the clause so that material changes to the infrastructure, the model, or the subprocessor trigger the obligation, and the documentation update follows. This is a small reframe that puts the focus where it belongs.
Build cooperation triggers around the forces pushing on you. Cooperation needs change across the contract lifecycle. A customer-initiated annual review is not the same as a 72-hour regulatory deadline. Identify the triggers, attach the right timeline to each, and back the vendor's response window off your own deadline by enough time to actually do your work. Giving the vendor your full window means you have no time to review what they send.
Reconcile the cooperation clause with the audit clause. Old SaaS audit rights buried elsewhere in the contract will conflict with new AI cooperation provisions. Whichever party wants to slow things down will pick the slower clause. Read both at drafting time and make sure they say the same thing about timing and scope.
Narrow "commercially sensitive" rather than fighting to delete it. Vendors have real interests in protecting trade secrets and genuinely proprietary methods. The customer-side fix is to define the carve-out around those specific interests, not to leave the vendor with discretion to refuse anything inconvenient. The narrowed version is enforceable. The broad one is not.
Specify who pays for cooperation based on the trigger. A customer-initiated annual review is reasonably the customer's cost. A vendor-caused breach or performance issue is reasonably the vendor's cost. Defaulting to "at customer's expense" sounds neutral but it is a one-way ratchet when something actually goes wrong. Build the allocation into the trigger structure.
Limit update notice to material changes and define material. Patches and routine updates do not need notice. Material updates that could systemically degrade performance, change the underlying model, or affect compliance posture do. The signal-to-noise problem cuts both ways, so the materiality threshold protects everyone.
Customers need remedies when models change, not just notice. Deemed-acceptance through continued use is not a remedy. The customer needs a clean exit when a material change creates a legal, compliance, or performance problem they cannot live with. Termination for cause is the floor. Matt's point was that negotiating this cleanly upfront moves deals faster than fighting customer pushback over a one-sided clause.
Subscribe to Stay in the Loop
How to Contract runs webinars like this one every week, and the newsletter is where the recaps land. Subscribe now to get the practical drafting insights, even if you could not attend the session live.
