Is It Safe to Send Customer Data to an LLM?

Two products that share a name

When someone asks whether it is safe to send customer data to ChatGPT, or Claude, or Gemini, they may mean two very different things.

The consumer chat product: the website or app an individual signs up for, often free. Under default settings, several of these use conversations to improve their models, retain them for extended periods, and are governed by consumer terms with no data processing agreement. A staff member pasting a customer's email thread into one of these has transferred personal data to a third party with no contract, no controls and possibly no ability to delete it. That is a GDPR problem and, in regulated industries, a reportable one.

The business API or enterprise tier: the programmatic service a product integrates, or the enterprise version of the chat tool. The major providers state that API inputs are not used for training by default, offer data processing agreements, publish sub-processor lists, allow retention to be limited or set to zero, and in several cases offer regional processing. This is the product a company should be using for anything involving customer data, and under those terms the question becomes an ordinary vendor-risk question rather than a novel one.

The first rule, therefore: customer data goes through the API or an enterprise agreement, never through a personal account in a browser.

The questions to settle with the provider

Training. Is our data used to train or improve models? Under API and enterprise terms from the major providers, no by default; confirm it in the contract, not the marketing page.

Retention. How long are inputs and outputs stored, and for what purpose? Typical defaults are up to thirty days for abuse monitoring; zero-retention options exist for qualifying customers. Shorter is better, and the retention period is what you will have to state in your privacy policy.

Region. Where is the data processed and stored? EU customers may need EU processing or appropriate transfer mechanisms.

Sub-processors. Who else touches the data? The provider's cloud host, at minimum.

Security. Encryption in transit and at rest, access controls, certifications such as SOC 2 or ISO 27001, and how incidents are reported.

A data processing agreement. The contract that makes the provider your processor under GDPR, with the obligations that implies. The major providers offer one; sign it before the first request. Our note on DPAs covers what it should contain.

Your own obligations do not disappear

Using a compliant provider makes you a controller with a processor, not a bystander. You still need a lawful basis for the processing, a privacy policy that mentions AI processing and the provider as a recipient, a record of the processing activity, and, for anything high-risk such as profiling or sensitive data, a data protection impact assessment. If customers can ask for their data to be deleted, you need to be able to honour that, which is one reason zero or short retention matters.

Send less

The most effective control is not contractual. It is sending only what the task needs.

• Strip identifiers before the request: names, emails, phone numbers, account IDs, addresses. Replace them with placeholders and re-insert them afterwards if the output needs them.
• Send the relevant excerpt, not the whole record. A model summarising a support ticket needs the ticket, not the customer's full history.
• Never send special-category data (health, financial details, identity documents) unless the use case genuinely requires it and the assessment has been done.
• Keep secrets out of prompts. API keys, passwords and internal URLs have no business in a model's context, and prompt injection can extract them.
• Log what was sent, so you can answer the question later.

A pipeline that pseudonymises before the API call and re-identifies after it has most of the benefit of the model with a fraction of the exposure, and it makes the privacy policy a short paragraph rather than a long one.

Local and private models

For organisations that cannot send data outside their own infrastructure, open-weight models can be run on your own servers or in a private cloud tenancy. Capability lags the frontier providers, cost and operational burden are real, and the choice between open and hosted models depends on the task. But for a bounded job on sensitive data, a smaller model that never leaves the building is sometimes the right answer.

A checklist before the first customer record

1. API or enterprise tier, not a consumer account.
2. DPA signed; training off; retention confirmed and as short as possible; region acceptable.
3. Privacy policy updated to name AI processing and the provider.
4. Pseudonymisation in the pipeline; sensitive data excluded.
5. Staff told, in writing, not to paste customer data into personal AI tools.
6. Logging of what is sent, and a way to honour deletion requests.

With those six in place, sending customer data to an LLM is as safe as sending it to any other cloud processor, which is to say safe enough for most businesses and an ordinary part of the AI readiness picture. Without them, it is a breach waiting for someone to notice. If you would like the checklist applied to a specific integration, book a call.

Common questions