AI Vendor BAA Template Checklist

AI vendors are some of the newest business associates a clinic will sign, and their BAAs often need more careful review than the typical SaaS BAA. The base HIPAA terms still apply, but several AI-specific risks need explicit treatment.

This article is a checklist to apply when reviewing an AI or ML vendor BAA. It is not legal advice. Have counsel review any AI vendor BAA before signing — these contracts evolve quickly and the wrong clause can put PHI in a foundation model’s training set.

Why this vendor category needs HIPAA review

An AI vendor that processes PHI on your behalf is a business associate. Whether the tool is a clinical documentation assistant, an intake summarizer, a coding helper, or a patient messaging draft tool, if PHI flows through it, the BAA is required under 45 CFR § 164.502(e).

What is different about AI vendors is the data lifecycle. Traditional SaaS reads PHI, returns a result, and stores logs. AI tools may additionally:

• Send prompts to a foundation model provider (OpenAI, Anthropic, Google, AWS) under the AI vendor’s account.
• Retain prompts and outputs for evaluation, debugging, or model improvement.
• Use customer data to fine-tune models, sometimes by default.
• Cache embeddings or vector representations of PHI for retrieval.

Every one of those steps is a potential disclosure of PHI. The BAA needs to address each.

Required BAA terms for AI vendors

Start with the base terms in 45 CFR § 164.504(e) — permitted uses, safeguards, breach reporting, subcontractor flow-down, termination, HHS access. Then add the AI-specific clauses below.

Training and fine-tuning prohibition. PHI must not be used to train, fine-tune, evaluate, or improve any model — neither the vendor’s models nor any third-party model — unless the covered entity authorizes it in writing for a specific purpose.

Foundation model provider flow-down. If the vendor accesses a foundation model from another provider, that provider must have a BAA in place, the data must route through the BAA-covered API endpoint (not consumer endpoints), and the flow-down obligations under 45 CFR § 164.502(e)(1)(ii) must be satisfied.

Prompt and output logging policy. The BAA should state how long prompts and outputs are retained, who can access them, whether they are encrypted, and when they are purged.

Output handling. AI outputs that include PHI are PHI. The BAA should treat outputs the same as inputs — same retention, same encryption, same access controls.

Data residency. Where do prompts and outputs land geographically? Where does the foundation model provider process them? The BAA should commit to a region.

Subprocessor disclosure. Vector databases, embedding services, evaluation tools, observability platforms — any of these may touch PHI and need flow-down BAAs.

Specific risks for AI vendors

• Default training on customer data. Some AI products opt customers into training by default. Read the data processing addendum and confirm the BAA overrides it.
• Consumer endpoint leakage. A vendor reselling foundation model access may route some queries through consumer endpoints (which generally use prompts for training) instead of the enterprise BAA-covered endpoints. Confirm in writing that all PHI traffic uses the enterprise endpoint.
• Long log retention. A 30-day prompt log is reasonable. A two-year log of every prompt with PHI is a problem.
• Embeddings and vector stores. Embeddings derived from PHI are PHI. They cannot be stored in a non-BAA-covered vector database.
• Human review. Some vendors use human reviewers to label or grade model outputs. If reviewers see PHI, they are workforce members of a business associate and need to be covered.

Evaluation checklist

1. Is there a signed BAA covering all 45 CFR § 164.504(e) terms?
2. Does the BAA explicitly prohibit use of PHI for training, fine-tuning, evaluation, or improvement?
3. If a foundation model provider is involved, is there a BAA between the AI vendor and that provider, and does traffic route through the BAA-covered API?
4. What is the documented retention period for prompts and outputs?
5. Are prompts and outputs encrypted at rest and in transit?
6. Are embeddings or vector stores in scope of the BAA, and where are they hosted?
7. Is data residency committed to (US-only, specific regions)?
8. Are subprocessors disclosed (vector databases, observability, evaluation, human reviewers)?
9. Is human review of PHI prohibited or controlled, and are reviewers covered as workforce?
10. Does the BAA commit to a breach notification timeline?
11. Is there a documented termination process for purging prompts, outputs, embeddings, and any fine-tuned models?
12. Does the vendor maintain SOC 2 Type II or HITRUST attestation?
13. Is there an opt-out mechanism for any model improvement programs, and is opt-out the default?

Common mistakes

• Trusting the marketing page. “HIPAA-ready” is not a BAA. Get the contract.
• Using consumer AI tools for clinical work. Free chatbots and consumer subscriptions do not come with BAAs and typically reserve training rights.
• Ignoring the foundation model. The AI vendor may be diligent, but if it routes prompts through a consumer endpoint, PHI ends up in the foundation provider’s training pipeline.
• Skipping log retention. A vendor that will not commit to a retention period in writing is not BAA-ready.
• Assuming embeddings are not PHI. They are derived from PHI and can re-identify. Treat them as PHI.
• Not involving counsel. AI BAAs are evolving. Have a lawyer review.

For broader guidance on when a vendor crosses into business-associate territory, see when a vendor needs a BAA. The vendor management hub covers the program-level work. PHIGuard tracks every AI vendor BAA and renewal alongside the rest of your compliance program.