Governance · 7 min read · Aug 12, 2026
Who sees it, and who keeps it.
This is the question that stalls more AI projects than cost, and it is usually asked too late and answered too vaguely. Here is what actually happens to a request, which parts are contractual rather than technical, and the specific questions that produce an answer you can act on.
Follow one request
A single call travels further than most people picture. Your application sends a prompt — which may include retrieved documents, customer records or a system instruction — to a provider endpoint. It is processed on the provider's infrastructure, which is frequently a hyperscaler's, in a region that may or may not be the one you assumed. A response comes back. Somewhere in that path, the request may be logged.
Every meaningful question about data protection sits in that last sentence. Not whether the request happened, but what persisted afterwards and who could read it.
The four things that actually matter
Strip away the marketing and there are four properties. They are independent of each other, and a reassuring answer on one tells you nothing about the other three.
| Property | The real question | Where the answer lives |
|---|---|---|
| Training | Is my data used to improve their models? | Contract / tier |
| Retention | How long is it stored, and can that be zero? | Contract / config |
| Residency | Which country is it processed and stored in? | Region setting |
| Access | Which humans can read it, and under what process? | Policy / audit |
Note the third column. Almost none of this is a property of the model — it is a property of the agreement and the configuration. The same model, from the same provider, can have entirely different answers depending on which tier you bought and which region you deployed in.
Consumer terms and business terms are not the same product
This is the single most common source of confusion inside organisations, and it usually surfaces as a policy argument based on a headline about the consumer product.
Consumer chat products and paid API or enterprise tiers generally operate under different terms, frequently with different defaults on training and retention. An employee pasting a client contract into a personal account and an application calling a business API under a signed agreement are two genuinely different risk events. Treating them as the same thing produces a policy that blocks the safe path and does nothing about the unsafe one.
The realistic leak in most organisations is not the API you procured. It is the browser tab someone opened because the procured tool was too slow to arrive.
Zero retention is a real setting, and it has consequences
Several providers offer configurations where request and response content is not persisted. Where available this is the strongest technical answer to the retention question, and for regulated work it is often what makes a deployment approvable at all.
It is worth knowing what you give up. Without retained logs, some abuse-monitoring features and provider-side debugging become unavailable, and you cannot ask the provider to help reconstruct what happened during an incident. That is usually the right trade, but make it deliberately — teams that enable it without noticing find out during their first production incident.
Residency is not solved by picking a region
Selecting a region controls where inference runs. It does not automatically tell you where logs go, where abuse-monitoring data goes, where the support team sits, or which sub-processors are involved. Those are separate answers and they are frequently different.
If a regulator or a client contract constrains you to a jurisdiction, region selection is the beginning of the answer, not the whole of it. Ask about each path independently.
The questions that get a straight answer
Vague questions get vague answers. These do not, and every one of them should be answerable in writing before anything sensitive is sent:
- Is our content used to train or improve your models under our current tier? Point me at the clause.
- What is the retention period for prompts and responses, and can it be set to zero on our account?
- In which region is inference performed, and in which regions is any logged content stored?
- Who are your sub-processors, and how are we notified when that list changes?
- Under what circumstances does a human at your company read our content, and is it logged?
- What happens to our data if we terminate — what is deleted, and on what timeline?
A provider selling to businesses will answer all six in writing. If any answer is a reassurance rather than a clause, treat that as the finding — it is the same signal as a vendor who will not quote running cost before signature.
What you control on your side
Provider terms are one half. The other half is what you chose to send, and it is the half you can change without a negotiation.
Most systems send far more than the task requires, because it was easier to pass the whole record than to select fields. Redacting or tokenising identifiers before they leave your boundary, sending the minimum context that answers the question, and keeping a log on your side of what was sent — not just what came back — cost little and change your exposure materially. The strongest position is not a provider promise about data they hold. It is not having sent it.
Dealing with this in your own group?
We answer scoping questions before there's a contract in sight — including the ones about cost and data handling.