Building compliant voice agents: HIPAA and PCI data flows

A voice agent hears more than a web form. It may capture a caller’s name, phone number, symptoms, appointment details, payment card, background conversation, and the reason they called, all inside one continuous stream. That data can appear again in transcripts, model requests, tool arguments, traces, recordings, review queues, exports, and evaluation fixtures.

If you own the product or engineering system, “our model provider is compliant” does not answer the hard question: where did the data go?

This guide gives teams a practical way to map and reduce sensitive data across HIPAA and PCI-related voice workflows. You will leave with an architecture review, control checklist, and test plan. It is engineering guidance, not legal advice, and it does not decide whether a specific organization or use case is legally compliant.

The short answer

Start with a data-flow map, not a certification badge. List every place audio and derived data can be captured, transmitted, transformed, logged, stored, reviewed, exported, backed up, and deleted. Then apply the correct rule and contract at each boundary.

For HIPAA-regulated work, determine with qualified counsel whether the organization and vendors are covered entities, business associates, or subcontractors, and whether business associate agreements are required. For PCI DSS, keep card data out of the general voice and model path where possible, and prevent sensitive authentication data such as card verification codes from being stored after authorization, including in audio recordings.

Do not treat redaction after storage as the main control. The safest sensitive field is the one your general-purpose model, transcript store, log pipeline, and eval dataset never received.

HIPAA and PCI are different control systems

HIPAA is a set of US federal rules governing protected health information for covered entities and business associates. It is not a product certification that makes every healthcare use compliant.

PCI DSS is an industry security standard for account data in payment-card environments. Its scope and validation depend on how card data is captured, transmitted, processed, and stored.

A voice workflow may involve one, both, or neither. Passing a PCI assessment does not satisfy HIPAA. Signing a business associate agreement does not make a card-recording design acceptable.

Global products also need to consider local privacy, call-recording, telecom, health, payment, data-residency, and consumer-protection rules. Use this article as an engineering map, then get region-specific advice.

This article reflects source material available on July 14, 2026. Standards and agency guidance change. Verify the current official text for your decision.

Scroll diagram horizontally on smaller screens.

Draw the full voice-data map

Use one real workflow and trace it from the caller to deletion.

Capture and transport

• Phone carrier, SIP trunk, WebRTC service, app, or device
• Caller ID and SIP headers
• Raw and mixed audio
• Dual-channel or participant-separated audio
• DTMF events
• Noise suppression and media relays
• Temporary buffers and packet captures

Live intelligence

• Voice activity and turn detection
• Partial and final speech recognition
• Language detection or translation
• Model context and response generation
• Text-to-speech requests and audio
• Safety, policy, or judge models running during the call
• Caches, retries, and provider fallback

Business actions

• Identity systems
• Scheduling, clinical, CRM, ticketing, or payment tools
• Retrieval systems and knowledge bases
• Messaging and callback services
• Human transfer and contact-center platforms

Evidence and operations

• Call recordings and transcripts
• Tool and application logs
• Distributed traces and error reports
• Analytics and product events
• Support tickets, screenshots, and exports
• Human quality-review systems
• Backups and disaster-recovery copies
• Evaluation datasets and regression fixtures

For each box, record owner, vendor, region, data fields, purpose, legal or contractual basis, encryption, access, retention, deletion, backup behavior, incident path, and whether the data trains any model.

If the team cannot draw the map, it cannot make a credible control claim.

HIPAA: focus on role, purpose, and safeguards

HHS guidance says that when a cloud service provider creates, receives, maintains, or transmits electronic protected health information on behalf of a covered entity or business associate, the provider is a business associate. HHS also says that storing only encrypted ePHI without holding the decryption key does not by itself remove business-associate status. A HIPAA-compliant business associate agreement and applicable safeguards are part of the relationship.

This matters for a voice stack because several vendors may handle the same call: telephony, speech recognition, model inference, speech synthesis, observability, storage, and testing. Map subcontractors and fallback providers, not only the vendor on the invoice.

HHS’s cloud guidance also says the covered entity or business associate should understand the cloud solution, conduct its own risk analysis, and establish risk-management policies. A signed BAA is necessary in many arrangements. It is not the complete security program.

