Clinical documentation AI — ambient scribes that listen to encounters and draft SOAP notes — is the fastest-adopted AI category in healthcare, and it is also a pipeline that moves protected health information through four stages before a note is ever signed. Compliance badges on a vendor homepage do not tell you whether that pipeline is governed; stage-by-stage controls do. This page maps where PHI actually travels in documentation AI, defines the controls each stage needs, and gives you the evaluation criteria to run against any tool — vendor-hosted or self-hosted — before it touches a real encounter.
The Pipeline: Where PHI Actually Travels
The pipeline runs capture to transcription to note generation to EHR writeback, with PHI present at every stage — raw audio of the encounter, verbatim transcripts, generated drafts, and the signed record — plus the retention stores and logs each stage leaves behind.
| Stage | What it holds | The exposure teams forget |
| Capture | Encounter audio — the richest PHI in the whole pipeline | Recordings lingering on phones or recorders outside any governed store |
| Transcription | Verbatim transcript of everything said | Transcript caches in vendor clouds beyond the BAA's scope |
| Note generation | AI-drafted SOAP or progress note | Drafts and prompt logs stored in services the BAA never named |
| Writeback and retention | The signed record, plus drafts, audio, and logs | Retention with no policy: audio kept indefinitely "in case" |
Two architecture variations change the map without changing the logic: some tools transcribe on-device before anything transmits, and some keep drafts inside the EHR vendor's environment. Map your candidate tool's actual path — where audio goes, where transcripts rest, what the note-generation service receives — because the controls in the next section attach to the path as it really is, not as the generic diagram draws it.
Controls per Stage: The Evaluation Criteria

Evaluate each stage against its controls: capture needs consent workflow and encryption at the source, transcription and generation need BAA-covered processing with no-training-on-your-PHI terms, writeback needs scoped EHR integration credentials, and every stage needs access control and audit trails — the criteria set is checkable per stage, not a badge on the homepage.
| Stage | Controls to verify | The artifact that proves it |
| Capture | Consent workflow, encryption from the device | Consent flow documentation; encryption spec for the capture path |
| Transcription and generation | BAA covering these services specifically; contractual no-training-on-your-PHI terms | The BAA text naming the features; the training-use clause |
| Writeback | Scoped EHR credentials; least-privilege integration account | The integration's permission set, not an admin service account |
| All stages | Role-based access; audit trails of access and processing | Access model documentation; a sample audit export |
The two checks that catch the most real-world problems are scope-checking the BAA (an agreement that covers "the platform" but not the specific ambient-scribe feature you are deploying is a gap, not a control) and the training-use clause (whether your encounters may improve the vendor's models — a term to bind off explicitly). Both are contract artifacts you can read, which is the point: every criterion in the table converts into a document you can request.
Accuracy Is a Clinical Control, Not a Feature
The draft note is clinical content: errors propagate into the record and downstream care, so accuracy measurement on your specialty's encounters, a documented review-and-edit workflow, and the signing clinician's retained accountability are compliance controls — vendor accuracy claims on their benchmarks are a starting point, not the control.
- Measure on your encounters: vendor accuracy figures come from their benchmark sets; your specialty, accents, and documentation style are different populations. Pilot on real encounters and measure.
- Track error classes: a missed medication name and an awkward phrasing are not the same class of problem; the review workflow should weight them differently.
- Document the review workflow: who reviews, what they check, and what happens when the draft is wrong — this is the control the compliance narrative cites.
- Retain clinician accountability: the signature on the note remains the clinician's; the tool drafts, the human attests. State it in policy.
This reframing matters in procurement: when accuracy is a control, "99% accurate" stops being a selling point and becomes a claim you verify on your own encounters before it enters your risk analysis.
Deployment Models: Vendor Scribe, Hybrid, or Self-Hosted
BAA-backed scribe vendors fit most small and mid-size practices that accept vendor processing under contract; hybrid designs keep audio capture on-device; self-hosted pipelines fit health systems with platform teams whose data policy demands the entire pipeline inside their boundary — each model shifts controls and evidence burden differently.
| Model | Fits | Control shift | Evidence burden |
| BAA-backed vendor scribe | Small and mid-size practices | Processing controls sit with the vendor, under contract | Verifying BAA scope, terms, and the vendor's attestations |
| Hybrid (on-device capture) | Practices wanting audio to stay local | Capture controls on your devices; processing possibly vendor | Device management evidence plus the vendor evaluation |
| Self-hosted pipeline | Health systems with platform teams and strict data policy | Every control inside your boundary; nothing external to contract | You produce all evidence — and own all operations |
No model is automatically compliant: a vendor deployment with an unscoped BAA fails an audit a well-governed self-hosted pipeline would pass, and vice versa. What differs is where the controls live and who produces the evidence. For health systems whose policy concludes self-hosting, dedicated environments such as OneSource Cloud's healthcare AI infrastructure are one option for running the pipeline inside the organization's boundary — evaluated against the same stage controls as any alternative.
FAQ
Do patients need to consent before ambient documentation AI records the visit?
Practically yes in most deployments: state recording-consent laws apply to encounter audio, and professional guidance favors disclosure-and-consent workflows. The consent mechanism belongs in the capture stage's controls and should be documented in your policy.
Who is responsible if an AI-drafted note contains an error?
The signing clinician retains accountability for the record — which is why review-and-edit workflows are a compliance control, not an optional step. Vendor terms govern the vendor's service obligations, not your clinical record's accuracy.
How long should encounter audio be retained after the note is signed?
Long enough to serve your QA and dispute-resolution process, no longer: retention is a documented policy decision per artifact type (audio, transcript, draft), and the shortest defensible window reduces both breach surface and storage compliance burden.