HIPAA-Compliant AI Voice Assistant for Healthcare: 2026 Compliance Guide

Introduction 

When evaluating a HIPAA compliant AI voice assistant in 2026, it is important to be aware of the dynamic regulatory landscape. On January 6, 2025, the U.S. Department of Health and Human Services Office for Civil Rights (HHS OCR) issued a Notice of Proposed Rulemaking (NPRM) to strengthen the HIPAA Security Rule for the first time in over 20 years. The proposal eliminates existing flexibility, updates the technical requirements for encryption and multi-factor authentication, and requires covered entities or business associates, such as the AI voice vendors, to demonstrate the controls, rather than just describe them.

Part of this page is dedicated to evaluating an AI voice assistant against that bar, reserved for those healthcare buyers in need.

Written for the people who actually sign the BAA: Chief Compliance Officers, Privacy Officers, CISOs, Practice Managers and Health-system Procurement. There are different evaluation lenses for each of those roles. There is a checklist provided for each in §7.

At the end of this page, you’ll receive four things: a plain-English summary of the changes made to the 2025 Security Rule NPRM specific to voice technology; a section-by-section map of the 45 CFR §164 obligations as they relate to voice technology; a vendor-evaluation checklist by persona; and a list of artifacts you should refuse to sign a BAA without.

What Changed: The 2025 HIPAA Security Rule NPRM at a Glance

The Security Rule of HIPAA for healthcare was finalized in 2003. It hasn’t been structurally altered since then. The NPRM issued on Jan. 6, 2025, marks the first major update, and OCR underscored that the impetus for issuing the NPRM was the healthcare industry’s increased volume of ransomware attacks, third-party vendor breaches and the rise of cloud-hosted ePHI processors.

Source: The information is from the Federal Register, “HIPAA Security Rule to Strengthen the Cybersecurity of Electronic Protected Health Information,” Doc. 2024-30983, published January 6, 2025. The public comment period ended March 7, 2025.

Why this matters for AI voice specifically: Every time an AI voice assistant records an audio, transcribes an audio, extracts structured data from an audio, or tracks metadata on an audio, it is handling electronic protected health information (ePHI). The NPRM sets the technical standard for how that data should be stored, transmitted, accessed, logged and guarded and the business associate in charge is required to meet the standard.

NOTE

HIPAA compliance is no longer a marketing tactic, it is now an evidence process. By 2026, health technology consumers will demand evidence from each AI voice service provider.

The 7 Most Important NPRM Changes for AI Voice Vendors

1. Removal of “addressable” specifications (§164.306)

Over the last 20 years, buyers have heard vendors respond to the question of encryption with “encryption is addressable, and we’ve written why we don’t need it in our deployment. Under the proposed rule, that sentence goes away. All implementation specifications are mandatory.

AI voice implication: Vendors are no longer allowed to avoid implementing encryption-at-rest for call recordings based on risk assessments. Request encryption at rest policies in writing.

2. Encryption required at rest and in transit (§164.312)

The proposed rule sets out the encryption of ePHI at rest and while in transit. There are only a few exceptions (on-device under harsh conditions, for instance), but the default is encryption.

AI voice implication: Encryption at rest for voice recordings, voice transcripts, and structured data, using AI voice implication. Organizations must encrypt voice traffic in transit (sent via SIP, WebRTC, or HTTPS) using modern transport encryption. Vendors and internal teams must meet the following requirements: Apply AES-256 (or equivalent) encryption to data at rest, deploy TLS 1.2 minimum (TLS 1.3 preferred) for data in transit, provide comprehensive key management documentation, and furnish clear evidence that teams encrypt backups as well.

3. Mandatory multi-factor authentication (§164.312)

Where ePHI is stored or processed, -MFA is required for access to the system.

AI voice implication: All user portals, all admin consoles, all API key issuance processes should have MFA. One factor login on the vendor’s side is non-negotiable.

4. Annual vulnerability scans + penetration testing (§164.308)

The proposed rule outlines vulnerability scans and penetration tests every 12 months at least annually.

AI voice implication: Ask the vendor for their latest pen-test executive summary and date of last scan for vulnerabilities. Request the latest pen-test executive summary and date of last vulnerability scan from the vendor. Regularly testing is not an answer. Request the report.

5. Asset inventory and network maps (§164.308)

Covered entities and business associates must maintain a current, written inventory of technology assets and a network map showing how they transmit, access, and utilize ePHI, updating these documents at least once a year.

AI voice implication: The AI answering service vendor needs to be able to present you with a data-flow diagram for the deployment, what cloud regions are used, where transcripts are saved, which sub-processors are involved with the data.