Apply minimum necessary carefully

The HIPAA Privacy Rule’s minimum necessary standard generally calls for reasonable steps to limit uses, disclosures, and requests for PHI to what is needed for the purpose, with exceptions described by HHS, including certain treatment disclosures.

Do not turn “minimum necessary” into a slogan that engineers apply without counsel. Use it as a design question:

• Does the scheduling agent need the full clinical record?
• Does the speech provider need caller identity fields in metadata?
• Does a quality reviewer need an unredacted recording?
• Does the LLM need a date of birth after identity is complete?
• Does analytics need transcript text at all?

A narrow appointment tool can return only available slots. It does not need to return diagnoses because the backend can.

Audio and transcripts are not harmless exhaust

HHS’s audio-only telehealth guidance discusses technologies that record or transcribe sessions and asks covered entities to consider risks to stored recordings and transcripts, encryption, authentication, interception, and asset inventory in risk analysis.

A fictional clinic agent may ask, “Are you calling about your cardiology appointment?” Even if the transcript drops the patient’s name, the combination of phone number, appointment type, and time can still be sensitive.

Treat raw audio, partial transcripts, model context, and metadata as data surfaces to assess, not disposable implementation details.

PCI: keep card capture away from general conversation systems

PCI SSC’s June 2025 FAQ says PCI DSS Requirement 3.3.1 prohibits storing sensitive authentication data after authorization, even when encrypted. That includes card verification codes in digital audio recordings. The FAQ says teams should make every effort to prevent the data from being recorded and enable suppression or redaction when the technology exists.

That has an architectural consequence. Do not rely on a nightly job to delete CVV from call recordings. By then, the value may have reached the recorder, transcript, model context, logs, backups, and review queue.

Prefer a payment boundary such as:

• Transfer to a PCI-scoped secure payment service
• DTMF capture that keeps tones and values out of the agent and recording path
• Pause or suppress recording and transcription before collection, with verified resume behavior
• Tokenized payment methods where the agent handles only a non-sensitive token or approved last-four display
• A human payment workflow with its own controls

Exact design and scope need review by a qualified PCI assessor and your payment partners.

Test the boundary, not only the happy path

For a fictional hotel-booking agent, a caller starts reading a card number before the agent initiates the secure payment flow. The system should interrupt safely, explain the secure path, and prevent the spoken digits from persisting where policy forbids them.

This is invented to illustrate a failure path.

Test:

• Caller volunteers card data early
• Speech recognition emits digits before suppression activates
• Recorder pause or redaction API fails
• DTMF leaks into audio or transcript
• The caller switches back to speech during secure entry
• Transfer to the payment service fails
• Recording resumes too early or never resumes
• Logs capture request bodies or query strings
• A support export reconstructs sensitive data

The control must fail safe.

Design ten control layers

1. Data minimization at collection

Ask only for fields the workflow needs. Use backend lookups and tokens instead of making the caller repeat data already verified. Separate high-risk collection from general conversation.

2. Explicit routing before sensitive speech

Move the session into a protected lane before asking for a health or payment field. Update recording, transcription, model, logging, and human-review behavior as one state transition.

3. Vendor and subprocessors review

Inventory every service that can receive sensitive or derived data, including fallback models and debugging tools. Review contracts, BAAs where required, PCI responsibilities, data regions, retention defaults, training terms, breach duties, and deletion behavior.

4. Identity and authorization

Separate caller identification from authorization to view or change a specific record. Test wrong-person, shared-phone, proxy, caregiver, and failed-verification paths approved for the workflow.

5. Access control and audit

Use role-based access, unique identities, least privilege, and reviewable audit trails. An engineer should not gain broad recording access because they can open an observability dashboard.

6. Encryption and key ownership

Protect data in transit and at rest across every hop. Document who manages keys, how rotation works, and what backups contain. Remember that encryption does not remove all regulatory role or scope questions.

7. Redaction before persistence

Apply redaction or suppression as early as the workflow allows. Keep structured markers that show a protected field occurred without keeping the value. Verify redaction across audio, transcript, logs, traces, model context, screenshots, and exports.

8. Retention and deletion

Use purpose-specific retention, not “keep everything in case it helps.” Account for replicas, exports, caches, and backups. Test deletion and legal-hold behavior rather than relying only on configuration.

