Where Your Data Goes

Retention, training use, and who answers for it differ across the three ways you can reach a model. This is procurement, not settings.

Where your data goes depends on how you reach the model. A personal interface, a per-call developer API, and an organizational agreement each say something different about retention, whether your content may be used for training, and who is accountable. This is a procurement decision, not a settings decision — what you can switch off in a settings panel is not the same as what a contract commits to.

After reading, you should be able to answer:

• Why does the assumption that one vendor has one policy get you into trouble?
• Which sentence do you actually need from a vendor, and why is "we take security seriously" not an answer?
• Which part of this is entirely yours to decide, before anything is sent?

One vendor, three tiers, three sets of promises

Consumer products. A personal interface, and usually the loosest terms: content may be used to improve the model, and human reviewers may see some of it. It is the most convenient, and the worst place for a customer list, a contract clause, or unpublished financials.

Developer APIs. You pay per call and build your own feature. The common wording here is "not used for training by default" — but "by default" is not a promise. A default implies a switch or a request path. Retention, encryption in transit, and whether a region can be fixed all vary by vendor and have to be read line by line. openai-data

Enterprise agreements. The organizational tier, where no retention, no training, and data residency can be written as terms, and the responsible party shifts from an individual to the contracting organization. It costs the most, and it is the only tier where these become a contract. anthropic-commercial Vendors generally state consumer and commercial services separately, which is what lets you check which side you are on. anthropic-privacy

The common mistake is extrapolating from one tier to the others. The same vendor can make very different commitments across all three. Whichever tier a given sentence lands in, that tier's terms are the ones that apply to it.

Did you get a commitment, or a default?

"We do not train on your data" and "your data is not used for training by default" read almost the same. They weigh very differently.

A default is a setting; a commitment is an agreement. A default means a switch exists, or a request path, or a state that continues unless you act; it also means the vendor can change it by publishing a new version rather than renegotiating with you. A commitment means it is written into a document that has a named party and a term, and changing it carries the cost of breach.

The moves differ accordingly. Faced with a default, find where the switch lives and whether the default still stands in the current version. Faced with a commitment, confirm which document it sits in, which service it covers, and how long it holds.

There is a time dimension too: terms get updated. The version you confirmed when you signed may no longer be the version in force a year later, while your own reasoning still rests on the old one. So review cannot be a one-off; treat it like a dependency upgrade and put it in your maintenance routine.

Four questions, and the fourth is the one usually skipped

For your own situation, replace "are you secure?" with four concrete questions.

The first three are technical terms. The fourth decides who carries it when something breaks — without it, the other three are good intentions.

The test is simple: did you get a sentence on paper, or a reassuring manner? The first has a subject, a scope, and a term. The second changes with the salesperson.

Exactly one part is fully yours

Everything above depends on what the other side writes down. This depends on what you send.

• Send only the stretch the task needs. Routing a support ticket needs the fault description and the error code, not the whole thread.
• Drop identifiers that are not required. Internal staff numbers, customer IDs, device serials: strip the fields before the request is built, not after.
• Do not make the model carry raw data. Let the system pass exact fields and keep the model to judgement — Don't Let the Model Haul Data covers the full practice.
• Narrow whatever can be narrowed. Restrict which sources it may use and which time range it may cover; that is both an accuracy move and an exposure move.

Minimisation does not fix the terms. It shrinks the "what if" — the less you send, the less you lose when a term turns out to say something you missed.

The red line is before the send, and the responsibility is yours

One boundary deserves its own place: once data enters a third party's training pipeline, it is effectively impossible to withdraw. Files can be deleted; what the weights picked up cannot. So "fix it afterwards" is not a real path, and the decision has to happen before the send.

If you are the one building the AI product, two obligations sit on that same line and nobody can carry them for you. First, write down what users need to know — whether content trains the model, how long it is kept, how it is deleted — in sentences they can read, in your own policy. Second, do not decide on their behalf — choosing a channel that feeds content into a third party's training is answering that question for every user, and they never agreed to it.

Which pushes the conclusion back onto you: the right question is a procurement question. Which tier you use, which sentences go into the contract, which fields never leave — all three are inside your authority, and none of them can be repaired after the fact.

Which work should leave the building and which should not is the other side of the same judgement: The Human Boundary draws that line, and once an answer comes back, Verifying Answers is the procedure you can follow.

That covers trusting and not trusting: why it invents, how to verify, and where the line between instructions and data sits. One thing remains that the earlier chapters never opened up — what this machine actually is, and why it is powerful and unreliable at once. The starting point is guessing the next token.