AI Infrastructure BAA Scope: What It Covers and What It Doesn't

Quick Answer: A Business Associate Agreement (BAA) is a HIPAA contract that defines how a business associate may create, receive, maintain, or transmit protected health information (PHI) on behalf of a covered entity. In AI infrastructure, BAA scope covers PHI processing, transmission, and storage within the provider's compute, storage, and network environment.

The agreement does not extend to the customer's application layer, model behavior, or data governance decisions, which remain the covered entity's responsibility. Healthcare teams evaluating GPU cloud or private AI infrastructure must understand this boundary, because it determines where compliance evidence must come from when auditors examine an AI workload.

This article explains what a BAA covers and what it excludes in AI infrastructure, how these terms shape provider evaluation, and how responsibility splits between customer and vendor in managed and hosted GPU environments.

What a BAA Covers in AI Infrastructure

Under HIPAA, a covered entity (a health plan, healthcare clearinghouse, or healthcare provider) must obtain a BAA from any business associate that creates, receives, maintains, or transmits PHI on its behalf. An AI infrastructure provider becomes a business associate the moment PHI enters its environment, whether for training data ingestion, inference over clinical records, or long-term model and log storage. The BAA must describe permitted uses of PHI, require appropriate safeguards, and prohibit uses beyond the agreement's scope.

PHI Processing, Transmission, and Storage

In AI infrastructure, the covered scope has three practical components. Processing covers the compute layer: training runs, fine-tuning, and inference that touch PHI. Transmission covers data movement between the customer environment and provider facilities, including API traffic and data egress. Storage covers data at rest: training corpora, model checkpoints, inference logs, and backups. Each of these paths must be identifiable in the contract, because an environment outside the BAA's scope cannot lawfully process PHI.

The BAA also obligates the provider to report breaches affecting PHI, flow the same protections down to subcontractors, and support the covered entity's audit of its safeguards. Audit rights are the enforcement mechanism: the covered entity must be able to inspect records demonstrating how PHI was handled, which is why the agreement should reference the specific infrastructure services in use.

What a BAA Does Not Cover: Customer Responsibilities

The BAA is a contract between the covered entity and the business associate; it does not certify the customer's AI application or the models it runs. The application layer (application code, API integrations, workflow configuration, and the data flows the customer builds on top of infrastructure) remains under customer control and customer accountability. If an application misroutes PHI to an unauthorized endpoint, the BAA does not transfer that responsibility.

The model layer follows the same logic. A BAA does not make model behavior compliant: whether PHI may be used for training at all, how de-identification is applied, and how inference outputs are governed are determinations the covered entity must make and document. Model artifacts derived from PHI can carry PHI-derived information, so retention, access control, and deletion of weights and checkpoints need governance beyond the infrastructure contract.

Data governance completes the customer side of the boundary. Classification of data as PHI, decisions about what enters the AI environment, application-level access controls, and the compliance program that ties risk analysis to infrastructure evidence all remain with the customer. The infrastructure contract defines the provider's obligations; it does not define the customer's policies.

How BAA Scope Shapes GPU Cloud and AI Infrastructure Evaluation

Willingness to sign a BAA is one of the clearest compliance signals a GPU cloud provider can give. Not all providers serving AI workloads are prepared to take on business associate obligations, and those that are must scope the agreement to the services actually used for PHI. Healthcare teams should treat a signed BAA as the entry requirement, then verify that its scope matches the real data path: the compute, storage, and networking services that PHI traffic will touch.

The data path matters because PHI must stay inside environments the BAA covers. Shared model catalogs, public inference endpoints, and transient test environments outside the agreement cannot receive PHI traffic without creating an unapproved disclosure. Private AI infrastructure simplifies this mapping: dedicated compute, storage, and networking on U.S.-based data centers make every PHI path identifiable and keep the covered scope legible to auditors.

Data Paths, Subcontractors, and Audit Rights

Two clauses deserve close reading during evaluation. Subcontractor clauses require downstream BAAs with any subprocessor that handles PHI, and the covered entity should receive notice when subcontractors change. Audit clauses define the records the covered entity can inspect; evidence such as SOC 2 reports, access logs, and incident documentation should be available on request. Providers that offer AI infrastructure for healthcare typically document these terms explicitly, because the agreements are the primary compliance artifact auditors examine.

Responsibility Splits in Managed AI and Hosted GPU Scenarios

