When an AI Note-Taker Requires a BAA

An AI note-taker becomes a business associate as soon as it touches protected health information. A general-purpose meeting tool that captures a care-coordination sync where a patient name is mentioned is legally indistinguishable from a purpose-built clinical scribe. The classification has nothing to do with intent or product category. It turns entirely on what data flows through the tool.

The downstream consequence is specific and non-negotiable. Sharing PHI with a vendor before a signed BAA is in place is itself a HIPAA violation, regardless of how good that vendor's encryption or security page looks. Compliance obligations run through all three phases of a note-taking workflow: recording the visit, reviewing and editing the draft, and finalizing before the note enters any record. Not just storage.

That classification is where due diligence begins, not where it ends. OpenWhispr's analysis of what HIPAA actually requires of an AI note-taker confirms the subcontractor flow-down rule. If the note-taker routes audio to a third-party model provider, that provider is also a subcontractor and needs its own BAA. The compliance surface widens beyond the single vendor relationship most teams negotiate.

What the BAA actually obligates a vendor to do — and where the document's reach stops

A signed BAA creates enforceable legal accountability for PHI handling. But its scope is defined by what the agreement actually enumerates. A BAA that does not name a feature does not cover that feature. That single sentence explains most of the compliance failures healthcare teams encounter in 2026.

The agreement must bind the vendor to five obligations. First, Security Rule safeguards: access controls, audit logging, encryption in transit and at rest, and a written incident response process. Second, breach notification: the vendor must notify the covered entity of any breach of unsecured PHI without unreasonable delay. Third, minimum necessary use: the vendor may only use PHI in the ways the BAA explicitly permits. The secondary use to scrutinize here is training AI models on patient data, because a BAA that does not prohibit it allows it.

Fourth comes subcontractor flow-down, the least understood obligation and the one that makes gateway architecture relevant later. Any third-party model provider in the audio or transcript pipeline must have its own BAA in place. Fifth is data disposition. The agreement should specify what happens to PHI if the organization stops using the service.

One phrase deserves a warning. "HIPAA certified" is not verifiable. No agency certifies software as HIPAA compliant. A vendor advertising certification is either shortening "we passed a third-party readiness assessment" or has misunderstood the rule. The honest phrasings are "HIPAA compliant," "we support HIPAA compliance," or "we sign BAAs." OpenWhispr's breakdown confirms the core point: without a signed BAA, sending PHI to a vendor is a violation however good their encryption is. The contract and the technical safeguards are both necessary. Neither is sufficient alone.

The trap most teams fall into: a BAA that excludes the AI features

The dominant failure mode in 2026 is not a vendor refusing to sign a BAA. It is a vendor signing one that quietly does not cover the AI pipeline. Teams walk away contractually papered over while their most sensitive workflow remains unprotected.

The structural reason this happens is procedural. Compliance reviews the core platform. The AI features ship later on a different legal footing. The carve-out never surfaces in the sales call. OpenWhispr's August 2026 analysis documents the pattern with a concrete example: Notion will sign a BAA, but only for Enterprise customers above a minimum seat count, and Notion AI is excluded from that coverage on every plan. Organizations can store PHI in a Notion database. They cannot point Notion AI at it.

The minimum-necessary-use provision makes scope especially consequential. A vendor can only use PHI the way the BAA allows. AI features left outside the BAA's scope are not constrained by minimum-necessary-use. The vendor can do what their standard terms permit. The minimum-necessary-use clause is toothless when AI features live outside the BAA's scope, because a vendor can process PHI however their standard terms permit once the agreement does not constrain it. If PHI redaction happens at the gateway, before audio or transcripts reach any model provider, the vendor's own AI terms don't matter. The sensitive data never arrives unguarded in the first place. The practical check this implies: ask for the BAA's scope in writing, feature by feature, rather than a yes-or-no about whether the company signs BAAs at all.

How the major general-purpose note-takers handle BAA coverage in practice

Among the widely used general-purpose AI note-takers, BAA availability is real but conditional. Every cloud vendor gates it to a top tier. Compliance becomes a plan-tier purchase as much as a vendor relationship.

