HIPAA-Compliant AI: Your Vendor's BAA Probably Doesn't Cover What You Think

This is an operator's map of how the pieces fit, not legal advice. Every specific decision here is one to make with counsel who knows your practice.

You run a clinic, a billing shop, a therapy practice, or an agency that serves them. Every tool you look at now has AI bolted on, and every one of them has a page that says "HIPAA compliant" in reassuring type. You want to use this stuff. You also know that if you get it wrong, the consequence isn't a bad quarter, it's a breach notification.

So you do the sensible thing and ask the vendor whether they'll sign a BAA. They say yes. You feel covered.

You're probably not. Not because the vendor lied, but because you asked about one link in a chain that has five.

What a BAA actually is

A Business Associate Agreement is a contract, not a certificate. It's the document where a company that touches your patients' data agrees, in writing, to handle it under HIPAA's rules and to tell you when something goes wrong. There's no "HIPAA certified" stamp any authority issues, so the BAA is the whole mechanism.

Two things about it surprise most operators.

Encryption doesn't get a vendor off the hook, and it doesn't get you off the hook either. The federal guidance is unusually direct here. A cloud provider that stores protected health information is a business associate "even if the CSP cannot view the ePHI because it is encrypted and the CSP does not have the decryption key." The common rationalization — it's encrypted, so it doesn't really count — is specifically addressed and specifically rejected.

The "we're just a pipe" defense is narrower than people think. There is a conduit exception, but it covers transmission only, with storage "other than on a temporary basis incident to the transmission service" falling outside it. A service that holds your data at rest is not a conduit. That covers nearly every AI tool you'd actually use.

The chain is the unit, not the vendor

Here's the reframe that does the real work. Ask which layers of your setup touch the data, then get a BAA for every one of them.

A realistic AI workflow for a clinic touches five:

The app host. Wherever the thing you built or bought actually runs.
The database. Where records land and stay.
The model provider. Whoever's AI reads the text.
The execution sandbox, if you're running agents that do work rather than just answer questions.
Logs and observability. The layer everyone forgets, and the one most likely to quietly write patient names to a file nobody reviews.

Miss one and the chain is open. It's not partial credit. A vendor with an immaculate BAA sitting upstream of a logging service with no BAA leaves you exposed at the logging service, and your careful work on the other four layers doesn't change that.

This is also why "is Tool X HIPAA compliant?" is close to an unanswerable question. Tool X is one link. The answer depends on what you plugged into it.

The boundary runs inside each vendor too

This is the part almost nobody tells you, and it's where good-faith operators get caught.

Signing a vendor's BAA does not put that vendor's whole product line under it. Each company draws a line through its own catalog, and the excluded features are usually the convenient ones.

Neon covers core Postgres under its BAA, but states plainly that its managed authentication uses "an authentication provider that is not covered under Neon's HIPAA compliance," and that its Data API is "hosted outside Neon's HIPAA-compliant infrastructure." Same vendor, same account, same dashboard — two features outside the boundary.
OpenAI's API BAA reaches only the endpoints eligible for zero data retention, and that eligibility is not a self-serve toggle. Several features have historically sat outside it (Assistants, Threads, the Files API, image generation, image inputs). [ambiguous — the excluded list comes from secondary compliance write-ups and OpenAI's enterprise docs move; confirm current scope with your account team before relying on it]
Anthropic signs a BAA for the Claude API, but not for the Free, Pro, Max, or Team plans, and its BAA excludes Workbench, the Console, Cowork, and features in beta.

Read that third one again, because it generalizes. The version of the tool you're already using is usually not the version that's covered. Your team pasting notes into a consumer chat subscription is not doing the covered thing, no matter what the vendor's compliance page says about its API.

What it actually costs

Access to a BAA is gated by plan, and the gates are set in wildly different places. Cheapest first:

Neon. Self-serve on the Scale plan: you read and accept the BAA in the console, no sales cycle. Currently free, with the docs stating a 15% surcharge will be added when they begin charging.
Fly.io. A $99/month compliance package, requested from the dashboard. It covers the VMs and Sprites, their agent-sandbox product.
Vercel. A $350/month add-on on Pro, purchasable yourself under Settings then Billing, and included in Enterprise contracts. Its in-scope product list is published and specific.
Supabase. The Team plan at $599/month, plus a HIPAA add-on around $300/month on top. Call it $900 before you've stored a single row.
Railway. No add-on price as such: they require a $1,000/month minimum spend before they'll sign, arranged through their solutions team rather than a checkout page.

Same category of legal guarantee, ninety-nine dollars to a thousand. That spread tracks who each company wants as a customer, not how well they protect the data. Railway isn't ten times safer than Fly. It has decided that customers who need a BAA are enterprise customers, and priced the paperwork to match.