In managed AI environments, the provider operates the infrastructure end to end: monitoring, patching, performance validation, and lifecycle management. The BAA covers the provider's handling of PHI within that operational scope, including access by provider staff and systems. Customers retain responsibility for the decisions that determine what PHI enters the environment and how it is governed once it does.

Orchestration adds a finer-grained boundary. The OnePlus Platform, OneSource Cloud's AI orchestration platform, separates workloads into per-team environments with usage metrics and scheduling controls; in a BAA context, that isolation becomes evidence that only authorized teams and workloads can touch PHI. Managed AI infrastructure builds the same separation into operations, so the provider can demonstrate which staff, systems, and data paths fall within the agreement.

Common BAA Misconceptions in AI Infrastructure

Five misconceptions recur when healthcare teams evaluate AI infrastructure under a BAA. Getting them right prevents compliance gaps that surface during audits.

• "A BAA makes the infrastructure HIPAA compliant." A BAA is a contractual foundation, not a certificate. Both parties must implement the safeguards the agreement references; infrastructure designed as HIPAA-ready supports that implementation, but compliance depends on the combined controls of customer and provider.
• "The BAA covers everything the customer does with PHI." Scope is limited to the business associate's services. Application behavior, model decisions, and governance stay with the customer even when PHI is involved.
• "A provider that will not sign a BAA is still acceptable for de-identified data." De-identification is a formal determination under HIPAA. Pseudonymous or synthetic data that can be re-linked to individuals remains PHI, and that assessment is the customer's to document.
• "Signing a BAA transfers all liability." The agreement allocates responsibility; it does not absolve the covered entity from its compliance obligations. Customer-side misuse of PHI remains a customer finding.
• "Model weights trained on PHI need no controls once the BAA is in place." Model artifacts derived from PHI can carry PHI-derived information. Governance of weights, checkpoints, and outputs is a customer responsibility the BAA does not cover.

FAQ

What is a business associate agreement (BAA)?

A BAA is a HIPAA contract between a covered entity and a business associate that creates, receives, maintains, or transmits protected health information on the covered entity's behalf. It defines permitted uses of PHI, requires safeguards, and assigns responsibilities for breach notification and audit support. In AI infrastructure, the BAA marks the boundary of provider responsibility for PHI across compute, storage, and network services.

Is an AI infrastructure provider required to sign a BAA?

Yes, when the provider creates, receives, maintains, or transmits PHI for a covered entity, HIPAA requires a BAA. Providers serving healthcare AI workloads should be prepared to sign one and scope it to the services used. Healthcare teams should confirm the agreement covers the actual compute, storage, and network paths PHI will traverse, because an environment outside the BAA cannot lawfully process PHI.

Does signing a BAA make an AI infrastructure HIPAA compliant?

No. A BAA is a contractual baseline that assigns responsibilities; it does not certify compliance. Both parties must implement the safeguards the agreement references, including access controls, encryption, breach response, and audit records. Infrastructure designed as HIPAA-ready supports that implementation, but a compliance determination depends on how the customer and provider together operate the environment for a specific workload.

How is a BAA different from a GDPR data processing agreement?

A BAA operates under U.S. HIPAA rules and governs PHI between covered entities and business associates. A data processing agreement (DPA) operates under the GDPR and governs personal data between controllers and processors. The two can coexist in the same engagement, and healthcare teams working with PHI that involves EU residents should evaluate both agreements rather than assuming one satisfies the other.

What should healthcare teams verify in a BAA's subcontractor clause?

The subcontractor clause should require downstream BAAs for any subprocessor that handles PHI, name the categories of subcontractors involved, and include notice obligations when subcontractors change. Healthcare teams should also confirm they can evaluate new subcontractors before PHI moves to them. A clause that allows unlimited subcontracting without notice weakens the data path controls the rest of the agreement establishes.

Summary

A BAA defines where provider responsibility for PHI begins and ends in AI infrastructure: processing, transmission, and storage within the contracted environment, plus breach notification, subcontractor flow-down, and audit support. What the agreement does not do is certify applications, models, or governance, which remain customer responsibilities. For healthcare teams, the practical outcome is clear: the infrastructure contract and the customer's own compliance program must be designed together, and both should be evaluated before PHI enters a GPU environment.

Next step: Explore OneSource Cloud's HIPAA-ready AI infrastructure for healthcare workloads →