Why "HIPAA Compliant" Is the Wrong Question to Ask
Every AI clinical documentation vendor claims HIPAA compliance. The phrase appears in product marketing, in security overview pages, in sales calls. It is not a meaningful differentiator because it is not a meaningful certification. There is no "HIPAA certified" designation issued by the Department of Health and Human Services or any authorized certification body. HIPAA compliance is a legal obligation and an operational posture — it is not a credential, not a test result, and not a third-party verified status.
What this means in practice is that "HIPAA compliant" can mean almost anything a vendor wants it to mean. A vendor that has signed a Business Associate Agreement and has a written privacy policy has technically established the minimum legal relationship required under HIPAA's Privacy Rule. That is very different from a vendor that has implemented encryption at rest and in transit, has access controls limiting PHI access to minimum necessary personnel, maintains audit logs of all PHI access, has a documented breach notification procedure, and conducts regular risk assessments under the Security Rule's requirements.
When evaluating AI documentation tools for clinical use, the right questions are specific. Not "are you HIPAA compliant?" but "what controls do you have in place, and can I verify them?"
The HIPAA Framework Applied to Ambient AI
Ambient AI documentation tools interact with protected health information at multiple points in their architecture, each with distinct HIPAA implications. Understanding where PHI exists in the tool's data flow is the prerequisite for assessing whether the controls are adequate.
Audio capture is the first and most sensitive point. When an ambient AI tool records a clinical encounter, it captures everything said in the room — the patient's health history, their symptoms, their personal circumstances, potentially their family medical history and mental health status. This audio is PHI from the moment it is captured. The legal and security question begins immediately: where does the audio go? Is it processed on-device, in the cloud, or both? If in the cloud, what data center controls apply? Is the audio retained after the note is generated, or deleted?
Note generation is the second PHI interaction point. The AI system creates a structured clinical note from the encounter audio. That note is a medical record — the most PHI-dense document type in healthcare. Access controls, transmission security, and EHR integration security all apply to this output.
EHR integration is the third point. When the note writes back to the EHR, the integration pathway must maintain the same PHI protections as the rest of the clinical record. SMART on FHIR connections require OAuth 2.0 authorization, but the specific scopes granted and the access controls on those scopes matter for security. An integration that is technically authorized but scoped too broadly creates exposure.
The Business Associate Agreement: What It Does and Doesn't Guarantee
A Business Associate Agreement (BAA) is a contractual requirement under HIPAA for any vendor that creates, receives, maintains, or transmits PHI on behalf of a covered entity. For AI documentation tools, this means every vendor that receives encounter audio or generates clinical notes must have a BAA in place with the practice before any PHI flows to their systems. This is not optional and it is not negotiable.
What a BAA does: it establishes the legal obligation of the vendor to safeguard PHI, notify the practice of any breach, use PHI only for agreed purposes, and return or destroy PHI at contract termination. It makes the vendor's HIPAA obligations legally enforceable rather than just aspirational.
What a BAA does not do: it does not verify that the vendor actually has the technical and administrative controls in place to meet those obligations. A BAA is a contract, not an audit. A vendor can sign a BAA and still have inadequate access controls, no audit logging, and a breach response procedure that doesn't meet the Security Rule's notification timeline requirements. The BAA creates legal accountability; it doesn't create security capability.
We are not saying BAA review is insufficient — it is necessary. We are saying it is not sufficient on its own as a security evaluation for a vendor that will process clinical encounter audio and generate patient records.
Encryption: Where the Specifics Matter
Encryption is the security control most often cited in vendor security documentation, and it is also the one most susceptible to technically accurate but operationally misleading claims. "End-to-end encryption" and "AES-256 encryption" appear in vendor materials without sufficient context to evaluate what they actually protect.
The relevant questions for AI documentation tools: Is the encounter audio encrypted in transit from the capture device to the processing endpoint? What encryption standard applies? Is PHI encrypted at rest on the processing servers? Is the encryption key managed by the vendor or by the customer (customer-managed keys provide meaningfully stronger controls)? Are the encryption keys rotated on a defined schedule?
For cloud-based AI processing — which most ambient documentation tools use for the NLU and note generation steps — the security of the cloud infrastructure provider (AWS, Azure, GCP) provides a meaningful baseline. Major cloud providers offer HIPAA-eligible service configurations with BAA coverage. But the application layer running on that infrastructure is the vendor's responsibility. HIPAA-eligible cloud infrastructure does not automatically make a poorly architected application HIPAA-aligned.
Questions to Ask Any AI Documentation Vendor
The following are not exhaustive, but they are the questions that surface genuine differentiation in security posture among AI documentation vendors:
- What is your audio retention policy? Is encounter audio retained after note generation, and if so, for how long and under what access controls?
- Does your system process PHI on-device or in the cloud? If in the cloud, which provider and which HIPAA-eligible services?
- Do you have a SOC 2 Type II audit report? Can we review it under NDA?
- What is your breach notification timeline, and what triggers a notification under your definition?
- How is PHI access controlled within your organization — minimum necessary principle, role-based access, audit logging?
- What happens to our PHI if we terminate the agreement?
A vendor that cannot or will not answer these questions with specificity is not a vendor whose security posture you can adequately assess.
No Data Retention as a Design Choice
The strongest security posture for ambient AI documentation is a no-retention architecture: encounter audio is processed, the note is generated, and the audio is deleted. No audio is retained in vendor systems after note delivery to the EHR. This design eliminates the largest single security risk — a data breach exposing a library of recorded clinical encounters — and removes a significant compliance burden, because audio files that don't exist can't be subject to a breach notification obligation.
Not all vendors have implemented this architecture. Some retain audio for quality assurance purposes, model improvement, or physician review access. These are legitimate operational needs, but they create retention risk that should be explicitly addressed in the BAA and the security assessment. Practices should understand what is retained, for how long, who can access it, and whether it can be deleted on demand.
The Right Framing for Security Evaluation
Security evaluation for AI documentation tools is a risk management exercise, not a compliance checkbox exercise. The goal is not to find a vendor that can say "HIPAA compliant" with sufficient confidence — all of them can. The goal is to understand where PHI exists in the vendor's architecture, what controls protect it, what the breach notification chain looks like, and whether the residual risk of using this tool is acceptable given the practice's risk tolerance and the regulatory environment it operates in.
Practices that approach this as a procurement compliance exercise tend to get less useful information than practices that engage their IT security team or a healthcare IT security advisor to conduct a genuine technical review. The investment in that review is proportionate to the risk: a tool that processes complete clinical encounter audio for every physician in a practice is a meaningful PHI asset, and the security due diligence should reflect that.