The privacy question in ambient clinical documentation starts before there is a note. It starts when a microphone is allowed to sit in the clinical encounter and collect a live conversation that was never shaped for a chart field: the patient’s symptoms, a spouse’s clarification, a child’s name, a family history detail, an offhand reference to someone else’s diagnosis, and the acoustic features of each speaker’s voice.

That is what makes ambient AI scribes different from ordinary EHR documentation. A clinician typing a note can still enter too much information, but the data path begins with human selection. Ambient documentation reverses that order. The system captures first, processes later, and decides downstream what should become part of the record. Privacy risk therefore cannot be evaluated only at the final note. It has to be followed through capture, transmission, model processing, storage, and secondary use.

Multi-layered privacy risk pipeline for ambient clinical documentation from exam-room capture through cloud transmission, LLM processing, storage, and secondary use

The Recording Layer: More Than a Faster Way to Write a Note

A standard privacy review often asks whether protected health information is being used for treatment, payment, or operations; whether a vendor signs a business associate agreement; and whether access is controlled. Those questions still matter. They do not fully answer what happens when the raw input is audio from an exam room.

Audio carries information that text does not. It may include bystanders who did not expect to be part of the documentation workflow. It may capture side comments before the clinician redirects the visit. It also contains voice characteristics that are harder to de-identify than a typed sentence. An AMA Journal of Ethics analysis in 2025 flagged voice biometric re-identification as an acknowledged gap when ambient listening tools integrate recordings with EHR data; removing names and obvious identifiers may not be enough if the voice itself remains linkable to a person.[1]

The practical implication is simple: consent and signage cannot treat ambient capture as if it were only a dictation tool. A patient may agree that the clinician can use a scribe to prepare the note, while still caring deeply about whether the recording is stored, whether family members’ comments are included, whether the vendor receives identifiable audio, and whether the audio can later be reused.

Transmission Risk Is a Workflow Question, Not Just a Security Checkbox

Many ambient documentation products depend on cloud services. That does not make them inappropriate for clinical use. It does mean the privacy analysis must name each handoff instead of collapsing the workflow into the phrase “HIPAA-compliant.”

A due diligence review should be able to describe where the audio goes after capture, whether transcription occurs locally or remotely, whether identifiable audio is transmitted, which subcontractors receive data, how traffic is encrypted, how failures are logged, and what happens when the visit cannot be processed. If the answer is only that the vendor has a BAA, the health system has not yet evaluated the transmission layer; it has evaluated one legal instrument attached to it.

This is also where legal theories can arrive earlier than operational teams expect. An ABA Health Law analysis in 2026 advised health systems to revisit consent practices and ensure BAAs address model use, subcontractors, and training data. It also discussed April 2026 class actions involving Sutter Health and Sharp HealthCare, where the alleged violation is tied to interception under CIPA and the Federal Wiretap Act.[2] Those allegations are early and untested. They are not proof that ambient scribes are unlawful. They do show why a privacy review that starts only after data has entered the EHR may be starting too late.

The LLM Processing Layer Is Where Documentation Can Leak

The most distinctive ambient clinical documentation privacy risks appear when the system converts a conversation into a note. At that stage, the issue is not only whether a model invents information. It is also whether the model includes real information that should have been excluded.

Chim et al. tested LLaMA-3.1, Mixtral, and Claude 3.5 on synthetic clinical transcripts and found that third-party personal information leaked into generated notes at rates ranging from 2% to 36%, depending on the model and prompting approach.[3] The study’s design matters: synthetic transcripts and a subset of models from late 2024 do not prove what every deployed product will do in a real clinic. The findings are still important because they isolate a failure mode inside the documentation act itself.

Third-party personal information leaking from a clinical transcript into an AI-generated note during LLM processing despite a partial privacy prompt filter

Third-party leakage is not the same as hallucination. A hallucination adds unsupported information. A leakage event can involve accurate information from the transcript that does not belong in the patient’s note. If a patient says, hypothetically, that their brother lost his job after a psychiatric hospitalization, the model does not need to fabricate anything to create a privacy problem. It only needs to carry the brother’s personal detail into the generated clinical documentation.

