A signed BAA doesn't make your AI feature HIPAA-compliant: the half developers keep skipping

There's a moment that repeats on every healthcare engineering team. An engineer is wiring an AI API into a product that touches patient data. Someone asks the one compliance question everybody knows to ask: "Does the vendor sign a BAA?" The answer comes back yes. The PR merges. And the team is still not compliant.

The reason is that HIPAA puts two separate obligations on you, and the BAA only satisfies one of them. The other one is yours to do, in your own system, and no vendor signature touches it. Most teams that get this wrong aren't careless. They just collapsed two requirements into one question.

I maintain BAA Atlas, a free directory that tracks BAA and PHI eligibility for the AI tools and SaaS vendors developers actually wire in. (Affiliation up front: it's my project, and the two links below point to it.) Going vendor by vendor through published terms, the same split keeps showing up. Here it is, written out as the two checks you actually owe before that feature ships.

The two obligations, and which one the BAA covers

A Business Associate Agreement is a contract between you (the covered entity, or another business associate) and the vendor. It governs the vendor's handling of protected health information: that they'll safeguard it, won't use it beyond what you authorized, will report breaches, and so on. When the vendor signs, that relationship is covered.

What the BAA does not do is govern your own system. HIPAA's Security Rule requires you to run an accurate, organization-wide assessment of the risks to the PHI you hold. That's the risk analysis at 45 CFR §164.308(a)(1)(ii)(A), and it's paired with a duty to implement reasonable technical safeguards (§164.312) in the systems you control. The vendor signing a BAA does nothing to discharge that. It's a different requirement, aimed at a different system: yours.

So the pre-ship question isn't really one question. There are two:

1. Vendor half: Will this vendor sign a BAA, and does it actually cover the feature and plan you're using?
2. Your half: Have you assessed and documented the risk in your implementation, and put the §164.312 safeguards in place?

Skip either one and the feature isn't compliant, no matter how clean the other looks.

The vendor half: signing is necessary, not sufficient

Start here because it can hard-stop you. If the vendor won't sign, or won't cover the specific surface you're calling, there's nothing to build on top of. You need a different vendor or a different data path.

And "will they sign" is a narrower yes than it sounds. Across the 34 AI tools I currently track, exactly one signs a BAA on its standard plan. Nine more will sign, but only on a gated or enterprise tier. Three handle it case-by-case on request. And 21 won't sign at all (verified against published terms, 1 June 2026). On top of that, plenty of vendors who do sign carve the generative-AI feature out of the same agreement, so the base product is covered while the AI layer isn't.

Three checks settle the vendor half:

• Will they sign for you? Not "is there a BAA template somewhere"; will they execute one for your account and plan.
• Does it cover this surface? Read for carve-outs. A platform BAA frequently excludes the newer AI feature you're actually calling.
• What's the data posture even with a BAA? Some vendors only allow PHI with zero data retention or training opt-out flags set. The BAA can be contingent on configuration you have to enable in code.

I keep the per-vendor verdicts and the four BAA postures current here: AI tools that sign a HIPAA BAA, and which don't. Use it to clear the hard-stop before you write integration code, not after.

Your half: the part no vendor signature covers

Say the vendor signs and the feature is covered. You're past the hard-stop, not past the obligation. Now the requirement is your own risk analysis and the safeguards that follow from it, and this is the half that quietly never gets done, because nothing external forces it the way a procurement gate forces the BAA.

What "your half" concretely means in the code you're shipping:

• Map the PHI data flow. Which fields leave your boundary, to which endpoint, in which request? You can't assess risk to data you haven't traced. This map is also the artifact an auditor asks for first.
• Minimum necessary in the payload. Don't ship the whole patient record to an AI endpoint when the task needs three fields. De-identify or tokenize what the feature doesn't strictly require.
• Encryption in transit and at rest (§164.312(a)(2)(iv), (e)), on your side of the wire and in your own stores and caches, not just the vendor's.
• Access controls and audit logging (§164.312(a)(1), (b)). Who in your system can invoke the PHI-touching path, and is it logged?
• Watch what you log. The classic self-inflicted breach: prompts and responses containing PHI written to application logs, error trackers, or an LLM-observability tool in plaintext. The vendor's BAA doesn't cover the Sentry project you piped the request body into.

These are decisions made in your repo, your infra config, and your logging setup. A signed vendor contract changes none of them. The risk analysis is what surfaces these gaps before an incident does, which is why an inadequate risk analysis is the single most-cited finding in HIPAA Security Rule enforcement.

If you've never run one, the fastest way to see where you stand is to walk the Security Rule's actual requirements as a checklist. I built a free, no-signup version that does exactly that: the 18-question HIPAA Security Risk Assessment self-check. It maps your answers to the specific §164.308 / §164.312 provisions and hands back a gap report you can act on. It won't replace a formal assessment, but it'll tell you in a few minutes which half you've been skipping.

The pre-ship sequence

Put together, the order that keeps a PHI-touching feature out of trouble:

1. Before integration code: confirm the vendor will sign, and that the BAA covers this exact feature and plan. If not, stop. Pick another vendor or path. (directory)
2. During build: trace the PHI data flow, trim the payload to minimum necessary, set encryption and access controls on your side, and scrub PHI out of logs and error trackers.
3. Before ship: run the risk analysis over the new flow and document it. (self-check)

The BAA and the risk analysis aren't a bigger version of the same task. They're two obligations on two different systems, and "the vendor signed" only ever answers half of it. The half that gets teams cited is almost always the one with no procurement gate forcing it. Your own.