Voice AI guardrails: what they are, how to implement them, and where they run

Two different things now go by the name "guardrails," and conflating them is how teams end up protected against the wrong failure.

One is about what ends up in your data: the account number sitting in a stored transcript, the profanity in a caption feed, the four minutes of hold music you paid to transcribe. The other is about what your agent does with what it heard: whether it stays on topic, whether it invents a refund amount, whether it passes a plausible-looking account ID into your billing system.

The first problem has been solved for a while. The second is where most voice teams are currently exposed. This covers both — what each control actually does, which ones run on streaming audio, what they cost, and the order to build them in.

What are Voice AI guardrails?

Voice AI guardrails are controls that filter, redact, and moderate transcript content so it meets compliance and safety requirements before anything is stored or acted on. On AssemblyAI they're four features you enable per request rather than a separate product to integrate: PII redaction, content moderation, profanity filtering, and a minimum speech threshold.

Here's what each one does and where it runs:

Add-ons stack and bill per second alongside the base model rate, so a pre-recorded call with text redaction, audio redaction, and profanity filtering runs $0.21/hr for Universal-3.5 Pro plus $0.14/hr in guardrails. Full table on the pricing page.

That covers the data side. The behavioral side — keeping an agent from acting on something it misheard — is a different mechanism entirely, and it's further down.

Which guardrails work with streaming, and which are pre-recorded only?

This is the question that trips up voice agent teams, because the answer changed recently and most write-ups still say guardrails are a batch-only concern.

PII redaction now runs on streaming transcription. Set redact_pii to true when you open the WebSocket and the API redacts personal information before final turns reach your client. The important constraint is in that sentence: redaction applies to final turns only. Partial turns are sent unredacted, so if you're rendering partials straight to a screen, set include_partial_turns to false and take only the masked finals. Policies are passed as redact_pii_policies — a JSON-encoded array over the raw WebSocket, a native list in the SDKs — and redact_pii_sub picks between hash and entity_name, defaulting to hash.

Profanity filtering runs on streaming too, across all three streaming models, and it masks both partials and finals. The mask keeps the first letter and replaces the rest with asterisks, preserving apostrophes and punctuation, so shit's comes back as s***'s. Two things worth knowing before you ship it. An unmasked partial can flash briefly during word completion, which is the same reason to reach for include_partial_turns: false on a user-facing caption stream. And the filter targets a fixed word list — crap and damn deliberately pass through — so stricter policies need your own post-processing on top.

Audio redaction, content moderation, and speech thresholds are pre-recorded only. There's no streaming equivalent of a beeped audio file, which is worth knowing if your compliance requirement is about the stored recording rather than the stored text. The usual pattern is to redact text live for the agent and the live UI, then run the recording through the pre-recorded API afterward with redact_pii_audio enabled to produce the version you archive.

How do you redact PII from a transcript?

Set redact_pii to true, name the categories you care about in redact_pii_policies, and choose a substitution scheme with redact_pii_sub:

{
  "audio_url": "YOUR_AUDIO_URL",
  "redact_pii": true,
  "redact_pii_policies": ["person_name", "phone_number", "credit_card_number"],
  "redact_pii_sub": "entity_name"
}

‍

With entity_name, "Hi, my name is Sarah" comes back as "Hi, my name is [PERSON_NAME]". With hash, it comes back as "Hi, my name is ####". Pick entity_name when something downstream needs to know what kind of thing was removed, hash when it shouldn't.

For the stored recording, add redact_pii_audio: true and you get back a copy of the audio with the same spans beeped out — or silenced, if you set override_audio_redaction_method to silence inside redact_pii_audio_options. Output defaults to MP3; redact_pii_audio_quality: "wav" gets you lossless. Redacted audio files are only available for 24 hours, so build the download into your pipeline rather than into a person's to-do list.

If you need the original for a human review step, redact_pii_return_unredacted is an opt-in that returns the unredacted transcript alongside the redacted one. Think carefully before you turn it on: the whole point of redacting at the API is that the unredacted version never reaches your infrastructure, and this hands it to you anyway. It defaults to false, which is the right default.

