你的 AI 提供商是否用你的数据训练？四个问题分清楚

"他们会训练我的数据吗？"这个问题问出来的时候，好像答案只有是或否。但实际上它既不是是也不是否，因为它把四个独立的问题压缩成了一个——关于你的文本的四个独立副本，每个副本受不同文件的不同条款约束。

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.

One structural point worth internalising before you route anything through anybody: a gateway is an additional processor in the chain, not a way around one. Multigrid publishes its own sub-processor list, including the inference providers a prompt can be forwarded to, precisely so the row above can be filled in without asking. Every gateway should be able to give you that list; if one cannot, the question above has no answer.

Zero Data Retention: What It Actually Means

DPAs and Sub-Processors for AI Vendors

Terms of Service Traps in AI APIs