A data privacy checklist for using LLMs with business data
Practical questions to answer before sending company or customer data to a language model, covering providers, retention, access control and logging.
Before sending business data to a language model, map what data it will see, check each provider’s training, retention, region and sub-processor terms, choose a hosting model that fits the data’s sensitivity, enforce source-system permissions in retrieval, log with sensitive values masked, and plan an incident response. This is an engineering checklist, not legal advice.
Teams adopt language models quickly and ask privacy questions late. This checklist moves those questions to the start. It is a practical engineering checklist, not legal advice, and the right answers depend on your industry, your contracts and where your customers live. Have counsel review anything regulated.
1. Know what data goes where
- Map every field the model will see: prompts, retrieved documents, attachments and tool outputs.
- Classify each as public, internal, confidential or regulated.
- Remove or mask anything the task does not need, such as ID numbers, card details and health information.
2. Check the provider terms
- Is your data used to train the provider’s models? Look for an explicit opt-out or a no-training commitment in the business terms.
- How long is data retained, and can retention be set to zero or a short window?
- In which regions is data processed and stored?
- Which sub-processors does the provider use?
3. Decide on the hosting model
| Option | Good when | Trade-off |
|---|---|---|
| Hosted API with business terms | Data is internal or lightly sensitive | Data leaves your environment under contract |
| Cloud provider private endpoint | You need regional control and enterprise controls | More setup and cost |
| Open-source model in your own environment | Data cannot leave at all | You run and maintain the infrastructure |
4. Control access
- Retrieval must respect the same permissions as the source system: a user should never get an answer drawn from a document they cannot open.
- Use least-privilege credentials for every tool an AI agent can call.
- Keep secrets out of prompts and logs.
5. Log and review
- Log who asked what, what was retrieved and what was returned, with sensitive values masked.
- Set a retention period for the logs themselves.
- Review a sample regularly for leaks and misuse.
6. Plan for failure
Decide in advance who is told, and how fast, if something sensitive is exposed. Write it down before you need it.
For how this fits into building and testing an assistant, see our evaluation checklist.