What a Provider's Terms Say About Using Your Prompts and Outputs to Train

“Do they train on my data?” is four separate questions wearing one coat, and a provider can answer no to the one you asked while the answer to the one you meant is yes.

Four clauses that get conflated

When people ask whether a provider trains on their data they are usually worried about a competitor benefiting from their prompts. That concern is spread across four independent clauses, and an agreement can be restrictive on one and permissive on the rest:

• Model improvement / training use. Whether submitted content and generated content may be used to train or fine-tune models. Look for the words train, improve our services, develop and machine learning. The phrase “improve our services” is the one to slow down over: it is broader than training and is sometimes the only hook that permits it.
• Retention. How long the content is stored at all, and by whom. A no-training commitment paired with a thirty-day retention still means your prompts exist on someone else’s disk for thirty days.
• Human review. Whether staff or contractors may read submitted content, typically justified by abuse detection or quality monitoring. This is frequently carved out of a no-training commitment as a separate permission, and it is the clause most often missed.
• Output rights. What licence, if any, the provider retains in the text the model generated for you, and what you are permitted to do with it — including whether you may use it to train a model of your own.

Grep your own agreement the way you would grep a codebase. Searching the PDF text for train, improve, derivative, aggregate, de-identified, retain, monitor and review finds these four clauses faster than reading front to back, and the words that appear near them are the qualifiers that do the work.

Defaults, tiers and where the setting lives

The commercially important pattern is that training use is commonly a default that differs by product surface. The same company’s consumer chat product, developer API and enterprise agreement can each have a different answer, and the terms that apply to you are the ones attached to the contracting entity and plan on your invoice — not the ones on the marketing page you read.

Three consequences for a migration:

• An opt-out that exists as a dashboard toggle is a setting, and settings are per account, per project or per key. Confirm which, and confirm that a new project created during the migration inherits it rather than starting at the default.
• An opt-out expressed only in a signed agreement does not travel to a second account you spin up for load testing. Test traffic containing real customer data has, more than once, been the leak that the production controls were designed to prevent.
• Terms can be amended on notice. Ask what the notice period for a material change is and whether it gives you a termination right — that pair is what turns a policy into something you can rely on for the length of a contract.

Retention is not training, and both matter

A zero-data-retention arrangement is the strongest common form: content is processed in memory to serve the request and not persisted at all. It is usually narrower than it sounds and worth pinning down on three axes — which endpoints it covers, whether it survives an error path where a request is logged for debugging, and whether it applies to the abuse-monitoring pipeline or is carved out of it.

The carve-out is the norm rather than the exception, because a provider that cannot retain anything cannot investigate misuse. A common settlement is a short retention purely for that purpose with access restricted to a named function. Whether that is acceptable is your risk decision; not knowing it exists is not.

Note also what “de-identified” and “aggregated” are doing when they appear. A clause forbidding training on your content but permitting use of de-identified or aggregated derivatives permits more than the first half suggests, and prompts are not reliably de-identifiable — a support ticket pasted into a prompt carries its identifiers in prose.

Who owns the output

Two distinct questions sit here. The first is what the provider grants you: most commercial API terms assign or licence the output to the customer broadly enough for ordinary commercial use, but the assignment is usually conditional on your compliance with the agreement, which means a termination for breach can unsettle it.

The second is what the provider retains, and this is the one relevant to the competitive worry. Look for a licence back — a clause under which the provider keeps a right to use inputs and outputs. Look separately for a restriction running the other way: a term forbidding you from using outputs to develop a competing model. That restriction is common, and it is the clause that decides whether a distillation or synthetic-data strategy is available to you at all. If your migration plan includes generating training data from a provider’s model, this clause is the plan’s gating dependency and should be read before any engineering starts.

A third-party angle is worth checking too: whether the provider serves your requests through a sub-processor whose own terms apply. A hosted open-weight model served through an intermediary can carry the model licence’s conditions in addition to the platform’s terms, and those can include use restrictions that the platform’s own contract does not mention.

Questions to put in writing

Ask these of the migration target and get the answers by email, from someone who can bind the company. The written answers are what you attach to the risk decision; a support-chat screenshot is not.

1. Under our plan and contracting entity, are inputs or outputs used to train, fine-tune or evaluate any model? If there is an exception, what is it and where is it documented?
2. What is the default retention period for request and response content, what is the shortest available to us, and is a zero-retention option available at our volume?
3. Under what circumstances may a human read our content, who, and is that access logged in a way we can be shown?
4. Does any clause restrict our use of outputs — specifically, may we use outputs to train or evaluate our own models?
5. Which sub-processors touch content, in which countries, and how are we notified when that list changes? This overlaps with the residency audit and should be asked once, jointly.
6. What notice do we get of a material change to these terms, and does it carry a termination right?

Record the answers next to the model registry entry for the provider, not in a document nobody opens. The point of doing this before the cutover rather than after is that the answers can still change the decision; afterwards, they only change how uncomfortable it is. What the resulting obligations look like in the contract itself is covered in what changes about a data processing agreement during a migration.