Who has to sign a BAA in an AI healthcare app
HIPAA's contract rule is short. A covered entity can hand protected health information to an outside company only under a business associate agreement, and that company can hand it further down only under another one. So the chain in an AI app runs: the practice signs with you; you sign with your cloud provider; you sign with whoever performs the model inference, because the model reads the note, and reading is a use. If PHI also passes through an email service, an error tracker, an analytics tool or a support desk, each of those is a link too. We listed the ones teams forget in the audit failures post; the error tracker logging PHI in stack traces is still the one we find most often.
Your app is the link that signs in both directions, and the two directions have to match. Whatever the clinic's agreement obliges you to do (encrypt, log access, report a breach within a set number of days, return or destroy the data at the end) has to be pushed down into every agreement you hold with a vendor that touches the same data. A downstream BAA that's looser than the upstream one leaves you holding the gap personally.
Who isn't in the chain matters just as much, and it's where the June call that prompted this post got interesting. A defense litigation firm asked us to wire an AI model into its practice-management system for medical chronologies. Our first read was that the firm sat outside HIPAA, since it receives medical records through discovery under 45 CFR 164.512(e), which makes it a recipient rather than a business associate. That holds for its trucking and construction cases. It doesn't hold for its nursing-home defense work, where the client being defended is itself a covered entity and the firm handles that client's PHI on its behalf. For those matters the firm is a business associate, which makes us a subcontractor business associate the moment we build the chronology pipeline, and the chain becomes three agreements: the firm with us, us with the model provider's API, us with AWS. One practice area flipped the compliance posture of the whole build.
Two more parties sit outside the chain. The patient's own mailbox: once PHI is in an email, it's in an inbox nobody you contract with controls. And the conduit exception, which is narrower than vendors like to suggest: HHS's cloud guidance says a cloud provider storing PHI is a business associate even when the data is encrypted and the provider holds no key, so "we only store ciphertext" doesn't get anyone out of signing.
Which AI providers sign, and under what terms
Every row was checked against the vendor's own page on 27 August 2026 and quotes are as written. Where a page refused our fetch we say so rather than guess. Model version names are left out on purpose; they change faster than a compliance record should.
| Vendor and product | BAA? | Conditions on the page | Source |
|---|---|---|---|
| Anthropic, API and Claude Enterprise | Yes | "Anthropic provides a BAA covering our HIPAA-ready services, such as use of our first-party API or Enterprise plans." Primary Owner signs, then asks Anthropic to turn it on. Excludes the Console, Cowork and betas; Batch, Files, Skills, Code Execution, Computer Use and Web Fetch are "not covered under Anthropic BAA". Newest models ("Covered Models") "require 30-day data retention" and can't run in a zero-data-retention org, effective 1 July 2026. | BAA article, Covered Models |
| Anthropic, Free, Pro, Max (and Claude Code on those accounts) | No | The BAA article is for commercial customers only. The consumer article covers "Claude Free, Pro, Max and when accounts from those plans use Claude Code": deleted chats leave the back end "within 30 days"; with training on, data may be kept "in a de-identified format for up to 5 years in our model training pipelines". | Consumer retention |
| OpenAI, API | Yes, on request | Developer docs name an "OpenAI Business Associate and Healthcare Addendum"; once provisioned, "BAA-eligible endpoints can be used for processing PHI, even if data is retained". Abuse-monitoring logs "retained for up to 30 days" by default; zero data retention "subject to prior approval". "Web Search with live internet access is not HIPAA eligible and is not covered by a BAA." The help-center article on requesting one returned 403 to us; its listing says the request goes by email and no enterprise agreement is needed for the API. | Your data |
| AWS, Amazon Bedrock | Yes, via the AWS BAA | Listed as HIPAA eligible, with an exclusion for the two newest Anthropic model families named on the page. "You agree not to use these HIPAA Eligible Services for any purpose or in any manner involving Protected Health Information (as defined by HIPAA) without first entering into an AWS business associate agreement." Accepted at account level in the console. | HIPAA Eligible Services |
| Microsoft, Azure (Azure OpenAI in Foundry) | Yes, by default | "There is no separate contract to sign": the HIPAA BAA "is available via the Microsoft Product Terms ... by default to all customers who are covered entities or business associates under HIPAA", for in-scope services. The in-scope list is a separate appendix we didn't open; confirm the model service is on it. Flagged prompts are stored for human review unless you're "approved for modified abuse monitoring", after which that "process described above is not performed". | Azure HIPAA, Data and privacy |
| IntakeQ / PracticeQ (the EHR side, for contrast) | Yes, self-serve, every plan | Signed inside the account settings, no negotiation. It's why we picked it for our first healthcare connector; most EHRs gate API access behind an NDA, a paid developer licence and a demo approval. | Our own build, July 2026 |
Read the table for the word "eligible". AWS and Microsoft sign for the platform, and the platform is a set of services you still configure: region, model, logging, retention. The BAA doesn't do that for you. Then notice the 30 days. On the API tiers of both model vendors the default is that inputs sit somewhere for up to a month, and at Anthropic the newest models now require it even under the BAA. A BAA makes that retention lawful, which is a different thing from making it zero, and if your contract with a clinic promises zero you have a problem the BAA won't solve.
What breaks when one link refuses
The consumer-plan trap first, because we fell into it. On the June call with the litigation firm we said the setup was "HIPAA compliant because the connector stores nothing". That's true of the connector and wrong about the system: the records still go to the model provider for inference, and at that point the plan matters more than the connector does. The firm's testing had run on a Max subscription, which is what most people have, and Max means consumer terms, no BAA, and retention of 30 days with training off or up to five years with it on. The proposal notes we wrote the next day moved the model call to the API with training off, a signed BAA and the strictest retention the chosen model allows, and carry the line "Stop using Max for PHI." We'd already written that rule into our own connector docs. We still said the wrong sentence out loud when a paralegal asked.
The same trap hides in every "we use Claude" or "we use ChatGPT" line in a product deck. Which plan. A founder on a consumer chat plan, a clinician pasting notes into a personal account, a support agent summarising a ticket in the desktop app: none of it is under a BAA at either vendor, and encryption inside your own app doesn't repair it. Anthropic's Covered Models page adds a sharper version for developers: as of July there's "no configuration that allows BAA-covered access to Covered Models in Claude Code or Cowork". If your newest agentic workflow touches patient data, that line is about it.
The retention trap is subtler because the vendor did sign. You hold the BAA, you assumed zero retention, and the page says 30 days by default. On Bedrock the default is no storage of inputs or outputs, with the same newest-model exception, quoted from AWS's own page in the zero-data-retention ceiling post. On Azure, flagged prompts go to a human-review store unless you've applied for modified abuse monitoring and been approved. None of it is hidden, it's just on a different page from the one that says "HIPAA".
The build that needs fewer BAAs
Three architectures answer the BAA question honestly, and all three are legitimate. Sign the whole chain: API tier, BAA, training off, retention pinned, every subprocessor listed. De-identify before the model call, so the model vendor never sees PHI and never becomes a business associate for it. Or run an open-weight model in your own tenant or on your own hardware, which removes the model vendor from the chain and leaves you with the cloud BAA, or none. Which one fits depends on what the feature has to read. A scheduling assistant doesn't need the chart. A discharge-summary drafter does. The chatbot architecture post walks the decision for the most common case, and the PHI-free path there skips the model-vendor BAA entirely.
De-identification only counts if it's real. The Safe Harbor route means all 18 identifier types are gone before the prompt is assembled; the re-identification key stays in your database and the model gets a token. The part teams skip is everything around the prompt. If the request is logged with the patient's name to an error tracker, or the response is emailed with the appointment details, or the analytics event carries the diagnosis, the PHI left through a side door and the vendor on the other side of it is a business associate with no agreement. Minimum necessary is a coding rule as much as a policy: the model gets the field the task needs, the log gets an ID, the email gets "you have a new message".
That last rule we can show from a build. The HIPAA case-management platform we built for a structured-settlement firm has three portals (client, broker, admin) and coordinates law firms, brokers and their clients around cases that carry medical detail. There's no AI model in its chain, which makes it a clean example of how far architecture alone shrinks the list of parties. The control matrix from the build, as we recorded it:
| Requirement | What we did | Effect on the BAA chain |
|---|---|---|
| Encryption at rest | S3 server-side encryption on every document | Storage stays with one party, AWS, under one BAA |
| Encryption in transit | HTTPS everywhere | No hop carries PHI in clear text |
| Audit trail | A custom audit_logs table in the app's own database, with a viewer in the admin portal |
No third-party logging service sees who opened which case |
| No PHI in email | Notifications through SES carry no case content, only "log in to see it" | The recipient's inbox, the one link nobody can sign, never holds PHI |
| Access control | Role-based permissions (spatie/laravel-permission) enforced server-side |
A broker sees assigned cases only; minimum necessary runs in code |
| Least privilege | IAM roles scoped to the S3 buckets and RDS instance the app needs | A leaked key can't reach data outside the app's own scope |
Add a model to that platform tomorrow and the matrix gains one row, "what the model sees", and the answer decides whether it gains one BAA or none. Send the model a case's document text and you sign with the model vendor's API tier and pin the retention. Send it a de-identified extract, a status and a document type, and you've kept it out of the chain. The second is less to sign and more to build, and for features that read one field rather than one file it's usually the better trade. The same fork shows up in patient portal work the first time a client asks for "an AI summary of my results" on a page that already holds the full record: the summary either runs on the record, with the vendor signed in, or on a de-identified copy, with nobody new in the chain.
What to put in writing
Three documents, none of them long. The first is an AI-use policy that names plans rather than vendors. A line like "we use Anthropic" tells an auditor nothing about which plan; write it as "PHI may be processed only through the API organisation covered by the BAA signed on this date, and never through any personal or team chat account". Put the banned list in it too, including the founder's own account, because that's the one an auditor asks about.
The second is the subprocessor list, with more columns than most teams give it: vendor, product tier, date the BAA was signed, the retention setting as configured, the model version pinned and why, and the date someone last re-checked the vendor's page. The Covered Models change on 1 July 2026 is why the last column exists. A team that signed an Anthropic BAA in spring and picked "the newest model" off a dropdown in July changed its retention posture without touching a line of code.
The third is the incident process. Your BAA with each clinic says how fast you have to tell them about a breach, usually far shorter than the 60-day outer limit in the Breach Notification Rule. Write down who at your company makes that call, who at the vendor they contact, and how you'd find out in the first place. If the honest answer to the last part is "we'd notice when a customer told us", that's the finding, and it's cheaper to fix now than in the first 24 hours of an incident.
Want your BAA chain drawn before someone else finds the gap?
We build HIPAA-scoped platforms and open-source AI connectors for healthcare and legal teams, and we've made the consumer-plan mistake ourselves, so we know where to look. Bring your vendor list and the feature you want to ship; we'll map which links sign, which don't, and what the architecture has to do about the ones that won't.
Book a 30-minute architecture call →Frequently asked questions
Does OpenAI sign a BAA?
For the API, yes, on request. OpenAI's developer documentation refers to an "OpenAI Business Associate and Healthcare Addendum" and says that once an organization is provisioned under it, "BAA-eligible endpoints can be used for processing PHI". The same page says API abuse-monitoring logs are kept for up to 30 days by default, zero data retention needs prior approval, and web search with live internet access is not covered by a BAA. OpenAI's help-center article on requesting one refused our fetch on 27 August 2026; its search listing says the request goes by email and no enterprise agreement is needed for the API. No consumer ChatGPT plan carries a BAA.
Does Anthropic sign a BAA for the Claude API?
Yes, under conditions. Anthropic's privacy center says it provides a BAA "covering our HIPAA-ready services, such as use of our first-party API or Enterprise plans". For the API, the organization's Primary Owner signs the BAA and then asks Anthropic to turn it on. The BAA excludes the Console, Cowork and beta features, and Batch, Files, Skills, Code Execution, Computer Use and Web Fetch are listed as not covered. Since 1 July 2026 the newest models, which Anthropic calls Covered Models, require 30-day data retention and can't be used from a zero-data-retention organization. Claude Free, Pro and Max have no BAA.
Is Amazon Bedrock covered by the AWS BAA for HIPAA?
Amazon Bedrock is on AWS's HIPAA Eligible Services Reference, with an exclusion for the two newest Anthropic model families named on that page. The page says you agree not to use HIPAA-eligible services "in any manner involving Protected Health Information" without first entering into an AWS business associate agreement, so the account-level AWS BAA has to exist before any PHI reaches Bedrock. Eligibility covers the platform; region, model, logging and retention are still yours to configure.
Do I need a BAA with the AI vendor if I de-identify data before sending it?
If what reaches the model is de-identified under the HIPAA standard, it's no longer PHI and the model vendor isn't a business associate for that data. De-identification has to be real, though: every identifier removed or a documented expert determination, the re-identification key kept on your side, and nothing identifying in logs, error traces, analytics or email. We've seen products strip names from the prompt and then log the full request to an error tracker with no BAA. If you can't prove the model never sees PHI, treat the vendor as a business associate and sign.
Who is not a business associate in an AI healthcare app?
The patient isn't a party, and neither is the patient's mailbox, which is why PHI sent by email sits outside every agreement you hold. A party that only transports data (an internet carrier, a courier) falls under the narrow conduit exception; HHS guidance says a cloud provider that stores PHI is a business associate even if the data is encrypted and it holds no key. A law firm receiving medical records through litigation discovery under 45 CFR 164.512(e) is generally not a business associate; the same firm defending a covered entity such as a nursing home generally is. Where the line falls for your product is a question for counsel; where it falls in your architecture is one you can answer with a diagram.
