Redaction guides

How audio PII redaction actually works

Redacting a text document or PDF means replacing characters or flattening pixels at fixed coordinates on a page. An audio recording, by contrast, is a continuous waveform with no built-in word boundaries—you cannot run a search or regular expression directly on raw sound samples. Reliable audio PII redaction requires turning speech into accurately timed words, understanding which spoken phrases are actually sensitive, mapping those phrases back to exact millisecond ranges in the audio, and giving a human reviewer the tools to verify and adjust the result before export.

The ASR + LLM pipeline behind AnyRedact

Rather than relying on a black-box redaction API, our audio redaction and speech redaction tool splits the job into four transparent stages:

1. Overlapping audio chunks: In your browser, the recording is decoded into 16 kHz mono WAV chunks with a short overlap between consecutive chunks. If a caller reads a surname or credit card number right across a chunk boundary, the overlap ensures the word is never cut in half—each chunk keeps only the words whose midpoint falls inside its own window.
2. Word-level automatic speech recognition (ASR): Plain sentence transcripts aren’t enough to bleep audio cleanly; every word needs an accurate start and end timestamp. Even a half-second timing drift can leave the first syllable of a name or the last digit of a phone number audible. We benchmarked speech models specifically on how completely their word timestamps cover spoken PII, using Microsoft MAI-Transcribe-2 (with automatic fallback to Deepgram Nova-3 and Whisper large-v3-turbo) for tight word-boundary alignment across 60+ languages.
3. LLM + pattern detection on the transcript: Once timed words are assembled into a transcript with character offsets, a large language model paired with deterministic checks (such as Luhn validation for payment cards, IBAN checksums, and phone/ID patterns) scans the text in full conversational context. When a person’s full name is identified early in a call, every shorter mention of their first or last name later in the recording is caught automatically.
4. Sample-level bleeping and re-encoding in your browser: Every flagged character span is mapped back to the start of its first spoken word and the end of its last spoken word, then widened with a 150 ms safety pad on both sides so consonant onsets and trailing syllables don’t slip through. When you click Download, your browser replaces those audio samples with a 1 kHz tone (or silence) using short fade-ins and fade-outs to avoid clicks, and encodes a brand-new audio file stripped of ID3 and MP4 metadata tags.

Why dedicated PII redaction models perform worse on audio

Many teams initially reach for either dedicated PII token-classification models (small BERT/DeBERTa NER taggers or Presidio-style pipelines) or the built-in pii_redaction flags offered by cloud speech APIs. In practice, pairing word-level ASR with an LLM outperforms dedicated PII models on real call recordings for several reasons:

• Spoken PII rarely looks like written PII: Dedicated NER models are trained primarily on clean written text with standard punctuation and casing. On a phone call, people read numbers in groups with pauses or filler words ("four five three nine—hang on—fourteen eighty-eight…"), spell emails and usernames out loud ("r dot delgado at outlook dot com" or "kofi underscore mensah 88"), and dictate addresses conversationally. An LLM understands spoken phrasing and disfluencies that slip right past rigid token classifiers.
• Context separates private data from public numbers: A dedicated PII tagger flags every phone number or date it sees—muting harmless appointment times, invoice totals, or a company’s own 0800 support line. An LLM reads surrounding context to distinguish a caller’s personal mobile number from a public helpline, and connects a casual first-name mention back to the full name introduced five minutes earlier.
• Black-box speech redaction APIs bake mistakes into the audio: Turnkey speech APIs that return a pre-redacted audio file give you no way to recover from an error. If the model falsely bleeps a key figure the recipient needs to hear, that audio is already destroyed; if it misses a softly spoken postcode, you have no timeline editor to bleep the gap yourself.

Why manual redaction is non-negotiable for audio

No automatic pipeline—whether ASR + LLM or an end-to-end speech model—can catch 100% of sensitive audio on its own. Real-world recordings include crosstalk where two people speak at once, heavy background noise, names spelled letter by letter ("S-M-I-T-H", which speech models often transcribe as separate single letters), and mumbled words that the ASR model mishears or skips entirely.

Because AnyRedact keeps the transcript, the detected spans, and the audio waveform linked in an interactive editor before anything is burned into the file, you stay in full control:

• Keep false positives in one click: Click any highlighted word in the transcript or bar on the timeline to uncheck it so it stays audible.
• Highlight words or add custom terms: Select any phrase in the transcript to bleep it on the spot, or type client names, codenames, and internal IDs under Always redact to bleep every spoken occurrence.
• Drag directly on the waveform timeline: If a speaker mumbles a number or someone says a name in the background that never appeared in the transcript, simply click and drag across that stretch of the audio timeline to bleep or silence the raw audio directly.
• Verify by ear before exporting: Click any word or timestamp to jump playback to that exact second, listen to how the bleeps line up, and export both your clean audio file and a matching redacted transcript when you’re satisfied.

For a quick walkthrough of the editor controls, see our step-by-step guide on how to redact an audio recording.