HIPAA-Compliant Voice AI Agents: Build Guide for Healthcare Call Automation

Quick Answer

HIPAA compliance for a voice AI agent means a signed Business Associate Agreement (BAA) with every vendor that can access Protected Health Information (PHI) — the telephony/SIP carrier, the speech-to-text engine, the LLM, and the text-to-speech engine — because each is technically a separate business associate under HIPAA regardless of how unified the product feels from the outside. On top of the BAA layer, HIPAA requires encryption in transit (TLS 1.2+/SRTP) and at rest (AES-256), role-based access controls, comprehensive audit logging of every PHI access event, and a minimum-necessary data-handling policy. None of this is automatic just because a vendor is "enterprise-grade" — it has to be verified contractually and built into the architecture from day one.

What Counts as PHI in a Voice AI Call

Protected Health Information isn't limited to diagnosis codes or lab results. In a voice AI context, PHI includes anything that combines individually identifiable information with health-related content: the patient's name plus the reason for their call, an appointment time tied to a specific provider or clinic, a medication name mentioned during an adherence check-in call, or even a callback number tied to a patient record. This matters architecturally because it means almost every healthcare voice AI call — not just ones explicitly about diagnoses — creates PHI the moment the agent captures caller ID, asks "what are you calling about," or reads back an appointment detail.

The practical implication for engineering teams: treat every call to a healthcare voice AI agent as a PHI-handling event by default, rather than trying to selectively route only the "sensitive" parts of a conversation through a compliant path. Selective routing is where compliance gaps get introduced.

The HIPAA Voice AI Stack, Layer by Layer

A voice AI call passes through at least four independent systems before it becomes a response the patient hears — and HIPAA treats each one as a separate business associate:

• Telephony / SIP trunk — carries the raw audio (and often caller ID/ANI) between the PSTN and your platform. The carrier needs a BAA if audio or metadata is PHI-bearing, and the trunk needs SRTP/TLS encryption end-to-end.
• Speech-to-Text (STT) — transcribes spoken PHI into text. This is often the layer teams forget needs its own BAA, especially when a voice AI platform silently routes STT to a third-party API under the hood.
• LLM reasoning layer — processes the transcribed PHI to generate a response, and may retain conversation context in memory or logs. The LLM provider's BAA needs to explicitly cover the API tier you're actually using, not just the provider's brand name.
• Text-to-Speech (TTS) — synthesizes PHI-containing responses (e.g. reading back an appointment time or medication name) back to the caller. Some TTS providers process this server-side and require their own BAA; others can run fully on-device.

A stack is only as compliant as its weakest layer. We've seen teams sign a BAA with their voice AI platform vendor and assume it's covered end-to-end, only to discover the platform's underlying STT provider was on a tier that excludes healthcare use — a gap that surfaces during a compliance audit, not during development.

Which Voice AI Vendors Actually Sign BAAs (2026)

BAA availability is a contractual and billing-tier decision, not a technical one — the same underlying model can be BAA-covered on an enterprise plan and not covered on a self-serve API key:

BAA terms change frequently — always confirm current BAA status and scope directly with each vendor before architecting a production PHI-handling pipeline around this table.

Technical Requirements Beyond the BAA

A signed BAA is necessary but not sufficient — HIPAA's Security Rule requires specific technical safeguards regardless of which vendors are involved:

• Encryption in transit — TLS 1.2+ for all API calls, SRTP/DTLS-SRTP for all call audio, no plaintext PHI on the wire at any hop.
• Encryption at rest — AES-256 for any stored transcript, recording, or extracted PHI field, including database backups and logs.
• Access controls — role-based access to PHI-containing systems, unique user IDs (no shared service accounts touching PHI), and automatic session timeouts.
• Audit logging — every read, write, or export of PHI logged with who, what, when, immutable and retained per your compliance policy (typically 6+ years).
• Minimum necessary standard — the voice agent should extract and retain only the PHI fields actually needed for the workflow, not the full raw transcript by default.
• Breach notification readiness — a documented process to detect, assess, and report a PHI breach within regulatory timelines if the voice AI pipeline is ever compromised.

