Engraved strongbox chained to a distant cloud vault while a figure outside holds the key, representing exclusive use of a fine-tuned model without possession of its weights

Who Owns the Model You Fine-Tuned? The Answer Surprises People

August 16, 2026

Executive Summary

Fine-tuned model ownership is decided by deployment architecture, not by intellectual property law. If you cannot export the weights, the ownership clause is decoration.
No major hosted platform (OpenAI, Anthropic, Amazon Bedrock, Google Vertex AI, Azure OpenAI) documents a way to download the weights your tuning run produced.
Open-weight models give you real portability, but not a blank check. Meta's license makes your derivative carry the Llama name and a "Built with Llama" notice forever.
55% of enterprise CIOs have already switched LLM providers at least once, and 40% say lock-in or pricing changes are hitting their AI budget hard. Plan the exit before the entrance.
The negotiation that matters happens before the first training job runs, not at renewal.

A client asked me last spring who owned the model we had just fine-tuned for them. Reasonable question. They had paid for the compute, supplied every row of the training data, and written the eval set. I gave them the honest version, which is that fine-tuned model ownership sounds like a legal question and is actually an engineering one. They owned the data. They owned the outputs. The thing in the middle, the artifact that made the whole project worth doing, lived on someone else's hardware and was never coming home.

That is not a scandal. It is the deal almost everyone signed without reading. But it is worth understanding before you spend a quarter of your budget producing an asset you cannot take with you.

Three engraved lockboxes on a workbench with the middle one sealed shut, representing training data, model weights and outputs as separate assets

What Fine-Tuned Model Ownership Actually Means

Fine-tuned model ownership splits into three separate assets that people constantly collapse into one: the training data, the resulting weights, and the outputs. You almost always own the first and third. The second is where the argument lives.

Legally, a fine-tune is not a new model. It is a modification of an existing set of weights. As the licensing analysis at WCR Legal puts it, "fine-tuning modifies the base model's weights, it does not create an independent model. The fine-tuned weights are, at minimum, a derivative work that remains bound by the base model's licence." Whatever the base license permits you to own is the ceiling on what you can own. Nothing you do downstream raises that ceiling.

Then there is the practical layer, which overrules the legal one in every case I have seen. Suppose a contract said in plain English that you own the fine-tuned weights outright. If the provider has no export mechanism, that sentence buys you a claim you can never exercise. You cannot serve the model elsewhere or hand it to a successor vendor. You have a title deed to a house with no doors.

This is the same trap I wrote about in vendor lock-in is just outsourcing with better branding, except worse, because a fine-tune is an asset you specifically built to be irreplaceable.

A row of five engraved vault doors with every handle on the far side of the wall, representing hosted fine-tuning across the major providers

Fine-Tuned Model Ownership, Provider by Provider

No major hosted provider currently documents a way to export the weights produced by their fine-tuning service. What differs is how each one describes the arrangement, and the language they pick tells you what they are actually promising.

OpenAI is clear about data and quiet about weights. Their enterprise privacy page states, "We do not train our models on your data by default. You own your inputs and outputs (where allowed by law)." Read that twice. Inputs and outputs. The fine-tuned artifact is neither. OpenAI's help documentation confirms that sharing fine-tuning data for their own training is off by default and opt-in, which is a genuinely good default. It just answers a different question than the one about ownership. In practice your fine-tune is a private instance hosted by OpenAI, reachable by model ID, and it goes away with your account.

Anthropic draws the same line, with an unusually sharp distinction between tiers. Their commercial terms state Anthropic may not train on customer content from the API, while consumer plans operate under an entirely different arrangement where chats can be used for model improvement if you allow it. If your team is doing serious work on personal Claude accounts, you have a governance problem that has nothing to do with fine-tuning. Custom models on the commercial side are provisioned as hosted endpoints. No weight download.

Amazon Bedrock produces the most quietly startling sentence in this entire category. AWS's own security guidance for Bedrock fine-tuning explains that "the fine-tuning process generates model artifacts, which are stored in the model provider AWS account and encrypted using the customer-provided KMS key." Your weights are not in your account. They are in the model provider's account, encrypted with your key. That is a thoughtful security design and it is also a precise statement of where the asset lives. Bedrock does offer Custom Model Import, which brings your own open-weight model in. The road runs one direction.

