Once you transcribe calls, you have a searchable text copy of everything callers said, including things they should not have to repeat anywhere else. Phone calls are full of personal details: people spell their email, read out an order number, give an address for a delivery or recite a card number because an agent asked.
Redaction, the removal or masking of such details from text, is the standard answer. It is also easy to do badly and to believe it is done well. This guide is about the practical side: what shows up in calls, how redaction methods work, where they fail and how to decide what to remove at which stage. It is a practical guide, not legal advice. What you must do depends on where you operate and what your customers have been told, so involve your counsel and privacy lead.
What personal data shows up in calls
Think in categories, because each behaves differently in a transcript:
| Category | Examples in speech | Why it is hard |
|---|---|---|
| Numbers read aloud | Card numbers, order numbers, account numbers, phone numbers | Spoken in groups, with pauses, “oh” for zero, corrections (“sorry, 5 5 4”) |
| Contact details | Email addresses, street addresses, postcodes | Spelled letter by letter, with “at” and “dot”, often mis-transcribed |
| Names | Customer, family members, agents | No fixed pattern; common words can be names |
| Identifiers | Birth dates, government or membership IDs, security answers | Look like ordinary numbers and words |
| Context that identifies | “My neighbor at number 12”, an employer, a rare situation | Not a pattern at all; a person must judge |
| Metadata | Caller phone number, call time, agent identity | Lives in the call record, not the audio |
Notice that one category is not in the transcript text at all. The caller's number and the agent's identity arrive with the call record, and they need their own handling.
Approaches, and how each one fails
Pattern rules
Rules look for the shape of a thing: sixteen digits that pass a card checksum, text with an at sign and a domain, a link with parameters. They are predictable and easy to test and version. They fail on speech: digits come out as words (“four one one one”), and speakers pause and restate. A good rule set normalizes spoken numbers first, then matches patterns.
Model-based detection
A trained model or a language model can spot names, addresses and unusual formats that no pattern covers. It is flexible and also non-deterministic: it can miss on Tuesday what it caught on Monday, and it is hard to prove what it will not miss. Using a model for redaction also means the unredacted text goes to that model, which is a decision to make deliberately.
Combined
The common design is both: rules for what has a clear shape, with checks that are exact, and a model or review step for the rest. Whatever you pick, plan for three failure modes:
- Misses. Data that stays in the text. The dangerous one. Measure it by hand on a sample of real calls, listening to the audio next to the redacted transcript.
- Over-redaction. Useful text removed: product codes mistaken for card numbers, a model number deleted, “order 5 days ago” mangled. Too much of it makes analysis useless, and people turn redaction off.
- Transcription errors. If speech-to-text writes “jane at example dot com” as “Jane at sample dot calm”, no rule will find it. Redaction can only be as good as the transcript.
Before analysis, before display, or both
The question is not just whether to redact, but where in the path of a call. There are three distinct moments:
- Before any analysis outside your own boundary. If transcripts go to an outside service for analysis, strip what that service has no need to see: card and payment details, emails, ID numbers, links with parameters, phone numbers. This is the strictest and most valuable step.
- Before search and indexing. A search index that holds raw text becomes another copy of the sensitive data. Index the redacted text, and treat queries that look like numbers with care.
- Before display. Supervisors who coach from a call may need to read the transcript and hear the audio. Showing redacted text by default, with a way to reveal a specific item with a stated reason, keeps casual browsing from becoming exposure.
The same detail may be needed in one place and not another. An agent's name matters for coaching, but an analysis service does not need it: replace names with stable aliases before analysis and map them back inside your own system. Callers' phone numbers can be replaced with a keyed, irreversible identifier so that repeat contacts can still be linked without anyone handling the number.
Audio is data too
Redacted text does not make the recording safe. The audio still contains the card number. Decide separately who can play recordings, whether your phone system pauses recording during payment, how long audio is kept and how it is deleted. A carefully redacted transcript next to an unrestricted audio file protects very little.
Access logs: the other half
Redaction limits what can be seen. Logs record what was seen. Useful logs are:
- Specific. Who played which call, who revealed which detail, who exported what, when and for what stated reason.
- Append-only. Nobody, including administrators, should be able to edit a past entry.
- Reviewed. A log nobody reads is a record for after something goes wrong. Pick a regular review, even a monthly spot check of reveals and exports.
Pair the log with roles: agents see their own calls, team leads their teams, and exports exclude phone numbers unless a permission says otherwise.
A practical checklist
- List the personal data categories in your calls, based on listening to real ones, not on guesses.
- Decide per category: remove before outside analysis, before indexing, before display, or keep.
- Normalize spoken numbers before applying patterns.
- Test on a hand-checked sample: count misses and over-redaction separately.
- Version the redaction rules and store the rule version with each result, so you can tell which calls were processed under which rules.
- Reprocess when the rules improve, and keep the old results traceable.
- Handle phone numbers and agent names in the call record, not only in the text.
- Restrict and log audio playback, number reveals and exports.
- Set a retention period and a way to delete all the calls of one customer on request.
- Have counsel review recording notices and consent for where you operate.
How VoiceVera handles it
In VoiceVera, redaction runs before any AI analysis, using a versioned rule set whose version is stored with every result. Phone numbers become keyed IDs on arrival, agents appear to the AI as aliases, and revealing a full number needs a permission and a reason and is written to an append-only log. The details are on the security page, and the integrations page covers how calls arrive in the first place.
Redaction also connects to evidence. If you analyze redacted text, every quote in a finding must come from that same text; we cover why in Why every AI finding needs a quote and a timestamp. And since the transcript is the starting point, two-channel recording helps here as well: knowing who said a number tells you which words to treat as the customer's.
Ask how we handle personal data
Send us your security questionnaire. We will answer it in full.