If nothing leaves your Mac, do you still need a BAA?
A business associate agreement (BAA) is the contract that lets you, the covered entity, share protected health information with an outside vendor and stay on the right side of HIPAA. So the question in the title is a fair one, and it comes up the moment a therapist starts evaluating BAA on-device software: if a tool runs entirely on your Mac and never transmits a word of your session anywhere, what exactly would the BAA cover? The honest answer is that a BAA exists to govern PHI that leaves your control. When nothing leaves, the premise of the contract starts to wobble — and that is worth understanding precisely, not waving away.
What a BAA actually is, and when it’s required
Under HIPAA, a business associate is a person or entity that creates, receives, maintains, or transmits PHI on behalf of a covered entity. The classic examples are a billing service, a cloud-based EHR, an answering service that takes patient calls. Because these vendors handle your clients’ health information, the rule requires a written contract — the BAA — that binds them to safeguard that information, limit how they use it, report breaches, and return or destroy the data when the relationship ends.
The trigger is the handling of PHI, not the category of the company. A vendor is a business associate with respect to the PHI it touches. If a tool genuinely touches none of it, there is no PHI relationship for a BAA to govern. This is the distinction that on-device software forces into the open.
Why BAA on-device software changes the question
Consider what happens when you record or dictate a session into software that transcribes and drafts a note entirely on your machine. The audio is captured locally. The transcription model runs on your CPU or Neural Engine. The SOAP, DAP, or BIRP draft is assembled in local memory and written to local disk. At no point does the vendor’s server receive the recording, the transcript, or the note. The vendor cannot read, store, or transmit information it never obtains.
In that arrangement, the software maker isn’t creating, receiving, maintaining, or transmitting your PHI. It sold you a tool — the way a notebook maker or a Mac itself isn’t your business associate. The processing happens on equipment you own and control. This is a different claim from “we encrypt your data” or “we’re HIPAA compliant.” It’s an architectural fact about where the computation runs. If you want the longer version of why the marketing badge isn’t the same as the architecture, see why HIPAA compliant is not enough. And if “on-device” still feels like a slogan, what on-device AI really means walks through how to confirm it rather than take it on faith.
A BAA is a promise about how a vendor will treat your clients’ information. When the vendor never receives that information, there is no treatment to promise.
The edge cases that actually matter
This is where careful evaluation earns its keep, because “on-device” describes the core feature but not always the whole app. A few channels can quietly send PHI off the machine even when transcription stays local:
- Telemetry and analytics. Usage analytics or crash reporting can scoop up identifiers, file names, or fragments of session content. A crash log that includes a client’s initials or a snippet of a note is PHI in transit. A tool with no telemetry has nothing to disclose here.
- Model downloads. Pulling a speech or language model from a server is a one-way fetch of the model, not an upload of your session. A model download moves weights to you; it does not move PHI from you. The direction is what matters.
- Support and screen sharing. If a support workflow uploads logs, syncs files, or has you screen-share a note, PHI can reach the vendor through the side door. That interaction may itself need a BAA even if the product doesn’t.
- Cloud sync and backup. The moment a “convenience” feature copies transcripts or notes to a vendor’s server, you’re back to a hosted-PHI relationship and a BAA is in play.
| Data path | PHI leaves your Mac? | BAA in play? |
|---|---|---|
| Local transcription and drafting | No | No |
| Model download (weights only) | No | No |
| Crash logs containing note content | Yes | Likely |
| Cloud sync or hosted backup | Yes | Yes |
The practical test isn’t the vendor’s slogan. It’s the data flow: ask what leaves the device, when, and to where. A vendor that can’t answer that crisply hasn’t earned the “no BAA needed” conclusion.
This is the design CouchNotes commits to: recording, transcription, and SOAP/DAP/BIRP drafting all run locally, with no accounts, no cloud, and no telemetry — and audio that auto-deletes per your setting once you’ve reviewed and finalized the draft. The clinician is always the author of record; the software produces a draft you edit and sign, never a finished note on your behalf.
So — do you still need one?
If a vendor handles your clients’ PHI in any form, get the BAA; that obligation doesn’t soften because a product is built carefully. If a tool runs fully on your device and demonstrably sends nothing — no session data, no telemetry, no logs — then the document that governs PHI handling has nothing to govern, and the question rightly shifts from “where’s the contract?” to “can I verify the data never leaves?”
None of this is legal advice, and the rules get interpreted differently across boards, payers, and states. Confirm your own situation with your licensing board or a healthcare attorney before you rely on it. But the underlying point holds regardless of product: a BAA is a tool for managing PHI that travels. The more your work stays on the machine in front of you, the fewer such tools you need — and the more your due diligence becomes a question of architecture rather than paperwork.