AI Business Associate Agreement Template: What to Include

What a Standard HIPAA BAA Requires

Under 45 CFR 164.504(e), a covered entity must obtain a written contract with any business associate that creates, receives, maintains, or transmits PHI on its behalf. HHS sample BAA provisions define the required elements: permitted and required uses of PHI, a prohibition on uses or disclosures beyond the contract terms, appropriate safeguards, reporting of breaches or security incidents, subcontractor flow-down obligations requiring subcontractors to agree to the same restrictions, and return or destruction of PHI at termination. HHS guidance clarifies that this obligation applies regardless of the technology a vendor uses to process PHI, which means an AI vendor meets the same threshold for BAA coverage as any other business associate. The Security Rule adds further requirements at 45 CFR 164.308 and 164.312, including access control, unique user identification, and audit controls that record and examine system activity involving ePHI. These provisions form the legal floor. They were not written with AI-specific processing in mind, and the gap becomes apparent once PHI moves through a model rather than a discrete data store.

Where Standard Templates Fall Short for AI Systems

Standard BAA templates assume PHI is processed and stored in discrete, auditable transactions. AI systems frequently ingest PHI into model inputs, embeddings, or context windows without a corresponding discrete transaction record, which makes the standard permitted-use and safeguard language difficult to verify in practice. Neither 45 CFR 164.504(e) nor the HHS sample provisions reference AI model training, fine-tuning, or machine-learning data retention as a distinct category of PHI use, so a signed BAA built on the standard template says nothing about whether submitted PHI is retained to improve a model. Subprocessor risk compounds this gap. Third-party foundation model APIs may sit beneath a primary vendor's BAA without independent contractual visibility into their own retention or training practices, even though the subcontractor flow-down requirement is meant to extend the same restrictions downstream. Agent-level access introduces a third gap: autonomous retrieval, tool use, and multi-step workflows are not addressed by BAA language written for static system-to-system data exchange, leaving no contractual definition of what an agent is permitted to query or act on.

Contract Language Versus Technical Enforcement

A BAA is a legal commitment, not a technical control. Standard agreements depend on the vendor's internal controls to enforce what the contract states, and this dependency is where AI-specific risk concentrates. The Security Rule's audit control requirement at 164.312(b) does not specify log formats or runtime verification methods, which leaves an open question in AI deployments: how should model inference and agent actions be logged as evidence that PHI was processed within the terms of the agreement. A BAA can require audit logging as a contractual term, but the agreement itself cannot verify that logging occurred or that it captured the right activity. Compliance leaders evaluating an AI BAA should treat the contract and the technical enforcement mechanism as separate but linked requirements, and should confirm that the vendor can produce audit evidence tied directly to the permitted-use and access-scope clauses in the agreement, not only a general statement of policy compliance.

Evaluating a Proposed AI BAA

• Confirm whether the vendor or any subprocessor uses submitted PHI for model training, and require an explicit contractual answer rather than relying on a general privacy policy
• Verify that all AI subprocessors, including third-party model APIs, are named and covered by consistent flow-down terms
• Check that retention terms extend to model context, logs, caches, and embeddings, not only the primary database
• Require a defined access scope for AI agents and ask how least privilege is enforced technically, not just described contractually
• Ask what audit logging the vendor can produce on request, and whether it maps to the specific permitted-use terms in the agreement

Accountability Beyond the Signed Agreement

AI vendor behavior and subprocessor relationships can change without contract renegotiation, which means a signed BAA reflects a point-in-time commitment rather than an ongoing guarantee. Compliance programs should assign clear internal accountability for AI-specific PHI use cases, including training data handling and agent-driven workflows, rather than treating vendor-stated policy as sufficient assurance. Periodic re-attestation of AI vendor and subprocessor compliance status, paired with a risk analysis process that explicitly accounts for AI system components, closes part of this gap. No AI-specific HIPAA rule currently exists, and voluntary frameworks such as NIST's AI RMF offer general risk-management guidance on data governance but do not establish HIPAA compliance requirements. Runtime governance capabilities, including agent permission enforcement, tool approval workflows, and audit logging tied to actual PHI access events, can provide the evidence a BAA's contractual terms depend on but do not themselves generate.