Enterprise AI data privacy

The short answer

On enterprise API tiers from the major providers, prompts are not used to train models by default, and that commitment is contractual rather than a promise in a blog post. Get it in writing and check the tier you are actually on.

But that is the smaller half of the question. The larger exposure is usually not the provider. It is your own architecture: what you send, what you log, who can read the logs, and how long they live.

The question behind the question

When a security team asks whether the data trains the model, what they usually mean is broader: where does our data physically go, who can read it, how long is it kept, and what happens to it if we leave.

Answer all four explicitly. Answering only the training question and treating the review as passed is how a project gets blocked two weeks before launch by something nobody had written down.

What actually happens to a prompt

It travels to the provider, is processed, and a response comes back. Depending on the tier and configuration it may be retained briefly for abuse monitoring, and that retention window is a specific documented number you can ask for.

Zero retention configurations exist on enterprise agreements for exactly this reason. If your data class requires it, ask for it explicitly rather than assuming your default tier includes it.

Your own logs are the bigger risk

To debug a production AI system you log prompts, retrieved context and outputs. That means your log store now holds customer data, assembled and concentrated, often in a system with looser access control than the database it came from.

This is the exposure nobody puts in the security questionnaire and it is the one most likely to cause an incident. Set retention, redact at write time, scope access, and treat the log store as production data. It is the uncomfortable half of observability.

Retrieval is where permissions leak

A system that retrieves broadly and filters afterwards will eventually show someone something they should not see, because the filter is a probabilistic step in a system with a non deterministic component.

Carry the requesting user's permissions into the retrieval query itself, so out of scope material is never a candidate. This is an architectural requirement rather than a policy one, and it is the point made in RAG and enforced by guardrails.

Residency and cross border

If you are subject to residency requirements, know which region processes your requests and whether failover can move it. Some providers offer regional processing commitments and some do not, and this is a real differentiator between them.

For Brazilian operations under the LGPD, and for European ones under the GDPR, this needs a documented answer with the legal basis attached, not an assurance in a sales call.

Fine-tuning changes the picture

Sending data for training is a different commitment from sending it for inference. A fine-tuned model may encode information from the training set, and extracting it is not straightforward but it is not impossible either.

So treat a fine-tune as a data transfer decision with its own review, and prefer retrieval when the goal is access to current information rather than a change in behaviour. That distinction is covered in fine-tuning.

What to require contractually

No training on your data. A stated retention period, ideally zero. Named subprocessors and notice before they change. Deletion on termination with a mechanism, not just a clause. Breach notification timelines. A DPA covering your jurisdiction.

Ask the vendor building the system, not only the model provider, since the integrator usually has broader access than the provider does. A vendor who cannot produce these quickly has not been through an enterprise review, which belongs on the vendor red flags list.

Architecture choices that reduce exposure

Send the minimum: identifiers instead of full records, the relevant passage instead of the whole document, a masked value where the model does not need the real one. Redact before the request, not after.

Keep the most sensitive classes out of the model path entirely where a deterministic lookup would do. Every field you do not send is a field that cannot leak, and this discipline also reduces cost for the same reason it reduces risk. See data readiness.