“We do not train on your data” and “we do not keep your data” are different sentences with different consequences, and most products make only the first. Knowing which one you have been given is most of what privacy literacy consists of here.
Two different promises
Promise Description no training Your input is not used to improve the model. It says nothing about whether the text is stored, for how long, who can read it, whether it is used to enforce policy, or whether it appears in support tooling and backups. no retention The text is not stored after the request is served, or is stored only for a stated short window. This is a stronger and rarer promise, it is usually a paid or enterprise option, and it typically comes with named exceptions such as abuse review. human review A third, separate question that neither of the above answers. Many services allow staff or contractors to read a sample of conversations for safety or quality purposes. This is usually disclosed and rarely read.The distinction is not pedantry. If your concern is that a phrase from your document might one day surface in somebody else’s answer, the training promise addresses it. If your concern is a data breach, a legal disclosure order, or a support engineer opening your conversation to debug a fault, only the retention promise touches it, and the training promise is irrelevant. The detail behind both is in what zero data retention actually means and how to read the clause that answers the training question.
What a setting cannot undo
Every control in a product is prospective. This is the part that is consistently misunderstood and it is worth stating flatly.
- Turning off training does not withdraw what was already used. If your conversations from last year were eligible for training under the terms in force then, a setting changed today applies to tomorrow. Model weights are not editable in that way, and no vendor offers to retrain because one user changed a preference.
- Deleting a conversation is not deleting the data. It removes it from your view. Retention periods, backups, and copies held for legal or safety reasons run on their own schedule, which the privacy policy states and which is typically measured in days to months.
- Nothing recalls what a third party received. If the product routes to a model provider, that provider received the text. Your settings with the interface you used do not bind them; their own terms do.
- A closed account does not unsay anything. Deletion rights under data protection law are real and worth using, and they are also subject to exceptions where a company has another lawful basis to keep something. The unresolved tension between erasure rights and trained models is covered in the right to erasure versus a trained model.
The practical consequence: the decision that matters is made before you press send, not afterwards in a settings panel. Everything downstream is damage limitation.
Four questions that work on any product
Product interfaces change constantly; these questions do not, and their answers are in the privacy policy and terms rather than the marketing pages. Search the policy for the words in brackets.
- Is my input used to train or improve models? Search for
train,improveandmachine learning. Note whether the answer differs between the free tier, the paid consumer tier and the business tier — under a single brand these commonly differ, and the difference is usually the point of the business tier. - How long is it kept, and where? Search for
retention,retainanddelete. A stated number of days is a real answer; “as long as necessary” is not one. - Who can read it? Search for
human review,sub-processorandservice provider. The sub-processor list tells you which other companies receive your text, and it is usually a separate page. - What happens if I opt out? Some products link history features to training consent, so opting out disables saved conversations. Knowing the trade before you make it prevents the common outcome, which is turning it back on a week later.
One thing worth knowing if you or a colleague ever moves from a chat product to calling models programmatically: the terms that apply are the ones belonging to whoever ultimately serves the request, and routing through a gateway does not change them. What it does change is that which provider handles a given request becomes a routing choice, so switching to one whose retention terms you prefer is a configuration change rather than a migration.
The practical routine
Most of the risk is removed by habits rather than settings, and the habits are cheap.
- Redact before pasting, not after. Replace names with
PERSON_A, companies withCOMPANY_A, and remove account numbers, addresses, dates of birth and reference numbers. The answer maps back trivially and the material never leaves in identifiable form. - Keep two mental buckets. Things that would be survivable in a leak, and things that would not. Nothing from the second bucket goes into a general-purpose chat product, whatever the settings say.
- Assume anything you paste could be read by a person. Not because it is likely, but because it is a cheap assumption that produces correct behaviour in every case.
- Do not paste other people’s data casually. A colleague’s medical note, a client’s file, a child’s school report. Your decision, their data, and in many contexts a legal duty attaches to it.
Work accounts are not your accounts
If your employer provides the tool, your employer generally has administrative access to what you put in it: conversation logs are usually available to administrators in business tiers, in the same way email is. That is not a scandal, it is what a business account is, but people routinely paste personal material into a work tool having assumed otherwise.
The reverse also holds and matters more: putting work material into your personal account moves company data outside its controls, which is a policy breach in most organisations even where nothing bad happens. If your organisation has not written the rule, somebody should — what a usable AI policy contains is a reasonable starting point, and the contractual layer for vendors is in data processing agreements for AI vendors.
Deletion, export and what they mean
If you are in the UK, the EU or another jurisdiction with comparable rights, you can request a copy of what a service holds about you and ask for it to be deleted. These are worth exercising, and it is worth being realistic about what comes back.
An export typically returns your conversations, your account metadata and your settings. It does not return derived data, internal classifications, or anything the company considers its own record of the interaction rather than your personal data. A deletion request removes what is identifiable to you within the exceptions the law allows, which include material a company must keep for legal, security or fraud-prevention reasons. Both are prospective. Neither reaches anything already incorporated into a trained model. The general compliance picture, from the other side of the relationship, is in GDPR and AI APIs.
Products change their settings, their defaults and their tiers frequently, and a page listing today’s toggles would be wrong within months. That is why this page teaches the questions rather than the menus. Re-read the policy of anything you use heavily about once a year, and specifically after any acquisition or change of ownership, which is when terms most often change materially.
답글 남기기