PII Redaction Developer Guide: Speech API Setup 2026

A contact center processing 10,000 calls daily handles credit card numbers, Social Security numbers, and health information in every conversation. One missed PII redaction creates a compliance violation costing $179 per exposed customer record, with average total breach costs reaching $4.88 million.

This guide helps you configure speech-to-text API redaction that catches sensitive data before it reaches storage and validate accuracy for compliance certification.

• PII redaction must address three compliance frameworks: PCI DSS for payment data, HIPAA Safe Harbor for healthcare identifiers, and GDPR for irreversible anonymization
• Streaming redaction with integrated pipelines achieves better latency performance than post-processing architectures that separate transcription and redaction steps
• Dual-channel audio recording improves redaction accuracy by separating agent and customer streams
• Automated systems require human review for HIPAA compliance since no tool achieves 100% identifier detection
• Credit card numbers split across transcript segments require context-aware buffering for accurate detection

Speech-to-text APIs categorize sensitive data into over 50 entity types across four categories: PII (names, phone numbers, SSNs), PHI (medical record numbers), PCI (credit card data), and other entities.

PCI DSS protects Primary Account Numbers (PAN), cardholder names, expiration dates, and service codes. Display masking allows maximum first 6 and last 4 digits. Full track data, CVV codes, and PINs must never be stored after authorization. Voice applications require DTMF suppression during IVR payment entry.

Modern speech APIs like Deepgram's redaction feature support targeting specific entities: credit_card, email_address, ssn, rather than blanket redaction. This provides protection without masking dates or numeric sequences carrying legitimate business value. APIs also detect phone numbers in various formats, including international numbers with country codes, local formats with area codes, and numbers spoken with pauses or corrections. Email addresses receive similar treatment, with detection covering spelled-out domains and common obfuscation patterns like "at" instead of "@".

