If you only ask one thing before putting protected health information into a vendor's tool, "do you sign a BAA?" is the wrong question. A yes can still leave you non-compliant, and a no is sometimes recoverable. What actually protects you is a repeatable procedure you run against every vendor the same way.
I maintain BAA Atlas, a free directory that tracks BAA and PHI eligibility for the AI tools and SaaS vendors developers and ops teams actually run. (Affiliation up front: it is my project, and the links below point to it.) After going vendor by vendor through published terms, the same checklist keeps surfacing the same traps. Here it is, written out so you can run it yourself.
First, the four postures a vendor can be in
Before the checklist, you need the vocabulary. Every vendor lands in one of four BAA postures, and each one points at a different next action.
| Posture | What it means | Your move |
|---|---|---|
| Available | A BAA covers the product on a normal plan; you accept it and go. | Confirm which services the BAA names, then proceed. |
| Plan-gated | A BAA exists, but only on a specific (usually Enterprise) tier. | Price the qualifying tier before you build on it. |
| On request | No standing BAA; the vendor will sign after a questionnaire or review. | Start the request early; it is a sales-cycle dependency, not a checkbox. |
| Not available | No BAA on any plan. | Keep PHI out, full stop. Find a substitute. |
The trap is that teams collapse all four into a binary. "Available" and "plan-gated" both read as "yes, they sign," but only one of them lets you ship on the plan you actually have. The AI HIPAA overview I keep here tags every tracked vendor with exactly this posture so you do not have to reverse-engineer it from a pricing page.
The checklist: seven questions before PHI touches a vendor
Run these in order. The first one that fails stops the line.
1. Is there a BAA on the plan you are actually on?
Not "does the company sign BAAs somewhere." Most BAAs are plan-gated to Enterprise. ChatGPT is the canonical example: a BAA is available on Enterprise, the API platform, and the new ChatGPT for Healthcare, but Free, Plus and Pro consumer accounts are excluded and cannot get one. Same shape for Claude, where the BAA rides Claude for Enterprise and commercial/API agreements, never consumer Claude. If your team is on the consumer tier, "they sign BAAs" is true and useless.
2. Which named services does the BAA actually cover?
A BAA binds to an enumerated list of services, not to the company brand. AWS, Google and Microsoft each publish a covered-services or HIPAA-eligible-services list, and that list is the contract. "We have a BAA with Google" means PHI is allowed in the specific Workspace services Google enumerates, not in every Google product. If the feature you want is not named on that list, it is not covered, no matter how enterprise the marketing sounds.
3. Is the specific feature you want inside that scope, or carved out?
This is the one that bites teams who did everything else right. The platform BAA is signed, you are on the covered tier, and the generative-AI feature bolted onto it is excluded from that same BAA. It happens often enough that it deserves its own pass: read the AI add-on terms separately from the platform BAA, because the carve-out usually lives in the add-on doc, not the master agreement.
4. Does PHI eligibility depend on configuration you have not done yet?
Some vendors will sign, but PHI is only permitted after you flip specific settings. Slack signs a BAA only on Enterprise Grid, and even then PHI is allowed only once the workspace is HIPAA-configured and third-party marketplace apps stay outside the trust boundary. "Signed" is necessary but not sufficient; "signed and configured" is the real gate.
5. If the posture is "on request," have you started the request?
An on-request BAA is a lead time, not a guarantee. Grok is a clean example: xAI can sign for Enterprise customers, but only after a BAA questionnaire, and PHI then has to go through the ZDR-enabled API rather than consumer Grok. If your launch depends on that signature, it belongs on the project timeline the day you pick the vendor, not the week before go-live.
6. Have you written down the source and the date you verified it?
Vendor terms move. A covered-services list changes, a new AI feature ships outside scope, a plan gets renamed. Capture the primary-source URL (the vendor's own trust center or HIPAA page) and the date you read it, so the next person does not re-litigate it from scratch and so you can tell when the answer has gone stale.
7. If the answer is no, is there a compliant substitute?
A "not available" verdict is the end of the line for that tool, not for the job. Perplexity does not sign a BAA on any plan, including Enterprise Pro, so it is simply out for PHI workflows. The useful move is to swap in a tool in the same category that does sign rather than try to argue the no into a yes.
The red flags that should stop you cold
A few signals reliably mean "do not proceed without a written answer":
- "We're SOC 2 / ISO 27001 certified." Real, and unrelated to whether they will sign a BAA. Security certifications are not HIPAA coverage.
- "It's enterprise-grade." Marketing language, not a covered-services entry. The homepage is not the contract.
- "The platform has a BAA, so the AI feature is covered." Assume the opposite until the add-on terms say otherwise.
- "We're working on HIPAA support." A roadmap is not a signature. Treat it as "not available" until the BAA exists.
- A BAA gated behind a tier you have not priced. Plan-gated coverage you cannot afford is functionally "not available" for your project.
Why a procedure beats a verdict
Any single "does vendor X sign a BAA" answer is a snapshot that rots. The checklist does not. It is the same seven questions whether you are vetting a chat model, a meeting-notes tool like Otter where the BAA is Enterprise-only, or a brand-new AI feature nobody has documented yet. Run it the same way every time and the traps stop being surprises.
I keep the per-vendor postures, the named-service detail and the primary-source links current on BAA Atlas, starting from the AI HIPAA overview. When a vendor changes its covered-services list or moves between the four postures above, that is where it gets updated, so the checklist always has fresh inputs to run against.
Top comments (0)