HIPAA Business Associate Definition for AI Vendors

To prevent sensitive customer data from reaching OpenAI or another model provider, use a gateway that enforces PII and PHI redaction before submission. HIPAA’s business associate definition still applies to vendors that handle PHI for a covered entity, including the gateway itself. The architecture needs both pre-submission controls and a complete business associate agreement, or BAA, chain for every provider that receives PHI.

Why the HIPAA business associate definition catches AI vendors automatically

45 CFR § 160.103 defines a business associate as a person who, on behalf of a covered entity, creates, receives, maintains, or transmits protected health information for a regulated function or activity. The definition expressly includes data analysis, data processing, claims processing, quality assurance, and practice management. These are routine jobs for AI systems. The function performed with PHI triggers the definition. A vendor does not need to call itself a healthcare company for that definition to apply.

That functional wording leaves no special exemption for AI. A model that processes clinical information is not outside the rule because a machine, rather than a person, reads the input. The disclosure still takes place when the workflow is automated. A vendor that handles PHI while doing covered work for the healthcare organization falls within the business associate definition.

HHS has already applied that reasoning to AI explicitly. It names a third-party AI chatbot on a provider’s patient portal as an example of a business associate relationship when the chatbot handles symptom assessment, medical reminders, and appointment scheduling. The chatbot performs services for the provider using patient information, which puts it inside the existing definition.

What "on behalf of a covered entity" actually means in an AI context

“On behalf of” means the vendor is performing a function the covered entity would otherwise perform itself. It does not require the healthcare organization to initiate every request. A patient can interact with a provider’s chatbot directly while the vendor still acts for the provider. The work establishes the relationship. This is why the phrase applies to purpose-built healthcare software and enterprise tools as well as outsourced administrative services.

An AI coding assistant illustrates the distinction clearly. When it reviews clinical notes and suggests billing codes, it performs a payment function that the billing department would otherwise handle. The vendor is therefore acting on the covered entity’s behalf. Calling the product an assistant does not change that role. Its task and its access to PHI establish the relevant relationship.

The same reasoning applies when a developer calls a model through an API to summarize patient records. The provider processes PHI to produce a result the covered entity needs. A consumer-facing interface does not create an exception when used for that work, and an enterprise label does not settle compliance either.

The encryption and zero-retention misconceptions that give teams false confidence

Encryption is a reasonable place to start protecting patient data, but it does not remove business associate status. HHS cloud guidance establishes that a cloud service provider can be a business associate even when it holds only encrypted ePHI and lacks the decryption key. Maintaining that information on behalf of a regulated entity is sufficient. The provider need not read the underlying records.

An endpoint that does not retain data narrows the breach surface, which is useful, but the vendor still receives and transmits PHI during the call. Those functions satisfy the definition when performed on the covered entity’s behalf. Retention is not the only legal trigger. A BAA is still needed when a zero-retention setting is in use.

The data boundary also extends beyond the prompt. Responses, conversation histories, embeddings, vector database entries, logs, traces, support tooling, and monitoring integrations can all become part of the PHI flow. For teams evaluating the deployment, the lesson is to examine that whole path rather than treating the model endpoint’s retention policy as the answer.

How the BAA chain extends downstream to every subcontractor that touches PHI

45 CFR § 164.308(b)(4) requires a business associate to execute BAAs with subcontractors that create, receive, maintain, or transmit PHI on its behalf. The obligation therefore continues beyond the first vendor. In an AI stack, a SaaS product may call a hosted model provider whose role is not apparent from the product’s compliance page. That backend relationship adds another agreement to the chain. A description of the SaaS vendor’s own infrastructure does not establish coverage for it.

OpenAI covers enterprise offerings, including ChatGPT for Healthcare and ChatGPT Enterprise with Regulated Workspace, and API endpoints provisioned with Modified Retention. Anthropic covers Claude Enterprise and first-party API. Google covers Gemini in Workspace and listed Cloud services. These are distinct BAA paths with coverage limited to the specified offerings.

Amazon Bedrock is HIPAA-eligible under an existing AWS BAA, with Fable and Mythos models excluded. Azure OpenAI is in scope through the Microsoft Online Services DPA. Neither arrangement automatically extends to a wrapper or orchestration layer in front of the service. That intermediary adds its own link to the chain. Its agreement must link to the subcontractor terms that cover the model provider.

A missing required agreement leaves PHI-bearing requests through that path without a complete BAA chain, making those disclosures impermissible. For that reason, provider eligibility alone cannot settle whether an AI product is ready to receive PHI.

What a BAA with an AI vendor must say that standard templates miss

A generic promise to cover “the platform” leaves important AI questions unanswered. The first is whether PHI may be used only to deliver the contracted service or also for model training, product improvement, benchmarking, or aggregate analytics. Silence is not a safe default here. A compliance officer reviewing the agreement should look for explicit limits or permission with a defined scope.

