Protecting personal data before it reaches an LLM

An LLM does not always need the identity behind a document to help with the document. If the task is to summarize a delivery dispute, names and email addresses may add exposure without adding useful context. A local masking step can remove selected values before the request leaves the device, then restore them in the response when appropriate.

That boundary needs a precise scope. Decide what may leave, what must remain local and what the user should see when the system cannot make that decision confidently.

Trace the whole request path

Consider an illustrative support workflow: an employee selects an email, asks an assistant to draft a response and reviews the result. The following example uses invented details and does not describe a customer deployment.

Original text, kept local:
Mara Example (mara@example.com) asks about order ZX-1042.

Text sent to the model:
[PERSON_A] ([EMAIL_A]) asks about order [ORDER_A].

Local mapping:
[PERSON_A] -> Mara Example
[EMAIL_A]  -> mara@example.com
[ORDER_A]  -> ZX-1042

The prompt should still describe the task: draft a polite response asking for the delivery date. Test whether the model can do that with the masked version before deciding to send more detail.

Draw the route through the application, not just the model API call. Include attachment extraction, request construction, retries, error reporting and response display. A masking function placed after an analytics event has already missed that copy of the original text.

Treat detection and policy as separate decisions

A detector proposes spans that look sensitive. Your policy decides what to do with them. In this example, an order identifier matters even if it is not recognized as a person's name, phone number or email address. Start with the actual documents and identifiers in the workflow.

Build a synthetic evaluation set containing misspellings, different languages, repeated names and internal reference formats. Label both values that should be masked and values that should remain. Missing a sensitive span and removing useful context are different errors; report them separately.

For uncertain inputs, give the employee an understandable choice: edit the protected text, remove an attachment or cancel the request. Do not claim a clean result merely because a detector returned no matches.

Keep the restoration map inside the boundary

The mapping is sensitive because it reverses the transformation. In the support example, keep it local and scoped to the individual operation. Avoid putting it in a model message, telemetry event, shared URL or unprotected persistent cache.

Define what happens when the user closes the window, cancels a request or starts a second conversation. A restored answer must not pick up values from another conversation that happened to use the same placeholder names.

Restoration should also be deliberate. A generated answer may alter, repeat or invent a placeholder. Restore only exact tokens known to the current mapping; leave unknown tokens unresolved and visible for review. If streaming output is supported, account for tokens arriving across chunk boundaries before replacing them.

Masking does not remove every disclosure path

Removing a name does not remove identifying context. A job title, unusual event and precise location may still identify someone. Reversible masking should not be described as a guarantee of anonymity. Review the remaining text against the workflow's actual disclosure constraints.

Also separate data masking from prompt-injection protection. Instructions embedded in an email or retrieved document can attempt to redirect the assistant. OWASP recommends layered defenses, including treating external content as untrusted, limiting tool privileges and validating outputs. A detector for personal data does not provide those controls. OWASP prompt injection prevention guidance

For our support assistant, drafting text and sending email should be separate operations. The employee should inspect the restored draft before sending it. If tools can retrieve customer records, authorize each tool operation independently of whatever the model requests.

Evaluate exposure and usefulness together

Before enabling a workflow, run the same synthetic tasks through the complete application path and inspect the outgoing payloads. A practical acceptance review asks:

• Did any labeled sensitive values leave in the prompt, attachments, telemetry or error reports?
• Did the response preserve the intended meaning after restoration?
• Did two conversations remain isolated when their requests ran concurrently?
• What did the interface show when detection or restoration failed?
• Could the employee recognize the remaining context before submitting it?

Keep the fixtures, configuration and detector versions with the results. Avoid a single “privacy accuracy” percentage that hides which error occurred. No benchmark result is claimed here; this is a proposed evaluation method for the illustrated workflow.

Build around the smallest useful disclosure

The broader engineering task is to make the boundary observable and testable. Start with one workflow, define its permitted disclosure and prove the path using representative synthetic inputs. Expand only when the results explain what is protected and what remains exposed.

We work with teams on privacy engineering for AI and enterprise systems. What shall we build together?