Otter.ai announced HIPAA compliance in July 2025 following an independent assessment. It signs a BAA, but only at the Enterprise tier. Basic, Pro, and Business customers cannot obtain one. A clinician on any of those plans is making impermissible disclosures regardless of the vendor's security posture. Audio is processed and stored on Otter's servers. PHI lives in Otter's cloud under contract, and compliance is a plan-tier purchase.

Fireflies.ai signs a BAA at the Enterprise tier and additionally requires Private Storage to be enabled. All three conditions, Enterprise plan, Private Storage, and signed BAA, must be in place simultaneously. Minutes' July 2026 breakdown documents this with unusual precision: if any one condition lapses, compliance is disabled. Free, Pro, and Business plans are not covered. Fireflies also reports signing BAAs with its own subprocessors barring ePHI training and storage. The subprocessor chain is contracted, not assumed.

Fathom publishes a blanket BAA, but the plan-gating is stated ambiguously across Fathom's own pages. Confirm in writing which tier your BAA covers before you record any PHI. Fathom uses US-only storage, while AI processing runs via Anthropic, OpenAI, Google, and ElevenLabs.

Granola states in its own documentation that it is HIPAA compliant for Enterprise customers and can sign a BAA on that tier. HIPAA support is not available on Free, Personal, or Business plans. Transcription runs via Deepgram and AssemblyAI, while notes route through OpenAI, Anthropic, xAI, Google Cloud, and Fireworks.ai, with storage on US AWS. The candor is notable and useful.

Krisp has a BAA available per its security page. On-device processing applies to the audio-cleanup path, the noise cancellation, not the notes pipeline. AI notes route through Azure and transcripts are stored in Krisp Cloud once notes are enabled. On-device transcript storage is an Enterprise-only feature. If you're drawn to Krisp for its on-device reputation, confirm exactly which pipeline components stay off-server under your plan.

What a genuinely covered deployment requires beyond the signed agreement

A signed, correctly scoped BAA is necessary but not self-executing. The configuration and controls that make it real are a separate checklist. Missing any one item leaves the deployment unsafe for PHI even with a valid contract in place.

Data residency and subprocessors come first. Where is data hosted, and does any offshore processing occur? Offshore routing can break local rules even when HIPAA is met. Training controls matter equally. Whether patient data trains models by default determines the entire risk profile, and for PHI the baseline requirement is no model training on patient recordings. Encryption standard must be confirmed in transit and at rest, not assumed from a security page.

Audit logging deserves its own line. Logs of PHI access, including who opened what and when, are needed for regulatory examination readiness, not just internal review. Role-based access controls and SSO/SAML are required for any healthcare team deployment where more than one person reviews or approves notes. Third-party certifications like SOC 2 Type II and HITRUST are supporting evidence that a vendor runs a real security program. They are not a substitute for the BAA or the configuration checklist. Treat them as a confidence signal, not a compliance shortcut.

Consent to record is a separate gate. Recording law and PHI rules are two independent requirements, and state law governs consent. Some jurisdictions require all-party consent. Others allow one-party. A compliant PHI workflow must clear both gates every time. The SimplePractice example makes the verify-in-writing point concrete: the company announced it would begin retaining de-identified and de-coupled Note Taker session transcripts on June 17, 2026, while emphasizing that it did not use retained transcripts to update the underlying AI model. Policies change. The burden is on the organization to catch the change.

Why the subprocessor chain is where most BAA coverage quietly breaks down

Even a correctly scoped BAA with the note-taker vendor does not guarantee protection if the LLM or ASR provider in that vendor's pipeline lacks a BAA of its own. Most general-purpose model providers do not offer BAAs on standard plans. This is the structural gap most teams never examine.

The specific exposure is well documented. OpenWhispr's August 2026 analysis notes that OpenAI's standard ChatGPT consumer plans, Free, Plus, Pro, Team, and Business, do not offer HIPAA Business Associate Agreements as of that date. The API does offer a BAA pathway for eligible healthcare customers. But sharing session transcripts or identifying client details with the consumer services constitutes a HIPAA violation regardless of what the note-taker's own BAA says. The note-taker's contract does not reach upstream to the model provider.