9. Evaluation and development data

Production evidence can leak into fixtures, notebooks, prompt examples, bug trackers, and model-tuning datasets. Create a governed process for approval, redaction, synthetic reconstruction, access, provenance, and expiry.

Our guide to turning a production failure into a regression case explains how to preserve the trigger with less customer data.

10. Incident response and recovery

Know who can disable recording, a tool, a vendor route, or a workflow. Preserve evidence safely, notify the right teams, meet applicable reporting duties, and test recovery. Include third-party failures and credential compromise.

Build policy into the state machine

Compliance controls should not exist only in a system prompt.

Represent sensitive states explicitly:

general_conversation
  → identity_pending
  → identity_verified
  → sensitive_field_required
  → protected_capture_active
  → protected_capture_complete
  → general_conversation_resumed

Each transition should have machine-enforced preconditions and side effects. Entering protected_capture_active might disable recording, stop transcript persistence, switch the media route, constrain tools, and emit an audit event. Leaving it should verify that capture ended and no sensitive buffer remains.

This is an illustrative state model, not legal guidance or a Voxeval API.

The prompt can explain the workflow to the caller. It should not be the only thing preventing a model from sending a card number to a tool.

Create a sensitive-data test matrix

Normal path

The caller provides only requested fields through the approved channel. Verify every destination and final record.

Early disclosure

The caller volunteers sensitive information before the protected state. Verify interruption, suppression, and safe redirection.

Over-disclosure

The caller adds extra health or payment details. Verify that unnecessary data is not propagated.

Tool and vendor failure

The secure capture or record system times out. Verify that data is not replayed into a less protected fallback.

Logging failure

An exception includes a request payload. Verify log filters and access controls.

Handoff

The call moves to a human. Verify what context and recording state cross the boundary.

Support and export

A reviewer opens, downloads, or shares the call. Verify role, masking, audit, expiry, and the absence of forbidden fields.

Deletion

The retention window ends or an approved deletion request applies. Verify primary stores, derived artifacts, and documented backup handling.

Use canary fixtures, never live card or health data, for automated checks. Seed values should be recognizable enough to detect leakage across systems.

Require evidence before launch

A compliance-aware release record should include:

• Current data-flow and vendor map
• Role and contract review by qualified owners
• Sensitive-state design and threat review
• Recording, transcription, logging, and redaction settings
• Access and audit evidence
• Retention and deletion evidence
• Tested normal, volunteered, failure, handoff, and export paths
• Incident and rollback runbook
• Known gaps and unsupported workflows
• Approvals and review date

Do not write “HIPAA compliant” or “PCI compliant” from an engineering checklist alone. State the assessed scope, evidence, responsible party, and date.

The voice-agent evaluation framework shows how policy and final-state checks fit beside conversation quality. The handoff testing guide covers context minimization and recording behavior across the human boundary.

Where Voxeval fits

Voxeval is being designed so teams can evaluate sensitive workflows without making raw customer data the default test asset. Cases can point to policy, use protected fixtures, check tool and final state, and record evidence access and release decisions.

The broader rule applies with or without Voxeval: map first, minimize early, enforce boundaries in code and infrastructure, and test the places where callers do something unexpected.

Common questions

Does a vendor’s BAA make our voice agent HIPAA compliant?

No single agreement settles the full system. A BAA may be required for a business-associate relationship, while the covered entity and business associates still have their own risk analysis, safeguards, policies, access, and incident obligations. Get qualified advice for your arrangement.

Can we store encrypted CVV in a call recording?

PCI SSC says sensitive authentication data such as card verification codes must not be stored after authorization, even if encrypted, and this includes digital audio recordings. Design to prevent recording or persistence and review the exact workflow with a qualified PCI professional.

Is a transcript less sensitive than audio?

Not automatically. A transcript can contain the same health, identity, or payment information and may be easier to search, copy, and export. Assess both, along with metadata and derived fields.

Should all sensitive calls avoid recording?

That depends on the workflow, applicable rules, purpose, contracts, and risk analysis. The engineering job is to support approved recording, suppression, access, retention, and deletion states reliably, not pick the policy alone.