Spoken numbers and spelled-out emails: why call transcript redaction misses them

Why does call transcript redaction miss spoken numbers?#

Call transcript redaction misses spoken numbers because most detectors look for digit patterns, and speech-to-text engines often write numbers as words. A card number read aloud may arrive as a run of number words, broken by pauses, filler words and the agent saying 'okay' halfway through.

Pattern rules for phone, card and account numbers expect a continuous string of digits with familiar separators. Checksum tests, which confirm a card number before flagging it, cannot run on a sequence of words. Named-entity models help with names and places but are weak on long numbers spoken in fragments.

The result is a transcript that passes an automated scan yet still holds the details billing and service calls exist to collect: account numbers, dates of birth, street addresses and callback numbers.

Which leak patterns are specific to call transcripts?#

The leak patterns specific to call transcripts come from how people speak and how speech engines transcribe them. Each pattern below needs its own fix, and a phone-heavy company will usually find several in one archive.

Review the list against a handful of real calls from your own archive before choosing tools. Every speech engine has its own habits with numbers, letters and punctuation, and a change of engine or settings partway through your history changes the patterns too.

How do you fix digit and letter detection before scanning?#

Digit and letter detection improves most when you build a separate scanning copy of each transcript before any detector runs. The scanning copy is never delivered; it exists so patterns, checksums and models see personal details in forms they recognize, and every hit is mapped back to the original words.

Keep word-level timestamps and turn identifiers through each step. Without them, a hit found in the scanning copy cannot be traced to the exact span in the original transcript or in the audio.

• 1Normalize spoken numbers: convert number words, 'oh', 'double' and 'triple' into digits, and drop fillers such as 'um' and 'okay' that sit inside a number.
• 2Rejoin spelled letters: merge runs of single letters and phonetic words into one token, and turn 'at' and 'dot' into symbols when they sit between letter runs.
• 3Normalize spoken dates and street numbers so they reach the same patterns as typed forms.
• 4Build a turn window: join each turn with the turns just before and after it, so split numbers appear as one string.
• 5Run detectors on the scanning copy: patterns with checksums for card numbers, models for names and places, and context cues such as 'card', 'date of birth' and 'last four'.
• 6Match known values: search for the name, phone, email and address held on the customer record linked to the call, including near spellings.
• 7Map every hit back to the original transcript span and redact it there with a typed placeholder, such as card number or email.

Where else does the same call leak details?#

The same call leaks details in several places besides the transcript text: the audio file, the automatic call summary, the agent's wrap-up note in the CRM or help desk, and the call metadata.

Audio is the hardest. Redacting a transcript changes nothing in the recording, so a dataset that includes audio needs each redacted span silenced or replaced with a tone, using the word timestamps kept from the scanning copy. Many companies decide to license text only, which also removes the voice itself as an identifier.

Summaries and wrap-up notes are written by a different system or by the agent, so they need their own pass. Metadata such as caller ID, the dialed extension, the agent's name and the exact call time can identify a person even when the words are clean.

Speaker separation matters too. When the speech engine attributes the caller's words to the agent, rules that scan only the customer channel miss them, so scan both sides of every call.

How far should automated detectors be trusted?#

Automated detectors should be trusted as a first pass, not a final answer. Presidio, an open-source SDK for finding and masking personal data that began as a Microsoft project and is now community-governed under the Data Privacy Stack organization, mixes named-entity recognition with pattern matching, rule logic and context-aware checksums, yet its documentation cautions that 'there is no guarantee that Presidio will find all sensitive information' and recommends layering further systems and protections on top.

That warning applies to every detector, commercial or open source, and more strongly to speech. A detector tuned on typed text has rarely seen a number spoken as words with 'oh' and 'double' mixed in. Plan a human review of sampled calls drawn across call types, agents, years and speech engine versions.

Treat each reviewer finding as a rule gap, not a one-off correction. Add the pattern, rerun the whole archive and sample again until reviews stop finding new leak types.

Which numbers should stay in the transcript?#

Numbers that describe the work should stay in the transcript, because they carry much of a call's value to an AI developer. Error codes, model and part numbers, quantities, appointment windows and ticket references show how problems are diagnosed and resolved, and blanking every digit erases them.

The rule is to redact by context and type rather than by format. A digit string after 'my card number is' goes; the same length of string after 'the model number on the unit is' stays, unless it is a serial number tied to one customer's equipment.

Illustrative: a home services call center finds what its first pass missed#

Illustrative: a fictional plumbing and HVAC company records calls in its cloud phone system and books jobs in ServiceTitan. Before licensing transcripts of booking and troubleshooting calls, its operations team ran a standard PII detector over the text and saw few hits.

A sample review told a different story. Callers read card numbers for deposits as number words, spelled email addresses for invoices letter by letter, and gave gate and lockbox codes using 'oh' for zero. Agents read back every address. The detector had caught almost none of it.

The COO approved a second pass with number normalization, letter rejoining, a window of neighboring turns and matching against the address and phone on each linked customer record. Gate and alarm codes became their own redaction type. The team licensed text only, dropped call summaries that copied customer notes, and kept model numbers and error codes. A fresh sample review found the earlier leak patterns closed before the dataset went to approval.

How SourceX handles call transcripts#

SourceX treats call transcripts as a Preparation task inside the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. Before anything leaves the supplier, the redaction method, the leak patterns tested and what the sample reviewers found are filed in the SourceX Evidence Packet's privacy record.

The supplier approves the prepared dataset and its scope, including whether audio is included at all. Nothing is shared during the initial assessment; the fit check asks which phone system and speech engine produced the transcripts and which call types they cover, not for the calls themselves.