Who Owns a Fine-Tuned Model, You or the Client?
The model is not one thing. It is four separable assets with four different owners, and naming them individually ends most ownership arguments in ten minutes.
If you fine-tuned a model for a client, "who owns the model" is the wrong question, because "the model" is not one thing. It is four separable assets with four different owners under most contracts, and the argument you are about to have is almost always about which of the four the client meant. Naming them individually is the fastest way to end the argument, and the fastest way to write a contract that does not produce one.
The four assets hiding inside "the model"
Asset | Who realistically owns it | Can the client take it? |
|---|---|---|
Base model weights | The model provider | No, never |
Training dataset | Usually the client, if built from their data | Yes |
Adapter or fine-tune artefact | Whoever the contract says, often unspecified | Depends entirely on the provider |
Evaluation set and results | Usually whoever built it, often you | Yes, and it is the valuable one |
Work through them in order and most disputes dissolve.
The base model is not yours to give away and never was. You fine-tuned somebody else's model. Whatever you sign, the client is not acquiring rights to a foundation model, and any clause suggesting otherwise is unenforceable rather than generous. If what fine-tuning actually does is fuzzy for the client, five minutes explaining that you adjusted a borrowed model rather than built one saves an hour of contract negotiation.
The training data is usually the client's, and you should say so early and without being asked. If it came out of their support tickets, their documents, or their transcripts, treat it as theirs. Trying to retain rights to a client's own data is the sort of clause that kills renewals.
The fine-tune artefact is where it gets genuinely complicated, and the answer is not in your contract. It is in the model provider's terms. With some providers a fine-tune lives inside their platform and cannot be exported at all; you can call it, you cannot hold it. With open-weight models you have a real file, typically an adapter of a few hundred megabytes, that can be handed over. The client cannot take delivery of something that does not exist as a portable object, and promising delivery before you have checked is a common and avoidable mistake.
The evaluation set is the asset nobody negotiates over and the one that carries the most transferable value. A good eval encodes what "correct" means for this client's task, and it keeps working when the base model changes underneath it. If you have built a real one, you have built the thing that survives the next model generation. What an AI eval is covers why.
What to actually write in the contract
Four clauses, in plain language. This is not legal advice and you should have counsel review the final wording, but these are the four decisions the wording has to encode.
Client owns their input data and any derived dataset. Unambiguous, easy to concede, and it buys goodwill on the clauses that follow.
Fine-tuned artefacts are delivered where technically portable, licensed for the client's internal use. Note the qualifier. It commits you to hand over what can be handed over, and does not commit you to conjure an export path the provider does not offer.
You retain your methodology, prompts, scaffolding, and tooling. The pipeline that produced the fine-tune is your product. Losing it means starting from zero on every engagement. This is the same boundary as who owns the prompts you wrote for a client, and clients accept it far more readily when it is stated upfront than when it is discovered later.
Evaluation sets are jointly usable or explicitly assigned. Pick one and write it down. The default of silence means you will both assume you own it.
The question to ask before you quote
Ask the client what they want to be able to do in two years without you. Not "do you want to own the model." The specific capability.
The answers cluster:
*"Run it if you disappear."* They want continuity. Solve it with an escrow arrangement or a documented handover, not an ownership transfer. Cheaper for both of you.
*"Switch to a different vendor."* They want portability. Give them the dataset and the eval set. Those are what actually transfer; the artefact usually does not.
*"Sell it or license it on."* They want a commercial asset. Now you are negotiating real value, and you should price accordingly.
*"I do not know, it sounded important."* Most common answer. Explain the four assets, and the conversation usually resolves in your favour within ten minutes.
Getting this into the discovery call rather than the contract review is the whole trick. It belongs alongside the other scoping questions in writing an AI project proposal.
The trap: promising portability you cannot deliver
The failure mode that generates actual disputes is not a greedy contractor. It is a well-meaning one who wrote "client shall own the fine-tuned model" into a proposal without checking whether the provider permits export, and then discovered at handover that the fine-tune is an identifier on someone else's platform.
Before you write any ownership clause, check three things with your provider:
Can the fine-tune be exported as a file, or does it only exist as a callable endpoint?
Can the endpoint be transferred to a different account or organisation?
What happens to the fine-tune if the base model it was built on is deprecated?
The third one catches people out most. Fine-tunes are anchored to a base model version, and base model versions retire. A client who believes they own a permanent asset owns something with an expiry date they were not told about. Say so in writing, in the proposal, before it becomes a surprise.
Priced correctly, the expiry is an argument for a maintenance retainer rather than a problem, and recurring maintenance is one of the more durable ways to make money from AI work as a services business.
A note on generated code and outputs
Fine-tuned model ownership is a separate question from who owns what the model produces, and clients conflate them constantly. Output ownership is usually settled by the provider's terms plus your contract, and it is generally simpler than people fear. Who owns AI-generated code covers that side. Answering it in the same conversation is efficient; answering it as if it were the same question is how contracts go wrong.
FAQ
Can a client legally own a fine-tuned model?
They can own the artefact and the data, subject to the base model provider's licence, which always survives. They cannot own the underlying foundation model. Whether the artefact is transferable is a technical question about your provider, not a legal one about your contract.
What if the client paid for everything?
Paying for the work buys the work product as defined in the contract. It does not automatically buy your reusable methodology or the provider's base model. Define the boundary in the proposal, because "we paid for it" is a reasonable instinct that a contract has to answer specifically.
Should I hand over the training data?
Yes, if it came from the client. It is theirs, retaining it creates data-protection exposure you do not want, and refusing looks worse than it is worth.
Does an open-weight model change the answer?
It changes the portability answer, not the ownership answer. With open weights the adapter is a real file you can hand over, so "the client can take it" becomes true. The base model's licence still governs what either of you may do with it.
How did this land?
About the author
Growth & SEO Lead
Manuele covers distribution: SEO, content strategy, and how AI-built products find their first thousand users. He tests everything he recommends.