6. 24-hour workforce access termination (§164.308)

Organizations must terminate a departing workforce member’s access to ePHI within 24 hours of their departure and notify business associates within 24 hours.

AI voice implication: If you use AI voice applications, the vendor’s Business Associate Agreement (BAA) must require them to establish an access termination procedure. This procedure must revoke your access and notify you within 24 hours of termination. The vendor must also align their Service Level Agreement (SLA) to match this 24-hour timeline.

7. BAA verification with annual written analysis (§164.314)

At least once a year, business associates must submit a written analysis of their technical safeguards, signed by a subject-matter expert, to the Business Associates Workgroup.

AI voice implication: AsWhen did the vendor create their most recent written technical safeguards analysis? This is the one piece of evidence that will be the easiest to defend in the event of a future OCR audit.

PRO TIP

Request the pen-test results summary, the SOC 2 Type II report, and the subprocessor list prior to scheduling a demo. Professional companies will have them prepared.

What Counts as PHI in an AI Voice Conversation

Those who try to sell any product to you that uses artificial intelligence for voice services and point their hand towards “we do PHI with care” while not clarifying its significance in the case of voice is just putting your safety at risk.

The instant an organization records and uses a patient’s voice to make healthcare decisions, that recording enters the designated record set.

Business Associate Agreements, What Healthcare Buyers Must Demand

The BAA is the legal structure that forms the foundation of your partnership with the AI receptionist provider. The vendor-provided BAAs are most of the time drafted to benefit the vendor, not the covered entity. Here’s what to require. 

AI phone call agents and chatbots are helpful to healthcare organisations. But implementing HIPAA-compliant AI voice agents is not as simple as it seems.

According to experts from Harvard Law School, HIPAA is an outdated practice and is unable to address the new privacy issues of AI platforms.

Required clauses every BAA must contain (this is HIPAA baseline, §164.504(e)):

The purposes for which ePHI can be used and disclosed.

• The uses and disclosures of ePHI that are permitted.
• The Safeguards the BA will use:
• The reporting obligations in respect of unauthorised use or disclosure.
• Subcontractor (subprocessor) flow down requirement
• Return or destruction of ePHI at the end of contract.

Clauses to demand that go beyond baseline:

• Subprocessor disclosure. Active list of all subprocessors (LLM providers, transcribers, telephony carriers, cloud hosts). Rubber banding of “third-party services” language is a danger sign.
• Breach notification SLA. An AI voice context can reasonably be provided within a time window of 24-72 hours, not “without unreasonable delay.
• Audit rights. Right to audit, or to have a third party audit report (SOC 2 Type II, HITRUST CSF) periodically.
• Data residency commitment. Where data is processed and stored and a contractual commitment to US processing if that’s your requirement.
• Encryption specification. The actual encryption standards in use (AES-256, TLS 1.3) are named in the BAA or a referenced security schedule.
• Termination assistance. At the end of the contract, the data export format and the data export timeline are provided.
• Vendors’ compensation for deficiencies. Partial but significant indemnity for any breaches by the vendor.

BAA red flags:

• The vendor supplies their “standard BAA” and won’t charge any extra for it.
• No named subprocessors
• Instead of given standards, “reasonable security measures” is used.
• There is no specific time frame for notifications.
• We retained the SPs list on our website instead of in the BAA.
• No audit right or sharing with third parties.

The HIPAA-Compliance Stack for AI Voice, What Every Vendor Needs

Encryption at rest

• Organizations protect stored recordings, transcripts, and structured data using standard AES-256 (NIST FIPS 197) encryption.
• Key management: Separate keys from encrypted data.
• Backup scope: Same encryption used on backup (a common deficiency)

Encryption in transit

• TLS 1.2 or later (TLS 1.3 preferred)
• Extension of SIP encryption (SIPS / SRTP) support for voice carrier traffic.
• An mTLS approach for vendor-to-customer API integrations
• Our team has documented the certificate renewal process, which we call certificate management.

Audit logging

• Who was accessing what ePHI, at what time and from where?
• Retention: minimum 6 years per §164.316(b)(2)(i)
• Integrity protection, tamper evident or WORM storage
• Review Cadence: Documented, conducted in practice.

Access controls

• Role Based Access Control (RBAC) with least privilege defaults.
• Organizations must enforce Multi-Factor Authentication (MFA) for all administrative and end-user access to ePHI.
• The 15-30 minute session time out for access to ePHI
• Unique user IDs (§164.312(a)(2)(i)) — no shared accounts

