Before launching an LLM application, use this practical privacy checklist to review the data moving through prompts, model providers, logs, tools, and storage. It gives development and IT teams a repeatable way to classify information, reduce unnecessary exposure, document approved data flows, and schedule reviews when the system or vendor changes.
Overview
LLM data privacy is an architecture and operations concern, not only a legal review. A chatbot, retrieval-augmented generation system, or AI agent may send information through several components: an application server, a model API, an embedding service, a vector database, observability tools, function integrations, support dashboards, and backup systems. Each component can have different access controls, retention settings, regional options, and deletion behavior.
The central question is simple: what data leaves your controlled environment, where does it go, who can access it, and how long does it remain available? Answering that question requires more than checking whether a provider offers encryption. Your review should also cover prompt construction, provider training and use policies, subprocessors, logs, cached responses, human review, deletion requests, and incident response.
Treat the checklist below as a release gate and a recurring tracker. Reuse it before an initial launch, a major prompt or model change, a new vendor review, a regional deployment, or a recurring compliance assessment. Provider terms, privacy controls, SDK defaults, and product features can change, so record the date and evidence for every decision rather than relying on memory.
What to track
1. Data classification and purpose
Start with an inventory of the information your application may receive, retrieve, generate, or store. Classify data according to your organization’s existing policy. Useful categories might include public information, internal business data, confidential information, personal data, authentication secrets, financial records, health-related information, or regulated records. Do not create new categories casually; map the review to the classifications already used by your security and privacy teams.
For each category, document the business purpose. A support assistant may need an order identifier and product history, but not a full payment card number. A document summarizer may need the document text temporarily, but not a permanent copy in application logs. Purpose limitation makes prompt data privacy easier to enforce because the system can reject fields that are not necessary for the task.
2. Prompt construction and redaction
Review system prompts, user messages, retrieved context, tool arguments, and conversation history as separate data sources. Identify whether any source can contain personal or confidential information. Then decide whether the application should remove, mask, tokenize, or generalize fields before the request reaches a model provider.
Redaction should be deterministic and testable. For example, an application might replace an email address with a stable token when the model needs to refer to the same person across a workflow but does not need the actual address. Keep the mapping in a separately protected system, and define who can reverse it. Test redaction against normal inputs, malformed inputs, multilingual text, uploaded files, and adversarial attempts to bypass filters.
3. Provider and vendor controls
A proper LLM vendor security review should record the provider, model or service used, data-processing terms reviewed, available training or product-improvement settings, subprocessors, support access, regional hosting options, and account-level privacy controls. Avoid assuming that controls are identical across models, endpoints, plans, or deployment types. Verify the configuration that your application actually uses.
Capture evidence such as a dated policy reference, an administrative setting, a contract record, or an approved security response. If a control cannot be confirmed, mark it as an open issue instead of treating silence as approval.
4. Encryption, access, and secrets
Confirm encryption in transit and at rest for each relevant component, including application databases, conversation stores, vector indexes, object storage, backups, and logs. Review identity and access management separately. A technically encrypted log may still expose sensitive prompts to too many engineers or support users.
Use least-privilege roles, separate development and production credentials, rotate API keys, and keep secrets out of prompts, source code, traces, and error messages. Pay special attention to function calling: tool arguments can contain the same sensitive information as the original prompt and may be forwarded to another service.
5. Logging, retention, and deletion
List every place where request and response data may be retained: application logs, provider dashboards, tracing systems, analytics tools, queues, caches, vector stores, backups, and exported evaluation datasets. For each location, record what is stored, the retention period, the owner, and the deletion method.
Choose the shortest retention period that supports debugging, security monitoring, evaluation, and business requirements. Consider storing metadata or redacted samples instead of complete prompts and responses. If users can request deletion, document which systems must be searched, how derived records are handled, and how completion is verified. Do not describe deletion as complete until backups, replicas, exports, and downstream systems have been considered.
6. Regional hosting, subprocessors, and human access
Map the geographic path of data where location matters to your organization. Include model inference, content moderation, embeddings, storage, support tooling, and subprocessors. A provider may expose a regional option, but the full workflow can still include services with different locations or administrative access arrangements.
Document when humans may view prompts or outputs, such as support investigations, quality review, abuse monitoring, or model evaluation. Define approval requirements, masking rules, access duration, and audit logging. Human review should be an explicit part of the data flow, not an undocumented exception.
Privacy review table
| Area | Questions to answer | Evidence to retain |
|---|---|---|
| Data classification | What data enters, leaves, or is generated by the system? | Data inventory and approved use case |
| Prompt redaction | Which fields are removed, masked, tokenized, or blocked? | Rules, tests, and failure handling |
| Provider policy | How may the provider use, retain, or access submitted data? | Dated policy or contract review |
| Security controls | How are data, credentials, and administrative access protected? | Configuration records and access review |
| Retention | Where are prompts, outputs, traces, and backups stored? | Retention schedule and deletion procedure |
| Subprocessors and regions | Which services and locations participate in the flow? | Architecture diagram and vendor list |
| Incident response | Who detects, contains, investigates, and communicates an exposure? | Runbook, owners, and escalation path |
Cadence and checkpoints
Use different review depths for different events. A lightweight monthly check can confirm that provider settings, model identifiers, API endpoints, logging configuration, and open privacy issues have not changed. A quarterly review can revisit the complete data inventory, access permissions, retention records, subprocessors, regional routing, and deletion tests.
Run a full checkpoint before these events:
- Launching a new AI feature, chatbot, agent, or retrieval pipeline.
- Changing model providers, model families, endpoints, SDKs, or account plans.
- Adding a new data source, tool, connector, memory store, or analytics system.
- Allowing personal, confidential, or regulated data into prompts.
- Expanding to a new country, business unit, customer group, or hosting region.
- Changing prompt templates, conversation memory, logging, or evaluation workflows.
- Receiving a vendor notice about terms, subprocessors, features, or security controls.
- Following an incident, near miss, failed redaction test, or unexpected data exposure.
Assign an owner to every checkpoint and record a status such as approved, approved with conditions, blocked, or pending evidence. Link each decision to a specific application version or architecture revision. This makes the review useful during incident response and prevents an old approval from being applied to a materially different system.
How to interpret changes
Not every change has the same privacy impact. A model version change may require a provider-policy and output-retention review even when the application code is unchanged. A new logging field may be more significant than a visible prompt edit because it can expand the number of systems storing sensitive content. A new tool integration can create a second disclosure boundary for data already present in the conversation.
Classify changes by their effect on four questions:
- Exposure: Does the change send more data, new data categories, or more detailed context to a vendor or tool?
- Access: Does it create new human, service, administrator, or support access?
- Persistence: Does it add a log, cache, memory store, vector index, backup, or longer retention period?
- Control: Does it alter redaction, deletion, regional routing, encryption, or incident-response procedures?
Escalate any change that increases exposure, access, or persistence. If a provider introduces a new privacy setting, test it in a non-production environment, confirm the SDK or API configuration, and add a monitoring check so a future deployment cannot silently disable it. For model evaluation, use sanitized test data whenever possible. Reliability testing should measure answer quality without turning real customer conversations into an unmanaged dataset. Related practices are covered in this guide to prompt regression testing and the workflow for troubleshooting LLM hallucinations.
Also review privacy and reliability together. A retrieval system that returns excessive source text may increase both hallucination risk and data exposure. A system prompt that asks for verbose reasoning may increase logging risk without improving the user-facing result. The safer design is usually to minimize context, constrain tool permissions, and return only the information needed for the approved task.
When to revisit
Make this checklist part of the release process rather than a one-time document. Set a monthly or quarterly calendar reminder, then trigger an immediate review whenever the data flow changes. At minimum, revisit the checklist when a provider changes its terms or privacy controls, a model or SDK is replaced, a new subprocessor appears, a region changes, retention settings are modified, or a deletion request and incident reveal an unexpected storage path.
A practical data-flow record can use this template:
- Use case and owner: What does the feature do, and who approves its operation?
- Input categories: What data may users, retrieval systems, or tools provide?
- Transformations: What is redacted, tokenized, filtered, or rejected?
- Destinations: Which model, storage, monitoring, and tool services receive data?
- Regions and subprocessors: Where can processing or access occur?
- Retention and deletion: What is retained, for how long, and how is deletion verified?
- Access and incident response: Who can access the data, and what happens if controls fail?
- Evidence and review date: Which records support approval, and when will they be checked again?
Keep the record beside the application’s architecture and evaluation documentation. When the next release changes a prompt, model, connector, or log, compare the new flow with the approved one. For systems using retrieval, review the recurring RAG knowledge-base audit workflow; for agent systems, inspect memory, routing, tools, and human approval as described in the AI agent workflow guide. A short, dated review that reflects the real data path is more useful than a broad policy that no longer matches the implementation.
