Where PHI actually lives in your voice AI stack

The seven layers a health system security review walks, the four places voice AI companies usually fail it, and why the fastest architecture is usually the least covered.

Prefia field notes · by Sanjeev Sharma

You have a signed pilot with a health system. Legal is done, the clinical champion is enthusiastic, and go-live is six weeks out. Then the security questionnaire arrives, and one line stops everything:

You have eleven vendors in your call path. You have BAAs with three of them. The deal does not die. It just stops moving for two months while you retrofit agreements you should have had from day one, and your champion spends that time explaining to their CISO why they vouched for you.

This is the single most common reason voice AI pilots stall in healthcare, and it is entirely avoidable. Here is the map.

The mistake underneath it

Most voice AI teams treat HIPAA as a transcript problem. Redact names and dates of birth from the text, and you are clean. You are not, for two reasons.

Voice is itself an identifier

HIPAA's Safe Harbor de-identification standard lists eighteen identifiers that must be removed. One of them is biometric identifiers, including finger and voice prints.

The raw audio is PHI. Scrubbing the transcript does nothing to the WAV file sitting in your object storage, the recording your telephony provider retained for debugging, or the audio buffer your speech provider held for model improvement. A patient's voice, attached to the fact that they called a cardiology clinic, is protected health information before a single word gets transcribed.

This catches almost everyone, because the redaction pipeline feels like the compliance work. It is not. It is one layer of seven.

The chain has no weak links

Under HIPAA, your subcontractors are business associates too. A complete chain of agreements, from the covered entity to you and from you to every vendor that touches the data, is the requirement. One uncovered hop is a breach, regardless of how well secured the other ten are.

That is what the questionnaire is actually testing. Not whether you are careful. Whether the chain is complete.

The seven layers

Rather than a vendor comparison table, which goes stale within a quarter and differs by product tier and configuration, here is the question to answer at each layer. Answer all seven and you can fill in any security questionnaire in an afternoon.

1. Telephony and transport

   Which specific products are covered, and is recording enabled?

   Major providers offer BAAs, but typically only across a defined list of eligible services, and often only once the account has been explicitly designated for healthcare use. General account-level coverage is rarely automatic. Recording deserves its own attention, since it is usually the layer that persists audio longest, under the default retention policy nobody changed.

2. Speech-to-text

   Where is the audio processed, and how long is it retained?

   Ask specifically about retention for model improvement. Several providers retain audio by default and require an explicit contractual or configuration change to stop.

3. The language model

   Which surface, and which tier?

   Coverage is per surface, not per vendor. With Anthropic, for example, the first-party Messages API can process PHI under a signed BAA with a HIPAA-enabled organisation, and Claude Enterprise can once an admin enables HIPAA readiness, while consumer tiers, Workbench and Console, and beta features have no coverage path. Claude Code is conditional, covered on specific paths only when Zero Data Retention is enabled. The cloud-hosted routes run under the cloud provider's BAA instead, which is often the cleaner arrangement. Every major provider has an equivalently shaped set of distinctions. "We use vendor X, they are HIPAA compliant" is not an answer to this question.

4. Text-to-speech

   Does synthesised output contain patient information?

   The most missed layer. If your agent reads back an appointment time, a medication name, or a provider's name, you are transmitting PHI to your TTS vendor. Teams that carefully secure the inbound path routinely leave the outbound one wide open.

5. Observability, logging, and evals

   What is in the trace?

   This is the biggest hidden leak in the modern stack. Your LLM observability tool captures full prompts and completions, which means the patient's entire context, verbatim, sitting in a third-party SaaS you almost certainly have no BAA with. Same question for error monitoring, product analytics, and any prompt-management tool. And if humans review call recordings for quality, those reviewers are workforce members with PHI access, which carries its own training and access-control obligations.

6. Storage and retention

   Where does audio actually live, and for how long?

   Transcripts in Postgres, audio in object storage, embeddings in a vector database, exports in a warehouse. Each needs coverage, encryption, access control, and a defined retention period. "Indefinitely, for debugging" is a finding.

7. The EHR integration layer

   What are you writing back, and under whose authority?

   Whether you go direct to Epic or Cerner or through an aggregator, this is where read scope, write scope, and audit logging get examined most closely, because it is the layer that touches the system of record. It is also where an over-broad scope request during app registration creates a problem that surfaces months later.

The four that actually fail

Across the stacks I have reviewed, the failures cluster:

1. Observability with no BAA. The trace tool was added during a debugging sprint and never revisited. It has every prompt.
2. TTS treated as harmless. Inbound audio is locked down; outbound synthesis of patient details is not considered.
3. Preview and beta APIs in production. Voice AI lives on the newest endpoints, and beta features are routinely excluded from BAA coverage even when the vendor's general BAA is signed. The realtime speech-to-speech APIs are the recurring example.
4. Default retention never changed. Every vendor in the chain keeps audio for some period by default. Nobody turned it off, because turning it off makes debugging harder.

The fastest architecture is usually the least covered. Direct speech-to-speech, edge inference, the newest preview endpoint: these are how you get latency under 800ms, and they are disproportionately the things outside BAA scope.

Nobody tells you that until a security team does, six weeks before go-live. Solving it is an architecture decision, which is why it is expensive to discover late and cheap to design for early.