A support copilot receives a customer’s email address, account history and a free-text complaint. An internal assistant receives an employee’s performance review. A document workflow receives a medical certificate. In each case, the question is not merely whether can LLMs process personal data. They plainly can, in the technical sense. The operational question is whether the organisation has designed that processing to be lawful, proportionate and controllable.
For teams deploying LLMs in the UK and EU, treating a model prompt as harmless application telemetry is a costly mistake. Personal data may be present in the input, generated in the output, retained in logs, or exposed through the provider and infrastructure chain. The controls need to apply to the full request path, not just to a privacy notice written after deployment.
Can LLMs process personal data lawfully?
Yes, but an LLM does not create an exemption from data protection law. Under the UK GDPR and EU GDPR, sending personal data to an LLM is processing. That includes collecting text from a user, transmitting it to a model provider, generating a response, storing request payloads, retaining traces and using outputs in downstream business decisions.
Lawful processing depends on the use case. A customer-service assistant may rely on performance of a contract where the processing is necessary to answer an account query. An internal knowledge assistant may sometimes rely on legitimate interests, subject to a documented balancing assessment. Other use cases require a different basis. Where special category data is involved, such as health information, trade-union membership or biometric data, an additional condition is required.
The model itself is not the legal basis. Nor is a supplier’s assertion that data is encrypted or that it will not train on submitted content. Those commitments matter, but they address only part of the analysis. The organisation still needs a defined purpose, a lawful basis, clear retention decisions and a defensible explanation of why the data sent is necessary.
This is why “we only use the best model” is not a privacy design. A capable model can still be the wrong destination for a particular request if the request contains data that should be removed, blocked or kept within a particular processing arrangement.
The real issue is the request path
Personal-data governance often breaks down because teams assess the provider but not the path between an application and that provider. A production request can pass through application code, observability tooling, a gateway, a routing layer, the selected model provider and downstream storage. Each point can create a new disclosure, retention period or access route.
A controlled architecture starts by treating every prompt and completion as data with a classification and a policy outcome. Before routing a request to any model, the system should assess whether the input contains sensitive content and whether that content is permitted for the intended task.
The order matters. Prompt-injection and jailbreak shielding should run first, because a malicious instruction may attempt to override safeguards or solicit hidden data. Data loss prevention then detects personal data and applies the configured action: log, warn, redact or block. If redaction is appropriate, the sensitive value is replaced with [REDACTED]; it is not preserved for later restoration. Only then should routing select the provider and model. Output moderation follows, ensuring the generated response does not create a fresh exposure.
That sequence turns policy into request-level enforcement rather than a set of guidelines developers are expected to remember under delivery pressure.
Redaction is useful, but it is not anonymisation
DLP redaction can reduce unnecessary disclosure. A model often does not need a customer’s full email address, National Insurance number or precise home address to classify a query, summarise a document or draft neutral copy. Removing those values before the request leaves the application with less sensitive material moving through the model path.
But redaction does not automatically make the remaining text anonymous. A combination of job title, rare circumstance, location and account context may still identify someone. Free text is particularly difficult: a complaint can reveal health information, family circumstances, ethnicity or financial hardship without using obvious structured identifiers.
The practical test is contextual. Ask what data the model actually needs to complete the task. If the task is sentiment classification, a narrow excerpt may be enough. If the task is generating a case-specific reply, more context may be justified, but only where the organisation has designed the workflow, controls and retention around that need.
Blocking is equally valuable. Some categories of prompt should never reach an external model endpoint, regardless of the selected provider. A block policy gives the application a clear, auditable outcome instead of quietly accepting a risk because a user pasted sensitive material into a chat box.
Provider choice remains a governance decision
Multi-provider routing can improve availability, performance and cost, but it also means data governance cannot be frozen around one vendor. If a routing rule may select different providers, the organisation needs to know which providers are eligible for each route and whether their contractual and technical terms support the intended data category.
This is not an argument against routing. It is an argument for named routes and routing priorities that reflect policy. A general-purpose route for low-risk product copy can have a wider approved provider set than a route used for customer correspondence. The governing principle is that efficiency optimisation works within policy boundaries, not around them.
For UK and EU organisations, transfer arrangements also need attention. Data residency is relevant, but it is not a shorthand for complete compliance. Teams should establish where processing occurs, which entities receive the data, how subprocessors are managed, what contractual safeguards apply and whether the actual request routing matches the documented position.
The controller-processor distinction matters here. Most organisations using LLMs to process their own customers’, employees’ or users’ data remain controllers for that use. Their infrastructure and model suppliers may act as processors, subject to the precise service and contractual arrangement. That relationship requires appropriate processor terms, documented instructions and reasonable assurance that those instructions are followed.
Logging can quietly become the largest privacy risk
Teams commonly protect the live inference call, then retain full prompts and completions indefinitely in logs for debugging. This recreates the problem in a new system, with broader internal access and no clear retention rationale.
Metadata-only logging is a more disciplined default. A useful operational trace can record the route, selected provider, model, latency, token usage, policy outcome, cost and request status without retaining the full payload. That gives engineering, FinOps and security teams evidence to investigate performance, spend and enforcement decisions while reducing the volume of personal data held for routine observability.
There are cases where payload retention is necessary, such as investigating a high-severity incident or evaluating a quality failure. It should be explicit opt-in, limited to a defined purpose, accessible only to appropriate roles and subject to a retention schedule. “We might need it later” is not a retention policy.
Per-request traces are especially useful when a decision must be explained. If a request was redacted, blocked, routed to a specific approved provider or moderated on the way out, the trace provides evidence of what happened without forcing teams to retain the underlying sensitive text by default.
Build controls around purpose, not prompt format
A common implementation failure is to focus on fields called email, phone or customer_id while treating the rest of a prompt as unstructured and low risk. Personal data does not respect schema boundaries. It appears in chat transcripts, uploaded documents, copied CRM notes and model outputs.
A stronger operating model starts with a small set of questions for each LLM workflow. What is the business purpose? What categories of data may enter? Which categories are prohibited? Which DLP action should apply? Which providers are approved? Is payload retention required? How will a person challenge or correct an outcome if the workflow materially affects them?
These are not one-off procurement questions. They should be attached to the route that governs live traffic, then reviewed when the workflow, model selection or provider set changes. This is particularly relevant for automated processes that inform employment, credit, insurance, health or other high-impact decisions. LLM output may be advisory, but the operational effect can still be significant.
A governed gateway provides one practical way to enforce this consistently. routeur.ai places one governed doorway between applications and model providers, allowing teams to apply prompt shielding, DLP actions, approved routing rules, output moderation and metadata-only traces without rewriting business logic. The control plane does not remove the need for a lawful basis or a data protection impact assessment where risk warrants one. It makes the controls designed by legal, security and engineering teams observable at the request level.
What good looks like in production
The strongest programmes do not attempt to ban all personal data from LLM workflows. That would rule out legitimate customer support, document processing and internal assistance use cases. Instead, they distinguish between necessary and unnecessary data, define approved processing paths, and make the safe path easier for product teams to use than an unmanaged direct API call.
They also accept that controls have trade-offs. Aggressive redaction can reduce answer quality when the removed context is genuinely needed. Blocking can create handling friction for users. Restricting a route to a smaller provider set may limit cost optimisation. Those are operational choices to measure and review, not reasons to avoid controls.
The useful standard is simple: every production request containing personal data should have a known purpose, a permitted path, an enforceable policy outcome and evidence that the policy was applied. When that becomes normal engineering practice, LLM adoption can move faster without asking privacy and security teams to accept blind spots.