HIPAA Safe Harbor requires removal of 18 identifiers including names, dates, phone numbers, SSNs, medical record numbers, and biometric identifiers. Voice prints (identifier #16) means audio recordings with identifiable voice characteristics constitute PHI. The standard is binary: all 18 identifiers must be removed with no acceptable failure threshold.

Choosing between streaming and batch redaction depends on your latency requirements and compliance framework.

Deepgram implements progressive refinement through two phases: interim results show generic [REDACTED] placeholders for low-confidence detections, while final results provide specific entity tags like [CREDIT_CARD_1] after high-confidence determination. Deepgram's streaming transcription maintains context across audio chunks to detect entities spanning multiple segments, achieving 90%+ accuracy at sub-300ms latency. Contact centers like Five9 and Sharpen use Deepgram to protect customer PCI data at scale while maintaining sub-300ms response times.

Batch processing analyzes complete audio files with full conversational context, eliminating cross-chunk detection challenges. This approach is ideal for call recordings where latency constraints do not apply. For HIPAA compliance, batch processing allows mandatory human review to achieve the 100% identifier removal standard that no automated system achieves independently.

Real-time agent assist applications require streaming with interim placeholders for immediate visibility. Call recording archives benefit from batch processing for maximum accuracy. Live voice agents need streaming redaction with post-call batch verification to catch any missed entities.

Configuration varies by vendor. For Deepgram's API, append redaction parameters to your request URL.

The following example shows how to enable multiple redaction types in a single request:

POST https://api.deepgram.com/v1/listen?redact=pci&redact=ssn&redact=pii

Available options include pci for credit cards, ssn for Social Security numbers, numbers for all numeric sequences, and pii for personal identifiers. Redacted output uses standardized format tags: first SSN appears as [SSN_1], credit cards as [CREDIT_CARD_1].

For streaming connections, pass the same parameters during WebSocket initialization:

const connection = deepgram.listen.live({

model: 'nova-2',

language: 'en-US',

redact: ['pci', 'ssn', 'pii']

});

Different substitution formats serve different use cases. Character masking (asterisks like --****-3456) provides visual redaction. Entity type labels like [CreditCardNumber] preserve context for downstream analysis. Detection-only modes support validation testing before production deployment.

Transcript redaction alone may not satisfy HIPAA when audio recordings are retained. Some providers support beep tone or silence replacement for audio-level redaction. For full HIPAA compliance with transcript-only retention, audio destruction after redacted transcript extraction eliminates the voice biometric identifier entirely.

Production deployments face challenges that demo environments never reveal.

Credit card numbers spanning multiple transcript chunks require context-aware buffering. Deepgram explicitly maintains context across chunks using its two-phase confidence approach. Other providers handle this through server-side processing or require developers to implement client-side sliding window buffering.

Contact center platforms using dual-channel recording achieve 90-95%+ PII redaction accuracy by separating agent and customer audio streams. Single-channel processing typically shows lower accuracy due to speaker overlap and cross-talk. This approach adds approximately 25% processing overhead but allows granular redaction policies: preserving agent identifiers while protecting customer data.

Research on clinical text de-identification shows automated tools achieve precision of 0.35-0.51 and recall of 0.74-0.79, meaning 21-26% of actual PHI goes undetected. Geographic subdivisions smaller than state level show highest automation failure rates. Systems struggle with contextual understanding of addresses embedded in conversation. Temporal references like "last Tuesday" or "three months ago" often pass through undetected since they lack explicit date formatting. Device identifiers and serial numbers spoken as separate elements also demonstrate elevated miss rates.

Validation requires measuring accuracy metrics, establishing audit trails, and understanding framework-specific requirements.

Measure precision, recall, and F1 scores against labeled test datasets. Configure confidence score monitoring with a typical 0.85 threshold, routing low-confidence items for mandatory manual review. Detection-only modes allow establishing baselines before production deployment.

Log what was redacted, when, and by which system. Maintain unredacted copies only in secure, access-controlled storage. Generate compliance reports documenting redaction decisions for HIPAA, PCI DSS, and GDPR audits.

HIPAA deployments require 100% removal of all 18 identifiers with no acceptable failure threshold. Since automated systems do not achieve perfect recall, healthcare organizations must implement mandatory human review capacity. Implement sampling strategies based on risk: review 100% of healthcare calls containing PHI indicators, 25% of standard customer service interactions, and 10% of low-risk informational calls.

Production PII redaction combines pre-transcription configuration, real-time processing, post-call verification, and secure storage practices.

Audio format requirements directly impact redaction accuracy. Configure recordings at 16kHz sample rate minimum with 16-bit depth for optimal speech recognition. Dual-channel recording separates agent and customer audio streams, allowing granular redaction policies. For IVR payment flows, implement DTMF suppression to prevent tone capture. Establish TLS 1.2+ connections for all API communications with certificate validation enabled.

Integrate streaming redaction directly into your transcription workflow rather than adding post-processing steps. Configure confidence thresholds at 0.85 for production deployments to balance catching genuine PII against false positives. Implement buffer management using built-in cross-chunk context handling or client-side sliding window buffers of 2-5 seconds. Monitor interim versus final results separately: interim [REDACTED] placeholders indicate active detection, while final entity tags like [SSN_1] confirm high-confidence identification.

HIPAA compliance requires human review workflows to supplement automated detection. Create escalation paths for low-confidence detections. When the API returns confidence scores below 0.85, flag those transcripts for priority review. Train reviewers on the 18 Safe Harbor identifiers with emphasis on high-failure categories: geographic subdivisions, temporal references, and device identifiers embedded in conversational speech.

Transcript-only retention eliminates voice biometric concerns entirely. Destroying original audio after redacted transcript extraction removes HIPAA identifier #16 from scope. When audio retention is required, encrypt at rest using AES-256 with customer-managed keys. Configure lifecycle policies enforcing retention periods: 7 years for HIPAA, duration of customer relationship plus applicable statute of limitations for GDPR. Implement separate storage tiers for redacted versus original content.

Architecture and compliance requirements drive platform selection.

Choose your architecture based on latency requirements. Integrated pipelines provide better performance for latency-critical applications requiring sub-300ms response times. Post-processing architectures that separate transcription and redaction APIs add overhead, affecting customer SLA guarantees and pricing models.

GDPR sets the highest bar, requiring irreversible anonymization rather than identifier removal. Technical methods meeting GDPR standards include k-anonymity (k ≥ 10), differential privacy (ε < 1.0), or voice morphing with Equal Error Rate > 40%. When multiple frameworks apply, implement controls meeting the most stringent requirement.

Platform builders embedding speech APIs into B2B products need to account for redaction latency in their unit economics. Multi-tenant architecture must support customer-specific redaction policies: healthcare clients require all 18 HIPAA identifiers while payment processors focus on PCI entities. Consider whether your platform needs audio redaction versus transcript-only approaches based on customer requirements.

PII redaction separates compliant voice applications from liability risks. The technical decisions in this guide determine whether sensitive customer data reaches storage and analytics where breaches create $4.88 million average costs.

Successful implementations require three elements. Entity type selection must match compliance requirements: PCI DSS for payment data, HIPAA for all 18 Safe Harbor identifiers, GDPR for irreversible anonymization. Streaming versus batch architecture affects both latency and accuracy, with real-time applications needing integrated pipelines that maintain context across transcript chunks. Validation workflows must account for automation limitations through confidence thresholds and human review escalation paths.

Deepgram's PII redaction supports over 50 entity types with sub-300ms streaming latency and two-phase confidence scoring that resolves interim placeholders to specific entity tags. The API maintains context across audio chunks, addressing cross-segment detection failures that plague post-processing architectures.

Ready to implement compliant PII redaction? Start building in Deepgram Console with $200 in free credits to configure entity selection and deploy streaming redaction for production voice applications.

Some providers support audio-level redaction with beep tones or silence replacement, while others support transcript-level redaction only. Organizations retaining audio should implement separate processing pipelines or destroy original recordings after transcript extraction. Deepgram's Audio Intelligence features focus on transcript-level analysis; for audio-level masking, consider transcript-only retention with original audio destruction.

Deepgram maintains context across chunks using a two-phase confidence approach: interim placeholders resolve to specific entity tags once the system achieves high confidence. Other providers handle this through server-side processing without documenting internal mechanisms. Some require developers to implement client-side buffering before passing audio to separate detection APIs.

Yes. Production deployments achieve 90-95%+ accuracy with dual-channel implementations, representing significant improvement over single-channel processing due to eliminated speaker overlap and cross-talk. This comes at approximately 25% additional processing overhead. Dual-channel also allows granular policies: preserving agent identifiers while redacting customer PII.

Production deployments typically use 0.85 as the confidence threshold for automated redaction. Lower thresholds catch more genuine PII but increase false positives that reduce transcript readability. Higher thresholds improve precision but risk missing actual sensitive data. Detection-only policies let you analyze detection patterns against labeled test data before committing to production thresholds. Start with 0.85, measure false negative rates through sampling, and adjust based on your compliance requirements.

PCI DSS requires suppressing DTMF tones during IVR payment flows to prevent card numbers from reaching recordings. Configure your telephony platform to mute or filter the audio stream during payment entry at the call recording layer, separate from transcript redaction. Most contact center platforms offer built-in DTMF suppression settings. For custom implementations, detect IVR payment prompts and pause audio capture until the transaction completes. This architectural control prevents sensitive authentication data from ever entering your transcription pipeline, complementing API-level redaction for defense in depth.