What is Business Associate Agreement (BAA)?
Governance & ControlThe contract that allows a covered entity to share protected health information with a vendor while keeping its HIPAA obligations intact. In practice it is the first architectural decision in a healthcare AI deployment, because nothing moves before it is signed.
Why It Matters
A healthcare AI deployment has more vendors than the diagram suggests. The model provider, the vector store, the observability platform, and the review tooling each receive health data at some point. Every one of them is a disclosure that needs a contract behind it.
The agreement is therefore a design constraint. If a vendor cannot sign one, that component cannot hold protected health information, which changes where retrieval runs, where traces are stored, and which model endpoint is eligible.
What It Has to Cover
Permitted uses, so the vendor processes data for the service you bought and nothing else. Safeguards, so the vendor meets the technical and administrative standards you are held to. Breach notification, with a clock attached. Subcontractors, since the vendor’s own providers inherit the obligation. And the term that matters most for AI: whether your inputs may be used to train or improve a shared model.
Retention and deletion belong in the same document. Health data that outlives the engagement is a liability regardless of who holds it.
Where It Breaks
The frequent mistake is signing with the platform and not with the model. Teams cover the application vendor and then send the same data to an inference endpoint governed by different terms.
The second is a no-training clause that only covers the vendor’s own training. Subprocessors, evaluation services, and observability tools often sit outside the negotiated terms.
The third is scope drift. The agreement describes the original deployment, then the system grows a new workflow that sends data somewhere the agreement does not reach. Re-reviewing coverage when the architecture changes is the only way to keep the answer current.
How Flytebit Handles It
We treat agreement coverage as an architecture input. Every component that will touch protected health information is listed with the agreement that covers it before a single record moves, and components that cannot be covered are replaced or re-scoped. Retention is set per artifact class, and residency decisions are recorded alongside the agreement rather than assumed from the vendor’s default region. The industry application is on our Healthcare & Life Sciences page, and the control design is covered in our AI governance and risk work.
More info
- HHS: Business associates Who counts as a business associate and what the agreement must cover.