HIPAA Business Associate Agreements for AI Vendors

A signed Business Associate Agreement is the legal line between using an AI tool with patient data and violating federal law, full stop. But the BAA templates most health systems still use were written for EHR vendors and billing companies years ago, and they do not account for how a large language model actually ingests, stores, and sometimes learns from the data it touches. This piece walks through what a BAA legally requires, why the old templates fall short, what "HIPAA compliant" actually means when a vendor prints it on a landing page, which major AI companies will sign one and what they leave out, and what a BAA needs to say if it's going to mean anything for a generative AI product.

Start with the definition, because it's broader than most compliance officers assume. Under 45 CFR 160.103(1)(i), a business associate is anyone who creates, receives, maintains, or transmits protected health information on behalf of a covered entity for a function regulated under that framework. A human or a model doing the processing makes no difference to that definition. An algorithm that reads a discharge summary and flags sepsis risk is doing the same regulated function a nurse reviewing that chart would do, and the law treats it that way.

Three categories of AI clearly meet this test, and they don't meet it in the same way. Clinical decision support tools sit closest to the obvious end: they pull ePHI straight from the EHR to generate a recommendation, so the PHI exposure is direct and unmissable. Administrative AI, things like coding assistants, scheduling bots, and prior-auth automation, is murkier, because vendors and buyers alike tend to treat PHI access as a side effect of the product rather than its core function. That's exactly why BAA coverage for this category is so inconsistent: nobody built the sales conversation around "this tool touches PHI," so nobody built the contract around it either. Then there's ambient AI scribes, tools like Nuance DAX, Abridge, and Suki, which record live clinical conversations and capture the patient's name, condition, treatment plan, and the physician's own diagnostic reasoning in real time. This is the fastest-growing category in clinical AI right now, and it raises particularly complex compliance questions, because the audio stream containing patient information is captured before any transcription even happens.

The gap this creates is already wide open in daily practice. Physicians paste clinical notes into consumer chatbots to draft a letter faster. Front-desk staff run AI scribes during patient phone calls without anyone in compliance signing off. Revenue cycle teams feed denial letters into generative AI tools to draft appeals. Most of these workflows started because someone found a tool that worked, not because procurement reviewed it, and many were never flagged to a compliance office. None of that changes the law's timing: disclosing PHI to a vendor without a BAA in place violates the law the moment the disclosure happens, even if nothing ever leaks. A breach isn't the trigger. The disclosure is.

What a BAA obligates a vendor to do, and what it leaves entirely with the covered entity

HHS requires four things in every BAA, and skipping any one of them isn't optional under the law. First, the agreement has to limit how the business associate can use or disclose PHI, restricting it to the purposes spelled out in the contract or required by law elsewhere. Linford & Co., in reviewing HIPAA compliance audits, found that vague language on this exact point is the single most common deficiency auditors flag in BAAs. "As needed to provide services" "As needed to provide services" is a blank check with a HIPAA label on it, not a use limitation. It's a blank check with a HIPAA label on it.

Second, the BA has to maintain administrative, physical, and technical safeguards that line up with the Security Rule. Third, it has to report unauthorized disclosures and breaches of unsecured PHI back to the covered entity. Fourth, it has to return or destroy PHI when the relationship ends. Those four are the floor, not the ceiling, and several other elements get missed constantly even though they're required: the BA has to support patient rights (access requests, amendment requests, accounting of disclosures), bind any subcontractor it uses to the same restrictions, and meet other obligations commonly required in practice.

Here's what none of that does, though. A signed BAA does not make a covered entity's overall workflow compliant on its own; it covers whatever surfaces the agreement actually names, and nothing outside those surfaces. It doesn't take workforce training, access control, minimum-necessary enforcement, audit logging, or risk analysis off the covered entity's plate, those obligations stay put regardless of what the vendor signs. It doesn't authorize PHI use in any feature the vendor has explicitly carved out of coverage. And unlike a lot of commercial contracts, a BAA doesn't automatically indemnify the covered entity if the BA screws up. If the covered entity never did due diligence on the vendor in the first place, both parties can end up sharing liability for the same breach.

A BAA covers the vendor's HIPAA obligations on the surfaces it explicitly names, and everything else stays the covered entity's problem.

Why standard-form BAAs drafted for EHR vendors fail when applied to modern AI systems

MDRx Law notes that most BAA templates were drafted when "business associate" meant something narrow, covering an EHR vendor, a billing company, outside counsel, or a cloud storage provider. Their PHI use was predictable, bounded, and always performed strictly on the covered entity's behalf. Nobody was worried the billing company might use claims data to train a product feature for other customers, because that use case didn't exist yet.