One caveat that catches teams in review, and it's the kind of thing you only find in production: PII redaction only redacts the text property. If you're also running entity detection or summarization on the same transcript, those fields can still contain the information you just stripped out of the transcript. Redact the whole response object, not just the part you looked at.

Redacting terms that aren't PII

Standard redaction detects categories using a model. It has no idea that Bearclaw is your unreleased product, or that a particular six-character string is an internal case ID.

redact_static_entities handles that. You supply a map of labels to exact terms, and every match is replaced with the label, on top of the standard PII pass:

{
  "redact_pii": true,
  "redact_pii_policies": ["person_name", "phone_number"],
  "redact_pii_sub": "entity_name",
  "redact_static_entities": {
    "INTERNAL_TOOL": ["Bearclaw"],
    "PROJECT": ["Halyard"]
  }
}

Matching tolerates casing, punctuation, and minor spacing or hyphenation drift from the transcription — listing Bearclaw catches bearclaw, Bearclaw's, and Bear-claw. It doesn't infer a category, so a term you didn't list isn't redacted. It requires redact_pii: true, runs as the final step, and matched terms are bleeped from redacted audio alongside standard PII.

Redacting part of an address

The granular location_* policies let you strip a street address while keeping the city — useful when your analytics need geography and your compliance policy doesn't allow doorsteps.

Matching is shape-dependent, which is the part worth reading twice. A full contiguous mailing address is treated as one location_address span. But a combined phrase that doesn't form a full address — Toronto, Canada — is treated as a single generic location span, and the granular subtypes won't match it. If you need both, include the broad location policy as well.

How do you catch sensitive content that isn't PII?

Content moderation flags what was discussed rather than who was named. Set content_safety to true and you get segment-level results across 19 topics — hate speech, weapons, crime and violence, drugs, gambling, terrorism, health issues, company financials, NSFW, and others — each with a timestamp, a confidence score, and, for most labels, a severity score.

The confidence and severity split is the useful part. Confidence answers whether the topic came up; severity answers how badly. A support call where a customer mentions a car accident and a call describing a violent incident both flag accidents, and only severity separates them. Tune the sensitivity with content_safety_confidence, an integer between 25 and 100 that defaults to 50.

Because results are segment-level with timestamps, this works as a routing signal rather than a pass/fail gate: send high-severity segments to a human, let the rest through.

Can a guardrail lower your bill?

One can. speech_threshold takes a value between 0 and 1 and refuses to transcribe a file whose speech percentage falls below it. You get an error naming the measured value instead of a transcript, and you don't pay for the transcription.

That sounds minor until you're running a contact center archive where a meaningful share of recordings are hold music, dropped calls, and voicemail beeps. It's supported for all languages, regions, and models, and it doesn't carry an add-on charge.

The guardrail most voice agent teams are missing

Everything above protects your storage. None of it protects your systems.

Here's the failure that actually costs money. A caller says an order number. The model mishears one character. The agent calls your refund tool with an argument that looks entirely plausible, and refunds the wrong order. No PII leaked. No sensitive content flagged. Every data guardrail passed, and you still have a support ticket and a chargeback.

Three mechanisms address that, and not one of them is a redaction setting.

Get the input right first. A guardrail that filters bad output is doing repair work; accurate transcription is prevention. And the metric that predicts this isn't word error rate — it's entity error rate, because entities are exactly what an agent acts on. Here's the Pipecat open STT benchmark, run on real agent conversations. Lower is better:

Word error rate varies by roughly 2x across those models. Entity error rate varies by more than 3x. A 50.50% entity error rate means half the names, places, and numbers come back wrong — and every one of those is an agent about to act on something that wasn't said.

