> Source: https://meetrix.io/blogs/hipaa-ai-voice-agent-aws/ > Markdown copy of that page. Cite the URL above, not this file. LLMs & APIs # HIPAA AI Voice Agent in Your Own AWS Account (2026) [By Shalomi Umeshika](https://meetrix.io/blogs/authors/shalomi-umeshika/) • October 21, 2026 • 11 min read English[Deutsch](https://meetrix.io/blogs/hipaa-ai-voice-agent-aws-de/)[Español](https://meetrix.io/blogs/hipaa-ai-voice-agent-aws-es/)[Français](https://meetrix.io/blogs/hipaa-ai-voice-agent-aws-fr/)[Italiano](https://meetrix.io/blogs/hipaa-ai-voice-agent-aws-it/) ## The Problem Starts Ten Seconds Into the Call A clinic's voice agent hears protected health information almost immediately. A name, a date of birth, "I'm calling about my test results." From that moment, every service the audio touches is handling PHI: the speech-to-text API, the LLM, the voice, the call recording, the logs, and whatever tracing tool someone wired up during the pilot. Each one is either a business associate you need an agreement with, or a place you can't send that data at all. Running the whole agent in your own AWS account changes the shape of that problem. The audio, the transcript, and the prompt never leave your VPC, and the list of companies you sign BAAs with gets short. This guide covers where PHI actually flows in a voice agent, the agreements you still need, the voice-specific risks (caller verification is the big one), and a reference stack. It's a technical guide, not legal advice. Have your compliance officer or counsel review what you build. The Quick Verdict Self-host on AWS High volume, few vendors allowed Audio, transcripts, and prompts stay in your VPC. AWS is the BAA that matters, and per-minute fees disappear. AWS-native AI You want fewer servers to run Amazon Transcribe, Bedrock, and Polly are all HIPAA eligible, so they sit under the same AWS BAA. You trade GPUs for per-use pricing. Managed with a BAA A pilot in the next few weeks Pick a platform that signs a BAA, and check every model provider behind it is covered too. Not yet No risk analysis on file Do the risk analysis first. Every design choice below should trace back to it. Before You Start - A named person responsible for HIPAA compliance, and a current risk analysis - An AWS account with the AWS business associate agreement accepted in AWS Artifact, ideally a dedicated account for PHI workloads - A list of every system the agent will read from or write to: EHR, scheduling, billing - Fake patients and test phone numbers. Real calls stay out of development. ## Where PHI Flows in a Voice Agent Most voice agents are a relay: caller audio in, voice activity and turn detection, speech-to-text, an LLM, text-to-speech, audio out. Our guide to the [self-hosted voice AI agent stack](https://meetrix.io/blogs/self-host-voice-ai-agent-stack/) covers each layer and the open-source pick for it. For HIPAA, the question is different: what does each layer see, and where does it keep it? | Layer | PHI it touches | Where it can persist | | --- | --- | --- | | Telephony or WebRTC | The caller's voice and phone number | Carrier call records, call recordings, voicemail | | Speech-to-text | Everything the caller says, as text | Transcript files, STT service logs | | LLM | The transcript, plus whatever your tools return from the EHR | Request logs, prompt caches, tracing and evaluation tools | | Tools and integrations | Appointments, results, medications, insurance | API logs on both sides, error reports | | Text-to-speech | Everything the agent says back | TTS logs, cached audio | | Observability | Often all of the above, in one place | Traces, dashboards, exception trackers | **The live call is rarely the risk. The leftovers are.** A transcript in a log line, a prompt in a tracing tool, a recording in a bucket nobody set a lifecycle rule on. Map every place in that third column before you go live. ## Three Ways to Build It on AWS Fewest vendors Fully self-hosted Best for high volume and strict vendor lists LiveKit for transport, faster-whisper for STT, an open-weights LLM on [vLLM on AWS](https://meetrix.io/blogs/vllm-aws-marketplace/), and Kokoro for the voice, all on EC2 in your VPC. AWS is the BAA that matters. AWS-native AI services Best for fewer servers to run Amazon Transcribe, Bedrock, and Polly, with Amazon Connect or the Chime SDK for calls. All are on AWS's HIPAA eligible list, so they're covered by the same AWS BAA. You pay per use. Managed voice platform Best for a fast pilot A hosted agent platform that signs a BAA. LiveKit is the exception to the usual enterprise-agreement requirement here: its self-serve Scale plan at $500/month includes a signed BAA, according to its security page. You'll still need the STT, LLM, and TTS providers behind it covered separately. **One thing to verify before you build:** vLLM 0.8 through 0.10 had a vulnerability (CVE-2026-15430) that affects confidential computing mode inside a Trusted Execution Environment. Use vLLM 0.10.1 or later and the SafeTensors format for model weights. Outside TEE mode, the risk is narrower, but SafeTensors is the right default either way. **Worth knowing:** Amazon Bedrock AgentCore became HIPAA eligible on February 10, 2026, alongside Bedrock itself. If you're building agent workflows rather than a straight LLM call, AgentCore gives you session isolation, policy-based access control, and audit-ready logging inside the same BAA umbrella. The first two can mix. Plenty of teams self-host the LLM, because that's where the most sensitive context lands, and use Amazon Transcribe for speech-to-text while they size their GPUs. Our [LiveKit Agents vs Pipecat comparison](https://meetrix.io/blogs/livekit-agents-vs-pipecat/) covers the framework choice, which is the same either way. ## The BAAs You Still Need Self-hosting doesn't make the cloud provider disappear. A provider that stores or processes ePHI is a business associate even when the data is encrypted, as our [HIPAA guide for self-hosted telehealth video](https://meetrix.io/blogs/hipaa-compliant-self-hosted-video-telehealth/) explains. So the agreement list for a voice agent looks like this: AWS Accept the AWS BAA in AWS Artifact, then keep PHI inside services on the [HIPAA eligible services list](https://aws.amazon.com/compliance/hipaa-eligible-services-reference/). That list passed 200 services on July 22, 2026, and it includes EC2, EBS, S3, KMS, CloudTrail, Transcribe, Polly, Bedrock, and Bedrock AgentCore. A service that isn't on the list doesn't get PHI, however convenient it is. Eligible doesn't mean compliant, though. The BAA covers the service; your settings still have to be right: encryption at rest with KMS, TLS in transit, and no PHI in logs you haven't thought about. Your phone provider A carrier that only passes the call through may fall under HIPAA's conduit exception. One that records calls, keeps voicemail, or transcribes audio is handling PHI, and likely needs a BAA. Let your compliance officer make that call for your provider. Anything that sees logs Tracing, error tracking, log search, and LLM evaluation tools are where voice agents leak. If a SaaS tool can see transcripts or prompts, it needs a BAA, or it needs to stop seeing them. People with server access Any contractor or support vendor who can log in to the instances while helping you should be asked directly whether a BAA applies. ## The Five Safeguards on a Voice Agent The HIPAA Security Rule's technical safeguards in [45 CFR 164.312](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.312) were written long before voice agents, but they map cleanly onto one. | Safeguard | On a voice agent | | --- | --- | | Access control | Give the agent its own narrowly scoped credentials for each system it calls, kept in Secrets Manager. Staff who review calls sign in individually through SSO, never a shared login. | | Audit controls | CloudTrail for the AWS account, plus an application log of every tool call: which caller, which record, which action. Log the fact of access, not the content. | | Integrity | Anything that writes to a patient record (booking, cancelling, updating) goes through a confirmation step and a validated tool, never free text from the model. | | Person or entity authentication | For staff, SSO with multi-factor authentication. For callers, a verification step before any PHI is disclosed (see below). | | Transmission security | TLS and SRTP on the SIP trunk, DTLS-SRTP for WebRTC, TLS between internal services, and the GPU instances in private subnets with no public IP. | For the staff sign-in half, [Keycloak on AWS](https://meetrix.io/blogs/keycloak-on-aws/) gives you SSO with MFA inside the same account. And remember the rule itself is moving: HHS proposed an overhaul of the Security Rule in January 2025 that would make encryption at rest and in transit mandatory rather than addressable. The final rule has been delayed to July 2027, so it isn't in force yet, but the direction is clear. Build as if it already is. ## Caller Verification Is the Voice-Specific Risk Web portals have logins. Phone lines have whoever is calling. A voice agent that reads back appointment details or results to anyone who knows a patient's name is disclosing PHI to an unverified person, and that's the failure most voice agent demos skip. The fix is a verification step before any PHI tool runs: date of birth plus a second identifier, such as the postcode on file or a code sent by text. And the important part: enforce it in code. A prompt that says "always verify the caller first" is a suggestion the model can be talked out of. A tool that refuses to run is not. ```python # Every PHI tool checks the session, not the prompt. class CallSession: def __init__(self): self.verified_patient_id = None def verify_caller(session, dob, postcode): patient = ehr.find_patient(dob=dob, postcode=postcode) if patient is None: return "I couldn't match those details." session.verified_patient_id = patient.id return "Thanks, you're verified." def get_next_appointment(session): if session.verified_patient_id is None: raise PermissionError("caller not verified") return ehr.next_appointment(session.verified_patient_id) ``` Two more rules that save trouble. Limit verification attempts per call, and hand off to a human after the limit. And never let the agent confirm which part of the details was wrong, because "that date of birth doesn't match" tells a stranger the name was right. ## Recordings, Transcripts, and Logs 1. Decide whether you record at allMany teams keep no audio, only a structured summary written to the EHR. If you record, do it deliberately, with consent, for a reason you can name. 2. Encrypt everything at restEBS volumes and S3 buckets encrypted with KMS keys you control. Snapshots and backups copy the PHI too, so they need the same treatment. 3. Turn off request logging in productionInference servers and STT services can log requests. Check what yours writes, and keep transcripts and prompts out of application logs. 4. Set retention, then enforce itS3 lifecycle rules delete recordings and transcripts on the schedule your policy sets. A retention policy nothing enforces is just a document. 5. Log access, not contentWho opened which recording, when. CloudTrail data events on the bucket give you that without copying PHI into another system. The same encryption rules from our guide to [WebRTC for AI voice agents](https://meetrix.io/blogs/webrtc-for-ai-voice-agents/) apply to the transport side: media is encrypted in transit by default, and your job is to keep the TURN relay and the agent inside your boundary. ## A Reference Stack on AWS Here's a fully self-hosted layout that keeps PHI inside HIPAA eligible services in one account. | Component | Runs on | Notes | | --- | --- | --- | | Transport (WebRTC and SIP) | LiveKit on EC2, public subnet | TLS and SRTP to the SIP trunk; see [self-hosting LiveKit on AWS](https://meetrix.io/blogs/self-host-livekit-aws/) | | Agent worker | EC2 or EKS, private subnet | LiveKit Agents or Pipecat; holds the session and enforces verification | | Speech-to-text and LLM | GPU EC2, private subnet | faster-whisper and an open-weights model on vLLM 0.10.1+, no public IP; SafeTensors format | | Text-to-speech | EC2, private subnet | Kokoro runs on CPU, Apache 2.0 licensed, suitable for zero-retention HIPAA modes | | Secrets | Secrets Manager | EHR and scheduling credentials, scoped per tool | | Storage | S3 and EBS with KMS | Lifecycle rules for anything you keep | | Audit | CloudTrail and CloudWatch | Metadata only, no transcripts | | Staff sign-in | Keycloak on EC2 | SSO with MFA for anyone reviewing calls | Every AWS service in that table is on the HIPAA eligible list. Check eligibility for your region before you build, because it can vary. On cost, the GPU dominates: our [GPU cost comparison for LLM inference](https://meetrix.io/blogs/gpu-costs-llm-inference-aws-vs-gcp/) has current instance prices, and the [vLLM developer guide](https://meetrix.io/blogs/vllm-developer-guide/) walks through launching the inference server. ## What Breaks HIPAA Here The usual ways a compliant design leaks - A SaaS tracing or LLM evaluation tool wired up during the pilot, still receiving every transcript - A fallback to a hosted LLM API "only when the GPU is busy." That's PHI going to a vendor with no BAA, at your busiest hour - An exception tracker capturing the request body when a tool call fails - Recordings in a bucket with no lifecycle rule, kept forever by default - An agent that reads back PHI before verifying the caller - A service used for PHI that isn't on AWS's eligible list, or isn't eligible in your region - Real patient calls used to test prompt changes The fallback one deserves a second look. It's the most natural engineering decision in the world, and it quietly undoes the whole design. If the GPU runs out of capacity, queue the call or hand it to a human. ## Where to Start Start with the risk analysis and the AWS BAA, not the model. Then build the verification gate and the logging rules before the agent can do anything interesting, because they're much harder to retrofit than a better prompt. For a first deployment, keep the scope narrow: appointment booking and reminders, with no results or clinical advice. Self-host the LLM, since that's where the most sensitive context lands, and decide on speech-to-text by volume. If you're doing a few hundred calls a month, a managed platform with a BAA is cheaper than a GPU idling around the clock (our [AI phone agent cost comparison](https://meetrix.io/blogs/ai-phone-agent-cost/) has the numbers). At thousands of calls a day, your own AWS account wins on cost and on the length of your vendor list. When you're ready to run the model yourself, the [vLLM store page](https://meetrix.io/store/vllm/) has the AWS and Google Cloud images. ## Frequently Asked Questions Can an AI voice agent be HIPAA compliant? Yes, but compliance comes from how you build and operate it, not from the model. You need a risk analysis, a BAA with AWS and any other business associates, PHI kept inside eligible services, access controls, audit logs, and caller verification before any PHI is disclosed. Do I need a BAA to run a voice agent on AWS? Yes. Accept the AWS BAA in AWS Artifact, then keep PHI only in services on the HIPAA eligible list. Self-hosting doesn't remove the requirement; it just shortens the list of other vendors you need agreements with. Which AWS services are HIPAA eligible for voice AI? EC2, EBS, S3, KMS, CloudTrail, Transcribe, Polly, Bedrock, and Bedrock AgentCore are on the list. The list passed 200 services in July 2026, and it can vary by region, so check the current list before you build. Is a self-hosted voice agent more HIPAA friendly than a managed platform? It can be, because fewer vendors touch the data and your PHI stays in your account. But a managed platform with a proper BAA and verified sub-processors can also be compliant. LiveKit's Scale plan, for example, includes a BAA at $500/month. The right answer depends on volume, vendor constraints, and how much infrastructure you want to run. Does my SIP trunk provider need a BAA? It depends on what they do. A pure conduit may fall under the conduit exception. A provider that records, stores voicemail, or transcribes is handling PHI and likely needs a BAA. Your compliance officer should make that call. How should the agent verify a caller? Date of birth plus a second identifier: postcode on file, or a code sent by text. Enforce it in code, limit attempts, hand off to a human after the limit, and never reveal which detail was wrong. Should the agent record calls? Only if you have a reason you can name and consent to match. Many teams keep no audio and write a structured summary to the EHR instead. If you do record, encrypt at rest with KMS, set a retention schedule, and enforce it with lifecycle rules. What does a self-hosted HIPAA voice agent cost on AWS? The GPU dominates. A roughly $1/hr GPU instance running 24/7 is about $720 a month, before storage, networking, and any other compute. At a few hundred calls a month, a managed platform is usually cheaper. At thousands a day, self-hosting wins. ## Run the LLM Inside Your Own AWS Account Launch a pre-configured vLLM inference server in your own VPC, so prompts and transcripts never leave your account. [Deploy vLLM on AWS Marketplace](https://aws.amazon.com/marketplace/pp/prodview-rvsnp5xf66l4m) Meetrix Store vLLM Serve open models on your own GPU [Deploy it](https://meetrix.io/store/vllm/) Meetrix Store New Deploy what this guide covers, pre-configured. - [vLLM Serve open models on your own GPU](https://meetrix.io/store/vllm/) - [Keycloak SSO with OIDC and SAML, an Auth0 alternative](https://meetrix.io/store/keycloak/) - [OpenWebUI A private ChatGPT-style assistant](https://meetrix.io/store/openwebui/) - [Llama 4 Scout Mixture-of-Experts, 17B active parameters](https://meetrix.io/store/llama-4-scout/) - [Jitsi Meet Self-hosted video calls for 50 to 500 users](https://meetrix.io/store/jitsi-meet/) - [RustDesk Remote desktop AMI, a TeamViewer alternative](https://meetrix.io/store/rustdesk/) [Browse all products](https://meetrix.io/store/)