The “do not train on my data” setting answers exactly one question: whether your content may be
used to improve future models under the provider’s policy. It is not a confidentiality control, and most
people using it believe it is. It does not tell you where the data is processed, how long it is
retained, who can reach it under legal process, whether your NDA permitted the disclosure in the first
place, or whether your organisation can audit any of it.
One switch. One question. Everything else about the risk is unchanged.
The four things it does not do
It does not stop the data leaving your network. The content still travels to a third
party and is processed on their infrastructure, in whichever territory their architecture puts it.
It does not set retention. Training use and storage duration are separate policies.
Turning one off says nothing about the other.
It does not change who you are contracting with. A consumer account has no
organisation-level contract, no policy enforcement, no central audit and no processor commitments you can
point a client at.
And it does not survive legal process. This is the one that turns an abstract
governance point into a concrete one.
The legal hold example, stated precisely
In 2025, litigation brought by the New York Times and other publishers led to a US court order
requiring OpenAI to preserve categories of consumer and API content that would otherwise have been
deleted. OpenAI states that the broad ongoing preservation obligation ended on 26 September 2025 and that
ordinary deletion resumed for new data, while a limited historical set remained preserved. Separately, in
December 2025 OpenAI said it was required to make a de-identified sample of 20 million consumer
conversations available under strict controls in that litigation.
The wrong lesson is “every deleted chat is stored forever”. That is not true, and repeating it damages
your credibility with the people you are trying to persuade.
The right lesson is narrower and more useful: a provider’s ordinary deletion policy can be
overridden by a valid legal preservation or disclosure order — in a case your organisation is not
party to, and with no notice to you. Consumer privacy settings are not immunity from legal process. If
your confidentiality obligation to a client depends on the assumption that you can delete something, that
assumption needs to survive a court order it will never hear about.
Classify by where data is processed, not by which model
The framework we use with clients has three tiers, and the axis is deliberately not model quality:
- Tier 1 — consumer. Individual accounts and free services. Public and non-sensitive
material only, because there is no organisation-level contract, policy enforcement or central audit. - Tier 2 — business or enterprise. Approved enterprise products and contracted APIs.
Internal data subject to your classification and the contract, because terms, identity, retention
controls, audit and processor commitments can all be reviewed. - Tier 3 — controlled local or sovereign. Models and services inside infrastructure you
control. Potentially your most sensitive classes, because inference data can remain inside the chosen
security boundary.
It is a policy framework, not a claim that every product within a tier is equivalent. A particular
enterprise service can still be inappropriate because of jurisdiction, subprocessors, retention or
contractual restrictions. The data chapter of our 2026 guide sets out the six
questions to ask a provider before approving one.
Give reasons, not just a list
Most “never enter this” lists fail because they are lists. People comply with a list in the cases it
names and improvise everywhere else. Attach the reason and they generalise correctly:
- Trade secrets, proprietary designs, unpublished R&D, source code — trade secret
protection depends on controlled disclosure. - Material received under an NDA — sending it to another processor may breach the
agreement even if no human ever reads it. - Personal data — lawful basis, processor terms, transfers, retention and access
controls all have to be understood first. - Board material, forecasts, M&A, unpublished financials — commercial sensitivity
and, in some contexts, market abuse obligations. - Export-controlled technical material — where processing happens can itself create the
compliance problem.
Then give staff the sentence they will actually remember: if you would not email it to a
competitor, do not paste it into an unapproved AI tool. Deliberately conservative, and it stops
people at the right moment.
The trap on the other side of the fence
Buying enterprise licences does not close this out, because it introduces a different problem.
An enterprise assistant honours the permissions of SharePoint, Drive or your CRM — and in doing so exposes
oversharing that already existed. The salary spreadsheet in an over-permissioned folder was technically
accessible yesterday; nobody knew where to look. Semantic search makes it trivial to find today.
The AI did not create the access right. It removed the friction that had been hiding the mistake. Audit
oversharing before enabling broad enterprise search, apply source permissions during retrieval
rather than after generation, and consider excluding HR, legal and corporate development from general
indexing.
One last thing worth saying to the person writing the policy: prohibition without a usable alternative
pushes activity outside your visibility. People reach for personal accounts when the sanctioned route is
absent, slow or materially worse. Find out what is already in use without turning it into a disciplinary
exercise, provide something that does the real job, and then enforce the boundary. The full framework is
in Understanding AI in 2026.