How can teams safely send customer data to an LLM?

A support agent pastes a ticket thread into a chat assistant and asks for a draft reply. Whether that prompt is safe to send comes down to four decisions made for that task alone. Transforming the text first reduces exposure, but it doesn’t remove the risk of re-identification. US federal guidance says even properly applied de-identification leaves some risk of identification. This article offers advice for how organisations can navigate ensuring the prompts they send to LLMs are free from sensitive customer data.

Approve one task and one data flow

A gateway or sidecar in a system’s architecture is where rules get enforced. The approval is narrow: may this task send this kind of customer text to this model on these terms? Write down:

• The task, as the job the model does. This has to be specific; drafting a reply to a billing complaint is a task, but “support use cases” is not.
• What crosses the boundary. Which details are transformed, which go through unchanged, and where the reverse mapping sits.
• What the vendor does with it, from the contract. Retention, logging, sub-processing and training use.
• The residual risk. This needs a named owner and the conditions that reopen the decision.

The US National Institute of Standards and Technology SP 800-188 has agencies send each request to a Disclosure Review Board, stating the data, the techniques used to limit disclosure and how effectiveness will be checked. It was written for US agencies but is offered for voluntary use elsewhere. This is what decides what is safe to send or not, based on the information provided above.

Whether the twin counts as personal data depends on where you are

In the EU, the question is whether the company receiving the data could realistically work out who it is about. In EDPS v SRB, decided in September 2025, the Court of Justice said the answer can differ from one company to the next. An EU body had sent Deloitte survey comments with the names swapped for codes. The body kept the list linking codes to names, so for them, the comments were still personal data. Deloitte had no list, so whether they were personal data in Deloitte’s hands depended on whether Deloitte could realistically re-identify the individuals in the data.

A well-built LLM deployment looks the same: you keep the key, and the model provider receives twins it has no way to reverse. That may mean the provider isn’t handling personal data, but it doesn’t take you off the hook. If the provider could recognise someone from a long or unusual ticket without the key, that counts against you. The court also didn’t say how this works when the recipient is your processor, which is how most LLM contracts are set up. The European Commission has proposed writing this approach into the GDPR; the EU’s data protection authorities oppose the change. Member states had not agreed on it by September 2026.

The UK law uses the same wording as EU law here, so UK courts may follow the same reasoning, though they don’t have to. The UK regulator, the ICO, says in its March 2025 guidance that pseudonymised data stays within data protection law. So long as a key exists that maps the twin back to the original, the data counts as personal. That makes where the key is kept, and who can reach it, the thing to get right.

For more information, see Swapping names isn’t enough.

The US has no single national privacy law, so the rules depend on the sector and the state. For health data under HIPAA, even the two approved de-identification methods leave a small risk that someone could be identified. California, and the states that copied its law, only treat data as de-identified if the business takes reasonable steps so that it can’t be linked to a person, promises publicly not to re-identify it, and requires anyone it shares the data with to do the same.

If you keep a key that reverses the twins, you are unlikely to pass that test, unless you can prove how it is stored. So in the US, treat the twin as personal information and rely on the contract with the LLM provider: it should act as your service provider, keep nothing beyond the task, and never train on your data. In all three places the conclusion is the same. Twinning lowers risk, but the data stays within privacy law, so the contract, privacy notice and key’s location all still have to be right.

A proxy only protects the traffic it sees

Presidio publishes a sample that routes traffic through the LiteLLM proxy with masking attached. It demonstrates that a control can be the most powerful guardrail, but it relies on being put in the right place and controlled properly to work effectively. Jane Doe and her phone number reach the provider as PERSON and PHONE_NUMBER, and 'output_parse_pii' restores them in the reply. The options matter more than the happy path. permissions: '{"pii": false}' turns masking off for a key, 'allow_pii_controls' lets callers switch it off per request, and a logging-only mode leaves the real request untouched. If a key can switch the control off, audit key issuance.

Both settings point to the same rule: a control is only as strong as where it runs and who can turn it off. For Nakato, this is why it runs inside the customer’s own environment, as a sidecar next to the application or as a shared gateway. The key that reverses the twins never leaves, which is exactly the arrangement the legal argument above depends on: the provider receives text it has no means to link back to a person.

Placement is the most important factor, though. A control inside your network only sees traffic routed through it, so the question to ask any vendor, Nakato included, is which calls go around it, such as a browser extension or a hosted assistant reached directly.

Utility and identifiability pull against each other

Stronger de-identification lowers privacy risk, but usually accuracy with it. This is because existing techniques to sanitise data generally strip context as well as identifiers. For example, a model writing an apology to PERSON about an order placed on DATE has less to work with than one given a plausible name and a shifted date. Semantic twins, the approach Nakato takes, are built to close that gap: the model gets a consistent name, a realistic date and figures in the right range, so the reply reads naturally and maps back cleanly. The cost is the one set out in the legal section. Because twins can be reversed, they are pseudonymisation rather than anonymisation, so a twinned prompt stays within privacy law wherever you operate, and the detector testing below matters more, not less.

Test the detector on your own text

Detectors fail in two ways: they can miss details, and label them wrongly. The second matters more than it looks. In a scheme that substitutes by type and reverses afterwards, a postcode tagged as a driving licence number gets the wrong kind of substitute, and the reply can read oddly or be restored onto the wrong span.

Take a few hundred real tickets, weighted towards long threads and escalations, where context does the most identifying. Have two reviewers label entities independently, run the sample through the control point in shadow mode, and count four failures separately: missed, mislabelled, replaced when the task needed the real value, and restored to the wrong original. Then hand a transformed ticket to a colleague who knows the customers and ask who it describes. Keep the sample with the exact settings behind each result so changes can be rerun.

What approval doesn’t settle

Keeping the mapping local doesn’t prove that the vendor or a logging pipeline can’t work out who a ticket describes from the story around the names. For this assurance, choose the vendor that has the highest detection that would suit your task.

Reopen the approval when you add:

• a model, vendor or route the sample never covered
• a key with masking or output parsing relaxed
• a ticket type, language or channel the detectors haven’t seen
• a change to detector or substitution settings
• a new data source in the prompt context

Start with the narrowest task worth doing: one queue, one model, one route, and a sample you can rerun.