Privacy
Is it safe to send company data to AI
There is no single answer, because 'sending it to AI' is not one thing. Data sent through an enterprise API and data pasted into a free chat interface fall under entirely different agreements, even when they reach the same model. The decision is less about which model than about knowing that difference.
- Published
- Built by
- Zero-Shot Team
- 4 min read
The biggest risk is the door, not the model
When an employee pastes a customer list into a free chat interface, that data falls under consumer terms and in some products may be used to improve the model. The same data sent through an enterprise API is usually governed by a different agreement that commits to not training on it.
So in most organisations the real risk is administrative, not technical: nobody knows who pasted what where. Writing an AI usage policy comes before building infrastructure.
The practical version of that policy is three lines: which tools are approved, which classes of data may enter which tool, and who to ask when something falls outside.
Four clauses to check
Is the data used for training. Enterprise plans generally say no, but this is confirmed in writing rather than assumed.
How long is data retained. Short retention for abuse monitoring is common; some providers offer a zero-retention option, usually enabled on request.
Where is data physically processed. Providers offering region selection let you choose an EU region, which eases the cross-border question without removing it.
Who are the sub-processors. The company running the model and the cloud provider hosting it are often different, and both process the data.
What changes legally
Sending personal data to a language model is a processing activity and a transfer. Your privacy notice must cover that processing, a lawful basis must be identified, and the conditions for cross-border transfer must be met.
The point most often missed: your existing privacy notice was written when no such processing existed. It has to be updated before the system goes live.
There is a contractual side too: a data processing agreement with the provider. Enterprise plans generally offer one; free products generally do not.
This is a map of the work, not legal advice. Any setup handling personal data needs a lawyer working the legal side.
Often you can send far less
The simplest control is shrinking what you send. Summarising a contract does not require the customer's ID number; names and numbers can be masked before sending and restored on return.
The second is narrowing scope: send the relevant passage, not the whole archive. A retrieval layer already does this — the side benefit is cost, the main benefit is sharing less.
The third is permission: retrieval must never fetch documents the asker cannot see. This is the internal half of privacy rather than the provider half, and it is routinely skipped.
Self-hosting
Running open-weight models on your own infrastructure means the data never leaves the organisation. In some sectors that is a requirement rather than a preference.
It has a price: hardware, idle capacity, upgrade work and someone to operate it. At low or spiky volume, total cost usually exceeds a provider API.
There is a middle path: sensitive work on a small in-house model, everything else with a provider. Making that split requires data to be classified — which returns to the first point, the policy.
In short
- The risk lies in which account and which agreement the data travels under, not the model.
- Check four clauses: training use, retention period, processing region, sub-processors.
- If personal data is involved, update the privacy notice and put a processing agreement in place.
- Send less: mask identifiers, narrow the scope, and filter by the asker's permissions.
- Self-hosting keeps data inside but raises total cost at most volumes.
Common questions
- Will our data be used to train the model?
- On enterprise API plans providers generally commit that it is not; free and consumer products can have different terms. Rather than assuming, confirm it in writing in the terms of the plan you actually use — terms can change when the plan does.
- Should we ban employees from using ChatGPT?
- Bans rarely work; usage just becomes invisible. What works better is providing an approved enterprise account and writing down which data classes may go where. People will find a route; if you provide it, you can supervise it.
- Is zero retention enough?
- It stops data resting with the provider but does not remove the processing in transit or the transfer question. Legally a transfer still occurred. A useful control, not a complete answer.