Can you use an LLM API to redact PII without exposing the data?

Why sending records to an LLM API is itself a disclosure#

Sending records to an LLM API discloses them to the provider before anything is redacted. The model has to read the names, emails, account numbers and credentials in order to find them, so the redaction step handles the rawest version of your data.

That makes the provider a processor of the very data you are trying to protect. Your customer agreements may limit which subprocessors can see their data, your privacy notice may describe where data goes, and any credentials in the text are exposed to one more system. A remote redaction service does not remove exposure; it moves it.

Consumer chat apps are the clearest no. Their terms can allow retention or use of inputs, and pasting customer records into them typically falls outside anything your customers agreed to.

Hosted API, your own cloud or a local model: how the options compare#

The deployment options differ mainly in where the raw text travels and which document governs it. Pick the option first, then the model; a strong model in the wrong place is still the wrong choice.

The cloud-hosted option still involves a provider, the cloud company, but usually under an agreement your security and legal teams have already reviewed for the same data. That is why it is often the practical middle path between a public API and your own hardware.

The six-point contract and configuration checklist#

The six-point checklist covers training, retention, the DPA, location, your own pipeline configuration and customer contracts; confirm each point in writing or in configuration before any record goes to a hosted model. If any point cannot be confirmed, move the job to a model inside your own environment.

Keep the evidence with the project record: the relevant contract clauses, the DPA, the region setting and an export of the retention configuration. Then the decision can be shown later rather than remembered.

• 1No training: the contract states that inputs and outputs are not used to train or improve the provider's models.
• 2Retention: inputs and outputs are not retained, or are kept only for a defined window, including abuse-monitoring logs, and you know how deletion is confirmed.
• 3Data processing agreement: a DPA covers the processing, lists subprocessors and sets security and breach-notice terms.
• 4Location: processing happens in a region your contracts and policies allow.
• 5Your own configuration: request logging, prompt tracing and observability tools in your pipeline do not store raw inputs, and API keys are scoped to this job.
• 6Customer contracts: your agreements with customers permit sending their data to this provider for this purpose, or that data is excluded.

Why LLM redaction still needs a second check#

LLM redaction needs a second check because language models can miss identifiers, flag the wrong text, behave inconsistently across chunks of a long thread and quietly rewrite sentences they were asked only to clean. A rewritten resolution note can lose exactly the technical detail that made it worth keeping.

Design the job so the model returns the spans to remove, each with a label, and let ordinary code apply replacements to the original text. Run a pattern-based detector alongside it for structured identifiers such as emails, phone numbers and card numbers, and review a sample by hand.

Tool makers say the same about automated detection generally. Presidio's own documentation warns that, because it uses automated detection, there is no guarantee it will find all sensitive information, and that additional systems and protections should be employed.

What a sound LLM redaction pipeline looks like#

A sound LLM redaction pipeline treats the model as a detector, not an editor. The practices below keep the original text under your control and make every result checkable.

• 1Send one record or one thread per request, with no unrelated records in the same call.
• 2Ask for a structured list of spans with a category for each, never for rewritten text.
• 3Give the model your allow list of product and module names so it leaves them alone.
• 4Check that every returned span exists in the original text before applying it.
• 5Log counts and categories, not raw text, in pipeline monitoring.

Alternatives that keep data in your environment#

Several non-LLM tools can run inside your environment or your existing cloud account and handle much of the work, especially for structured identifiers such as emails, phone numbers, card numbers and access keys.

Layer them rather than picking one. A common order of work keeps the expensive, least predictable step for the smallest share of the text:

• 1Pattern rules first, for identifiers with a fixed shape: emails, phone numbers, card numbers, access keys and your own account ID format.
• 2A named-entity detector next, for names, organizations and street addresses in free text, with your product allow list loaded.
• 3A self-hosted model last, only for what the first two miss, such as a name written in lower case or a person described by role and location.
• 4Managed cloud detection services still count as processors even inside your cloud account, so review their terms like any other vendor's.

Illustrative: a construction software vendor keeps redaction in-house#

Illustrative: a fictional vendor of construction project management software wants to prepare Intercom conversations and Jira issues for a licensing review. An engineer proposes pasting batches into a public chatbot to strip names.

The CTO stops the plan after checking the company's enterprise customer agreements, several of which restrict subprocessors. Instead, the team runs an open-weight model on a GPU instance in the company's existing cloud account, prompted to return labeled spans, plus a pattern detector for emails, phone numbers and project addresses.

Code applies placeholders to the original text, a reviewer reads a sample, and the CTO approves a package in which names and contact details are gone while RFI references, product terms and resolutions remain. No record leaves the company's environment during redaction.

How SourceX approaches redaction tooling#

SourceX treats the choice of redaction tooling as a supplier decision within the Preparation step of the SourceX five-step transaction. Records do not go to an outside service without the supplier's approval.

The privacy record in the SourceX Evidence Packet notes which tools ran, where they ran and how results were reviewed, so the buyer and the supplier's counsel can see how personal details were removed.