Why HIPAA-aligned voice AI is no longer optional

Healthcare contact centers handle some of the most sensitive conversations in the country. PHI moves through every call, and the tools that listen, transcribe, and summarize those calls now sit squarely inside HIPAA scope.

Most HIPAA vendor questionnaires were written for databases. They ask where the data lives, who can log in, whether the disk is encrypted. Reasonable questions about a record, and the wrong questions about a voice AI system, which does not hold one record. It holds a chain.

A call is not one artifact

When an AI system processes a call, the conversation does not stay a conversation. It becomes a chain of derived artifacts — audio, transcript, summary, embeddings, model outputs, logs, often training data. Each is generated from the last, and each can live in a different system, under a different retention rule, held by a different party.

Every one of them is derived from PHI. The compliance question is not "is the vendor secure." It is which of these artifacts exist, who holds each, for how long, and under what agreement. Ask a vendor where your data is stored and you get an answer about the audio. Ask about the embeddings and you often get silence, because nobody has asked before.

Each row below needs its own answer. A vendor who answers only the first row has not answered the question.

Artifact	What it is	Questions to ask
Audio recording	The raw call, containing voice, names, conditions, addresses	Where is it stored, in what region, encrypted with whose keys? How long is it retained, and can we configure that? Who can play it back, and is playback logged?
Transcript	Machine-generated text of the call	Which model produced it, and is it the vendor's own or a third party? Is it retained after the audio is deleted? Is redaction applied, and against what identifier list?
Summary	Model-written condensation, frequently pasted into an EMR or CRM	Where does it land downstream, and does that create a second copy of PHI under a different retention rule? Is it treated as PHI, or as "metadata"?
Embeddings / vectors	Numeric representations used for semantic search and clustering	Are they stored, and where? Deleted when the source transcript is? Treated as PHI, or as non-identifying derived data? Tenant-isolated, or pooled across customers?
Model outputs / scores	Flags, sentiment, risk scores, extracted entities	Are they linked to an identifiable patient? Who can view them? Do they persist after the call record is purged?
Logs and traces	Inference logs, prompt traces, evaluation sets, error dumps	Do prompts or transcript fragments appear in logs? Do those logs reach a third-party observability vendor? What is the retention on that pipeline?
Training data	Any of the above, reused to improve models	Is our data used to train or fine-tune models? Opt-in or opt-out? Shared models, or one isolated to us? Can we get that in writing?

The last row is the one most often unexamined. A vendor can be entirely honest that your audio is deleted after 90 days and still hold embeddings, evaluation sets, and fine-tuning corpora from your calls with no stated retention.

"It's de-identified" is a claim with a legal definition

Vendors often describe transcripts or training data as de-identified. HIPAA does not treat that as a marketing term. 45 CFR 164.514 defines two ways to get there.

Expert Determination

Under 164.514(b)(1), a person with appropriate knowledge of generally accepted statistical and scientific methods applies them, concludes the risk of re-identification is very small, and documents the methods and results. If a vendor claims this method, ask for that documentation. It is a required element.

Safe Harbor

Under 164.514(b)(2), eighteen categories of identifiers must be removed. Two matter for voice AI: biometric identifiers, including finger and voice prints at (b)(2)(i)(P), and the catch-all at (b)(2)(i)(R) covering any other unique identifying number, characteristic, or code. Safe Harbor also requires, at (b)(2)(ii), no actual knowledge that the remaining information could identify the individual alone or in combination with other information.

The practical consequence: redacting names and phone numbers from a transcript is a meaningful control, but it does not make the audio de-identified. Ask which artifact the claim covers, and by which method.

The six-year retention myth

This one appears constantly in vendor material, and it is wrong.

45 CFR 164.530(j)(2) requires that a covered entity "retain the documentation required by paragraph (j)(1) of this section for six years from the date of its creation or the date when it last was in effect, whichever is later." Paragraph (j)(1) covers HIPAA documentation — policies and procedures, required written communications, and records of required actions and designations.

HIPAA does not impose a six-year retention period on medical records, and imposes no retention period on call recordings at all. What governs how long you keep a recording comes from elsewhere: your own retention policy, state law, payer and contractual terms, litigation holds. For home health, 42 CFR 484.110(c) requires clinical records be retained for 5 years after the discharge of the patient, unless state law stipulates a longer period.