Google Vertex AI is the most transparent of the group about the mechanics. The Google Cloud Office of the CISO's AI trust paper describes parameter-efficient tuning as producing "additional learned parameters, called 'adapter weights' that are outside the foundation model," and states plainly that "the adapter weights are specific to the customer, and only available to the customer who tuned those." You can encrypt them with your own CMEK key and delete them whenever you like. Notice what that sentence grants and what it leaves out. Exclusivity and deletion, spelled out. Portability, never mentioned.

Azure OpenAI follows the same hosted-deployment pattern. Your tuned model is a deployment inside your Azure resource, subject to the region and residency controls you configure, and subject to Azure's idle-deployment policies. Useful controls. Not a copy of the weights.

The pattern across all five is consistent enough to be a rule. Providers will give you exclusivity, isolation, encryption under your own keys, deletion rights, and a promise not to train on your data. Those are meaningful commitments and I would not wave them away. What none of them gives you is the file.

An open engraved birdcage with the bird free but trailing a fine chain and a small maker mark tag, representing open weight license obligations

Open Weights Come With Strings Attached

Open-weight models are the only route to portable fine-tuned model ownership, and they still bind you: naming rules, attribution notices, and user-count thresholds. Tune one on infrastructure you control and the weights are genuinely yours to move. The license moves with them.

Meta's Llama Community License is the instructive case, because it is the most widely used and the most misunderstood. It requires that any model you train using Llama materials "include 'Llama' at the beginning of any such AI model name" if you distribute it. It requires you to prominently display "Built with Llama" on your product's website, interface, or documentation. It requires a Notice file with a specific attribution. And it contains the clause everyone quotes at parties: if your product exceeded 700 million monthly active users on the version's release date, you must request a separate license from Meta, which Meta may grant at its sole discretion.

For most organizations the user-count clause is theater. The naming and attribution obligations are not. If you were planning to fine-tune Llama and ship it as the proprietary heart of your product under your own brand name, the license says otherwise. Meta retains the base materials; you own your derivative, but your derivative wears Meta's badge.

Mistral is cleaner on this front. Several of their open models ship under Apache 2.0, which is a genuine permissive license with no naming obligation, though other Mistral releases sit under research or non-production licenses that are considerably more restrictive. Qwen's terms vary by model size and release. The lesson is not "open is better." The lesson is that "open weights" describes a distribution method, not a legal status, and you have to read the specific license attached to the specific checkpoint you are about to build a business on. I went deeper on this tradeoff in open-weight models grew up.

An engraved architectural blueprint with exit doors drawn in at the foundation stage, representing model ownership as an architecture decision

Ownership Is an Architecture Decision, Not a Legal One

You decide how much of your fine-tune you will own at the moment you choose a provider, and essentially never again. Everything after that is administration.

That is uncomfortable because provider selection usually happens early, when the project is a pilot and nobody is thinking about exit. It gets made on latency, price per token, and whichever platform your cloud contract already covers. Ownership is not on the scorecard. Eighteen months later the tuned model is running a workflow that matters and the switching cost is a rebuild.

The market has noticed. In a Dataiku and Harris Poll survey of 600 enterprise CIOs, 55% said they had already switched LLM providers at least once, mostly to cut cost, and 81% expected to run two or more providers in 2026. The same research found 40% of CIOs saying vendor lock-in or pricing changes were having a major or devastating impact on their AI budget, and 74% admitting regret over at least one AI vendor decision made in the previous 18 months. Those are not the numbers of a market that is settled.

Worth keeping in proportion: most organizations should not be fine-tuning at all. Menlo Ventures' 2025 state of generative AI in the enterprise found prompt design still dominant, retrieval second, and fine-tuning reserved for narrow high-value cases. If you are fine-tuning to teach a model facts, you probably wanted retrieval and a cleaner data layer instead, which is a cheaper problem with no ownership question attached. Fine-tuning earns its keep for behavior, format discipline, latency, and cost per call. Those are good reasons. "The outputs are wrong" usually is not.

