Blog · HIPAA · 2026-04-24
What is a BAA, actually — and what it does NOT cover
A Business Associate Agreement is a load-bearing piece of HIPAA compliance, and it is also a contract that many clinicians sign without ever reading. Here is what it does, what it doesn't, and why the 2026 subprocessor-breach pattern has changed how you should read one.
TL;DR
A BAA is the contract that makes a vendor a legal "business associate" of your practice when that vendor handles Protected Health Information on your behalf. It allocates breach-notification duties, subcontractor obligations, and liability. It does not prevent breaches, guarantee subprocessor behavior, shield against valid subpoenas, or remove your own Security Rule responsibilities. Treat it as one control in a stack — not the whole stack.
A common Tuesday at a private practice
A solo LCSW opens a browser, signs up for an AI therapy scribe, and gets a DocuSign link for a Business Associate Agreement. She reads the first page carefully, skims the middle, signs. The vendor's welcome email says "You are now HIPAA compliant." She feels, reasonably, that she has just bought a safe product.
Six months later she reads a headline. An LLM API provider — a subprocessor her scribe vendor uses behind the scenes — had a security incident. The scribe vendor sends out a breach notification letter. Under the HIPAA Breach Notification Rule, because she is the covered entity, she is the one who has to notify her clients. Her BAA was signed. Her compliance paperwork was in order. She still has to make the call.
The BAA did exactly what a BAA does. It did not do several things she thought it was doing.
What a BAA actually is (the legal version)
The BAA is defined in the HIPAA regulations at 45 CFR §164.504(e). In plain English, a BAA is the contract that exists because HIPAA allows covered entities (your practice) to disclose PHI to third parties (your scribe vendor, your EHR, your billing service) on two conditions: (1) the disclosure is permitted under the Privacy Rule, and (2) the third party has signed a written agreement that binds them to handle the PHI consistent with HIPAA's requirements.
That written agreement must, at minimum:
- Describe the permitted and required uses of PHI.
- Prohibit uses that would violate the Privacy Rule if done by the covered entity itself.
- Require appropriate safeguards (the Security Rule applies to business associates directly since the 2013 Omnibus Rule).
- Require the business associate to report breaches or unauthorized disclosures.
- Require the same contractual chain to extend to any subcontractor that receives PHI.
- Define termination conditions if the business associate materially breaches the agreement.
In legal-mechanism terms, the BAA is how PHI gets to move outside the covered entity without violating HIPAA. It is necessary. It is also procedural: it governs conduct, allocates duties, and sets up remedies. It does not by itself change the physics of what happens to the data once it leaves your office.
What a BAA does NOT cover
Five categories of risk commonly travel under the assumption that "we have a BAA" equals "we are safe." None of them are actually covered by the BAA itself.
1. Subprocessor breaches you will learn about after the fact
When your scribe vendor uses a third-party transcription API, a third-party LLM provider, and a third-party cloud host, each of those is a subprocessor. Under 45 CFR §164.502(e)(1)(ii), your vendor must have its own BAA with each subprocessor that receives PHI. The paperwork chain is complete. But the paperwork chain does not prevent a breach at a subprocessor from becoming a breach at your vendor — and because the data originally came from your practice, it becomes something you have to notify clients about. You are typically three or four relationships away from the actual systems that held your audio when the breach happened. The BAA tells you who pays for the lawyer; it does not put the data back.
2. Valid subpoenas and court orders
HIPAA permits disclosures in response to a subpoena, court order, or discovery request under specific conditions (45 CFR §164.512(e)). When the records live at a third-party vendor, that vendor is the custodian who answers the subpoena. Some BAAs require the vendor to notify the covered entity before responding; some do not, or carve out exceptions for court orders specifically directed at the vendor. The plaintiff-side discovery landscape in 2024–2026 has shifted: AI training pipelines, inference logs, and session archives are increasingly fair game in civil litigation, not just the narrow criminal and malpractice channels of the past. If the material exists in a third-party system, it is reachable through a subpoena that may never go through your lawyer's office first.
3. Vendor policy changes mid-subscription
A BAA you signed in January does not freeze a vendor's privacy policy in amber. Vendors announce policy updates; data-use terms change; subprocessors change; training-data clauses are added, removed, or redefined. In almost every consumer-SaaS contract the effective remedy for a change you do not like is to cancel and migrate, which can take months when an entire practice's workflow is on top of the tool. The BAA binds the vendor to HIPAA compliance; it does not hold any single privacy posture in place.
4. Model training, memorization, and leakage
Most reputable AI scribe BAAs prohibit training on your data, and most vendors honor that. What the BAA cannot guarantee is the behavior of the upstream models. If a vendor's LLM provider fine-tunes its base model on a corpus that includes customer chats from a different product line, inference-time leakage is not a hypothetical; it has been demonstrated in both academic and industry settings. "We don't train on your data" is a promise about the vendor's own pipeline — it is not a promise about every parameter on every GPU the vendor calls out to. The BAA does not reach that far.
5. Your own Security Rule obligations
This is the one that surprises the most clinicians. Signing a BAA does not transfer your Security Rule duties to the vendor. You remain the covered entity. You still owe a risk analysis (§164.308(a)(1)(ii)(A)), workforce training (§164.308(a)(5)), access management on your own devices and accounts (§164.312(a)(1)), and audit controls for the systems you actually run (§164.312(b)). An attacker who compromises your laptop, your email, or your EHR login does not care whether your AI scribe has a BAA. A BAA is not a substitute for the security posture of your own practice.
The 2026 pattern nobody advertised five years ago
The BAA-as-complete-trust-story idea worked well enough when "AI vendor" meant a dictation transcription service that passed text through a fixed pipeline and deleted the audio within 24 hours. In 2026 the supply chain has four structural changes:
- Deeper subprocessor chains. A modern AI scribe is rarely one company's stack; it is a scribe vendor, a transcription provider, an LLM provider (often the big three), a vector database, a cloud-storage provider, and a separate logging/observability vendor. Each is a link. Each has its own incident history.
- Active discovery against AI pipelines. Plaintiff attorneys have figured out that inference logs, prompt histories, and model-weight snapshots are discoverable. The subpoena targets are no longer just "records" in the EHR sense; they include "every prompt sent to your LLM provider during the relevant window."
- Training-data reuse ambiguity. Base models are retrained continuously from corpora whose provenance is not always clean. "No training on your data" is true at the vendor layer and unverifiable at the weights layer.
- Breach-notification cadence that favors headlines, not you. Large vendors disclose on their own timeline. The covered entity — your practice — is often downstream of that timeline, receiving the notification a week or a month into a public incident that has already been reported on.
None of these are new in kind. All of them are more common in magnitude than they used to be. A BAA signed in 2018 was written against a simpler data flow. Re-read the one you have today with a 2026 threat model in mind.
The architectural alternative
There is a different approach that some 2026 tools are taking, and it deserves its own section rather than being buried in marketing copy. If the AI inference runs on the clinician's own device — meaning the audio, the transcript, and the draft never leave the laptop — then there is no business-associate relationship for that flow of data. The vendor never receives PHI; the BAA for that data flow is not required because there is nothing to protect a BAA from.
This does not eliminate every BAA in the practice. If you still use a cloud EHR, you still need a BAA with the EHR vendor. If you back up your notes to cloud storage, the storage vendor is still a business associate for that data. The BAA analysis follows the data, not the tool. The architectural move narrows the data flows that need a BAA rather than eliminating BAAs entirely.
This is the design philosophy behind TherapyDraft. Session audio, transcript, and draft note never open a network socket — enforced at the macOS entitlement level, not merely promised in copy. The only permitted outbound endpoints are Stripe for license activation and a single update check. You can read the specifics on the privacy policy, the longer architectural argument on HIPAA AI SOAP note — drafted on your Mac with no BAA required, and a side-by-side with the cloud market leader on Mentalyc alternative: TherapyDraft keeps audio on your Mac.
An honest close
This is not an anti-BAA argument. A BAA is a legitimate, necessary legal instrument. If you use any cloud AI scribe — Mentalyc, Upheal, Blueprint, Supanote, Freed, any of them — you need the BAA, and you need to read it. If you use a cloud EHR you need a BAA for that too. The point of this post is smaller and more specific: the BAA is not a complete trust story on its own, and "we signed the paperwork" is not the same thing as "the data is safe."
A good compliance posture in 2026 looks like a stack: a BAA where PHI is shared with a vendor, plus an honest read of what PHI actually flows to that vendor, plus your own Security Rule compliance on the systems you run, plus an architectural preference — where it exists — for flows that do not leave your control in the first place. The BAA is one layer. It is load-bearing. It is also not the only layer. Reading it that way is how a clinician in 2026 ends up surprised by a subprocessor breach letter six months after signing up.
Read the BAA. Read the privacy policy. Ask where the data actually sits at rest. Ask who has keys. Ask what happens on a subpoena. And — if the architecture allows it — ask whether the data needs to leave your office at all.
Related reading
- HIPAA AI SOAP notes — drafted on your Mac, with no BAA required
- A private AI therapy scribe that physically cannot phone home
- Yes, there is a therapy-note AI that doesn't use the cloud
- Mentalyc alternative — architectural vs contractual HIPAA
- Supanote alternative — same price, different trust model
- TherapyDraft privacy policy
Try TherapyDraft
The private beta is free for 10 sessions, no credit card. Install the signed .dmg, give it microphone access, draft your first note on the laptop that already owns your day. If the draft quality and the workflow don't improve on your current setup, uninstall — nothing has been uploaded anywhere.
This post is general information about HIPAA mechanics as they apply to AI therapy scribes in 2026. It is not legal advice. For a BAA review tied to your specific practice, consult a HIPAA-experienced attorney.