What Happens to Your Data and Fine-Tuned Models When an AI Contract Ends
Switching a traditional SaaS tool usually means exporting records and closing an account. Switching AI vendors can mean losing something you built and can't simply download, and the loss isn't always obvious until you're already trying to leave.
Three kinds of customization, three different exit risks
It helps to separate what customization actually means across different AI product types, because the exit risk differs meaningfully depending on which one you're using. Knowing which category yours falls into changes how seriously to weigh the risk before investing further.
How much of it can you actually take with you
Prompts, workflows, agent configs
Text and structured config move, but tuned behaviour may not survive a different base model
Retrieval over your own documents
The source documents are yours; the index and retrieval configuration often are not
Fine-tuned model weights
Typically runs only on vendor infrastructure, and export is often restricted by the terms
The deeper the customization, the more value it creates and the less of it you can move.
- Fine-tuning adjusts a model's underlying weights based on your training data. This is the deepest form of customization and typically the least portable: the resulting model usually only runs on the vendor's own infrastructure, and there is often no mechanism to export the weights even if you wanted to, both for technical reasons and because many vendors' terms explicitly restrict it
- Retrieval-augmented generation, where a base model references your own documents at query time rather than being retrained, is generally more portable, since the underlying documents are usually yours and exportable, even if the specific indexing and retrieval configuration built around them isn't
- Custom prompts, workflows, or agent configurations sit closer to traditional software configuration, often exportable as text or structured data, though behaviour tuning that took months to get right doesn't necessarily transfer cleanly to a different vendor's underlying model even with the same source prompts
What to check before investing heavily in any of them
- Whether a fine-tuned model, once created, can be exported in any usable form or only used within the vendor's own platform
- Who legally owns the fine-tuned model or its outputs. This is a genuinely unsettled question across many vendor contracts and worth getting an explicit answer on rather than assuming
- What happens to training data and derived model artifacts if the contract ends: deleted, retained, or returned, and on what timeline
- Whether switching vendors means starting the customization process from scratch, and if so what that would realistically cost in time and effort
- Whether the contract specifies any transition period or export assistance if you leave. Most say nothing at all, which is itself worth noting during review
A scenario worth having in mind before it happens
A support team invests months fine-tuning a model on their own historical ticket data, building something genuinely tailored to tone, common issue categories, and escalation triggers. Nobody asked at the outset whether that model would be portable, because the immediate priority was getting it working well. When renewal arrives and pricing shifts unfavourably, switching turns out to mean starting the fine-tuning investment over from nothing. What looked like a straightforward renewal negotiation becomes a much weaker one, because the switching cost was far higher than anyone had mapped in advance.
The information asymmetry this creates at renewal
The vendor generally knows precisely how much you'd lose by leaving, since they built the system that holds it. An account team aware of exactly how much rework a switch would require has little incentive to move much on price. Closing that gap means knowing your own switching cost with the same specificity they do, before the renewal conversation rather than during it.
Questions worth asking before you're in this position
- Is this customization portable in any form, or captured entirely inside one vendor's environment
- If we had to switch next year, what specifically would we lose, and how long would it realistically take to rebuild
- Does the contract commit the vendor to assist with a transition: export documentation, a defined transition period
- Who owns the intellectual property in what we've built together, and is that addressed explicitly or left silent
What to write into the contract before you sign
Exit terms are easiest to negotiate before the first invoice, when the vendor is still selling. Four clauses do most of the work. Ask for a defined export format and a maximum window for producing it, so the obligation is testable rather than aspirational. Ask what happens to fine-tuned weights, embeddings and evaluation sets specifically, because generic data return language often covers inputs and outputs but not derived artifacts. Ask for a deletion certificate with a deadline, which matters for both privacy review and any downstream audit. Finally, ask for a paid transition period at the current rate, so leaving does not require a hard cutover on the renewal date. None of these are unusual requests, and vendors concede them far more readily at signature than at exit.