HIPAA Business Associate Agreement Clauses for an AI Vendor

A business associate agreement has a fixed list of required elements, and vendors will hand you a template that satisfies all of them. The template will still be wrong for an LLM provider, because every required element was drafted for an associate that stores your data rather than one that learns from it.

What the regulation actually requires

The contract requirements are at 45 C.F.R. § 164.504(e), with the security-specific requirements at § 164.314(a) and the disclosure permission at § 164.502(e). A compliant BAA must, at minimum, establish the permitted uses and disclosures of protected health information by the associate; provide that the associate will not use or disclose PHI other than as permitted by the contract or required by law; require appropriate safeguards; require reporting of any use or disclosure not provided for, including breaches of unsecured PHI; require flow-down to subcontractors; provide for access, amendment and accounting obligations under §§ 164.524, 164.526 and 164.528 where applicable; make the associate’s internal practices available to the Secretary; require return or destruction of PHI at termination; and authorise termination for material breach.

The Department of Health and Human Services publishes sample provisions covering exactly that list.

Use them as the floor and assume they are insufficient here. The sample provisions are silent on model training, silent on which subcontractor runs inference, silent on prompt and completion logging, and their return-or-destroy language assumes data that exists as records.

The training-use clause, and why the default is wrong

Section 164.504(e)(2)(i)(A) says the contract must describe the permitted uses and disclosures. Anything not described is not permitted, so in principle silence forbids training. In practice the vendor’s own terms of service, incorporated by reference, will contain a licence to use submitted content to improve the service, and the two documents will conflict. Fix that explicitly rather than relying on an order-of-precedence clause to do it for you.

There is a genuine legal question underneath, and it is worth knowing which part is contested. Section 164.504(e)(4) permits a business associate to use PHI for its own proper management and administration, and to provide data aggregation services relating to the health care operations of the covered entity, if the contract so provides. Vendors sometimes read “proper management and administration” to cover improving their model. That reading is aggressive: the provision is generally understood to cover running the associate’s business, not developing a new product from customer data, and OCR has not published guidance resolving it for model training specifically. The safe drafting position is to remove the ambiguity rather than to win the argument later.

A clause that does the job needs to cover more than the word “training”, because the interesting uses are adjacent to it:

• No use of PHI, prompts, completions, embeddings or derived artefacts to train, fine-tune, evaluate or otherwise develop any model, including models made available to other customers.
• No human review of prompts or completions except as strictly necessary to provide the service to the covered entity, and then only by personnel bound by the same terms.
• No retention beyond a stated period. Many providers offer a zero-retention configuration for API traffic; if you are relying on it, name the configuration in the contract rather than in an email, because a setting can be changed and a contract cannot.
• De-identification handled explicitly. Under § 164.514(a)–(b) properly de-identified data is not PHI, so a vendor that de-identifies and then trains has escaped the clause. Decide whether you permit that, and if you do, specify which method — expert determination or the Safe Harbor removal of the eighteen identifiers — and require documentation.

Flow-down to inference subcontractors

Since the 2013 Omnibus Rule, a subcontractor that creates, receives, maintains or transmits PHI on behalf of a business associate is itself a business associate under the definition at § 160.103, and § 164.502(e)(1)(ii) requires the associate to obtain satisfactory assurances from it. The chain is legally continuous however long it gets.

For AI products that chain is longer than customers expect. An application vendor may call a model provider, which may serve the model from a cloud provider’s infrastructure, which may route to a different region under load. Each hop that touches PHI needs an agreement. Draft for the shape rather than for today’s list: require a current written list of subprocessors that process PHI, advance notice of additions with a right to object, a prohibition on processing outside named jurisdictions, and a commitment that subcontractor terms are no less protective. The general treatment is in the page on subprocessor due diligence, which is written from the GDPR side but describes the same chain.

One asymmetry to price in: HIPAA imposes direct liability on business associates for certain provisions, so your subcontractor is regulated whether or not you can reach it contractually. That is a comfort about enforcement and no comfort at all about your own compliance, because the covered entity is the one that has to answer for the disclosure.

Breach timing you have to shorten by contract

Section 164.410 requires a business associate to notify the covered entity of a breach of unsecured PHI without unreasonable delay and in no case later than sixty calendar days after discovery. Read that against the covered entity’s own duty at § 164.404: notice to affected individuals without unreasonable delay and no later than sixty calendar days after discovery of the breach.

The two sixty-day clocks are the trap. If the associate uses its full period, the covered entity receives notice on the day its own deadline would expire had discovery been imputed to it. Standard practice is to contract for a much shorter associate notification — commonly within a small number of business days of discovery, with an immediate preliminary notification for incidents above a severity threshold — plus a duty to cooperate in the risk assessment under § 164.402, which is what determines whether an impermissible use is a reportable breach at all.

AI-specific incidents also need naming, because they do not look like the events a template contemplates. A prompt-injection attack that causes an assistant to return one patient’s data to another patient’s session is an impermissible disclosure, but a security team monitoring for exfiltration may not classify it as an incident at all. Define reportable events to include unauthorised disclosure through model output and through retrieval scoping failures, or the clause will not fire.

Return or destruction, and the model that cannot comply

Section 164.504(e)(2)(ii)(J) requires that at termination the associate return or destroy all PHI it still holds, including copies held by subcontractors, and if return or destruction is infeasible, extend the protections of the contract to the information and limit further uses to whatever makes it infeasible.

If PHI was used to fine-tune a model, this provision has no clean answer. Model weights are not a record you can delete a row from. Whether weights that were trained on PHI are themselves PHI is unresolved: they are not a record in the ordinary sense, yet research on memorisation shows training data can sometimes be extracted from a model, and no OCR guidance or court decision squarely addresses it. You should not write a contract that depends on the answer.

Draft around it instead. The clean position is the training prohibition above, which means no weights are ever affected. Where fine-tuning on PHI is genuinely required, the contract should require that the tuned model is dedicated to the covered entity, never served to another customer, and deleted along with its checkpoints and training artefacts at termination, with written certification identifying every artefact destroyed. Note also that the FTC has, in unrelated matters, ordered deletion of models built from unlawfully collected data — the remedy sometimes called algorithmic disgorgement, discussed in the COPPA page — which is a different agency and a different statute, but it shows the remedy is not hypothetical.

Drafting order

The sequence matters, because the answers to the early questions determine whether the later clauses are needed at all.

1. Establish whether the vendor is a business associate. If PHI never leaves your environment — a model you host, or a deployment where the provider has no access — you may have a different relationship. Do not sign a BAA to feel safe; sign one because the definition at § 160.103 is met.
2. Confirm the vendor will sign one at all, for the specific product and tier you intend to use. Coverage frequently differs between a consumer product, an enterprise plan and the API, and a marketing page saying “HIPAA-eligible” is not the same as the service being in scope of the executed agreement.
3. Define permitted uses narrowly and add the training prohibition, covering prompts, completions, embeddings and derived artefacts, plus human review and de-identification.
4. Fix retention. Name the zero-retention or limited- retention configuration, state the maximum period, and require deletion from logs and backups on a defined schedule.
5. Flow down to subprocessors with a maintained list, notice of change, jurisdictional limits and no-less-protective terms.
6. Shorten the breach clock well inside sixty days, define AI-specific reportable events, and require cooperation in the § 164.402 risk assessment.
7. Write the termination clause for artefacts, not records — tuned models, checkpoints, embeddings, caches and indices, each named, with certification of destruction.
8. Add the assurance you can actually verify: audit or information rights, a current third-party report, and notice of material model changes. Then verify one of them once, early, while the relationship is new.