You can push those numbers further on your own vocabulary. Keyterms prompting biases the model toward exact strings you supply, and it's included at no extra cost on Universal-3.5 Pro Realtime. Limits differ by surface: async accepts up to 1,000 words or phrases with a maximum of six words per phrase — treat that as a ceiling rather than a promise, since tokenization, capitalization, and longer words all consume capacity — while a streaming session takes at most 100 keyterms of 50 characters each.

Constrain the shape of what a tool will accept. In the Voice Agent API, a tool's parameters is a JSON Schema object, and the keywords you set on each property do real work at runtime. enum restricts a value to a fixed set, which removes "the model invented a category" bugs entirely. pattern is a regex the produced value has to match. examples and format describe the shape for well-known types like emails and dates. A spoken value that doesn't fit is rejected before your tool runs, and the agent re-asks for that one value instead of firing with garbage. The same hints sharpen turn detection — knowing what a complete phone number looks like is what stops the agent cutting in after "my number is four one five…".

Two caveats worth having before you write your first pattern. The agent's cleanup of spoken input is best-effort, not guaranteed: it's reliable for well-known shapes, but a long digit sequence can reach your tool as it was spoken, spaces and all — "4 2 4 2 4 2…" for a card number the caller read one digit at a time. And a pattern that only accepts the tidy form (^\d{16}$) doesn't fail safe, it fails loud: every attempt is silently rejected and the caller hears "I didn't catch that" on repeat. Write patterns that bound the digit count rather than the character count, allow interior spaces, and strip non-digits in your own handler.

Gate the tools themselves. Progressive tool reveal is the strongest version of this: don't register every tool at session start. Expose the lookup tool first, and only add the commit tool after the lookup returns a real result. A tool that isn't in the current list can't be called, so the model cannot book the ride before it has resolved the pickup address — it can verbally promise a booking, it just can't create one. Pair it with an anti-fabrication clause in the system prompt, because gating makes a hallucination harmless without stopping the agent from saying it out loud.

All of this runs on the same WebSocket as the speech, at a flat $4.50/hr covering speech-to-text, the language model, and speech synthesis. There's a walkthrough in building with the Voice Agent API.

What compliance frameworks do voice AI guardrails support?

Guardrails are controls, not certifications — they help you meet obligations that sit with you. What they map onto:

• PCI DSS v4.0. Held at the platform level. Redacting credit_card_number, credit_card_cvv, and credit_card_expiration from both transcript and audio also keeps cardholder data out of the systems where you'd otherwise have to defend it.
• HIPAA. AssemblyAI enables covered entities and their business associates subject to HIPAA to use the AssemblyAI services to process protected health information (PHI). AssemblyAI is considered a business associate under HIPAA, and we offer a standard Business Associate Addendum (BAA) that is required under HIPAA to ensure that AssemblyAI appropriately safeguards PHI. The BAA can be signed in minutes, without a sales call.
• GDPR. EU data residency runs at api.eu.assemblyai.com and streaming.eu.assemblyai.com, at the same price as US, with data staying in the EU.
• SOC 2 Type 2 and ISO 27001:2022. Held at the platform level, alongside self-hosted deployment in your own cloud when data can't leave it.

Commure, which builds healthcare AI infrastructure and ambient documentation, sits at exactly this intersection of accuracy and controls:

"We've integrated the newest models from AssemblyAI for pre-recorded audio ASR in our ambient product, and it's been excellent. We're now exploring Universal-3.5 Pro for async and realtime speech-to-text capabilities for new use cases. What's been just as important is the reliability of the platform itself—both technically and in terms of partnership." — Gautam Pradeep, Tech Lead, Commure

Calabrio and Nextiva run comparable stacks on the contact center side, where the compliance surface is PCI rather than PHI but the architecture is the same.

Build the guardrail layer in this order

1. Redact at the API, not after it. A redaction step that runs in your own service means the unredacted version existed in your infrastructure. Set the parameters on the request.
2. Redact the whole response. Text, audio, and any Speech Understanding fields you also requested.
3. Turn on moderation as a routing signal, not a gate. Severity scores are more useful for deciding what a human sees than for pass/fail.
4. Add a speech threshold before you tune anything else about cost. It's the cheapest line item on this list, and free.
5. Put shapes on your tool parameters, and gate the tools that commit. This is the one most teams skip, and the only one on the list that prevents an action rather than a disclosure.

