Buying AI capability from a vendor feels, on the surface, like buying any other software: a demo, a pilot, a contract, a rollout. But the underlying asset is different in ways that most procurement processes are not built to catch. The model, the prompts, the fine-tuning data and the evaluation history all accumulate value over time, and if none of that is contractually yours, you are not buying a capability, you are renting one indefinitely at a price the vendor will set later.
The organisations getting burned are not naive ones. They are careful buyers who ran a thorough evaluation of the product and simply never asked the exit question, because at the point of signing, exit felt like the least relevant clause in the document. It rarely stays that way.
What you are actually buying
Separate, at the contracting stage, what is genuinely proprietary to the vendor from what is generated through your use of their product. Base model weights belong to the vendor; that is normal and rarely negotiable. But your prompts, your fine-tuning data, your evaluation datasets and the outputs generated for your business are a different category, and vendors will happily let ambiguous language leave them owning more of that than they should.
Read the data rights clause as if you were planning to leave in eighteen months, because that is exactly the scenario it needs to survive. If the language does not clearly state that your input data, your derived data and your evaluation records are yours to extract in a usable format on request, assume they are not.
If the contract does not tell you how you leave, assume the vendor has already decided you will not.
Portability is a technical requirement, not just a legal one
A contract clause promising data portability is worth little if the actual export format is proprietary, undocumented or delivered so slowly that it is useless for an active migration. Before signing, ask the vendor to demonstrate an export, not describe one, and have your own technical team attempt to load it into a neutral format.
The same applies to fine-tuned models and custom configurations. If the vendor's fine-tuning process only works within their platform and produces no artefact you can take elsewhere, you have built dependency into your own product roadmap. Insist on knowing, before you commit budget to fine-tuning, what happens to that investment if you leave.
- 路Require a documented, tested export path for prompts, evaluation sets and fine-tuning data before signing
- 路Ask what proportion of your investment in customisation is portable versus vendor-specific
- 路Negotiate evaluation rights that let you benchmark the vendor against alternatives on an ongoing basis, not only at procurement
- 路Set contractual notice periods long enough to actually complete a migration, not just to announce one
Evaluation rights protect you from drift
AI products change underneath their contracts more than traditional software does: models get updated, retrained, deprecated, and the output you evaluated at signing may not resemble the output you get eighteen months later. Contracts that do not give you an ongoing right to re-evaluate performance against agreed benchmarks leave you unable to prove, contractually, that the product has degraded even when your users can feel that it has.
Build re-evaluation windows into the contract at fixed intervals, with clearly defined benchmarks and a genuine remedy, not just a conversation, if the vendor fails them. This is the clause vendors resist hardest, which tells you how much it is worth having.
The exit plan belongs in the contract, not in a crisis
Every AI vendor relationship should have a written exit plan agreed before go-live: what data leaves, in what format, over what timeframe, and at what cost. Treat the absence of this plan as a red flag regardless of how strong the product demo was, because the product being good today says nothing about the terms of leaving tomorrow.
This is not adversarial. Vendors confident in their product should be comfortable agreeing exit terms, because they are betting on being good enough that you will not use them. The vendors who resist are telling you something important about how they expect to retain your business.
None of this argues against buying AI from vendors rather than building it yourself; for most organisations, buying remains the right call. It argues for negotiating the contract with the same discipline you would apply to any strategic dependency, rather than treating it as a straightforward software purchase because the sales conversation felt familiar.
The cost of getting this wrong rarely shows up at signing. It shows up two years later, when the business case for switching is strong and the contract quietly makes switching impossible.