Managed API Stack vs Self-Hosted Stack

There are two architecturally distinct ways to reach HIPAA compliance, and the right choice depends on call volume, budget, and how much infrastructure ownership your team wants:

See our self-hosted LiveKit deployment guide and LiveKit + Asterisk/FreeSWITCH integration guide for the infrastructure side of the self-hosted path.

PHI Audit Logging Middleware (TypeScript)

A minimal audit-logging wrapper around a LiveKit voice agent's PHI-touching functions — every access is logged before the data is used, not after:

interface PhiAccessEvent {
  timestamp: string;
  callId: string;
  actorService: "stt" | "llm" | "tts" | "telephony";
  action: "read" | "write" | "export";
  fieldsAccessed: string[];   // e.g. ["patient_name", "appointment_time"]
  purpose: string;            // minimum-necessary justification
}

async function withPhiAudit<T>(
  event: Omit<PhiAccessEvent, "timestamp">,
  fn: () => Promise<T>
): Promise<T> {
  const record: PhiAccessEvent = { ...event, timestamp: new Date().toISOString() };

  // Write immutable audit record BEFORE the PHI-touching call executes
  await auditLog.append(record);

  try {
    return await fn();
  } catch (err) {
    await auditLog.append({ ...record, action: "read", fieldsAccessed: ["ERROR"] });
    throw err;
  }
}

// Usage inside a LiveKit agent handler
const transcript = await withPhiAudit(
  { callId, actorService: "stt", action: "read", fieldsAccessed: ["raw_audio"], purpose: "transcription" },
  () => deepgramClient.transcribe(audioChunk)
);

const patientReply = await withPhiAudit(
  { callId, actorService: "llm", action: "read", fieldsAccessed: ["appointment_time", "provider_name"], purpose: "generate_response" },
  () => llmClient.complete({ context: transcript, minimumNecessary: true })
);

Common HIPAA Voice AI Mistakes

• Assuming a platform is HIPAA-ready because it's SOC 2 certified — SOC 2 and HIPAA are different compliance frameworks; only a signed BAA authorizes PHI processing.
• Not verifying BAA coverage extends to the specific STT/LLM/TTS providers a platform uses under the hood, especially when the platform lets you swap providers.
• Storing raw call recordings indefinitely with no encryption-at-rest policy or retention schedule, rather than following the minimum-necessary standard.
• Using a consumer-tier or free API key for an LLM/STT/TTS provider that only offers BAAs on enterprise or dedicated tiers.
• No audit trail on who accessed a specific patient's call transcript or recording after the call ended — this is required, not optional, under the Security Rule.
• Treating outbound reminder calls as 'low risk' and skipping BAA review because the content feels routine — appointment time + patient name is still PHI.

Healthcare Voice AI Use Cases We Build

Platform HIPAA-Readiness Comparison

For the broader platform decision beyond HIPAA readiness alone, see our full VAPI vs Retell vs LiveKit vs Bland AI comparison.

Development Cost & Timeline

• Pilot / single-use-case managed API build — $15,000–$25,000, 6–8 weeks (e.g. one intake or reminder workflow).
• Full managed API build, multi-use-case — $25,000–$45,000, 8–10 weeks (intake + scheduling + adherence, EHR integration).
• Self-hosted stack (LiveKit + Asterisk/FreeSWITCH + self-hosted STT/LLM/TTS) — $40,000–$90,000+, 10–16 weeks depending on model self-hosting complexity.
• Ongoing: managed-API BAA vendor fees scale per-minute/per-token; self-hosted scales with infra cost, typically cheaper past a few hundred thousand minutes/month.

Frequently Asked Questions

Related Reading