Contract Terms Worth Checking Before You Commit to an AI Vendor

Engineering decides whether you can move providers. The contract decides when, how long the overlap has to be, and what it costs while both are running. Those are the terms worth reading closely before signing, and they are rarely the ones under discussion during procurement.

Read the contract as a migration schedule

A useful trick when reviewing an AI vendor agreement is to stop reading it as risk allocation and start reading it as a timetable. Almost every clause that matters to an engineering team answers one of three questions: how long must I keep paying after I decide to leave, how much warning do I get before something I depend on changes, and what happens to my data on the way out.

Those three answers, multiplied together, are the shape of your migration. A ninety-day exit notice plus a thirty-day model deprecation window plus a commitment that does not prorate means the practical minimum for a provider change is a quarter of dual-running, whatever the engineering estimate says. That is a number worth having before you sign rather than after.

Data: retention, training and deletion

• Retention period for inputs and outputs. Look for how long request and response content is stored, why (abuse monitoring is the usual stated reason), who can access it, and whether a zero-retention or reduced-retention arrangement is available. Zero-data-retention arrangements often exclude specific features — anything stateful, anything with server-side conversation storage, anything involving file upload — so the question to ask is not “do you offer ZDR” but “which endpoints and features are out of scope for it”.
• Training on your inputs and outputs. Check whether the position is contractual or a console setting, because the two behave differently: a setting can change on a new account, a new project or a new workspace created by somebody in a hurry. Ask whether it applies to inputs, outputs, and metadata separately, and whether human review is a separate carve-out from model training.
• Deletion on termination. The clause usually specifies a window rather than immediacy. What matters at exit is the interaction with the previous point: content retained for abuse monitoring may survive account deletion until its own window expires. Ask for the deletion certificate process if you will need to evidence it.
• Data residency and sub-processors. Where content is processed, and by whom underneath. The sub-processor list is the one document here that changes most often, so the operative term is the notice period for adding one and whether you may object.

Change: deprecation, pricing and sub-processors

The clauses in this group determine whether a migration is something you plan or something that happens to you.

• Model deprecation and version notice. The most consequential term in an AI agreement and frequently the vaguest. Ask for a committed minimum notice before a model version is retired or a pinned version stops being served, and ask whether silent updates to an unpinned alias are permitted. A short or unspecified window means your migration timetable is set by someone else’s release calendar.
• Price change notice. Whether rates can move mid-term, with what notice, and whether a change triggers a termination right. A commitment priced against rates that can move is a commitment to a volume, not to a cost.
• Service levels, and what a credit is worth. Read the remedy, not the percentage. Service credits are almost always capped at a fraction of fees for the affected period, which is unrelated to what an outage costs you. Treat the SLA as a signal of what the vendor expects of itself, and treat fallback to a second provider as the actual remedy.
• Rate limits and capacity. Often not in the contract at all, which is itself the finding. If your workload needs guaranteed throughput, that belongs in writing rather than in a dashboard, and it is a different negotiation from price.

Exit: term, notice and return

These clauses set the floor on how fast you can move, and they compose in ways that are easy to miss when each is read alone.

• Term length and auto-renewal. The renewal notice window is the one to diarise. A term that renews automatically unless cancelled thirty days out means a decision made thirty-one days out is a decision, and one made twenty-nine days out is another full term.
• Termination for convenience — whether it exists at all. Many enterprise agreements do not offer it, and the ones that do usually pair it with the commitment surviving termination. Ask explicitly what happens to an unmet commitment if you terminate early; the answer is the real price of leaving.
• Data return format and window. A right to your data is worth what its format is worth. Ask what the export contains, in what schema, and for how long after termination it can be requested. The gap between “your data” and “a usable artifact” is the subject of what you actually own when leaving a managed platform.
• Assignment and change of control. Whether the vendor may assign the agreement, and whether an acquisition gives you any right to exit. In a consolidating market this is not theoretical.

Assurance clauses and what they cover

Security and compliance attachments are where scope does most of the work. A SOC 2 report is an auditor’s opinion about specified systems over a specified period against criteria the vendor selected — the framework is published by the AICPA. Three questions make it useful rather than decorative: which systems are in scope, is it Type II with an observation period rather than Type I at a point in time, and how old is the report — a stale report plus a bridge letter is a different assurance from a current one.

The same scoping question applies to every other assurance term. An IP indemnity for model outputs typically carries conditions: that you used the safety features provided, that you did not modify the output, that you notify promptly. Those conditions are the clause. Read them before relying on the headline.

How to ask

The most effective procurement question in this space is not about any single clause. It is: walk me through what happens operationally if we give notice on day one of a term. The answer forces the retention window, the commitment treatment, the export format and the deletion process to be stated together, in sequence, which is how they will actually be encountered.

Two follow-ups are worth the time. First, what is the minimum notice before a model we depend on stops being served, in writing. Second, if we move traffic to a second provider mid-term, does that breach anything — because dual-running is how a safe cutover is done, and a contract that penalises it converts a controlled migration into a flag-day one. The arithmetic of that second question is worked through in minimum commitment clauses in AI vendor contracts.