HIPAA-Compliant Ambient AI Medical Scribe (2026):
7 BAA-Signing Vendors + Build Guide
Abridge, Nuance DAX Copilot, Suki, Augmedix, athenaAmbient, DeepScribe, and Heidi Health — the BAA-signing ambient AI medical scribe vendors in 2026. Plus the engineering blueprint to build your own when off-the-shelf doesn't fit: BAA-eligible speech + LLM stack, recording consent, clinician-in-the-loop review, hallucination guardrails, and FHIR write-back.
BAA-eligible speech + LLM stack
Recording consent done right
Clinician-in-the-loop + FHIR write-back
By Garvita Amin· Co-Founder & CTO
May 30, 2026 · 14 min read
The ambient AI scribe is the rare healthcare tool that sells itself: a clinician walks into the room, has a normal conversation with the patient, and walks out with a draft note already written. By 2026 it has gone from novelty to near-default — the majority of large health systems run one, and vendors have bundled it straight into the EHR. But the moment that microphone turns on, you are recording two people's voices, processing their words through a language model, and generating the legal record of care. HIPAA, state recording law, and basic patient safety all show up at once. This is the engineering version: where the PHI flows, which vendors will sign a BAA, how consent actually works, why a human has to stay in the loop, and how the note lands in the chart.
The 60-Second Answer
Seven ambient AI medical scribe vendors sign a BAA in 2026 and are safe to use with PHI:
- Abridge — clinical-grade ambient scribe, used at Mayo Clinic and Kaiser. Strong physician-facing UX, Epic + Cerner integrations, BAA on every tier.
- Nuance DAX Copilot (Microsoft) — deepest EHR integration (Epic-native), the most mature ambient scribe deployment. BAA on Microsoft Healthcare contract.
- Suki AI — voice-first assistant that does scribing plus dictation and chart navigation. Specialty templates for primary care, cardiology, and orthopedics.
- Augmedix — long-form transcription with human-in-the-loop review (lower hallucination risk by design). Strong for high-acuity specialties.
- athenaAmbient — bundled free with athenahealth EHR subscriptions starting February 2026. Lowest-friction option if you're already on athenaOne.
- DeepScribe — outpatient-focused ambient scribe with EHR-agnostic deployment (works with most major systems via API).
- Heidi Health — fast-growing scribe with strong international deployments (Australia, UK), now expanding US presence. Free tier available.
Build your own when off-the-shelf doesn't fit (specialty-specific notes, multi-language patients, on-device speech recognition for poor connectivity): the engineering blueprint — 6-stage pipeline from consent capture through FHIR write-back — is below. Skip to the BAA-eligible speech + LLM stack →
Consumer ChatGPT, Otter.ai, Notion AI, free transcription apps, and most general-purpose dictation tools — none of these sign BAAs. Routing visit audio or transcripts through them is a HIPAA breach.
Key takeaways (2026)
- A HIPAA-compliant AI medical scribe captures audio, transcribes, generates SOAP/HPI/MDM notes, and writes audit logs — every step requires a signed BAA with the vendor processing PHI.
- BAA-eligible transcription vendors in 2026: AWS Transcribe Medical, Azure Speech (HIPAA-eligible), Google Cloud Speech-to-Text (HIPAA-eligible), Deepgram Enterprise.
- For drafting notes: OpenAI Enterprise/API, Anthropic Enterprise, AWS Bedrock, Azure OpenAI, Google Vertex AI, or self-hosted Llama/Mistral on HIPAA-eligible cloud.
- On-device speech recognition (Whisper.cpp, Whisper variants) keeps audio off third-party servers entirely — strongest privacy posture.
- Clinician review/sign before commit is required for every AI-generated note — Part 11 + clinical safety both demand human attestation.
Why did the AI scribe become 2026's breakout healthcare app?
Documentation is the most hated part of modern medicine. Clinicians routinely spend more time typing into the EHR than looking at patients, and "pajama time" — charting at home after hours — is a top driver of burnout. The ambient scribe attacks that directly: it listens to the visit, transcribes it, and drafts a structured note, so the clinician edits instead of authors.
~15 min
Documentation time saved per encounter (reported)
2 of 3
Large health systems running an ambient scribe
↓ burnout
The pitch clinicians actually care about
Adoption numbers vary by source and setting, so treat them as directional — but the direction is not in doubt. EHR vendors now ship ambient documentation natively, and national health systems are rolling it out facility-wide. That also means the bar has risen: a scribe that is "mostly accurate" or "probably compliant" is no longer interesting. The interesting question is how to build one that holds up to an OCR investigation and a malpractice deposition.
An ambient scribe turns a spoken conversation into a signed clinical note. Every word of that conversation is PHI from the first second, and the note it produces is a legal medical record. Build it like both of those things are true, because they are.
What does a HIPAA-compliant AI medical scribe actually require?
There is no badge you can buy that makes a scribe HIPAA-compliant. Compliance is a property of the entire system — the microphone app, the transcription service, the language model, the storage, and the controls around them. A scribe that records a visit and drafts a note is a HIPAA application in full, with the same obligations as a patient portal or an EHR. If you have the foundations from our HIPAA-compliant healthcare app guide, most of this is already in place.
A BAA with every vendor that hears or sees PHI — the speech-to-text service and the LLM first, then hosting, storage, and any analytics or observability.
Encryption of audio, transcript, and note — TLS 1.2+ in transit and AES-256 at rest, on every store. As of the 2025 Security Rule update, encryption and MFA are required, not merely "addressable."
Recording consent — the patient is told an AI assistant is listening, consents, and may decline. This is a legal requirement on top of HIPAA, covered below.
Access controls and identity — only the treating clinician and authorized staff can open a given encounter's audio or note.
Audit logging — who recorded, which model version drafted, who edited, who signed, what was written to the EHR. Retain six years.
Zero-retention / no-training configuration with the speech and model vendors, so audio and transcripts are not stored by them or used to train models.
A written risk analysis that names the audio store, the transcription vendor, the LLM, and every PHI flow — the first artifact OCR asks for.
The encryption mechanics for each store are in our HIPAA PHI encryption guide, and the model-side controls mirror those in our HIPAA-compliant AI guide. The framework-level overview lives on our HIPAA compliance page. For the automated approach to checking each of these controls on every commit — instead of waiting for an audit — see automated HIPAA compliance scoring.
The PHI Data Flows in an Ambient Scribe
Map where PHI goes before you write a line of code. A scribe has more PHI surfaces than a chatbot, because it starts with raw audio — the richest, most identifying form of PHI you can capture.
The audio stream. A recording of the patient's and clinician's voices. Biometric, deeply identifying, and PHI from the first word. Encrypt in transit and at rest, and decide its retention deliberately.
The transcript. The speech-to-text output — a full text record of the encounter, with speaker labels. A PHI document of its own.
The model prompt. The transcript (plus any context) sent to the LLM to draft the note leaves your perimeter for the provider. This is the flow that needs the BAA and zero retention.
The draft note. The generated SOAP or H&P note, staged for review. PHI, and soon to be the legal record.
Logs and telemetry. The flow teams forget. Latency traces and debug logs of transcripts or prompts routinely leak PHI into non-BAA tools. Redact before anything leaves your boundary.
EHR write-back. The signed note filed as a FHIR resource — a separate PHI flow into the chart, with its own auth and audit story.
The recording is the riskiest asset you will hold
Raw visit audio is more sensitive than almost anything else in your stack: it identifies both speakers by voice, captures everything said (including asides the note will never contain), and is a magnet for subpoenas and breach claims. Treat the audio store as your highest-risk PHI system — encrypt it, lock it down, and have an explicit reason for every day you keep it.
The Consent Problem Unique to Ambient Scribes
This is where scribes differ from every other healthcare AI app, and where teams get blindsided. You are not just processing data the patient handed you — you are recording a conversation, and recording law is separate from, and often stricter than, HIPAA.
HIPAA is the easy part
Under HIPAA, using the encounter to create documentation is a treatment activity, which is permitted. So HIPAA does not, by itself, forbid an ambient scribe. If HIPAA were the only rule, consent would be a formality.
State recording law is the hard part
Many U.S. states require all-party (two-party) consent to record a conversation. A clinic in a two-party-consent state that records visits without telling the patient is exposed under wiretapping and eavesdropping statutes regardless of HIPAA. Because patients and staff cross state lines, the safe engineering default is to treat every recording as needing explicit consent rather than tracking jurisdictions per encounter.
What "consent done right" looks like
Notify the patient that an AI assistant will listen and help write the note, capture an explicit yes (verbal or tapped), make declining easy and consequence-free, and disclose that a human clinician reviews and signs the result. Store the consent as a first-class record tied to the encounter — an auditor will ask to see it. Build consent capture as a gate before the microphone starts, not a checkbox buried later.
HIPAA asks "may you use this PHI?" State recording law asks "were you allowed to record this conversation at all?" An ambient scribe has to answer both, and the second one is the one teams forget.
Which transcription + LLM vendors sign HIPAA BAAs in 2026?
A scribe has two model layers, and both need a BAA: the speech-to-text (ASR) that produces the transcript, and the LLM that turns the transcript into a structured note. A signed BAA on one layer does not cover the other. The 2026 shortlist for PHI-eligible inference:
| Layer / Option | BAA | Best For | Watch Out For |
|---|---|---|---|
| AWS Transcribe Medical + Bedrock | Both layers inside one AWS BAA | Confirm each service + model is in BAA scope | |
| Azure AI Speech + Azure OpenAI | GPT models inside an Azure boundary | Request the abuse-monitoring opt-out for zero retention | |
| Google Speech-to-Text + Vertex AI | GCP-native shops | Covered by the Google Cloud BAA, not consumer Gemini | |
| Deepgram (ASR) + BAA-covered LLM | Best-in-class medical transcription accuracy | Two vendors = two BAAs to track | |
| Self-hosted (Whisper + open LLM) | Full data residency, no third-party egress | No vendor BAA needed, but you own every control + GPU bill | |
| Consumer ChatGPT / free transcribers | — | No BAA — never send them audio or transcripts |
Staying inside a single cloud (both ASR and LLM under one provider's BAA) is the simplest path to audit. Self-hosting an open model is the only option with zero third-party egress — valuable for some government and EU customers — at the cost of running and securing the whole pipeline yourself. The BAA mechanics are in our BAA vs HIPAA explainer.
"We signed a BAA" is not "zero retention is on"
Several providers retain audio or prompts for abuse monitoring even under a BAA unless you explicitly request the zero-retention / no-training configuration. Sign the BAA and confirm the retention setting in writing — they are two separate steps, on two separate layers (speech and LLM).
How does an AI medical scribe pipeline turn a visit into a signed note?
The scribe feels like one button. Inside, it is a pipeline, and each stage produces or consumes PHI and needs its own integrity story.
1. Consent and capture
Gate recording behind consent capture, then stream encrypted audio. Decide up front whether you process in real time or after the visit, and where the audio is buffered — both are PHI-handling decisions.
2. Transcription with speaker diarization
The ASR layer converts audio to text and labels who said what (clinician vs patient). Medical-tuned models matter here — drug names, dosages, and anatomy are where generic transcription fails and a hallucinated milligram becomes dangerous.
3. Note generation by the LLM
The LLM turns the transcript into a structured draft — SOAP, H&P, or your template. Constrain it to summarize only what is in the transcript, and have it flag anything it is unsure about rather than smoothing it over.
4. Clinician review and edit
The draft is presented to the clinician to correct, complete, and approve. This is not optional polish — it is the control that makes the whole system safe and lawful. Surface low-confidence sections and make editing fast.
5. Attestation and sign-off
The clinician signs. That signature is what turns a draft into a legal medical record authored by a licensed human — not by the model. Log the signer, the timestamp, and the model version that produced the draft.
6. EHR write-back via FHIR
Write the signed note to the chart as a FHIR resource (commonly a DocumentReference or Composition), via SMART on FHIR auth. Integration patterns are in our EHR builder guide, and the audit fields to capture are in our audit logging deep dive.
The reliable pattern in 2026 is: the model drafts, the clinician disposes. Speech-to-text and the LLM do the typing; a licensed human owns every clinical word and the signature. The AI is the fastest medical student in the world, not the attending.
How should clinicians review AI-generated SOAP notes?
For a scribe, the dangerous failure is not a crash — it is a confident, wrong sentence in the chart. A hallucinated finding, an invented medication, or a dropped "denies chest pain" can change downstream care. The mitigations are concrete.
Clinician-in-the-loop, always. No note is filed without a human reviewing and signing it. This is the single most important control in the system.
No autonomous sign-off. The scribe drafts and stages; it never finalizes a note on its own. The signature must be a human action.
Ground strictly in the transcript. Instruct and constrain the model to summarize what was said, not to infer or "complete" clinical reasoning that did not happen.
Surface uncertainty. Flag low-confidence sections and unresolved items for explicit clinician attention rather than burying them in fluent prose.
Keep the source transcript. So any disputed line in the note can be traced back to what was actually said.
PHI redaction before logs. Transcripts and prompts pass through a redaction step before any observability or analytics tool sees them.
A scribe that diagnoses is a medical device
Keep the scribe on documentation. The moment it suggests a diagnosis, interprets a result, or recommends a treatment, it can fall under FDA Clinical Decision Support / Software-as-a-Medical-Device rules — see our FDA compliance overview. Summarizing what the clinician said is documentation; generating clinical judgment the clinician did not make is a different, regulated product. If your scribe writes into records governed by an FDA predicate rule (clinical trials, GxP-regulated environments), the audit-trail and e-signature bar climbs sharply — see our FDA 21 CFR Part 11 software guide.
Integrations: Speech, Storage, EHR, Observability
A scribe is only useful if the note lands in the chart. Every external system is a BAA decision and a PHI flow.
| System | PHI Touches | BAA Needed | Notes |
|---|---|---|---|
| Speech-to-text (ASR) | Always (audio + transcript) | Medical-tuned model; zero retention configured | |
| LLM (note generation) | Always (transcript) | Separate BAA from the ASR layer | |
| Audio / transcript storage | Always | AES-256, strict access, explicit retention policy | |
| EHR (Epic, Cerner, athena) | Always | FHIR DocumentReference/Composition; SMART on FHIR auth | |
| Analytics / observability | If logs include PHI | Redact at source or use a BAA-covered tier | |
| Mobile / capture device | Always (microphone) | Encrypt on-device; no PHI in crash/analytics SDKs |
The rule never changes: every vendor whose systems hear or see PHI signs a BAA, and you can draw every flow on a whiteboard.
The AI Scribe Launch Checklist
Walk this before the scribe records a real patient. Each line maps to a control an OCR investigator — or a plaintiff's attorney — will ask about.
BAA signed with the ASR vendor, the LLM provider, storage, and any analytics — both model layers covered
Zero-retention / no-training confirmed in writing for speech and LLM
Audio, transcript, and note encrypted in transit (TLS 1.2+) and at rest (AES-256)
Recording consent captured before the microphone starts, stored per encounter, easy to decline
Clinician review and signature required before any note is filed
No autonomous sign-off; the scribe only drafts and stages
Low-confidence sections flagged; source transcript retained for traceability
PHI redaction runs before transcripts/prompts reach logs or analytics
Explicit audio retention + deletion policy, documented and enforced
EHR write-back via FHIR with full audit logging of who signed and what was filed
Audit log per encounter: recording, model version, edits, signature, EHR event — retained 6 years
Risk analysis updated to name the audio store, ASR vendor, LLM, and redaction pipeline
What mistakes break HIPAA in a medical scribe pipeline?
Mistake 1: Recording without consent in a two-party state
Teams reason "HIPAA lets us use the visit for documentation" and forget recording law entirely. Recording a conversation without all-party consent where it is required is a separate legal exposure from HIPAA — and class-action territory. Gate the mic behind consent, everywhere.
Mistake 2: Letting the AI sign the note
Auto-filing a generated note to save the clinician a click removes the one control that makes the system safe and lawful. The clinician is the author of record. The model never signs.
Mistake 3: Hoarding the raw audio "just in case"
Indefinitely retained visit audio is a liability, not an asset — a breach or subpoena magnet that adds little once the note is signed. Decide a retention period, justify it, and delete on schedule.
Mistake 4: One BAA, two layers
Signing a BAA with your cloud for the LLM and assuming it covers the third-party transcription service (or vice versa) leaves a PHI flow uncovered. Both the speech and the language layers need a BAA.
Mistake 5: Shipping transcripts into observability tools
Debug logs and traces routinely carry full transcripts straight into Datadog or Sentry. If those tools are not under a BAA with redaction at source, your monitoring stack is an unlawful PHI disclosure.
Mistake 6: Treating it as "just a transcription tool"
The audio is biometric PHI and the output is the legal record of care. A scribe is a full HIPAA application held to the same standard as the EHR — skipping the risk analysis and BAAs because it "only listens" is exactly how clinics end up in an OCR file.
How to Actually Ship a HIPAA-Compliant AI Scribe
Pick the speech + LLM stack and sign both BAAs first
Choose your ASR and LLM, sign a BAA on each layer, and confirm zero-retention in writing before any code. Switching providers after launch is a painful migration.
Build consent capture as the first gate
No audio streams until the patient has been notified and has consented, with the consent stored against the encounter. Make declining trivial.
Map every PHI flow on a whiteboard
Audio, transcript, prompt egress, draft note, logs, EHR write-back. Each gets an owner, a BAA, encryption, and an audit line.
Wire transcription with diarization and a medical model
Accuracy on drugs, doses, and anatomy is a safety feature. Validate the ASR on real clinical speech, not demo audio.
Constrain the note generator and flag uncertainty
Ground the LLM strictly in the transcript, structure to your note template, and surface low-confidence sections instead of smoothing them over.
Make clinician review and signature mandatory
The draft cannot be filed unsigned. Build the review UI to be fast, and the signature to be an explicit, logged human action.
Write back via FHIR with full audit logging
File the signed note as a DocumentReference/Composition over SMART on FHIR, logging signer, timestamp, model version, and what was written.
Set retention, redaction, and incident response before launch
Decide how long audio lives, route all telemetry through PHI redaction, and add "scribe hallucinated a finding" and "recording without consent" to your incident playbook.
Frequently Asked Questions
Is an ambient AI medical scribe HIPAA-compliant?
It can be, but nothing is HIPAA-compliant out of the box. Compliance is a property of the whole system: a signed BAA with the speech-to-text vendor, the LLM, and any storage; encryption of audio, transcript, and note; access controls and audit logging; recording consent; and a clinician who reviews and signs. A scribe that records a visit and drafts a note is a full HIPAA application.
Do I need patient consent to record a visit for an AI scribe?
Yes, from two angles. HIPAA permits using PHI for treatment, but state recording law is stricter — many states require all-party consent to record. The practical standard is to notify the patient that an AI assistant is listening, capture consent, let them decline, and store that consent against the encounter.
Which AI medical scribe vendors sign a BAA in 2026?
Seven turnkey ambient scribe vendors: Abridge, Nuance DAX Copilot, Suki AI, Augmedix, athenaAmbient, DeepScribe, and Heidi Health. All sign BAAs as part of their standard contract. If you build your own, you need a BAA at two layers: for speech-to-text — AWS Transcribe Medical, Azure AI Speech, Google Cloud Speech-to-Text, or Deepgram. For the note-drafting LLM — Azure OpenAI, AWS Bedrock, Google Vertex AI, Anthropic Enterprise API, or OpenAI enterprise. Consumer ChatGPT, Otter.ai, Notion AI, and free transcribers will not sign a BAA and must never touch the audio or transcript.
Can an AI scribe write notes into the EHR automatically?
It can draft and stage a note, but it should not sign or finalize one on its own. The clinician is the legal author of the record and must review, edit, and attest before the note is filed — typically as a FHIR DocumentReference or Composition in a pending state until signed, with an audit trail of who signed and when.
What happens if the AI scribe hallucinates something in the note?
A fabricated finding or dropped negative is a patient-safety event, because the chart drives downstream care. That is why clinician-in-the-loop review is non-negotiable: the model drafts, the clinician verifies against what happened and signs. Good systems flag low-confidence sections, never auto-file unsigned notes, and keep the source transcript so any line can be traced back.
Is an AI medical scribe a regulated medical device (FDA)?
A scribe that transcribes a visit and drafts documentation for clinician review is generally administrative and outside device rules. The line is crossed when it suggests a diagnosis, interprets results, or recommends treatment, which can pull it under FDA Clinical Decision Support / SaMD regulation. Keep the scribe on documentation and let the clinician own every clinical judgment.
How long should I keep the ambient scribe audio recording?
As short as you can justify. Many implementations transcribe, let the clinician sign the note, then delete the audio — the signed note is the record of care, and retained audio is a breach and subpoena risk. If you keep it, treat it as PHI: encrypt, restrict access, set an explicit retention/deletion policy, and document the decision in your risk analysis.
Build a HIPAA-compliant AI scribe without rebuilding the compliance stack
VertiComply generates healthcare app code with BAA-ready AI integration, PHI encryption, audit logging, consent capture, and FHIR write-back built in — so your team ships the scribe workflow, not the regulatory plumbing.
BAA-ready AI. PHI encrypted by default. Audit logs you can hand to OCR.
In This Guide
01
Why did the AI scribe break out in 2026?
02
What does HIPAA-compliant actually require?
03
The PHI data flows
04
The consent problem
05
Which vendors sign HIPAA BAAs?
06
How does the pipeline work?
07
How should clinicians review notes?
08
Integrations
09
The launch checklist
10
What mistakes break HIPAA?
11
How to actually ship it
12
FAQ
Key Points
BAA on speech AND LLM
x2
Before the mic starts
Consent
Signs every note
Human
Audit log retention
6 yrs
Glossary
Topics
Related Articles
Continue reading about healthcare AI and compliance
HIPAA Compliant AI: How to Build It Right in 2026
The AI vendors that sign BAAs, where PHI leaks happen, and the architecture that keeps LLM features safe under HIPAA. For builders, not lawyers.
Read article
Build a HIPAA-Compliant AI Chatbot for Patient Intake in 2026
The architecture for a HIPAA-safe intake bot, which LLM vendors sign BAAs, PHI-redaction patterns, and the 3 things most chatbot builds miss.
Read article
Automated Compliance Scoring: How AI Validates Healthcare Code
How AI scores healthcare code against § 164.312 line-by-line, the rules that catch real PHI leaks, and where human review still wins.
Read article