BAAs Explained: When You Need One and What It Covers

The contract that makes HIPAA work in a supply chain

HIPAA does not just regulate hospitals and insurers (the covered entities). It reaches everyone they hand protected health information to — and everyone those vendors hand it to. The legal instrument that carries the obligations down the chain is the Business Associate Agreement, or BAA. If you build software that touches PHI on behalf of a healthcare customer, you are almost certainly a business associate, and you need to understand this contract.

Who is a business associate?

A business associate is any person or entity that creates, receives, maintains, or transmits PHI on behalf of a covered entity to perform a function or service. That is broad. It includes:

• A SaaS product that stores patient records for a clinic.
• A cloud provider hosting infrastructure where PHI lives.
• An analytics, logging, or email vendor that processes PHI.
• A billing or claims-processing service.

A useful test: do you handle PHI as part of delivering a service to a covered entity (or to another business associate)? If yes, you are a business associate, whether or not anyone has sent you a contract yet. Note the "conduit" nuance — a pure transmission service that never accesses the data, like some postal or dumb-pipe telecom, may be exempt, but this exception is narrow and does not cover cloud vendors that store data, even encrypted.

What a BAA actually obligates

A BAA is not boilerplate to sign and forget. Signing one means you contractually agree to, among other things:

• Use and disclose PHI only as permitted by the agreement or as required by law — nothing more.
• Implement safeguards. Business associates are directly subject to the HIPAA Security Rule. The technical safeguards (access control, audit controls, integrity, transmission security, encryption) are your legal responsibility, not just your customer's.
• Report breaches and security incidents to the covered entity, within defined timelines.
• Ensure subcontractors comply (more on this below).
• Make PHI available for access, amendment, and accounting-of-disclosures requests.
• Return or destroy PHI at contract termination where feasible.

Crucially, since the HITECH Act, business associates have direct liability under HIPAA. Regulators can penalize you directly, not only your customer. The BAA is not just risk transfer from the covered entity — it documents obligations you are independently on the hook for.

Subcontractor flow-down

Here is the part engineers underestimate. If you are a business associate and you pass PHI to your vendors — your cloud host, your managed database, your email sender — those vendors become your business associates, and you must have a BAA with each of them. The obligations flow down the entire chain. A gap anywhere breaks it.

Practically: before you route PHI through any third-party service, confirm that vendor will sign a BAA. Major cloud providers offer them, but often only for a specific subset of their services, and sometimes only after you explicitly opt in. Sending PHI to a service you don't have a BAA with is itself a violation, even if nothing leaks.

Getting a BAA from your AI/LLM provider

If you're building on a foundation-model API and PHI might ever touch a prompt, you need a BAA with that provider too — the same way you'd need one from your cloud host or your logging vendor. The catch: BAA availability and scope vary a lot by provider, and by which product you're actually using — the API is often covered where the consumer chat app is not. Verify everything below directly with the provider before you route PHI anywhere; this is one of the fastest-moving corners of any vendor's terms.

OpenAI. For BAA-covered API use, email baa@openai.com with your organization and use case; OpenAI has reported responding within 1–2 business days and reviews requests case by case. Coverage is limited to API endpoints eligible for zero data retention (ZDR) — the consumer ChatGPT app is not covered. OpenAI has also introduced a separate healthcare-specific product path outside the core API; check whether that fits your use case better before assuming the API is your only route.

Anthropic (Claude). For Claude Enterprise, only the organization's Primary Owner can turn this on: Organization settings → Data and privacy → HIPAA Compliance → Enable, then review and accept the BAA. This can't be reversed from admin settings once accepted. One nuance that's easy to get backwards: Covered Models require standard 30-day data retention and are not available with zero data retention (ZDR) enabled — the opposite of the OpenAI pattern above. Workbench, Console, Cowork, Batch/Files/Skills/Code Execution/Computer Use/Web Fetch, and most Claude Code usage fall outside BAA coverage today. For the first-party API, the Primary Owner accepts the BAA, then a sales or account contact turns it on for the org.

Google (Vertex AI / Gemini). Google Cloud's HIPAA BAA is self-serve: in Cloud Console, go to IAM & Admin → Privacy, find the "Google Cloud Platform HIPAA Business Associate Addendum," and accept it — once per Google Cloud account, not per project. Vertex AI sits on Google's HIPAA-eligible services list, so a covered project can call Gemini through it. The consumer Gemini app and Gemini inside Google Workspace are separate: Workspace has its own BAA amendment accepted in the Admin console, and neither of those covers the consumer app.

Microsoft Azure OpenAI Service. Usually the least friction if you're already an Azure customer: the BAA is built into the standard Microsoft Products and Services Data Protection Addendum for customers on an eligible agreement (Enterprise Agreement, CSP) — there's no separate document to sign. Scope is narrower than it looks, though: coverage is for production, text-based interactions. Preview features and non-text capabilities may sit outside it — confirm current scope before sending anything but text.

xAI (Grok). xAI runs a BAA Questionnaire that an authorized company representative submits (x.ai/legal/baa); their team reviews it and follows up. PHI is only permitted through xAI's zero-data-retention Enterprise API once a BAA is signed — never through the consumer Grok app. This is the newest process of the five here, with the thinnest public track record, so budget extra time and get everything in writing.

A pattern worth noticing: every provider above draws a hard line between its enterprise/API surface (BAA-eligible, more configuration required) and its consumer product (never covered, no matter what you're told in a support chat). If a vendor conversation doesn't clearly land on one side of that line, don't send PHI until it does.

Tracking the ones you have

This applies to the AI/LLM providers above just as much as your cloud host or database vendor. BAAs are living obligations, and this is where compliance quietly fails. Common gaps:

• Missing BAAs for a vendor that started handling PHI after the initial vendor review.
• Expired or superseded agreements nobody renewed.
• Untracked subcontractors — a vendor swapped their sub-processor and never told you.

Maintain an inventory: every vendor that touches PHI, whether a signed BAA exists, its effective and expiration dates, and which services it covers. Review it on a schedule, and re-check whenever you add a data-handling vendor. This is exactly the kind of drift a compliance program should surface automatically rather than discover during an incident. Tools like KollGuard can help keep a vendor-and-agreement inventory visible alongside your technical posture, so a lapsed BAA is a flagged item, not a surprise in a breach investigation.