The part worth internalizing

Guardrails get discussed as a cost of compliance — a tax you pay to put voice into production. That framing made sense when the only question was what ended up in storage.

It doesn't anymore. Redaction protects you from what you keep. Entity accuracy, parameter hints, and tool gating protect you from what you do — and as more voice pipelines start taking actions rather than producing records, that's where the exposure moved. Most teams have built the first half and assume it covers them.

Check which half you have. The pipeline that redacts perfectly and then refunds the wrong order is still a pipeline with a guardrail problem.

More on what sits alongside this on the Guardrails product page and in the API reference.

Frequently asked questions

What are AssemblyAI's Voice AI Guardrails?

Voice AI Guardrails are four built-in controls that filter, redact, and moderate transcript content: PII redaction across text and audio, content moderation across 19 sensitive topics, profanity filtering, and a minimum speech threshold. They're request parameters on the existing speech-to-text APIs rather than a separate product, so enabling one is a field in your JSON payload. PII redaction and profanity filtering run on both pre-recorded and streaming audio; audio redaction, content moderation, and speech thresholds are pre-recorded only.

Can I use AssemblyAI's Guardrails with streaming speech-to-text?

Yes, for PII redaction and profanity filtering. Set redact_pii or filter_profanity when you open the WebSocket connection. PII redaction applies to final turns only, so set include_partial_turns to false if you render partials directly to users; profanity filtering applies to both partials and finals. Audio redaction has no streaming equivalent — run the recording through the pre-recorded API afterward to produce a redacted audio file.

What is the pricing for AssemblyAI's Voice AI Guardrails?

Guardrails are per-hour add-ons that stack on the base model rate and bill per second: profanity filtering is +$0.01/hr, PII text redaction +$0.08/hr, PII audio redaction +$0.05/hr, and content moderation +$0.15/hr. Speech threshold carries no add-on charge. A pre-recorded call on Universal-3.5 Pro with full text and audio redaction runs $0.21/hr plus $0.13/hr in guardrails, with no minimum commitment.

Does AssemblyAI automatically redact patient PII from medical transcripts?

Redaction is opt-in rather than automatic — you enable redact_pii and name the policies, including healthcare-specific ones like healthcare_number, medical_condition, medical_process, and drug. Redaction runs across both the transcript text and, with redact_pii_audio, the stored recording, so an archived clinical call doesn't carry identifiers the transcript no longer has. For clinical accuracy on the same audio, Medical Mode is a separate add-on activated with domain: "medical-v1" alongside Universal-3.5 Pro. AssemblyAI is considered a business associate under HIPAA and offers a standard Business Associate Addendum (BAA) for customers processing PHI, signable in minutes without a sales call.

Can speech-to-text APIs detect profanity or compliance issues?

Yes, through two separate mechanisms. Profanity filtering masks a fixed list of profane words with asterisks as the transcript is produced, on both pre-recorded and streaming audio. Content moderation is the broader control: it flags 19 categories of sensitive content — hate speech, weapons, crime and violence, drugs, and others — at segment level with a confidence score and a severity score, so compliance review can be triaged by severity rather than applied to every call.

How do I keep a voice agent from acting on something it misheard?

Two layers, and the redaction guardrails don't cover either. First, evaluate the speech model on entity error rate rather than word error rate, since entities are what agents act on — on the Pipecat open benchmark, Universal-3.5 Pro Realtime records a 15.31% entity error rate against 50.50% for Deepgram Flux. Second, constrain your tools: in the Voice Agent API, JSON Schema parameter hints (enum, pattern, examples, format) cause a value that doesn't match the expected shape to be rejected before the tool runs, so the agent re-asks instead of acting, and progressive tool reveal keeps a commit tool out of the model's reach until the prerequisite lookup has actually returned.

‍