Six clauses that show up in nearly every AI vendor SOW. Three protect you. Three protect the vendor. Knowing which is which is the difference between a contract you can defend and a contract you have to live with.
The AI implementation SOWs we read on the buyer side average around 4 pages. Our own engagement letter and master SOW total 14. The compression on the vendor side isn't about brevity. It's about which clauses the vendor wants the buyer to gloss past on the way to signature.
This post walks the six clauses that determine whether the contract you're signing protects the work or merely documents that work happened. Three of them are protections you want in your favor. Three are protections the vendor wants in theirs. The asymmetry is the point.
1. Acceptance criteria, named in the SOW. The contract should state, in writing, what each milestone deliverable is and what it must do to be accepted. If the SOW says Phase 1: model deployment, the acceptance criteria for that phase should be specific — what accuracy threshold, on what data, measured how. Without acceptance criteria, delivered becomes a vendor judgment call. With them, it becomes a contractually-defined event.
2. Change orders in writing, signed by both sides. Scope creep is the most expensive feature of any consulting engagement. A contract that allows scope to be expanded by verbal agreement during a working session is a contract that will have a year-two reconciliation argument. The right clause: any change to scope, fees, or schedule requires a written change order signed by both parties before the changed work begins.
3. Data ownership and exit rights. When the engagement ends, you should have a contractual right to extract every artifact — data, configurations, custom prompts, training corpora, model fine-tuning artifacts — in a portable format, within a defined transition window. Vendor's IP stays with the vendor. Your data stays with you. The contract should say so explicitly.
4. The limitation of liability cap. Most vendor SOWs cap the vendor's liability at the fees paid in some preceding window (12 months is common). This is industry-standard and reasonable on its face. What to check: are there carve-outs for breaches of confidentiality, IP infringement, indemnification, or willful misconduct? If the cap applies even to those, your remedy in the worst case is the return of fees you've already paid. That's not a remedy; that's a refund.
5. The IP assignment language for custom work. Vendors typically retain ownership of their platform IP and license you a right to use it during the engagement. That's expected. What's contestable: who owns the custom work the vendor builds specifically for you. Two common patterns:
The second is what you want. The first is what most SOWs default to. The negotiation between them is one paragraph; missing it is one of the highest-cost oversights in AI procurement.
6. The data-handling and sub-processor list. The AI vendor processes your data — and so do their sub-processors (cloud hosting, AI providers, monitoring tools). The contract should name the sub-processors, commit the vendor to materially-equivalent protections downstream, and require notice before any new sub-processor is added. If the SOW is silent on sub-processors, your data is flowing through pipes you can't enumerate.
Every AI vendor SOW we've reviewed contains language designed to do one of three things: limit the vendor's exposure if the project fails, lock the client to the vendor's tooling, or preserve the vendor's right to use the client's data in aggregated form to improve their own models.
The first is reasonable. Software projects fail; bounding the failure is what allows vendors to take the risk. Read the carve-outs.
The second is contested. Lock-in is a structural advantage for the vendor and a structural risk for you. The right counter-language is data-portability, output-portability, and an explicit prohibition on the vendor disabling functionality you've paid for after the engagement ends.
The third is where most clients sign away more than they intended. The phrase to look for: the vendor may use de-identified, aggregated data derived from Customer's use of the Service to improve the Service and its other offerings. What this means in practice: your operational data, stripped of obvious identifiers, becomes a training signal for the vendor's next product. Some clients are fine with that; many wouldn't be if the consequence were stated plainly. Either accept the clause knowingly or strike it.
A defensible AI implementation contract has six things in writing:
Most AI vendor SOWs default to half of these in the vendor's favor and silence on the other half. The negotiation is shorter than buyers expect. Vendors who refuse the negotiation are telling you something useful about the engagement you're about to sign.
The discovery call is the right starting point if you'd like a second read on a draft SOW you're sitting with. Send the document ahead; we'll walk the six clauses on the call.