Breach notification

• Have an internal incident response plan in place and tested annually.
• The notification SLA between the vendor and customer (as specified in the BAA)
• Patient Notification within 60 days of discovery in accordance with §164.404
• Media notification when 500+ residents of a state are affected
• HHS OCR notification on the Breach Portal

De-identification

• Two HIPAA recognized methods: Safe Harbor (Removal of 18 identifiers under §164.514(b)(2)) and Expert Determination (statistical certification)
• If voice biometric data is not removed from a transcript, removing the name does not de-identify the call and will not remove the voice context.
• If a vendor states that it de-identifies your data, it should explain how and offer evidence.

Data residency

• Committed to process only in the United States, based on the requirements of your contract.
• Data residency for the sub-processors should be US-only as well.
• Expect the unexpected with third country LLM providers, ask explicitly.

Subprocessors

• A list that is kept up-to-date.
• For each subprocessor in a BAA (subprocessor flow down)
• Modern BAA standards require the notice and opt-out for new subprocessors

HIPAA + State Law Overlay: The Stack You Actually Comply With

HIPAA is a minimum requirement, not a maximum. This is on top of HIPAA, and there are a growing number of state laws that are more specific, and some are more stringent.

The state breach notification windows are typically earlier than the federal window of 60 days — some states require notification within 30 days, and a few require notification within shorter windows for “high-risk” breaches. Before signing a BAA, ensure that your patient population is mapped to the appropriate state law.

Persona Playbooks, How to Evaluate an AI Voice Vendor by Role

Compliance Officer’s checklist (10 questions)

1. Do you have a copy of your BAA and are you willing to discuss certain terms?
2. What are your subprocessor list and how frequently do you update it?
3. Within how many hours must the vendor notify our organization following a suspected or confirmed data breach?
4. Submit your latest SOC 2 type II report (bridge letter is not sufficient if it is more than 12 months old).
5. Have you been certified as HITRUST CSF? At what level?
6. How do you know how long to keep ePHI, and how do you ensure that it remains there?
7. If applicable, can you explain in writing how you accomplish your technical safeguards as outlined in the 2025 NPRM?
8. Which states do you collect data from and is there an option to collect data for only the USA?
9. What is your policy for patient access requests for §164.524?
10. Discuss the last security incident you have encountered and what measures were taken to resolve the incident.

Privacy Officer’s checklist (10 questions)

• Does the system capture any types of PHI, such as audio, transcripts, structured data, metadata, or biometrics?
• How do you de-identify information and do you do it using Safe Harbor or Expert Determination?
• What is the state law on consent for call recording?
• What are your patient rights workflows (access, amendment, accounting of disclosures)?
• Does the vendor retain recordings for a specified period, and can you set shorter retention periods?
• Does the vendor store voice biometrics separately, and can we choose not to create a voiceprint?
• What is your “no frills” access posture for support staff?
• Will you be able to show us how data moves for our use case?
• How did you separate training data and customer data?
• If yes, do you use customer recordings to train models? The answer should be no, unless otherwise specified.

CISO’s checklist (12 questions)

1. Submit your standard for encryption at rest and key management documents.
2. Give the specification of the encryption media with which you are communicating (TLS version, cipher suites).
3. Last penetration test was when? And provide an executive summary?
4. On what exact date did your security team run your most recent vulnerability scan, how frequently does your team perform these scans, and what specific timeframe does your policy mandate for remediating critical findings?
5. How is your posture on MFA for admin, end users, and API access?
6. What is your access termination SLA? How does it work with our SCIM/IdP?
7. Please present your network diagram to me for our deployment.
8. How long do you store your audit logs, and how do you safeguard those logs against tampering?
9. Does your team maintain an incident response plan, and if so, when did you last test it?
10. Explain detection & response capability (SIEM, EDR, SOC).
11. How often do you process CVEs for critical updates?
12. Outline your third party risk management (TPRM) Subprocessors.

Practice Manager’s checklist (8 questions)

1. What if the patient declines to have his/her records taken?
2. What occurs if the AI has a clinical question that it can not answer?
3. How does the system escalate after-hours emergencies to a clinician?
4. Can patients request that the organization delete their recordings or transcripts?
5. What strategy does the AI use for calls made in Spanish or languages other than English?
6. What will the staff at the front desk do when the AI is in operation?
7. What will be the metrics to measure the accuracy of the AI in the first 90 days?
8. What to do in case the AI is wrong on clinical significance?

Health-system procurement’s checklist (10 questions)