Whatever window you set must hold across every derived artifact. A 90-day audio retention policy is not a 90-day policy if the transcripts, embeddings, and evaluation sets outlive it. We covered the recording side in HIPAA Call Recording Compliance: A 2026 Guide for Healthcare Operators.

Minimum necessary applies to derived artifacts too

45 CFR 164.502(b) requires that a covered entity or business associate "make reasonable efforts to limit protected health information to the minimum necessary to accomplish the intended purpose of the use, disclosure, or request." Exceptions at (b)(2) include disclosures to or requests by a health care provider for treatment, disclosures to the individual, and uses or disclosures required by law.

Nothing in that standard limits it to structured records. If QA reviewers pull full audio when the flagged 30 seconds would serve, that is a minimum necessary question. So is giving every analyst vector search across the whole corpus of patient conversations. Role-based access on the transcript viewer does not help if the embeddings are queryable by anyone with a dashboard login.

The same section, at 164.502(e)(1)(i) and (e)(1)(ii), is where the assurances chain lives: PHI flows to a business associate, and onward to its subcontractors, only on satisfactory assurances. Contract requirements sit at 45 CFR 164.504(e). That chain deserves its own treatment.

A signed BAA is not the end of diligence

On March 5, 2026, OCR announced a $10,000 settlement with MMG Fusion, LLC, a business associate, with a three-year corrective action plan. The breach affected approximately 15 million individuals. Exposed data included names, phone numbers, mailing and email addresses, dates of birth, and dates and times of medical appointments.

Note the field list. Not diagnoses. Appointment metadata and contact details, precisely what a call summary or entity extraction contains. Note also that OCR resolved directly against the business associate. "Our vendor signed a BAA" describes the start of diligence, not the end of it.

For scale: OCR's Annual Report to Congress for CY2024 records 663 breaches affecting 500 or more individuals, covering approximately 242,908,056 people, with 534 reports (81%) attributed to hacking or IT incidents.

What is law today, and what is only proposed

On December 27, 2024, HHS issued a Notice of Proposed Rulemaking to strengthen the HIPAA Security Rule, published at 90 FR 898 on January 6, 2025. HHS cites a 102 percent increase in large breach reports from 2018 to 2023, and a 1,002 percent increase in individuals affected.

It is a proposed rule. As of this writing HHS states that "while the Department is undertaking this rulemaking, the current Security Rule remains in effect," and no final rule has been published. Treat vendor claims of readiness for "the new Security Rule" accordingly, and re-check its status before relying on it.

The email you can send your vendor

Paste these. They are written to be answered artifact by artifact.

• List every artifact you generate or store from our calls: audio, transcripts, summaries, embeddings, model outputs, logs, evaluation and training datasets. For each, state where it is stored, its default retention period, and whether that period is configurable by us.
• When we issue a deletion request for a call, which artifacts are deleted, on what timeline, and which persist? Answer per artifact.
• Are our recordings, transcripts, or derived data used to train, fine-tune, or evaluate models? Opt-in or opt-out, and is that in the agreement or only the documentation?
• Do transcript fragments or prompts appear in application logs or third-party observability tooling? What is the retention there?
• If you describe any artifact as de-identified, which method under 45 CFR 164.514 applies, and can you provide the Expert Determination documentation?
• Which subprocessors touch PHI, and can we see the current list and be notified of changes?
• Who internally can access customer audio and transcripts, under what approval, and are those accesses logged and visible to us?

Broader vendor security diligence — SOC 2 scope, incident response, access reviews — is a separate exercise, written up in The Security Questions You Should Ask Any Healthcare SaaS Vendor Before Signing. The questions above are the layer that checklist does not reach.

Why this is no longer optional

Voice analytics used to be a back-office tool. It is now the system of record for coaching, QA, complaint documentation, and compliance review. Once an artifact is the evidence you hand a surveyor, its lifecycle stops being an IT detail and becomes a governance question.

You do not need a vendor to tell you they are HIPAA compliant; there is no such certification. You need them to answer the table above, row by row, in writing, and to put those answers where your BAA and retention policy can reach them.

SurfacerIQ builds call intelligence for healthcare contact centers, and we think these are the right questions to put to any vendor in this category, including us. To work through the table against your current stack, talk to us.

This article is general information for healthcare operators and is not legal advice; consult your own counsel and compliance officer before making decisions about retention, de-identification, or vendor agreements.