MODULE 5 · LESSON 3
Free — no login requiredSign in to track progress, save quiz attempts and enrol in the full course.
Sign in to track progress / enrolContracts, Data Rights and Getting Out
Nothing here is legal advice, and your legal team should draft the words. What follows is what a manager needs to ask for, because a legal review checks the terms present — it rarely notices the terms absent.
The data questions
The most important commercial questions in an AI contract are about data, and standard software agreements frequently do not address them.
Can our data be used to train their models? The default in some contracts is yes. Establish it explicitly. If your data is the moat from lesson 1, allowing it to improve a product your competitors also buy is a strategic decision, not a procurement detail.
Is our data used to improve the service for us specifically? A different question, and often desirable. You may want your corrections to improve your instance while never leaving it.
Where is it processed and stored, and by which sub-processors? The model provider behind a vendor's product is a sub-processor, and vendors change model providers. Ask to be notified.
What happens to it when we leave? Deletion, on what timescale, with what confirmation.
Who owns the outputs? Usually you, and it should say so.
What you should be able to take with you
Lock-in in AI contracts is rarely about the model. It is about accumulated assets, and these are the ones worth naming explicitly:
The second row is the one to fight for. Two years of staff corrections is precisely the dataset that makes a switch feasible, and it is exactly what a departing customer is least likely to receive unless the contract says so.
The last row is worth understanding rather than negotiating. A model adapted on your data usually cannot be extracted in a usable form. If the deal depends on that, structure it so the data stays portable instead.
The AI-specific terms
Model change notification. The vendor may change the underlying model. Your carefully tuned configuration may behave differently overnight. Ask for notice and a testing window. This term barely exists in standard software contracts and matters enormously here.
Performance commitments in your terms. Vendors resist accuracy guarantees, often reasonably. What you can obtain is a commitment to measure and report on an agreed metric, plus a remedy if it degrades materially. Reporting you can see beats a guarantee you cannot enforce.
Uptime and latency where the system sits in a live workflow.
Liability for outputs. What happens if the system produces something that harms a customer. Expect vendors to cap this heavily. The negotiation matters less than knowing where you stand — because as module 1 established, accountability does not transfer regardless of what the contract says about liability.
Regulatory support. If you are subject to AI regulation, you will need documentation from the vendor: what the system does, how it was tested, what its known limitations are. Put the obligation to supply it in the contract, because requesting it afterwards from a vendor with no commercial reason to help is difficult.
Price protection. With usage-based pricing, an unbounded per-unit price is an unbounded budget. Seek a cap or an agreed review mechanism.
Define the exit before you sign
Write down, before signature, three things:
- What would make us leave? Price, performance, a strategic change, an acquisition.
- What would we need to leave cleanly? Data, labels, configuration, in what formats.
- How long would it take, and who else could we go to? If there is no answer, you have single-supplier dependency and should know it.
You will probably never use this. Writing it changes the negotiation anyway, because a customer who has thought about leaving negotiates differently from one who has not — and vendors can tell.
A composite of a very common situation, assembled from the ordinary way these agreements are written.
A company adopts a document-processing product. It works. Over two years the operations team corrects the system's output thousands of times, and accuracy on their specific document types improves markedly — precisely because of those corrections.
At renewal the price rises substantially. The team investigates alternatives and finds one that is cheaper and, on paper, at least as capable.
Then the switching analysis:
- The corrections live in the vendor's system. The contract says the customer owns their "data", which the vendor interprets as the original documents — not the correction history, which they treat as system-generated. Two years of labelling is not portable.
- The configuration — extraction rules, field mappings, exception thresholds — was built inside the vendor's interface with no export.
- A new vendor would begin at roughly the accuracy the incumbent had on day one, meaning the team absorbs a year of degraded performance to save on licensing.
- The audit trail regulators may ask about sits in a system they would no longer have access to.
They renewed at the higher price, which was the rational decision by then and was determined two years earlier by a contract nobody read closely.
Three clauses would have changed the outcome, and all three are ordinary asks at signature and nearly impossible at renewal: corrections and labels are our data and exportable in a documented format; configuration is exportable; audit logs are retained and provided on exit. None is unreasonable. Very few contracts contain them unless the customer asks, and the moment to ask is when you still have the option not to sign.
Which asset is most often lost in an AI vendor switch, and why does it matter most?
The four data questions
Click to flipCan our data train their models; is it used to improve the service for us specifically; where and by which sub-processors is it processed; and what happens to it when we leave.
Click to flip backThe contract decides more than the technology, and standard software agreements miss the terms that matter for AI. Settle the data questions explicitly — training rights, sub-processors, deletion, output ownership — and insist that corrections, configuration and audit logs are yours and exportable, because those are what make a future switch possible. Ask for model change notification and reported performance rather than unenforceable guarantees, and write your exit position down before you sign.