What is a BAA (business associate agreement)?
A vendor either signs one or it cannot touch patient data at all. Most AI vendors default to no, and finding that out after the pipeline is built is the expensive way to learn it.
BAA (business associate agreement)
business associate agreement
A BAA, or business associate agreement, is a HIPAA contract between a covered entity and a vendor that handles protected health information on its behalf. It binds the vendor to safeguard that data, and limits how the vendor may use it.
HIPAA calls the hospital, clinic or health plan a covered entity. Any outside party that handles PHI for that entity is a business associate: a cloud host, a billing service, a logging vendor, a model API. The agreement is the contract HIPAA requires between them before that handling can start.
This duty runs both ways. Since HITECH, a business associate can be fined directly for a breach, not only through the party that hired it. Signing the agreement makes both sides liable for their own half.
A BAA does not stop at the first vendor. At 45 CFR 164.504(e), a business associate must get its own subcontractors to agree to the same restrictions. Any subcontractor that touches PHI is covered. A hospital's agreement with you does not reach your model API. Yours has to.
The gap no agency answers directly
Buyers usually ask the wrong question first: does this vendor sign a BAA. The sharper question is narrower. Is the specific product you plan to use, at the tier you plan to pay for, covered by that BAA.
Model providers are the sharpest version of this gap. A provider can offer a BAA on its enterprise API while its free consumer product carries none. A team that tested the free tier can wire the wrong endpoint into production without noticing. The agreement names an exact service. Someone still has to confirm the code calls that service and no other.
HHS's own guidance is explicit that a signed agreement is not itself compliance. The Security Rule's safeguards still have to be in place and working. Legal gets the signature. Engineering owns whether the system behind it is true to it.
- 01It binds the vendor to use PHI only for the purposes the agreement allows.
- 02It requires the vendor to report a breach back to the covered entity.
- 03It requires the vendor to flow the same restrictions down to its own subcontractors.
- 04It does not, on its own, make the vendor's software HIPAA compliant.
- Covered entityHospital, clinic, health plan.
- BAA signedVendor now a business associate.
- Safeguard dutySecurity Rule controls apply.
- Subcontractor flow-downEvery downstream touchpoint, own agreement.
- Breach reportingBack to the covered entity, on terms.
The chain breaks most often at the fourth node. A model API added mid-project is a subcontractor too, and it needs its own agreement before patient text reaches it.
Related questions
01Which AI vendors sign a BAA?
It varies by provider and by product tier, and the terms change often enough to check at signing rather than trust from memory. The pattern that holds across providers is that enterprise or business API tiers are more likely to offer one than free or consumer-facing products. Confirm the exact product name on the agreement matches the exact endpoint your code calls.
02Do we need a BAA with every vendor we use?
Only with vendors that create, receive, maintain or transmit protected health information on your behalf. A vendor with no access to PHI is not a business associate, and signing an agreement anyway adds paperwork without adding protection. The test is what the vendor touches, not how central it feels to the project.
03Does a BAA make our software HIPAA compliant?
No. HIPAA compliance belongs to the whole system: who can log in, what gets logged, how data moves, and a risk review you actually did. A BAA is the contract that obliges a vendor to support those duties. Neither side is excused from them by the signature alone.