Two practical consequences. The first is that your compliance bill is decided by vendor choices you probably made for unrelated reasons — you picked a host because you liked the deploy flow, and inherited a $12,000 annual floor. Worth re-examining before you renew, not after. The second is that most of these companies don't publish the number anywhere. Fly's docs say to just ask. Vercel's announcement points at the agreement. Railway's compliance page names a threshold without the figure. Confirm every price here with the vendor directly, including the ones in this list.

The Fly line is the one to look at twice. One $99 package covering both the compute and the sandbox layer is two links of the chain for one fee, which is the cheapest version of the move in the next section. If you're running agents that execute work rather than just answer questions, that bundling is worth more than the sticker price suggests.

One more thing about Railway's, because it's an honest tradeoff and a good example of what a BAA actually changes: once the BAA is in effect, "the Railway team will no longer be able to directly access your running workloads." That's the protection working as designed. It also means the support experience you had last month is not the support experience you'll have next month. Worth knowing before the outage, not during it.

Two moves that make this tractable

The chain framing is correct, and followed literally it's exhausting. Five BAAs, five renewals, five vendors to re-check when someone ships a new feature. There are two ways to make it smaller.

Shorten the chain by consolidating. Running a model through a hyperscaler you already have a BAA with removes a separate processor from the picture entirely. Claude through AWS Bedrock sits under your AWS agreement; Google's Vertex sits under your GCP agreement. One BAA, one security review, one vendor relationship, and the model provider is no longer a link you manage separately. For most practices this is the single highest-leverage simplification available.

The same principle works further down the stack, and it's cheaper there. Fly's compliance package covering both its VMs and its Sprites sandboxes collapses two links into one agreement for $99. Every time one vendor's BAA reaches across two layers you were going to pay for separately, you've cut a renewal, a security review, and a thing to forget.

Or move the boundary so PHI never reaches the AI at all. This is the better move where it fits, and it's underused. If the job is "summarize how the practice performed last month," the model doesn't need rows, it needs aggregates. De-identify or aggregate before the data crosses into the AI layer, and that layer stops being a HIPAA problem, because properly de-identified data isn't protected health information.

HIPAA gives two routes to de-identification: Safe Harbor, which means stripping a specified list of eighteen identifiers, and Expert Determination, where a qualified person documents that re-identification risk is very small. Safe Harbor is the one you can reason about without hiring anyone.

The engineering discipline this implies is worth naming, because it's the actual work: the de-identification has to happen at a boundary you can point at, in a step you can test, not as a thing the pipeline generally tends to do. If you can't show which line of the system removes the names, you haven't moved the boundary. You've just hoped.

What to do first

Don't start by shopping for compliant vendors. Start by finding out where the data already goes.

Write down every service that touches patient data today, including the ones nobody chose deliberately (analytics, error tracking, the transcription tool someone expensed, backups). This list is always longer than expected, and the surprises on it are the actual risk.
For each one, find out whether a BAA exists and what plan it requires. Ask the vendor directly and get it in writing. "Their site says HIPAA compliant" is not an answer to this question.
Check what the BAA excludes, not just that it exists. Ask specifically which products and features fall outside it. If a vendor can't answer that crisply, treat the ambiguity as a finding.
Ask whether you can avoid the whole problem for this particular use case by aggregating or de-identifying first. Frequently you can, and it's cheaper than five BAAs.
Then, and only then, pick tools. Compliance is a filter you apply to a shortlist, not a feature you shop for.

Operator's take

The honest summary: this is more tractable than the fear suggests and less tractable than the vendor pages suggest.

The fear is overblown because the paths genuinely exist now. Every layer of a normal stack has a real BAA option, several are self-serve, and the consolidation move (one hyperscaler agreement covering the model) collapses most of the complexity. Three years ago the honest answer to "can I use AI on clinical data" was mostly no. It isn't anymore.

The vendor pages are overblown because "HIPAA compliant" on a marketing page is a claim about the company's capability, not about your configuration. Every one of these agreements is a shared-responsibility model, which in plain terms means the vendor secures their part and you're on the hook for yours. Buying the compliant plan and then piping PHI into an excluded feature is a thing you can do on a Tuesday afternoon without any warning appearing on your screen.

What I'd actually worry about isn't the model provider. It's the four boring layers around it. Nobody accidentally sends patient records to an unapproved LLM. People accidentally send them to a logging service, a screenshot in a support ticket, a spreadsheet export, or a transcription tool someone signed up for with a company card. The AI decision gets the scrutiny; the plumbing gets none.

And the question I can't answer for you, which is the one that decides it: is the workflow you have in mind worth a compliance program? Not worth a BAA — a program, meaning someone owns the vendor list, reviews it when things change, and notices when a vendor ships a feature outside its own boundary. If the answer is yes, the paths above are real and the cost is knowable. If the workflow is a nice-to-have, the correct move is to de-identify it into irrelevance or skip it, and spend the attention on something that doesn't come with a notification obligation attached.