How to Redact PII from Speech-to-Text Transcripts Before They Reach an LLM

Map the data path before choosing a tool

Start by drawing every route a transcript can take to a model. The obvious route is a transcript pasted into a prompt. Less obvious routes include transcripts chunked into a retrieval index, summaries passed between agents, and tool calls that fetch call records mid-conversation. Each route is a place where personal data can cross the trust boundary you intended.

Define what counts as PII for this data. NIST defines PII as information that can distinguish or trace an individual's identity, alone or combined with other information that is linked or linkable to a specific individual. That definition is wider than a list of formats. Names and account numbers are direct identifiers, but NIST also notes that unstructured text can carry additional information that serves as a quasi-identifier. A transcript is unstructured text, so assume both kinds are present.

Scope the control to responses as well as inputs. NIST's draft generative AI profile points to detecting sensitive data in generated output, because models can leak or infer sensitive information. A redaction design that covers only the outbound prompt leaves retrieval context and model responses unexamined. NIST SP 800-122 also advises minimizing the use, collection and retention of PII to what the business purpose requires, which applies to what downstream systems keep as well as what the model sees.

Choose where redaction runs

There are three common placements: at the ASR output, at an intermediary in the request path, and in the application layer. They differ mainly in coverage and bypass risk, and the tradeoffs below come from how each is built rather than from measured benchmarks.

Redacting at the ASR output removes PII early and reduces how much sensitive text is stored. It does not cover transcripts that arrive from other systems, and it does nothing for text a user types into the prompt or for data retrieved later. Application-layer redaction is easy to ship and tune, but every service that calls a model needs the same logic, and any service that omits it is a bypass.

An intermediary in the request path sees every prompt, retrieval payload and tool result headed to a model, so one policy applies regardless of which application sent the request. Its costs are added latency on each call and a new component that must be highly available. For most security teams, the intermediary is the right enforcement point because it is hard to route around. ASR-side redaction can still be added as a minimization layer, but treat it as defense in depth rather than the control you rely on.

Whichever placement you choose, block direct egress from applications to model endpoints. A redaction point that can be skipped is a recommendation, not an enforced control.

Pick a detection approach and test it on real transcripts

Pattern-based detection handles structured identifiers with predictable formats and is deterministic and fast. Model-based detection (named entity recognition) handles names, organizations and context-dependent mentions that have no fixed format. A hybrid runs both and applies the stricter result. That is usually the practical choice for transcripts, which contain both kinds of identifier.

Transcripts break assumptions that text-based detectors are built on. Speakers say digits aloud, so an account number may appear as words, in groups, or with fillers between digits, and a digit-format pattern will not match it. Recognition errors can alter names into common words or split an identifier across tokens. Speaker labels attach identity to turns, and missing punctuation removes the sentence boundaries a model-based detector uses as context. Health details and other sensitive facts are often stated in plain sentences with no identifier format at all. Plan for each of these in your detector configuration, for example by normalizing spoken numbers before pattern matching and treating speaker labels as in scope.

NIST states that de-identification tools should be validated on the specific kinds of data they will process, and that a tool built for one format may miss identifying information in a text field. Build a labeled sample of your own transcripts, measure what each detector misses, and repeat the test when the audio source, ASR model or call type changes. Set the acceptable miss rate with the risk owner before launch, not after.

Compare substitution strategies

What replaces the detected span determines both exposure and how well the LLM can still do its task. NIST notes that selective redaction can introduce bias into data, so test each strategy against your actual use case, such as summarization or intent classification, rather than assuming it is neutral.

• Masking: Replaces the span with a fixed character string. Lowest exposure and simplest to run, but the model loses the type of information removed and cannot tell two different people apart.
• Typed placeholders: Replaces the span with a label such as a person or account type. Keeps sentence meaning and entity type for the model. Numbering the placeholders per speaker preserves who said what.
• Reversible tokenization: Replaces the span with a token mapped to the original value in a separate vault. Lets the application restore values in the response, at the cost of operating a vault that holds the sensitive data.

Control reversibility and residual risk

If you use reversible tokenization, treat the vault as a regulated data store. Keep it outside the model path, limit who and what can request re-identification, authorize each restoration separately, and set retention for mappings that matches the interaction's purpose. Restore values only after the model response returns, never in the prompt. NIST describes pseudonymization as a way of labeling multiple de-identified records from the same individual. That consistency is useful for the LLM, and it is also what makes tokens linkable if the vault or the tokens leak.

Redaction is suppression. NIST SP 800-188 states that redaction alone is generally insufficient to provide formal privacy guarantees. Quasi-identifiers can survive in a redacted transcript, such as a rare job title combined with a location. Document the residual re-identification risk threshold, who accepted it, and the validation results for the detector. NIST SP 800-122 supports context-based decisions about protection level, so record the policy rationale for what is redacted, what is allowed, and what is blocked outright.

Where runtime enforcement fits

The approach in this guide depends on enforcement in the execution path, so the decision is made on each interaction before the request reaches the model. Trussed does this for regulated enterprises: it enforces policy in the execution path across models, agents, tools and MCP servers, with allow, redact, block, rate limit and escalate outcomes applied to individual interactions and tool calls. Enforcement is at runtime, not reviewed after the fact, and it generates audit-ready evidence that maps to frameworks including HIPAA and NIST. Trussed deploys self-managed in the customer cloud, with configurable retention and data residency, so transcripts and evidence stay inside your boundary.

The design principles above hold with any tooling. Place the control where it cannot be bypassed, validate detection on your transcripts, pick a substitution strategy against your task, and produce evidence per interaction.