1. What is your current insurance position; cyber liability, E&O, and is it adequate with our patient volume?
2. List 3 health care references with comparable number of patients seen.
3. How healthy are your finances, and can you afford a $5 million fine for violating HIPAA?
4. What’s your contract termination assistance package?
5. So, what is your plan for compliance with the NPRM by the 2025 deadline?
6. Is it possible to carry out an audit of your premises (or for you to receive a recent third party audit)?
7. What is your sub-processor concentration risk (dependency on LLM or dependency on telephony carrier)?
8. What’s your historical uptime, and what’s your SLA?
9. How does the vendor communicate pricing changes throughout the contract?
10. What’s the named compliance contact and their escalation?

SOC 2 Type II, HITRUST CSF, and Other Evidence to Demand

There are 3 rules of thumb:

• Bridge letters expire. Yellow flag is a SOC 2 Type II report that is more than 12 months old, and lacks a bridge letter from the auditor. A red flag is if they are more than 18 months old.
• HIPAA is NOT a qualification. There is no body to certify HIPAA, so any vendor that states they are “HIPAA certified” is lying. The correct term is “HIPAA-compliant” backed up by evidence.
• SOC 2 reports on the scope of the vendor’s work. Always read scope section. A SOC 2 that doesn’t address their corporate IT infrastructure and instead only addresses their AI voice production infrastructure is of little value.

The 6-Step Vendor Evaluation Process for HIPAA-Compliant AI Voice

Successful health deployments go in this order.

Step 1: BAA review with legal.  As early as the point where the data enters the vendor’s system. Vendors usually wrap the price of a standard Business Associate Agreement (BAA) directly into their software-as-a-service (SaaS) subscription tiers.

Step 2: Security questionnaire. Offer a HIPAA mapped or HITRUST mapped questionnaire. Make comparisons of responses to vendor claims on their Public Site.

Step 3: Architecture review. Obtain a data-flow diagram of your particular deployment. Trace all systems related to ePHI. Identify every subprocessor.

Step 4: Use synthetic PHI with a pilot. Have a 2-4 week pilot with synthetic patient data. Ensure accuracy, audit logging and incident handling processes without risking exposure of actual ePHI.

Step 5: Penetration test / red team. On larger deployments, perform a pen-test on your own or hire a red team that specializes in healthcare testing to perform the pen-test.

Step 6: Risk-acceptance and documentation/sign-off. Record residual risk, obtain Compliance Officer, Privacy Officer, and CISO’s approval. Schedule annual re-review.

5 Failure Modes That Get Healthcare Organizations Fined

The unsigned BAA assumption. A vendor has agreed verbally to be HIPAA compliant. No BAA is made. Vendor is in breach. The covered entity will be liable for all of the above and OCR penalties for the lack of a BAA, a violation in itself under §164.502(e). Ensure BBA is always signed prior to data flow.

• The “compliant by association” fallacy. Vendor says, “We have a HIPAA compliant vendor called a HIPAA LLM, and therefore we are HIPAA-compliant. The sentence doesn’t make any sense. The LLM provider has done its part with its service; your AI voice provider needs to take care of the controls in its product. Make sure you’re requesting evidence at the product level, not the underlying-provider level.
• The audit-log gap. Vendor has Audit logs but no retention policy. Has logs, but doesn’t read logs. Or logs in as admin but not as an API user. The first question in OCR’s audit typically is related to logs. Ensure these are maintained, kept for 6+ years and reviewed.
• The unencrypted backup. Organizations encrypt data when they store it, but they fail to encrypt backups because they route backup files to another system. One of the most prevalent HIPAA breach patterns on the HHS Breach Portal.
• The forgotten subprocessor. A vendor’s LLM provider creates a new sub-region in a foreign country. The vendor is oblivious. After six months, a vendor used your patient information in a country that your BAA does not include. Solution: BAA language giving advance notice of new sub-processors, and ability to cancel contracts without penalties.

The Decision

Procurement of a HIPAA-compliant AI voice solution in 2026 is very different from procurement in 2024. The Security Rule NPRM issued in 2025 has elevated technical safeguard requirements and eliminated the addressability loophole, making it necessary for vendors to submit written assessments each year signed by a subject-matter expert. Failure to take these differences into account while purchasing a SaaS solution would lead to failure at an OCR audit.

On the bright side, it also allows vendor evaluation to be much more transparent. The vendor either has SOC 2 Type II, HITRUST certification, a recent penetration test, an effective BAA, and a technical safeguards analysis in writing, or they don’t. The process of vendor evaluation is one of checking off boxes.