Almost every AI vendor contract now carries some flavor of compliance and governance language, and much of it gets lifted from older software deals or generated by an AI tool in the first draft. That is where the trouble starts, because AI does not behave like the software we spent two decades learning to paper. A system can run exactly as designed and still drift, produce biased results, or get used in ways nobody planned for, and the recycled language tends to fall apart at precisely the moment you need it.
Laura Frederick ran a drafting-format session on this with two speakers who took opposite sides of the table. Olga Mack, CEO of TermScout and a former General Counsel, argued the customer position, while Linsey Krolik, who teaches AI governance at Santa Clara University School of Law and serves as product, privacy, and AI counsel at Credo AI, played the vendor. Having both a builder who runs a data company and a vendor-side governance lawyer in the room meant the trade-offs got tested in both directions rather than presented as one tidy answer.
The conversation worked through three real provisions that an AI tool had drafted, covering bias testing, warranty scope, and disclosure and reporting. Along the way it pressed on the harder questions too, like why disparate impact is a dangerous standard to import into a commercial contract, what to do when a fix would require retraining the model, and what documentation a customer can actually request during procurement.
Here are our top ten takeaways from the speakers' comments during the webinar:
Ask who is accountable when the AI misbehaves. Every compliance and governance provision answers one question, no matter how many words it uses. Olga framed it as who is accountable when the AI does not behave the way everyone expected, and keeping that question in front of you makes the drafting easier. The system can run perfectly and still produce biased or unexplainable outcomes, which is exactly why these provisions exist.
Build for visibility before you reach for liability. By the time you are fighting about liability, you have already lost, because something has already gone badly wrong. The stronger move is making sure you can see how performance is measured, what has changed, and whether risk is climbing. The best provisions create a clear flow of information rather than the harshest remedies, and that visibility is what keeps you out of the dispute in the first place.
Stop recycling your old software language for AI. For years we drafted around uptime, availability, and whether the system works. AI breaks that mold, because a system can perform exactly as designed and still drift, change, or get misused in ways nobody planned for. Treating an AI product like traditional software from twenty years ago is the most common mistake we see, so the language has to account for change over time and not just a snapshot at signing.
Treat the vague triggers as the real fight. Words like periodic, material, promptly, aware, and commercially reasonable feel like a fair compromise during negotiation. Six months later, both sides discover they read those few words completely differently. Decide which of those terms actually matters for your deal and tie them to something concrete, like a model change or a defined cadence. Olga was honest that whether she picks that fight depends on how important the data is and the size of the contract.
Anchor soft standards to applicable law. Adding "consistent with applicable law" gives you a standard that is far harder to negotiate away than a freestanding obligation you invented, and it lets regulators in places like California and the EU do some of the bargaining for you. It also builds in an evolving standard as the rules mature. Laura added a practical companion move, which is to ask for the testing methodology the vendor already uses and attach it as an exhibit, ideally as a floor.
Think twice before importing disparate impact. Disparate impact sounds protective, but it is a very high bar borrowed from employment law, where you can do everything right and still be on the hook for the outcome. Proving it usually means statistical studies, which turns into a litigation nightmare for both sides. For most day-to-day commercial contracts, that standard does not belong in the document. It is also a warning about AI-drafted clauses, which will happily insert language you never stress-tested against your use case.
Make warranties measure something you can stand behind. A warranty that the system conforms to the documentation often just describes features, which fails badly for AI. The better question is whether both sides have agreed on what success looks like, whether that is accuracy, reliability, consistency, or drift. Vendors are understandably reluctant to warrant outcomes they cannot fully control, so pick the metrics that matter to you, press there, and accept softer language elsewhere.
Read the definition of documentation before you rely on it. A warranty tied to substantial conformance with "the documentation" is only as good as what that defined term actually contains. A thin list of features makes the warranty nearly empty, while a vendor preparing for the EU AI Act or running a frontier model may hand you a system card that runs past two hundred pages. Linsey reminded us those model cards are now a real source of detail, not marketing, so ask to see what exists before you decide how hard to negotiate.
Separate disclosure from remediation, and remediation from blame. Disclosure is about transparency, remediation is about fixing the problem, and they are not the same obligation. Fixing an AI issue can take real time and sometimes requires retraining, because the model is probabilistic and has no judgment of its own. The bias may even come from the customer's own data, so the contract should not assume the vendor is always at fault. Olga suggested answering three questions up front, which are when the vendor must tell you, what they must share, and what rights you have while the fix is underway.
Map how the AI is actually used before you draft a word. Do not assume your data is being used to train a model, since that happens in a narrower set of cases than people expect. Inventory the AI uses, classify them by kind, and ask specifically when and whether your data trains anything. Once you have that map, the right contract language tends to become obvious, because you will know exactly what words to use once you understand the problem you are solving.
Subscribe to Stay in the Loop
If this kind of clause-by-clause breakdown is useful, our weekly newsletter delivers more of it, along with early word on upcoming How to Contract webinars and recaps of the ones you missed. Subscribe now and keep these practical insights landing in your inbox.
