Bottom line up front: before you sign an AI vendor contract, settle three things — who owns the data, how the SLA is measured, and how you get out. Leave any of the three vague, and after go-live the vendor decides all of them for you. This article is the clause-by-clause checklist I use when I review these contracts. If the vendor cannot answer a question on it, do not sign.
Why an AI vendor contract is not a generic SaaS contract
A generic SaaS contract covers accounts, fees, and availability. An AI vendor contract adds three variables the template never mentions: your operational data may feed the vendor's models, model performance drifts over time, and switching vendors costs far more than switching software.
I have seen this exact failure three times, and the script never changes. Selection goes great, the contract gets signed on the vendor's standard template in a hurry, and three months after go-live something breaks. That is when someone finally reads the contract and discovers the rights they assumed were never written down.
In 2023, a third-party logistics provider in eastern China handling apparel fulfillment signed up for a visual verification system. The contract said data belongs to the customer. Two years later they wanted to switch vendors. The vendor exported the data — raw files with no field documentation, historical images that did not match the picking records, and annotation results that could not be exported at all. The new vendor said re-annotating months of data was required before they could start, and the project stalled for two months. Data belonging to you is not the same as data you can actually use.
In early 2024, an electronics warehouse in southern China adopted an AI demand forecasting tool. The contract SLA covered system availability only. The system stayed online every day, but the forecasts drifted further off. The warehouse overstocked slow-moving product and stocked out of the models customers actually wanted. When they complained, the vendor pointed at the SLA: the system had not gone down, so the SLA was met. If an AI SLA only measures whether the system is up and never measures whether it is right, it is not an SLA at all.
First item in an AI vendor contract: data ownership, four questions, no shortcuts
Split the data into four categories and settle each one: the business data you feed in, the process data generated while the system runs, the outputs the model produces, and the model and parameters fine-tuned on your data. For each category, the contract should state ownership, permitted use, and retention period.
Push hardest on training opt-out: the contract must state in plain language that the vendor may not use your business data to train general models, or may do so only with your prior written consent. A verbal promise does not count; if the clause is missing, assume your data can be used. Then settle deletion: when the contract ends or you request it, how quickly must the vendor delete your data, and what proof do they owe you? A clause that says the vendor shall delete data, with no deadline and no proof, is the same as no clause.
| Checklist item | What the contract must spell out | What happens if it does not |
|---|---|---|
| Input data ownership | Your raw business data stays yours; the vendor gets a use license only | The vendor trains a competitor's model on your order data |
| Process data ownership | Who owns run logs, annotations, and feedback data | Your historical annotations cannot move with you when you switch |
| Fine-tuned model ownership | Whether a model fine-tuned on your data can leave with you | Switching vendors means retraining from zero |
| Training opt-out | Whether your data may train general models | Your operating patterns become someone else's model capability |
| Deletion and proof | Deletion deadline and form of proof after the contract ends | Your data keeps sitting on the vendor's servers after you leave |
One detail people miss: the data export format. Export must be structured and directly usable, with field documentation alongside. A contract that promises export without specifying the format leaves the vendor free to hand you raw files.
Second item in an AI vendor contract: SLA must be measured on business metrics, not just uptime
An AI SLA needs at least three layers: system availability, model performance, and response and support. Availability is whether the system is up, model performance is whether it is right, response and support is how fast someone acts when something breaks.
For visual verification, talk about missed defects and false alarms; for forecasting, how often error exceeds the agreed band; for a service bot, the escalation rate to human agents. Metric definitions, measurement method, and measurement period all belong in a contract appendix. If the method is unclear, the monthly review becomes two sides arguing past each other.
Remedies must be concrete too: what happens when the SLA is missed — a credit against the monthly fee, a service extension, or a right to terminate. An SLA that says the vendor shall be responsible, with no remedy mechanism, is just an argument waiting to happen. Also settle model change notification: when the vendor upgrades the model or adjusts parameters, how much advance notice do you get, does it need your approval, and can you roll back if performance drops?
Third item in an AI vendor contract: exit clauses, write the breakup while you still like each other
Exit clauses are the easiest to skip and the most expensive to regret. Signing day is when the relationship is at its best, which makes it the cheapest moment to negotiate a breakup.
| Checklist item | What the contract must spell out | What happens if it does not |
|---|---|---|
| Termination conditions | Which events allow termination, such as repeated SLA misses, vendor acquisition, or service discontinuation | You cannot leave and must wait out the full term |
| Data export | Export scope, format, field documentation, and completion deadline | The exported data is unusable, which is the same as no export |
| Transition period | How long the vendor keeps serving you after termination | The old system stops before the new one is ready, and operations stall |
| Fee settlement | How early termination fees are calculated, and whether prepaid unused fees are refunded | Leaving costs you an extra bill on top of everything else |
| Knowledge transfer | Whether interface docs, configuration notes, and history are provided | Switching vendors turns into a full re-implementation |
The transition period should at least cover the time you need to switch vendors, with its service level and fees stated. One more item people forget: the vendor's obligation to delete your data after exit, which ties back to the data section of this contract. Model decay and drift monitoring clauses matter as well, but that deserves its own article — here I will only say this: monitoring frequency and retraining responsibility belong in the contract.
The night-before-go-live checklist: three topics, nine questions
The night before signing, run through these nine questions. If any one of them has no answer, do not sign the next morning.
- For each of the four data categories, are ownership, permitted use, and retention all spelled out?
- Is the training opt-out in black and white, with a deletion deadline and proof of deletion?
- Are the data export format and field documentation written into the contract, not just a promise to provide export?
- Does the SLA cover model performance metrics, with definitions and measurement periods in an appendix?
- Is the remedy for a missed SLA concrete — how much, in what form, and who decides?
- Do model changes require advance notice, and can you roll back if performance drops?
- Do the termination conditions include repeated SLA misses and service discontinuation, not just expiry?
- How long is the transition period, and are its service level and fees spelled out?
- Are early termination fee settlement and knowledge transfer covered?
Here is the counterintuitive judgment: the more detailed the contract, the smoother the partnership. Many managers avoid negotiating exit clauses for fear of hurting the relationship. The result is half a day saved at signing and half a year of disputes after go-live. If a vendor dodges the data and exit clauses and refuses to put them in writing, that is the strongest signal of all — walk away before signing. Contract clauses may carry legal consequences, so have a lawyer review the final terms; this article covers the business points you must settle first.
By Lin Xiao, WMS Implementation Consultant
