Does Your AI Provider Train on Your Data?

“Do they train on my data?” is asked as though it has a yes or a no. It has neither, because it compresses four separate questions about four separate copies of your text, each governed by a different paragraph of a different document.

This page is engineering guidance for finding the answer in your own contracts. It is not legal advice: a lawyer reads the contract, and what follows is how to work out which contract to hand them.

It is four questions, not one

Separate them before you go looking, because a vendor can answer “no” to one and “yes” to another entirely honestly, and a procurement thread that has not separated them will run for a fortnight without anybody being wrong.

• Is the content used to train or improve a model? The question everyone means. Note that “improve our services” is broader than “train a model” and is the phrasing more often used.
• Is it retained at all, and for how long? A provider can decline to train on your data and still keep it for thirty days for abuse investigation. That retention is a separate risk with a separate answer.
• Can a human read it? Abuse review, safety classification and support debugging are three different paths by which a person ends up looking at a prompt. Each is usually governed by its own sentence.
• Who else receives it? The provider you contract with is not necessarily the party running the model. Sub-processing is where most of the surprise lives.

The contract stack, in precedence order

The answer is rarely on the page you found by searching. Vendors publish a marketing page about privacy, a set of consumer-facing terms, an API-specific policy, a data processing agreement and, separately, whatever was negotiated into an enterprise order form. These frequently disagree, and the disagreement is not usually dishonest — they were written at different times for different products.

Read them in that order and stop at the first one that speaks to your specific question. If the DPA says thirty days and a blog post says zero, the DPA is what you are entitled to enforce.

The four clauses that decide it

You are looking for four clause types. They are rarely labelled and are rarely adjacent, so search the text rather than skimming headings.

• Purpose limitation. Find the sentence that lists what the vendor may do with customer content. The word to hunt for is the qualifier: “to provide the service” is narrow, “to provide and improve the service” is not, and the difference between those two phrases is the whole question.
• Retention. Look for a period, in days, and for what resets it. Also look for the exception — retention limits routinely carve out legal hold, abuse investigation and backup expiry, and a backup carve-out with no stated window is effectively unbounded.
• Human access. Search for “review”, “monitor” and “personnel”. A commitment not to train is compatible with a commitment to have staff read flagged content, and if you are sending regulated data the second one may matter more than the first.
• Sub-processors. Find the list, find how changes are notified, and find whether you may object. If there is no list there is no answer to this question, whatever else the document says.

Why the default differs by surface

The same company can hold genuinely different defaults across its own products, which is why an answer copied from a forum is worthless. The axes that usually move the default:

• Consumer app versus paid API. These are commonly governed by different terms with different defaults, and people answer for one while using the other.
• Free tier versus paid. A free or evaluation tier is sometimes priced by what it is allowed to do with the traffic.
• Explicit feedback. Thumbs-up buttons, bug reports and shared conversation links are frequently opt-ins to broader use, carved out of whatever the general commitment is. If your product exposes a feedback control, you have built the carve-out into your own UI.
• Uploaded training data. Fine-tuning files, evaluation sets and RAG corpora sometimes sit under separate terms from inference traffic, because the vendor is storing them rather than passing them through.

Write the answer down where it is auditable

Whatever you find, the finding needs to survive the person who found it. One row per vendor per surface, in the repository rather than in a document nobody opens:

vendor:            <name>
surface:           api | console | fine-tuning | consumer
governing_doc:     <url or contract reference>
doc_version_seen:  <date you read it>
trains_on_content: yes | no | opt-out available
retention_days:    <number> | unspecified
retention_carveouts: [abuse-review, legal-hold, backups]
human_review:      yes | no | on-flag-only
subprocessor_list: <url> | none published
change_notice:     <days> | none
reviewed_by:       <person>  reviewed_on: <date>

The two fields people leave out are the ones that make the row worth keeping. doc_version_seen turns a stale answer into a visibly stale answer, and retention_carveouts is where the honest “zero retention” claims quietly stop being zero. Re-read the row on a schedule, because none of these documents notify you when they change.