Running a Voice AI Pilot in a Regulated Contact Centre
A voice AI pilot in a regulated contact centre lives or dies on three mechanics: how consent gets captured before the model ever hears a customer's problem, how transcription accuracy gets audited after the call ends, and how the system decides it's out of its depth. Get any one of those wrong and the quality of the underlying language model stops mattering. You end up with a compliance incident, a bad transcript feeding a bad decision, or a customer stuck arguing with a bot that should have handed off three turns earlier.
I've run pilots in insurance claims intake and in debt collections. Both are environments where one mishandled call turns into a regulatory filing fast, and both taught me things the vendor pitch decks never mention. What follows is that missing operational detail.
Consent capture requires a state machine, not a checkbox
Most teams treat consent as a single yes or no gate at the top of the call. "This call may be recorded and processed by an automated system, press 1 to continue." Necessary, sure. Nowhere near sufficient once you're in a regulated environment, though, because consent scope moves around mid-call in ways a single gate can't capture.
A customer might agree to voice recording and transcription but never agree to having that transcript used for model retraining later. Same customer might be fine with an AI agent handling a balance inquiry, then expect a human the second the conversation touches a medical diagnosis code or a dispute over how much they actually owe. Treat all of that as one binary flag and you've built the wrong system before the pilot even starts.
What actually worked was layering it: recording consent at call start, a separate AI-handling consent captured before the bot takes over from the IVR, and data-use consent for retraining or QA sampling or third-party review disclosed on its own, usually through a follow-up SMS rather than crammed into the call script where nobody's really listening anyway. Each layer gets logged with a timestamp, the exact script version played, and the customer's response, whether that's a spoken yes, a keypress, or silence. And silence is its own headache. TCPA and GDPR do not agree on what silence means, and your legal team won't either, unless you force the question early and get it in writing.
One thing that catches almost every team off guard the first time: consent has to be revocable mid-call, not just locked in at intake. A customer says "I don't want this recorded" three minutes into the conversation, and the system needs a defined behavior for that exact moment. In our build it triggered an immediate handoff to a human agent, plus a hard stop on any downstream processing of that audio beyond whatever the legally required retention window demanded.
Transcription QA: treat confidence scores with skepticism
Vendors hand you a word-error-rate number off their own benchmark and act like that settles it. It doesn't. WER on a clean benchmark dataset tells you almost nothing about a real call center recording, with cross-talk, a bad cell connection, a customer whose accent the model wasn't tuned on, or someone eating lunch three inches from the microphone.
So the fix is a sampling program that runs continuously, not a validation exercise you do once and file away. Pull a random slice of calls every week, have a human review the transcript against the audio, and track error rate by category. Numeric misfires matter most, dollar amounts, account numbers, dates. Name and address errors matter too. But the category I actually worry about is what I've started calling intent-flip errors, where the transcript reads close enough to correct but flips the meaning in a way that would change a downstream decision. "I do not want to proceed" rendered as "I do want to proceed" is a single dropped word. It's also a five-alarm problem if that transcript feeds an automated account closure.
Stratify the sample instead of pulling it evenly. Weight it toward your highest-risk call types: collections calls involving payment disputes, claims calls involving denials, anything touching a protected category of information. A regulator evaluating whether your system is fit for purpose cares far more about how it fails on the hard calls than how well it does on average. I've seen a system post 96% accuracy overall and drop into the low 80s specifically on hardship claims, and that gap never shows up if you're only looking at the aggregate number.
Set a cadence and hold to it. Weekly for the first few months, monthly once the error rate settles down. And when a transcript gets flagged for an intent-flip error, send it back to the vendor with the actual audio clip attached, not a paragraph describing what went wrong. Vague feedback gets you a vague fix, every time.
Escalation thresholds: the part nobody wants to own
Every pilot eventually runs into the same wall: at what point does the system admit it can't handle this and pass the customer to a person? Set the threshold too conservative and you escalate half your call volume, which defeats the entire point of running a pilot and irritates agents who now field a queue full of interruptions. Set it too permissive and the bot keeps going into territory it has no business handling, sometimes with a customer who's genuinely in financial or emotional trouble on the other end.
Threshold works better as a composite of signals than as a single confidence score. Speech-to-text confidence still matters, but weight it alongside intent-classification confidence, sentiment signals like a raised voice or repeated interruptions or specific distress phrases, and a hardcoded list of topics that force escalation no matter how confident the model claims to be. That last part is the one that matters most in a regulated setting. Bankruptcy, self-harm, legal action, a request for a supervisor: any of those should trigger an immediate handoff, full stop, regardless of what the confidence score says. Confidence is a statistical property of the model's output. It has nothing to do with whether the topic belongs in an automated system at all, and treating those two things as the same is where a lot of pilots go wrong.
Log every escalation with the specific trigger, whether that's low ASR confidence, a sentiment threshold breach, a hardcoded keyword, or a manual agent override, and review that log weekly to retune. Early in one pilot, our sentiment model kept over-triggering on customers who just talked fast, a regional speech pattern the model hadn't seen enough of in training. Nobody caught that from the escalation rate alone. You only find it by reading the actual reasons behind each escalation, one by one.
What the pilot actually proves
A successful pilot proves you have a working system for knowing when the AI fails, and a feedback loop fast enough to fix it before the failure does real damage. Consent architecture, QA sampling, and escalation thresholds are the three legs holding that up. Skip one and you're carrying real liability no matter how clean the interface looks in the demo.
Regulators looking at these systems, and attention here is growing fast across financial services and healthcare communications, will ask less about benchmark accuracy and more about your audit trail. Who consented to what. How you caught the errors that slipped through anyway. How you know the system knows its own limits. Answer those three with actual logs and actual process, not a slide deck, and the pilot has done its job.