Termination language presents a different gap. Standard BAAs require the return or destruction of PHI, but AI introduces the question of what happens to model weights trained on that information. The treatment of those weights is genuinely unsettled, and auditors are beginning to raise it. The agreement should address that disposition expressly. A generic destruction clause does not resolve the AI-specific question by itself.

Feature scope needs the same precision because enterprise BAA coverage may exclude consumer chat interfaces, marketplace plugins, or third-party integrations. The agreement must cover how the platform will be set up and used, beyond naming the platform. That review should also check that the limits in the contract match the minimum necessary standard for inputs. An AI coding system should receive only the clinical documentation it needs for coding, with the rest of a patient’s full longitudinal record left out. The BAA and deployment architecture should enforce that boundary.

How do you enforce sensitive data redaction at the AI gateway while maintaining the BAA chain?

A managed AI gateway places a control layer between the application and downstream model providers. For pre-submission protection, PII and PHI redaction runs at that layer before any prompt reaches a provider. The sequence is the central safeguard. A provider’s zero-retention promise covers what happens after it receives the data, while gateway redaction controls what gets sent. Those controls can work together.

The HIPAA Security Rule groups technical safeguards into access control, audit controls, integrity, authentication, and transmission security. A gateway provides one chokepoint where those controls can be applied consistently across model calls. In practice, that includes RBAC restrictions on which users and teams may call which models, plus request records containing identity, model, token count, latency, and output. Exportable audit trails make individual calls reviewable rather than forcing teams to reconstruct activity from provider invoices. Because outputs and logs can contain PHI, they also belong inside the data-flow review.

Concentrate is a fully managed HIPAA-compliant AI gateway with a BAA available on the paid plan. It enforces PII and PHI redaction at the gateway before providers receive prompts and includes zero data retention, SSO, RBAC, and audit logs. It routes across models from dozens of providers, so changing models does not require rebuilding the compliance controls. The fully managed service removes proxy deployment, patching, and maintenance work for healthcare teams without a platform team.

Depending on its architecture, a gateway with its own BAA and subcontractor BAAs can consolidate the covered entity’s contracting into one gateway agreement. That arrangement does not eliminate downstream obligations. Any model provider that receives PHI still needs to be covered by the right BAA relationship. The gateway supplies enforcement and routing, not an exemption from the chain.

How OCR enforcement has developed around business associate oversight and what exposure looks like now

OCR collected over $9.9 million in HIPAA settlements across enforcement actions in 2024. Business associate agreement deficiencies were cited as a contributing factor in numerous cases, and enforcement increased further in 2025. Those figures cover HIPAA enforcement overall. A healthcare organization still has its own duties even when an AI vendor promises to comply.

HHS’s Breach Notification Rule places ultimate responsibility for notifying affected individuals on the covered entity. Business associates must notify covered entities when a breach occurs, while the covered entity retains its notification obligations to individuals and HHS. A signed BAA therefore needs to support a workable breach response.

The proposed 2026 HIPAA Security Rule update would change encryption from an “addressable” specification to a required specification for all ePHI, with limited exceptions. It would also introduce new vulnerability scanning expectations for systems handling ePHI, including AI systems. The proposal remained provisional as of the supplied source material and signals a direction for deployment planning.

A structured process for vetting an AI vendor's business associate status and BAA adequacy

A practical vendor review should start by following the PHI. Map where it enters, is processed, is stored, is logged, and is transmitted, including prompts, responses, embeddings, vector databases, monitoring tools, and backups. This map determines which entities need to be evaluated as business associates. The map also establishes the paths where pre-submission redaction and minimum necessary input limits need to apply.

Next, confirm BAA availability for the tier and features the team will actually use. Enterprise or API tiers commonly offer BAAs, while consumer and pro tiers almost universally do not. Then trace the subcontractor chain revealed by the data map. Ask which model and cloud providers receive PHI and whether coverage comes from the vendor’s subcontractor agreements or directly held agreements, such as an existing AWS or Azure BAA. The answer must match the deployed configuration.

With that chain established, review the agreements’ substance. Examine training restrictions or scoped permission, model-weight disposition at termination, feature coverage, and breach notification timelines. Then verify the safeguards independently. Ask for the SOC 2 Type II report, check the encryption standards at rest and in transit, and check whether audit logs can be exported and in what format. Check RBAC and MFA availability and incident response procedures that account for AI system failures.

Finally, document the risk assessment as part of the vendor evaluation. Regulators increasingly expect AI-specific risk assessments as part of the annual Security Risk Analysis, so the process should leave a record of the data flow, what the agreements cover, and which safeguards were reviewed. This workflow is a practical guide, and complex deployments warrant review by a HIPAA compliance attorney or auditor.