Ambient AI documentation tools record conversations between physicians and patients. The moment you understand this, the privacy and compliance questions follow immediately: who has access to those recordings, where is the audio stored, how long is it kept, and what obligations does the practice take on by using a tool that handles protected health information?
This article addresses those questions from a practical standpoint - what a physician or practice administrator needs to understand before deploying an ambient documentation tool in a HIPAA-covered practice.
The HIPAA framework for ambient documentation
Under HIPAA, patient visit audio that contains identifiable health information is protected health information (PHI). A vendor that receives, processes, or stores that audio on behalf of a covered entity is a Business Associate. Before any PHI-handling tool goes live in a covered practice, a Business Associate Agreement (BAA) must be in place between the practice and the vendor.
A BAA is not a HIPAA certification and it is not a guarantee of security. It is a contractual commitment by the vendor to handle PHI appropriately, to use it only for the purposes defined in the agreement, to report breaches to the covered entity, and to return or destroy PHI upon termination. Practices should read BAAs rather than just signing them - the specific terms around data retention, sub-processors, and training data use are meaningful.
Any ambient documentation vendor that is unwilling to execute a BAA is one that should not be used in a covered practice. Full stop. A vendor may claim they de-identify audio before processing; this needs to be independently verified rather than accepted on the vendor's assurance, because de-identification is a specific technical standard under HIPAA, not a casual description.
Audio retention: what to ask and why
The single most important data handling question for ambient documentation is: what happens to the audio after the note is generated?
There are essentially three models in the market. The first - and from a risk management standpoint, the preferable one - is that audio is processed transiently: it is held in memory during note generation and then discarded. Nothing is persisted. The second model involves audio being retained for a defined period (24 hours, 72 hours, 7 days) to allow for note regeneration or quality review, then deleted on a schedule. The third model involves longer retention, ostensibly for model improvement or quality assurance purposes.
Practices should have a clear answer about which model their vendor uses, and that answer should be reflected in the BAA. Longer retention periods mean higher risk exposure in the event of a breach, higher compliance complexity around data subject access requests, and greater exposure to the question of what the vendor is actually doing with retained audio.
Patient consent: state law variation
HIPAA sets a federal floor for PHI privacy but does not directly govern audio recording consent. That is primarily a state law question, and state laws vary.
Most states are one-party consent states for recording: if one participant in a conversation consents to recording it, the recording is lawful. In a physician-patient visit, the physician can consent on their own, and the recording is lawful. However, this is distinct from what is ethically appropriate and what patients expect.
A handful of states - California is the prominent example - are all-party consent states: everyone in the recorded conversation must consent. In those states, patient consent is a legal requirement, not just an ethical preference.
Independent of legal requirements, most practices find that informing patients of ambient recording before the visit - and giving them a clear way to decline - is the right operational approach. Patients who feel they were recorded without knowledge are a source of complaints and erosion of trust that is not worth whatever small efficiency is gained by skipping the consent conversation.
Sensitive visit types
Some visit types carry additional privacy sensitivity that makes ambient recording inappropriate or legally complex: mental health visits, reproductive health and termination discussions, domestic violence disclosures, substance use counseling, and visits involving minors with specific confidentiality protections under state law.
Practices deploying ambient documentation should have a defined policy for which visit types are excluded from ambient recording, and a workflow for how the physician switches to a non-recording mode for those visits. This is not a theoretical edge case - practices running ambient documentation without a sensitive visit policy eventually encounter one of these scenarios and deal with it ad hoc, which is worse than having a policy.
A good ambient documentation tool makes this easy. The physician or front desk should be able to mark a visit as excluded from recording before it starts, and that selection should persist without requiring the physician to remember to take additional action during the visit itself.
The model training question
One area where practices should carefully read BAA and service agreement terms is model training. Some ambient documentation vendors use customer data - including de-identified visit audio or transcripts - to improve their language models over time. Others explicitly prohibit this use and contractually commit to not using customer data for model training purposes.
Neither approach is categorically wrong from a regulatory standpoint, provided de-identification meets HIPAA standards. But practices should know which model they are signing up for and make that decision deliberately rather than by default. Physicians who understand that their de-identified visit transcripts are being used to train the model should have consented to that use; practices that haven't thought about it simply have a gap in their vendor management process.
What "HIPAA-designed" means in practice
Vendors use various formulations around HIPAA - HIPAA compliant, HIPAA-ready, designed with HIPAA controls. These phrases should be understood as descriptions of architecture, not certifications. There is no government body that issues HIPAA certifications to software vendors. Compliance is achieved through technical safeguards, administrative controls, and contractual commitments - not through a credential.
When evaluating an ambient documentation vendor's privacy posture, the right questions are: what are the specific technical safeguards (encryption in transit and at rest, access controls, audit logging)? What are the administrative controls (employee training, access provisioning policies)? What is in the BAA regarding breach notification timelines and vendor liability? These questions produce useful information. Asking "are you HIPAA compliant?" produces a yes that tells you nothing.