AI Procurement Clauses Your Lawyers Haven't Learned to Ask For Yet

The 14-month-old AI vendor contract on your shared drive was drafted from a SaaS template. It guarantees uptime, names a security contact, and caps liability at twelve months of fees. It says nothing about whether your prompts get fed into the next training run, what happens when the model you depend on is quietly swapped for a smaller variant, or which region your inference logs sit in when a regulator asks. The lawyer who drafted it did a competent job with the vocabulary they had. The vocabulary is a generation behind the surface area.

Procurement teams are still optimizing for the wrong contract. The standard MSA fights battles from the 2010s — outage credits, breach notification windows, indemnification for IP that makes it into the source repository. AI vendor relationships have a different attack surface, and the clauses that matter most are the ones that don't have a heading in your existing template. The team that lets last year's procurement playbook handle this year's vendor stack is signing away leverage they will need within a year.

The training-data exclusion clause is not optional

The default state of an AI vendor contract is that your prompts, your outputs, your tool-call traces, your retrieval results, and the metadata around them are all candidate training data unless you say otherwise in writing. Plenty of vendor TOS pages flip the default to opt-out for enterprise customers, but "enterprise" is a self-declared label in many of them, and the opt-out frequently lives behind a console toggle that an admin can flip back without a contract amendment. Your contract needs the prohibition baked into the agreement itself, not delegated to a runtime setting.

Two specific phrasings matter and they are not interchangeable. A clause that prohibits training "foundation models" leaves a vendor free to train fine-tunes, classifiers, safety models, retrieval indexes, embedding models, and "internal quality" models on your data — that is most of the artifacts that actually shape the product you are paying for. The clause you want prohibits use for any "model improvement" or "training, fine-tuning, evaluation, benchmarking, or model development" purpose, with explicit reference to prompts, completions, tool inputs, tool outputs, embeddings, and logs. The asymmetry of the language is the point: the vendor knows what taxonomy of artifacts they produce; your lawyer's template does not.

The downstream-flow problem is the second teeth in this clause. Most large vendors run a chain of subprocessors — a hosting provider, an evaluation vendor, a moderation API, a logging vendor, a CDN. The training prohibition needs to flow to subprocessors with a contractual obligation to flow it to their subprocessors, and a list of named subprocessors with a notice-and-objection right when that list changes. Without this, the vendor can route your data through a partner whose terms are silent on training and have plausible deniability when it turns up in a model six months later. The "vendor doesn't train on your data" headline is true; the "vendor's logging partner sells your prompt corpus to model labs as a benchmark dataset" reality is also true.

Model-version pinning, not model-version hopes

The clause that says "vendor will use commercially reasonable efforts to maintain availability of the Service" implies that the Service is a stable thing. It is not. The vendor ships a new model checkpoint, swaps a 70B variant for a 34B distilled variant under the same product name, quantizes the deployed weights from FP16 to INT8 to reduce serving cost, and tightens the safety classifier in a way that changes refusal rates by twenty points — and your contract is silent on every one of those events because your contract was drafted in a world where the underlying compute was a database.

Pinning is the lever that gives you ground to stand on. The clause names a specific model identifier (vendor-issued model ID plus a version string), commits the vendor to keeping that exact identifier callable for a defined window, and obligates them to send a notice — to a named contact, in a defined channel, with a defined lead time — before the identifier changes behavior or is deprecated. The GSA's 2026 proposed clause for federal AI procurement is a useful reference point: it requires concurrent access to successor models for thirty days for major versions and fifteen for minor, which means the buyer can run their own evaluation on the new endpoint before being forced to migrate. Most commercial contracts give you neither the parallel-access window nor a definition of what "major" and "minor" mean, and that ambiguity benefits the vendor every quarter.

The pin only matters if you are testing it. Your engineering team needs an evaluation harness that runs against the pinned model ID weekly, with an alert when output distributions or refusal rates drift past a threshold, and a contract escalation path the vendor's account manager actually responds to. The legal clause without the technical instrumentation is decorative. The instrumentation without the legal clause is a graph nobody can act on.

Indemnification has a hole the size of your output

The vendor indemnification clause on most enterprise AI contracts in 2026 covers the vendor's training data — they will defend you if a third party claims the model was trained on copyrighted work. What it does not cover, in most templates, is the model's output. If a customer-facing summary your product generates reproduces a paragraph of someone's copyrighted blog post verbatim, or invents a defamatory claim about a real person, or recommends a course of action that violates a regulation in your industry, the vendor's standard indemnity has a carve-out and you are alone.

The asymmetry that needs negotiating is which side of the prompt the vendor backs. Some major vendors — Microsoft, Google, OpenAI for paid tiers — now offer output-side indemnity for a defined scope of services, but the scope is named with surgical precision and the conditions of the indemnity are also named with surgical precision. You typically must use the vendor's safety classifier, accept the vendor's default content filtering, not modify the system prompt outside an allowed envelope, and report claims within a tight window. The list of conditions is the part lawyers without AI experience miss; an indemnity that is unavailable the moment your engineering team turns off the vendor's profanity filter for a legitimate enterprise use case is an indemnity that won't be there when you need it.

Loading…