Why your voice AI leaks customer data on every sensitive call, and how we fixed it

Your highest-value calls leak customer data into six layers of your stack

Voice AI's highest-value use cases all involve customers speaking sensitive data out loud, whether that's Aadhaar during KYC & onboarding verification, or PAN and policy details on an insurance claim. 

In most voice AI systems, that spoken data leaks unredacted into every layer of the stack, from the STT output and raw transcript through the LLM prompt and model provider API to your prompt logs and QA dashboards, creating six copies of the same PII with no protection at any point in the chain. 

For teams deploying voice AI at scale in banking, brokerage, insurance, or lending, this is the gap that blocks compliance sign-off on the use cases that drive the most revenue, and closing it requires catching PII at the transcription layer, between the STT engine and the LLM, before it reaches anything downstream.

How SquadStack's PII redaction works

We built an inline processor that redacts PII in real time at the transcription layer, running inside your existing pipeline without requiring a separate service, a sidecar, or any architectural changes. The processor operates on the transient STT output in memory, so raw PII is redacted before any transcript is written to storage or sent downstream.

The processor replaces each detected value with a typed token, so your LLM receives [AADHAAR] instead of the actual 12-digit number. The model still knows the customer shared their Aadhaar and can respond with "Thank you, I've noted your details," but it never sees the raw value, and neither do your logs, prompts, or observability tools.

This gives your compliance team a clean audit trail, lets engineering share transcripts for QA without creating new exposure, and keeps raw PII off your LLM provider's servers. This means the compliance review that was blocking your highest-revenue deployments can now sign off.

What makes voice harder than text

On a web form, a customer types their Aadhaar into a masked field and your system intercepts it at the input boundary. On a voice call, that information arrives fragmented across turns: a customer spells their PAN as "Alpha Bravo Charlie" in one turn, "1234" in the next, and "K" in the third, with each turn looking like noise to any scanner that only reads the current transcript.

Our processor runs two detection passes on every transcript turn: the first scans the current turn alone, while the second combines it with the previous five turns in a rolling window and runs detection on the merged text. 

When a PAN or Aadhaar number spans multiple turns, the system catches it on the closing turn and redacts before forwarding anything to the LLM, with each call running its own isolated redactor instance so no customer data bleeds between conversations.

Types of PII covered

Each type has its own detection pattern tuned for how Indian customers speak these values on calls, including Hinglish dictation, spelled-out characters, and digits split across turns.

Signed off by a regulated brokerage's compliance team

This pipeline has been running in production on a deployment with Angel One, where their information-security and compliance teams reviewed the redaction approach and signed off for live customer calls. 

We treat it as a learning system because voice traffic surfaces patterns no test suite can predict. The regression suite covers 400+ known spoken-pattern cases, including Hinglish dictation, spaced digits, and multi-turn PII fragments, with every production miss converted into a new test case and a targeted fix.

Where this leaves your deployment

The calls where voice AI creates the most value are the same calls where customers share the most sensitive data, and with PII redaction running inline, the compliance gate that was blocking those deployments opens.

Book a Demo

‍