PHI in Ambient AI Documentation: A Compliance Guide for Clinics

Ambient AI scribes have moved from pilot to production in primary care, behavioral health, and specialty clinics over the past two years. The pitch is simple: the clinician talks to the patient, an app listens, and a draft note appears in the EHR. The compliance reality is more involved. An ambient scribe captures one of the most intimate PHI streams in the practice, and the controls around that stream are often softer than the controls around the EHR it feeds.

This guide walks through the PHI that flows through these tools, the HIPAA rules that govern them, the gaps we see most often, and what to verify before you trust a vendor with live encounters.

What PHI flows through ambient AI documentation

An ambient AI scribe touches almost every category of PHI in a single visit:

• Audio of the full encounter — chief complaint, history of present illness, social and sexual history, family history, mental health disclosures, physical exam narration, assessment, and plan. The audio file is PHI from the moment it is captured.
• Transcript — a near-verbatim text version of the audio, often retained longer than the audio itself.
• Draft note — a structured SOAP or H&P note generated by the model, including diagnoses, medications, and plan.
• Metadata — patient identifier, provider identifier, encounter timestamp, location, and sometimes device identifiers.
• Side-channel data — speaker labels, sentiment scores, or coding suggestions, depending on the product.

Because the audio captures unfiltered patient speech, it often contains PHI the patient did not intend to put in the chart: a comment about a family member’s diagnosis, a disclosure about substance use, an off-topic mention of another provider. All of that is in the recording.

HIPAA requirements that apply

Ambient AI documentation falls squarely inside the Privacy Rule and the Security Rule:

• Treatment, Payment, Operations (TPO) — Use of PHI to draft a clinical note is a treatment activity. The covered entity does not need patient authorization to use the PHI for this purpose under 45 CFR 164.506.
• Business associate relationship — A vendor that creates, receives, maintains, or transmits PHI on behalf of a covered entity is a business associate under 45 CFR 160.103. Ambient AI vendors meet this definition. A BAA is required before live use under 45 CFR 164.504(e).
• Security Rule safeguards — Encryption in transit and at rest, access controls, audit logging, and a documented risk analysis under 45 CFR 164.308 and 164.312.
• Minimum necessary — Under 45 CFR 164.502(b), uses and disclosures of PHI must be limited to the minimum necessary. Recording an entire encounter is justifiable for a clinical note, but the same recording cannot be repurposed for marketing or general analytics.
• Right to amend — Patients have the right to request amendment of PHI under 45 CFR 164.526. If an AI-generated note contains errors and the provider attests to it, the patient retains amendment rights against the final record.
• Accounting of disclosures — 45 CFR 164.528 requires a covered entity to track certain disclosures of PHI on request.

Common compliance gaps in ambient AI documentation

Four gaps appear repeatedly when we review ambient AI deployments at small clinics.

1. No signed BAA, or a BAA that does not cover audio. Some vendors offer a generic SaaS terms-of-service and treat the BAA as an enterprise upsell. Others sign a BAA that names the transcript and the note but is silent on the raw audio. If the audio touches the vendor, it must be covered.

2. Unclear retention and deletion of audio. Practices often cannot answer how long the audio is kept, where it is stored, who can access it, or whether deletion is verified. “We delete it after processing” is not a control. Document the retention period in the BAA or vendor security documentation.

3. Model training on identifiable data. Some early vendor agreements reserve broad rights to use customer data to improve the product. That is incompatible with a HIPAA BAA unless the data is de-identified using a method that meets 45 CFR 164.514. Practices that signed those agreements early often have not gone back to renegotiate.

4. Patients are surprised. Even though HIPAA does not require separate authorization for an AI scribe in a treatment context, patients often do not know it is happening. A surprised patient is a complaint to the OCR waiting to happen. Inform patients verbally, post a notice in the room, and document the disclosure in your Notice of Privacy Practices if your model warrants it.

How to make ambient AI documentation HIPAA-compliant

1. Sign a BAA that covers audio, transcript, draft note, and metadata. Read it for vendor secondary uses. Strike or narrow any language that lets the vendor use identifiable PHI for model training, marketing, benchmarking, or sale to third parties.
2. Document audio retention, storage location, and deletion. Get vendor answers in writing: where the audio lives, encryption at rest, who at the vendor can access it, and the retention period. Add audio handling to your risk analysis.
3. Inform patients before recording. A short verbal script (“I use an AI assistant to help me write the note from our visit. Is that okay with you?”) plus a posted notice covers most expectations. Document the practice in policy.
4. Require provider review and attestation of every note. The AI draft is not the medical record. The provider’s reviewed and signed note is. Build review into the workflow and audit it.
5. Honor amendment requests under 45 CFR 164.526. Treat AI-generated content like any other PHI when patients ask for corrections. Train front-desk and clinical staff to route amendment requests to the privacy officer.

Vendor BAA requirements for ambient AI documentation software

Before you go live, the BAA should clearly address:

• Scope of PHI — audio, transcript, draft note, metadata, model outputs, and any logs that contain identifiers.
• Permitted uses — limited to providing the documentation service to the covered entity. No general analytics, no benchmarking against other customers’ data, no model training on identifiable PHI.
• Subcontractors — every cloud provider, transcription engine, and model host the vendor uses. Each subcontractor must sign a downstream BAA per 45 CFR 164.308(b).
• Security controls — encryption standards, access controls, logging, vulnerability management, and incident response timelines.
• Breach notification — vendor must notify the covered entity without unreasonable delay, with a defined maximum window.
• De-identification methodology — if the vendor wants to use data for product improvement, require Safe Harbor or Expert Determination methodology under 45 CFR 164.514 and the right to audit it.
• Termination and return or destruction of PHI — including audio, transcripts, and any derived data, with written attestation.

If a vendor cannot or will not sign a BAA with these terms, they are not ready for clinical use. That is a hard line, not a negotiation.

For a broader framework on when a vendor crosses into business associate territory, see when a vendor needs a BAA. For other PHI flows in your practice, the PHI workflows hub maps the most common compliance pressure points.

When you are ready to centralize vendor BAAs, audit logs, and risk analyses for the whole practice in one place, PHIGuard is built for clinics with 3 to 50 staff and publishes BAA details on the pricing page with pricing details published on the pricing page.