Modern AI systems break that assumption at the root. Many ingest and retain PHI at scale specifically to train, fine-tune, or improve the underlying model, and that's a fundamentally different use than "process this claim and send it back." It's a secondary use, one that falls outside HIPAA's permitted purposes unless a covered entity has explicitly authorized it, and the old templates simply never anticipated the question.

Three structural gaps appear here that no legacy BAA addresses. Model training is the first: if a vendor's product improves because it learned from patient data, that's a use for the vendor's own benefit, not "on behalf of" the covered entity, and HIPAA doesn't permit it without separate written authorization. Retention at scale is the second: AI systems can hold onto raw inputs, embeddings, or other derived representations of PHI long after the original transaction closes out, in a way a claims-processing vendor from an earlier era structurally could not. Inference outputs are the third, and the one most compliance teams haven't fully priced in: a clinical summary, a risk score, or a suggested diagnosis generated from PHI can itself qualify as PHI, or be re-identifiable even when the vendor assumed it wasn't.

Then there's the subcontractor chain, and this is where AI deployments get genuinely tangled. A single AI support vendor might call a large language model through an API, run its infrastructure on a separate cloud host, and route audio through a third-party transcription service, three different nodes, each one touching PHI at some point. HIPAA requires the business associate to get written assurances from every one of those subcontractors. If the vendor signs a BAA with the health system but pipes prompts through an LLM API that has no no-train, BAA-covered agreement of its own, the chain breaks at that link, and the exposure lands back on the covered entity, not the vendor who broke the promise. EHR-embedded AI adds one more wrinkle: when an EHR platform bolts on a third-party AI feature, the covered entity has to determine whether that AI developer has its own independent access to PHI or operates entirely inside the EHR vendor's walls, a question that turns on how the business associate definition applies under 45 CFR 160.103. The original EHR BAA, signed years before that feature existed, almost never resolves the question either way.

What does a broken subcontractor chain actually look like? A breach affecting 483,126 patients across six hospitals was traced to Serviceaide, an agentic AI-powered workflow tool, and that is not a hypothetical about paperwork. That's what happens when nobody mapped the chain before turning the tool on.

The "HIPAA certified" and "HIPAA compliant" language vendors use, and what it means

No government agency certifies AI products as HIPAA compliant. None. HIPAA is a federal law that sets requirements for covered entities and their business associates, and there's no seal, badge, or certification body that signs off on a product and declares it clean. When a vendor's homepage says "HIPAA certified," that phrase describes a marketing choice, not a regulatory status.

Vendors can get real, independent assurance work done, SOC 2 reports, HITRUST certification, and those mean something. They're audited frameworks that speak to a vendor's security posture. But they're not government certifications, and they're not a substitute for a signed BAA covering the specific product surface a health system plans to use.

Two phrases get used almost interchangeably in vendor marketing, and they shouldn't be. "HIPAA eligible" means the service has the technical features needed and the vendor is willing to sign a BAA for it. "HIPAA compliant" describes an end state, one where the health system has actually configured that service correctly, with every required safeguard turned on and working. Buying an eligible service doesn't produce compliance by itself; the configuration work still sits with the organization that bought it. A vendor can build every technical control HIPAA asks for and a health system can still be fully exposed, either because no BAA exists or because the BAA that does exist doesn't cover the specific data flow the clinical team is actually using.

So evaluating the vendor can't stop at "does this vendor offer a BAA." Which product tier, which features inside that tier, and which subprocessors are actually named in the agreement produce the real answer, and the evaluation has to check the agreement itself to know. That's the question the next section works through, vendor by vendor.

Which major AI vendors will sign a BAA, what they cover, and where the gaps sit

"Vendor X offers a BAA" and "this health system can use Vendor X for PHI" are two different claims, and AI Career Lab's review of major vendor agreements shows that every one of them covers specific tiers, specific features, and specific configuration steps, not the product as a whole. Sales-assisted BAAs typically take two to eight weeks to process, which matters if a rollout has a deadline attached.

Anthropic offers a BAA on exactly two surfaces: the Claude API and its HIPAA-ready Enterprise plan, both available self-serve and through sales. The default Enterprise plan does not include BAA coverage out of the box; a Primary Owner has to go into Organization Settings, find Data and Privacy, then HIPAA Compliance, accept the BAA, and explicitly turn on HIPAA mode, a step that Anthropic treats as a significant configuration commitment. Once enabled, covered surfaces include chat, projects, artifacts, file creation and code execution, voice, web search, research, and skills, subject to the specific configurations Anthropic permits under that plan. Not covered: Claude Free, Pro, Max, Team, Claude Cowork, Workbench, Console, Claude Code (unless Zero Data Retention is separately turned on), Claude in Chrome, third-party MCPs and connectors, Enterprise Search, and research previews. Timing matters here too: BAAs signed before December 2, 2025 cover the API only, and organizations that signed one before that date have to sign a new agreement to add Enterprise coverage.

