LLM Data Privacy: Sending User Data to AI APIs Safely

Adding an AI API changes where application data travels. A support summary might send private messages to an external processor; a document assistant might include uploaded contracts in a prompt; a debugging trace might preserve both long after the feature finishes. Privacy work starts by mapping those paths, not by adding a reassuring sentence to the interface.

For developers, the practical goal is bounded data processing: send only what the feature needs, to an approved destination, for an understood purpose and duration. Legal and security colleagues should confirm the applicable obligations, but engineering must make the resulting commitments true in the running system.

Map the complete processing path

Begin with one concrete workflow. Record the original source, browser requests, backend services, provider endpoints, storage locations and downstream tools. Include embeddings, retrieved passages, generated responses, error reports, review queues and observability platforms. The final answer may contain less sensitive information than the hidden context used to generate it.

Create a data inventory that distinguishes account identifiers, contact details, private content, credentials and sensitive categories relevant to your users. Record who can access each copy and whether data crosses organisational or geographic boundaries. Avoid assuming that a hashed or pseudonymous identifier is automatically anonymous.

List every processor and intermediary involved in the chosen deployment route. Calling a model through a cloud platform or gateway can introduce different contracts, regions and logging behaviour from calling the original provider directly. A diagram should show the actual deployed route, not the architecture the team originally intended.

The ICO data protection guidance is a useful starting point for UK GDPR questions. Other jurisdictions and sectors have different requirements. Use authoritative guidance with qualified advice rather than treating a general engineering checklist as a legal determination.

Minimise payloads before they leave your server

Build a server-side allowlist of fields for each feature. A summariser may need message text but not billing details, internal risk flags or the user's entire account record. Purpose-specific payloads are easier to review than generic objects that accumulate unrelated fields as the application grows.

Remove secrets entirely. API keys, session cookies, reset tokens and private signing material should not enter prompts. If identifiers are unnecessary, replace them with local placeholders and keep the mapping inside your trusted environment. Remember that surrounding details can still identify a person even after their name is removed.

Use the JSON formatter with fabricated payloads to inspect the proposed request structure and spot fields that should be excluded. Do not paste production records into a public utility. A well-formatted object makes review easier, but formatting provides no privacy protection by itself.

A useful implementation prompt is deliberately restrictive:

Create a server-side serializer for the summary request.
Allow only message text, message role and a local case alias.
Exclude emails, credentials, billing fields and internal notes.
Apply size limits and reject unknown top-level properties.
Use synthetic fixtures to test that excluded fields never leave.
Do not log request bodies when validation fails.

Treat redaction as defence in depth, not a guarantee. Pattern matching misses unusual formats and contextual identifiers, while model-based redaction can make its own mistakes. Prefer not collecting or selecting sensitive fields over trying to remove them from a large payload afterwards.

Verify the exact provider arrangement

Separate training use, request retention, abuse monitoring, human access and regional processing. These are different properties. A service may not use API inputs for training while still retaining some records for operational or safety purposes. Check the precise product and account configuration rather than relying on broad marketing language.

Review contracts, processing terms, subprocessors and deletion mechanisms with the appropriate owners. The OpenAI API data controls documentation illustrates why endpoint and account details matter. Confirm current terms directly before making a commitment to customers; do not assume another provider uses the same definitions.

Document retention by data type. Raw uploads, prompts, outputs, embeddings, application logs and backups can have different lifetimes. Include deletion delays and exceptions that your team cannot control. A short application retention policy cannot erase a longer provider-side retention period.

The LLM provider selection guide places these requirements alongside quality, latency and cost. Treat mandatory data controls as selection gates, not preferences to trade away because another model produces a slightly better demonstration. Recheck the arrangement when changing endpoints or introducing a fallback provider.

Enforce access and tenant boundaries

Keep provider credentials on the backend and apply normal authentication and authorisation before assembling context. A request for another customer's record must fail before retrieval or generation. Tenant isolation should be enforced in database queries, document indexes and tool handlers, not delegated to a prompt telling the model to behave.

Scope retrieval to resources the requesting user may access. Validate citations and downloadable artefacts against the same permissions. An assistant can leak data through a generated file or search snippet even if its main answer looks harmless.

Treat external content as untrusted instructions. The OWASP LLM security project describes risks such as prompt injection and sensitive information disclosure. Limit tools and outbound destinations so hostile document text cannot turn a summarisation request into an exfiltration workflow.

For agentic features, follow the backend agent workflow guide to separate model proposals from authorised execution. Explicit approvals are useful for sensitive transfers, but approval must name the destination and data involved. A generic confirmation button cannot make an undisclosed disclosure transparent.

Make deletion and accountability testable

Assign an owner to every stored copy and define how a deletion request propagates. Removing a document should address source storage, derived chunks, embeddings, caches and associated outputs according to the applicable policy. Deletion is a workflow, not one database command.

Minimise observability payloads. Store request IDs, timing, token counts and error categories where possible instead of complete conversations. If restricted debugging samples are necessary, define access controls, expiry and review procedures. Ensure automatic error reporters do not undo the careful minimisation performed in the primary request path.

Test privacy controls with synthetic canary values. Verify that excluded fields never reach provider adapters, cross-tenant retrieval is rejected, deleted content disappears from search, and logs omit sensitive request bodies. Include backups and delayed jobs in the test plan, documenting limitations rather than claiming instantaneous erasure everywhere.

Maintain clear user notice explaining what the feature sends, why it sends it and what choices exist. Provide a non-AI route where required or appropriate. Review the data map whenever features, providers or logging settings change, and prepare an incident process that can identify affected records without collecting unnecessary content in advance.

Key takeaways

• Map prompts, retrieval, outputs, logs and derived data together.
• Build minimal allowlisted payloads using synthetic review examples.
• Verify training use, retention, region and access as separate controls.
• Enforce permissions before retrieval and outside model instructions.
• Test deletion, logging and user notice against the deployed workflow.