AI Meeting Assistants Under HIPAA: Architecture and Evaluation

A meeting assistant that joins a call, transcribes it, and emails the summary is genuinely useful — and in a healthcare organization it is also a PHI pipeline, because clinical coordination calls, case conferences, and payer discussions routinely contain identifiable health information. The question is not whether your teams will use meeting AI (they already are, sanctioned or not) but which architecture their PHI flows through. This page explains when meetings pull PHI into scope, compares the three deployment architectures, and gives the evaluation questions that settle any tool.

When a Meeting Pulls PHI Into Scope

A meeting falls under HIPAA when its recording, transcript, or summary captures individually identifiable health information — which describes most clinical coordination calls, case conferences, and payer discussions, and means the question is not whether your teams use meeting AI but which tool architecture their PHI flows through.

The scope boundary is porous in practice: any meeting can drift into patient detail, which is why ungoverned AI notetakers create exposure even in organizations that never intended them for clinical content. Compliance guidance specifically flags general-purpose notetakers capturing PHI on healthcare calls without governance as a real and common risk pattern. Treat scope classification as a starting point for policy, not a guarantee — the architecture section assumes PHI will show up in meetings you did not predict.

Three Architectures: Where the Audio Goes

Three architectures exist: SaaS bots that join calls and process audio in vendor clouds under BAA, boundary-internal processing where transcription and summarization run on infrastructure you control, and on-device capture that never transmits audio at all — differing in control, evidence burden, and operational cost.

On-device, bot-free transcription is a real and growing option — vendors now position local processing explicitly as the way to keep PHI on the clinician's device — and boundary-internal processing is the standard answer for organizations that want transcription and summarization on infrastructure they govern; dedicated environments such as OneSource Cloud's healthcare AI infrastructure are one way to host that middle architecture. None of the three is automatically compliant: a SaaS bot with a well-scoped BAA and managed retention can out-perform a sloppily run internal deployment on every audited dimension.

Evaluating Any Meeting AI Beyond the BAA

The BAA is the entry ticket, not the evaluation: check what the BAA scopes (which features), where recordings and transcripts live and for how long, whether retention and deletion work, who can access outputs, whether redaction is available, and how the tool announces itself to participants.

• BAA scope: does the agreement name the specific features you will use — transcription, summaries, search — or just "the service"? Feature-scoped or nothing.
• Storage location and retention: where do recordings and transcripts rest, for how long, and does deletion actually propagate to backups and derived indexes?
• Access model: who can see a meeting's outputs — the participants, the whole org, anyone with a link? Sharing defaults are where meeting PHI leaks.
• Redaction and minimization: can the tool redact identifiers from transcripts, or exclude meetings by policy?
• Bot disclosure: does the assistant announce itself, and does your policy require it? Recording-consent law applies to bots as to any recorder.

Run the checklist against one candidate in a trial environment and record the gaps — the artifact trail (BAA text, retention configuration, an access review) is what your compliance file needs, and what a vendor homepage cannot supply.

FAQ

Is Fireflies HIPAA compliant — or Read, or Otter?

The general rule answers all three: a tool is HIPAA-usable when your deployment has a BAA covering the exact features used, plus the retention, access, and disclosure controls above. Vendor offerings change by tier and over time, so verify the current agreement rather than relying on any standing label.

Do we have to tell participants a bot is recording?

Yes in most cases: state recording-consent laws apply to meeting bots as to any recording, and disclosure is the professional baseline in healthcare settings. Build the announcement into the meeting policy rather than relying on platform notifications.

Can we just ban meeting AI instead?

You can prohibit unapproved tools — and should — but bans alone push usage into shadow IT. The durable answer is an approved architecture (even a narrow one) plus policy, because the demand for meeting notes is real and ungoverned tools are worse than governed ones.