Vendors that handle this correctly document it explicitly. Fireflies reports signing BAAs with its own subprocessors barring ePHI training and storage. The subprocessor chain is contracted, not assumed. The practical verification question this creates applies to every note-taker under evaluation. Ask not just "do you sign a BAA?" but "who are your subprocessors for audio transcription and AI note generation, and do you have BAAs with each of them?"

On-device or local processing changes this calculus. A tool that transcribes and processes audio entirely on the clinician's own hardware never transmits PHI to a cloud provider. That eliminates the subprocessor flow-down problem at its root. But it requires verifying that every stage of the pipeline, including any cloud sync, remains local.

How an AI gateway changes the compliance architecture for teams handling PHI across multiple models

For healthcare and healthtech teams routing PHI through multiple AI services, per-vendor BAA negotiation is an incomplete approach. The compliance surface is too wide. The controls are too fragmented to audit reliably.

A gateway sitting in front of every model call solves the subprocessor problem at the infrastructure layer. PII and PHI redaction runs at one chokepoint before any prompt leaves the organization's perimeter. That replaces redaction implemented separately in each application, where it can be skipped or drift between microservices. The audit trail argument points the same direction. Redaction logic distributed across applications produces no unified record of what was redacted, by which policy, and when. A gateway produces one centralized log covering every service, satisfying HIPAA audit requirements without manual aggregation.

The reliability argument is inseparable from the compliance argument. A healthcare application that calls LLM APIs directly is one provider outage away from downtime. A gateway with automatic fallback across providers serving the same model keeps the product online when one provider goes down, no code change needed. Spend visibility matters here too. AI usage in regulated workflows should be traceable by team, project, and model in real time, not reconstructed from end-of-month invoices.

Even when a note-taker vendor does sign a BAA and includes AI features, the downstream question remains: which model providers does it use, and do those providers have BAAs of their own? Teams deploying note-takers through a unified LLM gateway, such as Concentrate, can verify the full chain in a single compliance conversation rather than negotiating separately with the note-taker vendor and each model provider it selects. For AI-native healthcare startups specifically, a fully managed gateway, one that does not require a platform team to deploy or maintain, makes enterprise-grade controls available from day one. Concentrate sits between the note-taker and multiple model providers, centralizing the compliance surface and enforcing zero data retention so PHI never persists in the model provider's systems. That addresses the subprocessor obligation at the infrastructure layer rather than leaving it to each application team to negotiate individually.

The six-item checklist a healthcare team should run before any AI note-taker touches PHI

A BAA is the starting point of due diligence, not the end of it. The checklist that follows separates a healthcare team that is genuinely protected from one that is contractually covered but operationally exposed. Item 1: BAA scope. Request the BAA and confirm it names AI transcription and note generation specifically, not just data storage. Ask which plan tier the BAA covers and whether any features are excluded from its scope.

Item 2: Subprocessor chain. Ask for the vendor's full subprocessor list for audio and AI processing. Confirm BAAs exist with each and that they prohibit training on PHI.

Item 3: Retention and training controls. Confirm in writing how long raw audio and transcripts are retained. Check whether deletion is automated, and whether any opt-out of model training is required proactively rather than applied by default.

Item 4: Encryption and access controls. Verify encryption standard in transit and at rest. Confirm RBAC and SSO/SAML are available and enabled for your deployment, not just listed in the security page.

Item 5: Audit logs. Confirm the vendor produces logs of PHI access, who accessed what, when, and what was changed, in a format that supports regulatory examination. Those logs must be available to your compliance team, not just the vendor.

Item 6: Consent to record. Verify the consent workflow matches the recording law of every jurisdiction where the tool will be used. This is a separate legal gate from HIPAA and must be cleared independently.

Compliance is a deployment property, not a vendor feature. The BAA is the document that starts the conversation. The configuration, the subprocessor chain, and the six checks above determine whether a healthcare team is genuinely protected or just contractually papered over.