Who Owns a Customer-Specific Fine-Tuned Model and Its Training Data?

Most AI service agreements promise that the vendor will not use customer data to train or improve any model. Converra's standard terms say exactly that, and define customer data broadly enough to include traces, prompts, transcripts, simulation outputs, and evaluation results. That promise is what customers rely on when they connect production traffic. A fine-tuning offer that touches customer data is an exception to it, and the exception has to be explicit.

The right shape is a written election: the customer opts in, in a signed order or amendment, to a fine-tuning engagement for named agents, with the model artifact and dataset scoped to that customer alone. Silence is not consent, a product setting is not consent, and a general clause permitting service improvement is not consent. Absent the election, the default holds and no training happens.

An adapter trained on one customer's conversations encodes that customer's rules, vocabulary, and sometimes their users' phrasing. It must never serve another tenant, and the examples must never enter another tenant's dataset, a shared base, or a vendor-owned model. This is a property to enforce mechanically, not a policy to remember: artifacts carry a tenant identifier, the serving layer refuses a mismatch, and the dataset build refuses cross-tenant lineage.

The vendor keeps what is genuinely its own: the pipeline, the review workflow, the gate contract, the evaluation methods, and any synthetic data it generated without customer inputs. The line is the source of the bytes. Anything derived from a customer's runs stays on the customer's side of it.

Saying the customer owns the model is not enough, because a fine-tune produces several artifacts and they live in different places. There are the adapter weights, or the merged full weights if the adapter was folded in. There is the dataset version, with its examples and their lineage. There are the gate results, the training receipts, and the evaluation outputs. Each has an owner, a storage location, and an export path, or it has none and the ownership claim is hollow.

The practical test is portability. Can the customer take the adapter and run it on a different provider tomorrow? Can they take the dataset and retrain elsewhere? If a provider hosts the training and holds the weights, the contract with that provider has to grant export, and the customer needs to know that before they sign the election.

When the engagement ends, the customer gets their export and the vendor deletes what it holds. The hard part is the third party. If training ran on a hosted provider, the dataset was uploaded there and the adapter was created there. Deletion has to be requested on that provider too, confirmed, and recorded. A vendor that deletes its own copy and leaves the provider's copy in place has not deleted anything from the customer's point of view.

Set the timeline before the engagement starts, and make deletion a receipt rather than a promise: a dated record of which artifacts were removed from which systems. The same applies to temporary evaluation endpoints, which hold the weights while they run and should be verified gone after each use, not assumed gone.

Training data comes from production runs, and production runs involve end users whose data the customer holds under its own agreements. If a user withdraws consent, a data subject request lands, or a downstream customer of the customer leaves, some examples may lose their basis. A dataset with per-example lineage can find and remove them. A model trained on them cannot unlearn them.

Decide in advance what a rights lapse does to the artifact. The defensible rule is that the affected examples are removed from the dataset, the dataset gets a new version, and the current model is marked as trained on data that is no longer fully licensed. Whether that invalidates the model for serving is a decision for the customer and their counsel, but it has to be a decision someone is positioned to make, which requires the lineage to exist. Part 12 covers how to keep it.

Hosted fine-tuning providers have their own terms about what they retain, where it lives, which subprocessors touch it, and what you may upload. Those terms change, and they apply to the customer's data the moment it is uploaded. A zero-retention promise for inference does not automatically extend to training data, and some providers place restrictions on the content of training inputs that a distillation dataset may or may not meet.

Re-read the provider's current terms for each engagement and record the version you reviewed. If the customer's data cannot leave their own cloud account, the engagement needs a training path inside that account, which is a different product with different costs. Part 42 goes into how provider terms shape what can be distilled at all.

A LoRA adapter is meaningless without its base, and the base has a license. Qwen3's dense models are released under Apache 2.0, which permits commercial use and redistribution with attribution and notice preservation, and imposes no naming rule on derivatives. The Llama 4 Community License permits use but requires that a model built from the materials carry Llama at the beginning of its name and display Built with Llama where the model is offered. Those obligations attach to the customer's artifact, not just to the vendor's pipeline.

Ownership language has to acknowledge this. The customer owns their adapter, and their adapter is subject to the base license. Pick the base with the license obligations in view, record the license version in the dataset and model manifest, and make sure the customer knows which obligations they inherited before the election is signed.

A vendor that builds this well has real intellectual property, and none of it is the customer's weights. It is the review workflow, the admission rules, the gate contract, the sizing method, the production verification machinery, and the operational method that turns a customer's reviewed evidence into a candidate and a verdict. Synthetic data the vendor authored from its own fixtures is its own. Aggregate, non-identifying operational metrics about the pipeline may be, depending on the agreement.

What the vendor may not keep is anything that lets it reconstruct the customer's data or reuse the customer's behavior. If a lesson from one engagement improves the method, the method improves. The examples that taught it stay where they came from.

Converra's standard terms state that customer data is not used to train, fine-tune, or improve any model, including models used to serve other customers, and its trust page describes that boundary. A customer-specific fine-tuning engagement is therefore possible only under a written, tenant-exclusive election, and the resulting adapter and dataset belong to the customer. Converra's fine-tuning workflow keeps per-example lineage in versioned datasets and records training jobs and gate results against those versions; the training itself runs on the customer's chosen provider or infrastructure, not on Converra.

Exact export formats, provider-side deletion procedures, and the handling of a rights lapse are engagement terms to be written down with the election rather than product defaults to assume. No customer fine-tuned model has been produced yet, so every one of these is a position to agree in advance rather than a practice to point at.