AI Vendor Business Associate vs Subcontractor: HIPAA Guide

HIPAA does not use a separate legal category for "AI vendor." Every AI vendor relationship is evaluated under the same definitions that apply to any vendor handling protected health information (PHI), as codified in 45 CFR 160.103: business associate and subcontractor.

How HIPAA Defines Business Associate and Subcontractor

A business associate is any person or entity that creates, receives, maintains, or transmits PHI on behalf of a covered entity, or on behalf of another business associate. The definition is functional, not contractual. Title, technical role, or how a vendor markets itself has no bearing on classification. What matters is whether PHI moves through the vendor's systems in the course of performing a function for the covered entity.

A subcontractor is a business associate that operates one tier removed from the covered entity, performing its function on behalf of another business associate rather than the covered entity directly. Before the 2013 HIPAA Omnibus Rule, subcontractors carried only indirect liability through their contracts with an upstream business associate. The Omnibus Rule closed that gap: subcontractors now hold direct liability for Security Rule compliance and applicable Privacy Rule provisions, regardless of how many contractual layers separate them from the covered entity.

There is no cap on the number of subcontractor tiers. Each entity in the chain that creates, receives, maintains, or transmits PHI must operate under a business associate agreement (BAA) with the entity immediately above it, a requirement generally referred to as flow-down.

Applying BA/Subcontractor Rules to Modern AI Vendor Stacks

AI vendor stacks complicate this analysis because a single interaction can pass through several distinct vendors before touching PHI, or without clearly intending to. A typical stack might include a foundation model provider, an orchestration or agent framework, and one or more third-party tools or APIs the agent invokes at runtime.

HHS has not issued guidance specifically addressing AI agent tool-calling architectures, Model Context Protocol (MCP), or multi-agent orchestration frameworks. In the absence of AI-specific rules, existing BA/subcontractor definitions apply by analogy, and classification still depends on function and data flow rather than on the technical protocol used to connect vendors.

A foundation model provider that receives PHI as part of an inference request made on behalf of a covered entity generally qualifies as a business associate, because it is receiving and processing PHI while performing a function for that entity. An orchestration layer sitting between the covered entity and downstream tools may itself be a business associate if it handles PHI directly, and it may simultaneously create subcontractor relationships with every tool or model it invokes on the covered entity's behalf.

Tool-calling architectures such as MCP are integration standards, not classification frameworks. The protocol a vendor uses to connect to other services does not determine its HIPAA status. What determines status is whether the invoked tool or API creates, receives, maintains, or transmits PHI during that call. Because agents can select tools dynamically at runtime, the set of business associates and subcontractors in a given workflow is not fixed and should be treated as something to monitor continuously rather than classify once.

Business Associate vs Subcontractor: Key Distinctions

The table below summarizes how each classification, and the flow-down obligation connecting them, applies across an AI vendor stack.

Runtime Governance and Audit Controls for Agentic PHI Access

Classification determines contractual obligation. It does not, by itself, produce evidence that PHI was actually handled in compliance with those obligations. The Security Rule requires audit controls, and in agentic workflows where tool selection happens at runtime, the audit trail has to capture which tool was called, what data was passed, and which entity received it, not just which vendors were contractually approved in advance.

This is where runtime governance becomes part of HIPAA compliance work rather than a separate concern. Logging tool invocations, enforcing permissions at the point of a tool call, and requiring approval before a new tool is added to an agent's available set all produce the kind of record that supports Security Rule audit control requirements across a multi-tier vendor stack.

Trussed AI provides runtime governance for enterprise AI agents, including audit logging of tool invocations, permissioning and least-privilege controls at the agent and tool level, and approval workflows for new tool integrations. These capabilities do not change how a vendor is classified under HIPAA. They support the operational evidence a compliance program needs to demonstrate that classification decisions are being enforced in production, particularly in MCP-style architectures where the set of invoked services can change without a corresponding change to the vendor contract.