The connection to sovereignty is direct, and it is the same distinction I drew in data residency is not sovereignty. Knowing which region your weights sit in is residency. Being able to pick them up and leave is sovereignty. Most fine-tuning contracts sell the first and let you assume the second.

An engraved clockwork contract press stamping five seals onto a single scroll before a furnace is lit, representing terms to negotiate before training

What to Negotiate Before You Train Anything

Negotiate five things before the first training job runs: weight export, termination handling, output ownership, base-model deprecation notice, and dual-run rights. Your leverage disappears the moment the tuned model becomes load-bearing.

Can we export the weights or adapters, in any format, under any circumstances? Ask for a yes or no in writing. A vague answer is a no. If the answer is no, that is often fine, but now you are choosing it rather than discovering it.

What happens to the tuned model at termination? Get the deprovisioning and deletion timeline in the contract. Get confirmation that your training data and the artifacts derived from it are destroyed on a defined schedule, not "in accordance with our policies."

Who owns the outputs? Most enterprise terms already grant this. Get it in writing anyway, along with confirmation that your content is excluded from the provider's training by default rather than by request.

What is the deprecation notice period for the base model? This is the one people forget. Your fine-tune is bound to a base checkpoint. When the provider retires it, your tuned model retires with it, and you re-run the whole project against a new base. Contract benchmarks routinely list 180 days of deprecation notice as a negotiable term. Ask for it.

Can we run a parallel evaluation on a second provider? Dual-run rights during the term are the cheapest insurance available, because they keep a fallback warm instead of hypothetical.

None of this requires you to avoid hosted fine-tuning. I use hosted services constantly and recommend them often. It requires you to price the arrangement honestly: you are renting a capability, not building an asset, and the budget line should say so. If the business case only works when the tuned model is treated as owned intellectual property on the balance sheet, the business case is wrong and better to know now.

The clients who handle this well are not the ones with the most aggressive lawyers. They are the ones who decided, deliberately and early, which parts of their stack they were willing to rent and which parts they needed to own, and then chose infrastructure that matched the answer. That decision costs nothing at the start of a project. It costs a rebuild in the middle of one.

If you want a clear read on which parts of your AI stack are rented and which are actually yours, book a system review diagnostic and we will map it together.

Wide engraved frieze of chained vault doors receding to a vanishing point, a section break for the fine-tuned model ownership FAQ

Frequently Asked Questions

Do You Own a Fine-Tuned AI Model?

Usually you own the training data and the outputs, and you get exclusive use of the result. On hosted APIs you rarely own or receive the weights themselves. Vendor ownership language typically covers inputs and outputs, and the tuned artifact sits outside that promise.

Who Owns the IP of a Fine-Tuned Model?

Split ownership is the norm. The provider owns the base model, you own your training data and generally your outputs, and the fine-tuned weights are a derivative work bound by the base model's license or hosting agreement.

Can You Take a Fine-Tuned Model to Another Provider?

Not on OpenAI, Anthropic, Vertex AI, Bedrock, or Azure OpenAI. None of them documents an export path for weights their fine-tuning service produced. Portability exists only when you fine-tune an open-weight model on infrastructure you control.

Does Fine-Tuning on My Data Mean the Provider Can Train on It?

On enterprise and API tiers, no by default. OpenAI, Anthropic's commercial terms, and Vertex AI all state that customer content is not used to train their base models. Consumer tiers operate under different terms, which is a good reason to keep company work off personal accounts.

Is a Fine-Tuned Model a Derivative Work?

In most readings, yes. The tuned weights are a modification of the base weights, so the base license's obligations travel with your derivative, including naming and attribution requirements like the Llama license's "Built with Llama" clause.

What Happens to My Fine-Tuned Model If I Stop Paying?

On hosted services the model is deprovisioned with your account. You keep the training data you supplied. You do not receive a copy of the weights on the way out, which is exactly why the export question belongs in the contract rather than the exit interview.

References

Back to Blog