OpenAI runs several paths at once. There's the API for healthcare workloads, but only on Modified Retention or ZDR-eligible endpoints. There's sales-managed ChatGPT Enterprise with a Regulated Workspace, plus ChatGPT for Healthcare. And there's ChatGPT for Clinicians, free for verified US clinicians, with its own separate in-product BAA flow. ChatGPT Free, Plus, Pro, Team, and self-serve Business are not eligible at all, putting PHI into any of those tiers is a violation on its face. Even the API path has caveats, since certain features have been excluded from ZDR coverage at different points, and the eligible endpoint list needs checking against current terms before anyone designs a workflow around it.

Microsoft delivers its BAA through the Online Services Data Protection Addendum, covering Microsoft 365 Copilot on commercial or enterprise tenants and Azure OpenAI Service. Family and Personal subscriptions are not covered, and Copilot accessed through a personal Microsoft account stays outside BAA protection no matter what feature is in use. Image inputs, DALL-E and vision features, sit outside the Azure OpenAI BAA as of mid-2026. Microsoft holding a BAA with an AI vendor that runs on Azure infrastructure does not mean the health system has a BAA with that AI vendor. Those are two separate agreements, and a lot of procurement teams conflate them.

Google made Workspace with Gemini eligible under its BAA in the Business and Enterprise tiers starting in late 2024. Proper configuration steps need to be completed for every workload that touches PHI. Consumer Gemini through a personal Google account is not eligible, and some experimental Gemini features, along with Gemini in Chrome, have been excluded from coverage.

AWS makes its BAA available self-service through AWS Artifact at no extra charge. As of February 2026, HIPAA-eligible services include Amazon Bedrock, Bedrock AgentCore, Amazon Polly, Amazon Transcribe and Transcribe Medical, Amazon Comprehend Medical, and Amazon Lex. The same infrastructure-layer trap applies here as with Microsoft: an application built on top of Bedrock needs its own separate BAA with the application's own vendor, not just AWS's underlying agreement.

A few notable names don't offer coverage at all for most customers. Perplexity has no BAA on its consumer or Pro tiers, though one is available for Enterprise Pro and Enterprise Max customers. GitHub Copilot offers no HIPAA BAA at any tier.

Organizations that want AI capability without any PHI leaving their own environment have another path worth weighing: architectures built specifically so no PHI ever gets retained, transmitted to an outside model API, or used to improve someone else's product. Where that's true by design rather than by contractual promise, the whole BAA exposure calculation changes shape, because there's less to disclose.

The AI-specific provisions a BAA must include beyond the four HIPAA minimums

The four HIPAA minimums keep a BAA legal. They don't make it adequate for an AI deployment, and healthcare privacy counsel, per MDRx Law's analysis and the broader compliance research on this question, has started converging on a shorter list of provisions that actually address how these systems behave.

Model training prohibition is the top of that list, and most standard-form BAAs are missing it entirely, mostly because they were drafted before generative AI deployments were common. The language needs to explicitly bar the vendor from using PHI to train, improve, or refine its models unless the covered entity has given separate written authorization, often paired with requirements around compensation or de-identification to HIPAA's actual standard. And it can't stop at raw PHI. It has to reach embeddings, derived representations, and any intermediate output generated along the way, because those can carry the same identifying signal the raw data did.

Sub-processor disclosure is the second piece. The agreement needs to name every sub-processor that will touch PHI, confirm each one is bound to HIPAA-equivalent terms, and give the covered entity advance notice and a real right to object before a new sub-processor gets added. That covers the LLM API provider, the cloud host, the transcription service, whatever else sits in the chain between the point of capture and the final output.

Retention, return, and destruction terms need teeth too: a defined window, measured in days, for returning or irreversibly destroying PHI and its derivatives once the relationship ends. And that requirement has to extend past raw data into model weights, embeddings, logs, and cached outputs, any of which might carry PHI's fingerprint even after the original record is gone.

Last comes re-identification. The BA needs to warrant, in writing, that it will not attempt to re-identify data a covered entity has de-identified and handed over. That warranty matters more with AI than it ever did with a billing vendor, because pattern-matching across large datasets is precisely what these models are built to do well, whether or not anyone asked them to.

Put all four provisions next to the four HIPAA minimums and a pattern is visible: the law's floor was built for a world where a human read a chart and typed a note. AI systems don't work that way, and a BAA that doesn't say so in writing is a BAA that hasn't actually caught up.