That distinction matters for mitigation. General accuracy testing may miss it. A note can be faithful to the conversation and still be privacy-inappropriate. A clinician reviewing the note may also miss the problem if the leaked detail looks clinically adjacent, especially when the visit included a complicated social or family context.

The Chim et al. study also found that privacy instructions reduced leakage by about 7.2 percentage points, but did not eliminate it.[3] That is the right way to think about prompts: useful controls, not absolutions. A prompt can tell the model not to include third-party personal information. It cannot, by itself, guarantee that every generated note will respect that boundary.

One particularly uncomfortable finding was “knowing leakage” in open-weight models: cases where the model appeared to recognize that information should not be included, yet included it anyway.[3] That is different from a model failing to understand the instruction. It is a behavior pattern that should push buyers away from relying on vendor assurances about policy alignment and toward evidence about actual output behavior under realistic documentation tasks.

The best results in the study came from combining privacy prompts, structured outputs, and post-processing.[3] That combination is more operationally credible than any single safeguard. Structured outputs can constrain what the model is asked to produce. Post-processing can scan for categories of information that should not enter the note. Human review can catch clinical context that automation may not understand. None of those layers is perfect; together, they give a health system something to audit, tune, and improve.

What to Ask at the Processing Layer

  • Does the vendor test for third-party leakage separately from hallucination and general note quality?
  • Are privacy instructions embedded only as prompts, or are they reinforced through structured fields, exclusion rules, and post-processing?
  • Can the health system review sample failures, not only aggregate accuracy claims?
  • Does the product preserve enough audit information to reconstruct why inappropriate information entered a note?
  • Are clinicians trained to review for privacy-inappropriate content, not only clinical inaccuracies?

Consent for ambient documentation can become too thin if it is treated as a front-desk formality: “We use AI to help document your visit; is that okay?” That may satisfy a local workflow requirement, but it does not necessarily answer the questions patients consider material.

Lawrence et al. reported in a 2025 JAMA Network Open study that 59.2% of patients did not want their data shared with the ambient documentation vendor. Patients rated knowing where audio is sent and how it is used as critical at 96.1% for each item, and knowing who has access as critical at 98.1%.[4] The study was a single-site quality improvement project at NYU Langone with 103 patients; the sample was 92.2% English-speaking and 81.6% college-educated, so it should not be stretched into a universal national estimate.[4] Even with that limitation, the signal is hard to ignore: patients are not merely reacting to the phrase “AI.” They are asking about data movement, access, and use.

That distinction should change consent scripts. A meaningful script does not need to become a technical lecture, but it should not hide the vendor relationship. It should tell patients whether the conversation is recorded, whether audio leaves the organization, whether the vendor processes identifiable information, whether recordings are retained, who may access them, and whether data may be used to improve or train systems.

The hard part is that consent language must match the contract. If a script says audio is used only to create the note, the BAA and service terms should not permit broader uses through a secondary clause. If the contract allows subcontractors to process audio, the patient-facing explanation should not imply a closed internal workflow. If data is retained for quality assurance, the retention period and deletion process should be knowable before deployment.

Pipeline stagePrivacy question that should not be skippedWhy a single safeguard is insufficient
CaptureWho and what may be recorded in the room?Consent may cover the patient but not fully address bystanders, incidental disclosures, or voice data.
TransmissionWhere does audio or transcript data travel before note generation?A BAA does not by itself explain routing, subcontractors, failure handling, or logging.
LLM processingCan the model include information that should be excluded?Privacy prompts reduce leakage but do not eliminate it.
Storage and retentionWhat is kept, in what form, and for how long?A final EHR note policy may not govern raw audio, intermediate transcripts, or vendor logs.
Secondary useCan data be used for product improvement, model training, analytics, or evaluation?Consent language and vendor terms may diverge unless reviewed together.

Storage and Retention: The Note Is Not the Only Artifact

Once the clinical note is signed, privacy teams still need to know what remains outside the EHR. Ambient documentation workflows may create raw audio, transcripts, intermediate model inputs, generated drafts, metadata, logs, and quality review artifacts. Some may be ephemeral. Some may be retained by the vendor. Some may sit in systems that are not visible to ordinary chart access auditing.

