Get a BAA in place before you paste anything

What a BAA is

A business associate agreement is a contract. A covered entity signs it with a vendor that will handle protected health information on the covered entity’s behalf, and it commits the vendor to safeguarding that information, restricting what it does with it, reporting breaches, and passing the same obligations down to its own subcontractors.

It is worth being precise about what signing one changes, because the common misreading is expensive. A BAA does not make a product secure, and it does not make a decision safe. It allocates responsibility for information that was always sensitive, and it makes the vendor answerable for a category of failure it would otherwise have no duty to you about. The security was either there or not there before anyone signed.

The other half of the misreading runs the opposite way: a signed BAA is not permission to put anything anywhere. It covers a named set of services on a named plan. What sits outside that set is uncovered even when it is the same login, the same browser tab, and the same company.

Check whether you need one at all

HIPAA applies to covered entities and to their business associates. Plenty of people working in health are neither — cash-pay aesthetics practices with no insurance billing, coaches, supplement and skincare brands, most founders before they have a clinical product. If that is you, a BAA may be irrelevant, and chasing one is a distraction from the rules that do reach you.

It does not follow that nothing applies. The FTC Health Breach Notification Rule reaches health apps and connected devices that HIPAA never touches, state consumer-health statutes reach further still, and FTC Act §5 reaches any claim you make about what you do with data. The toolkit’s “Who this applies to” page lays out which regimes typically govern which kind of reader, with the primary sources behind each.

If you are a business associate rather than a covered entity — a vendor processing PHI for a practice — read your own contract before you read the AI vendor’s terms. Whether you may subcontract processing to a third party at all is usually settled there, and that is where this goes wrong most often.

The plan you are on is the thing to check

The single most common failure is not choosing a vendor that will not sign. It is being on the wrong plan at a vendor that will. A BAA very often lives on a tier the reader is not paying for, and a page that says “we offer BAAs” is true and useless at the same time.

The directory records this per tool as a posture scope: which plans the claim actually covers, in plain terms. Read that line before the dots above it. On several major assistants the consumer subscription most individuals pay for is explicitly outside the BAA, while the API and an enterprise tier are inside it.

Check the scope again after any plan change, any migration, and any acquisition. The account you signed the BAA on is the account that is covered.

The four ways vendors hand them out

The first and easiest: the BAA is part of the platform terms, so you are covered from the moment the account exists. Freed is the clearest example in the directory — its BAA is in the terms rather than in a procurement cycle. There is nothing to chase.

The second: an in-product flow. Some vendors have built a self-serve path for individual clinicians, so a solo practitioner can be covered without a sales conversation. ChatGPT for Clinicians is the entry in the directory that works this way, gated on clinician verification rather than on contract size.

The third: request it by email. The OpenAI API’s BAA is available on request to baa@openai.com without an enterprise agreement, which makes the developer platform an easier route to coverage than the consumer product sitting on top of it. That is worth knowing even if you never write code, because it is often the cheapest covered path for a small internal tool.

The fourth: a sales-managed contract, sometimes with a switch to throw afterwards. Claude Enterprise is covered once the Primary Owner activates HIPAA on the workspace — coverage is not automatic on signing, and several features become unavailable once it is on. Microsoft’s HIPAA BAA runs the other way: it reaches most commercial Microsoft 365 customers by default through the Data Protection Addendum, so a practice already on Microsoft 365 may be covered for Copilot without signing anything new.

What is still not covered after you sign

Coverage is per service, and the exclusions are where people get caught. A vendor can cover its chat product and exclude the file API, the browsing tool, or the batch endpoint alongside it. The directory’s posture scope names the exclusions where the vendor states them; when the vendor’s own page does not say, the toolkit says nothing rather than guessing, which is why some entries carry no posture claim at all.

Retention is a separate axis from coverage. At least one covered route in the directory requires thirty-day retention rather than zero retention as a condition of being covered, which is a trade a security review will want to know about explicitly rather than discover later.

And a BAA covers an account, not a person’s habits. The most common real-world leak after a practice signs one is a clinician using a personal consumer login for the same work, on the same laptop, because it is already open. Whatever you sign, that is the thing to actually check.

What to do this week

Write down which AI tools are already in use, including the ones nobody approved. Ask; do not audit from the invoices, because the tools that matter here are usually free.

For each one, open the vendor’s own terms — the directory links them, dated — and find the plan the practice is actually on. Not the plan on the pricing page. The plan on the invoice.

Execute the BAA where one is available, on the account people actually use. Then write one page saying which tool is for which work, and what never goes into the uncovered ones. A rule nobody wrote down is a rule that lasts about a fortnight.