This is where procurement language becomes privacy infrastructure. Retention periods should be explicit for each artifact, not only for the final note. Deletion rights should include vendor-controlled copies where feasible. Audit logs should show who accessed retained data and why. Incident response terms should account for audio and transcript exposure, not only EHR record compromise.

The operational test is whether the organization could answer a patient who asks, “Where did my voice go?” A defensible answer cannot be assembled after the fact from marketing claims. It has to be built into the contract, architecture review, and clinic workflow before the first room is enabled.

Secondary Use Is Where “Documentation Support” Can Become Something Else

Secondary use is often where ambient documentation reviews become vague. The product is introduced as a way to draft notes, but the vendor terms may discuss quality improvement, analytics, product development, model evaluation, or training. Those uses are not all equivalent, and they should not be hidden under a general statement that the tool helps clinicians document care.

The ABA analysis specifically recommends that BAAs address model use, subcontractors, and training data.[2] That is a minimum due diligence expectation, not a paperwork preference. If identifiable clinical conversations can contribute to model improvement, the health system needs to know whether patients were told, whether the use is permitted, whether opt-outs are honored, whether de-identification is adequate for voice and transcript data, and whether downstream recipients are bound by the same limits.

This is also where internal governance should avoid a false binary. A health system does not have to reject every form of product improvement to manage privacy risk. It does have to distinguish operational support for a specific encounter from broader reuse of accumulated clinical data. Patients may accept the first and object to the second, as the Lawrence et al. consent findings suggest.[4]

Privacy Review Now Overlaps With AI Governance

Ambient scribes that summarize conversations are not merely passive transcription systems. They select, condense, and structure clinical information. That matters for note quality, patient safety, and regulatory classification as well as privacy.

Ohde et al. noted in a 2026 npj Digital Medicine perspective that AI scribes with summarization, rather than transcription alone, may meet FDA medical device criteria, and that NHS England has already classified such tools as requiring regulatory scrutiny.[5] The article is a perspective, not an empirical deployment study, but it marks an important boundary: once a system transforms conversation into clinical documentation, privacy due diligence should sit beside broader AI governance, not in a separate paperwork lane.

A Due Diligence Frame for Ambient Clinical Documentation Privacy Risks

The evaluation should follow the data, not the sales category. A health system can be enthusiastic about reducing after-hours documentation and still require stage-specific answers before deployment.

  • Capture: Define when recording starts and stops, how patients and bystanders are informed, what happens if consent is declined, and whether voice data is treated as a special privacy concern.
  • Transmission: Map where audio, transcripts, and drafts travel; identify cloud services and subcontractors; verify encryption, logging, and failure handling.
  • Processing: Require evidence on third-party leakage, not only general accuracy; ask how prompts, structured outputs, post-processing, and human review work together.
  • Storage: Specify retention and deletion rules for raw audio, transcripts, drafts, metadata, logs, and quality review artifacts.
  • Secondary use: Separate documentation for the encounter from analytics, product improvement, model evaluation, and training; align consent language with contract terms.
  • Accountability: Make audit trails, incident notification, subcontractor controls, and patient inquiry responses testable before go-live.

A BAA matters. Consent matters. Privacy prompts matter. Each addresses only part of the pipeline. Ambient clinical documentation privacy risks become manageable only when the organization can say what is captured, where it goes, how the model behaves, what is retained, who else can touch it, and whether today’s clinical conversation can become tomorrow’s training data.

References

  1. How Should We Think About Ambient Listening and Transcription Technologies' Influences on EHR Documentation and Patient-Clinician Conversations? — AMA Journal of Ethics, 2025
  2. Ambient AI Scribes - Efficiency Gains vs Emerging Privacy and Cybersecurity Risks — ABA, 2026
  3. Evaluating privacy leakages in LLM-driven ambient clinical documentation — Frontiers in Digital Health, 2026
  4. Informed Consent for Ambient Documentation Using Generative AI in Ambulatory Care — JAMA Network Open, 2025
  5. Barriers and opportunities of scaling ambient AI scribes for clinical documentation across diverse healthcare settings — npj Digital Medicine, 2026