HIPAA Business Associate Agreement Requirements for AI Vendors

A medical practice can have signed business associate agreements for its billing platform and its EHR vendor, and it can still find, on close inspection, that it has no executed agreement covering the scheduling bot staff started using six months earlier. That gap reflects a compliance program that was built around a prior generation of vendors and has not caught up to how AI tools actually enter a practice's operations. Standard BAA templates were written for billing companies and cloud storage providers, so you won't find language in them that addresses how AI systems move, retain, and process protected health information. That mismatch is now an active compliance and enforcement risk, not a theoretical one.

HIPAA itself is technology-neutral. Any vendor that creates, receives, maintains, or transmits PHI on a covered entity's behalf is a business associate, and a BAA is required before PHI flows to that vendor, regardless of whether the product is marketed as an AI tool, an automation platform, a scheduling agent, or a documentation assistant. The law does not carve out an AI exemption, and it never evaluates a vendor by its product category. It evaluates the vendor by what happens to the data.

The regulatory baseline shifted in a way that makes this gap harder to ignore. The proposal has not been finalized, but it is moving toward implementation, and OCR has already made vendor accountability a central part of its 2026 enforcement priorities. BAA deficiencies are typically among the first gaps OCR identifies when it investigates a breach.

The exposure accumulates in small, everyday moments. Each of these is a PHI exposure if the BAA review has not already happened, and AI tools are entering healthcare operations faster than most compliance programs can evaluate them.

Which AI vendors require a BAA

Whether a given AI vendor needs a BAA turns entirely on what that vendor does with PHI inside the actual workflow, not on what the vendor calls its product or whether its marketing copy uses the word "compliant." In each case, a BAA has to be in place before PHI is permitted to flow, not after.

There are narrower circumstances where a BAA may not be required, but even those require an explicit, documented analysis. A vendor receiving only properly de-identified data under the Safe Harbor method or Expert Determination, as defined at 45 CFR 164.514(b), generally does not need a BAA for that specific data flow, but if the vendor itself performs the de-identification, a BAA is required to authorize that function. Conduit services that only transmit PHI temporarily and retain nothing also fall outside BA status, but HHS has confirmed that a cloud service storing electronic PHI is not a conduit, even when the data is encrypted and the vendor holds no decryption key, and an AI service that processes prompts is doing far more than transmission. An AI tool used only with information that contains no PHI at all falls outside the requirement too, but practices should be cautious about assuming a dataset is truly free of identifiers.

A vendor's claim that no BAA is needed is a technical assertion, not a settled fact, and the covered entity bears the burden of verifying it. When the conclusion of this analysis is "no BAA needed," that determination deserves the same documented rigor as a determination that one is required.

How AI systems move PHI in ways that standard BAA language was never written to govern

AI systems create several new surfaces where PHI can move, persist, or be retained, and most of those surfaces did not exist when the BAA templates still circulating today were drafted. Standard language was never written with any of them in mind.

The first is the prompt and transcript layer. AI platforms may retain the prompts sent to them, the transcripts they generate, audio recordings, and system log files, and each of these can contain PHI. None of this is addressed by a standard "return or destroy PHI at termination" clause unless retention periods for each category are spelled out explicitly in the agreement. Voice and conversational agents sharpen this problem further: a practice needs to know where recordings and transcripts live, how long they persist, whether they feed into any model-improvement process, and how the vendor would locate and delete the organization's data on request.

The second is the model training risk. Using PHI to train an AI model without explicit written patient authorization, or another recognized HIPAA-compliant pathway such as proper de-identification or a BAA that expressly permits training, violates HIPAA's Privacy Rule. But the enterprise or healthcare-specific tiers of those same products, with explicit BAA coverage and model-training restrictions written into the contract, are a meaningfully different product, so practices need to know which version they are actually using.

A third category deserves particular attention because it departs from how most compliance frameworks were built: screen-operating and computer-use agents that navigate browser interfaces, fill out payer portal forms, and read information directly off EHR screens. Local processing reduces the risk that comes with cloud transmission, but it does not remove HIPAA obligations from the equation.

A fourth concern is the minimum necessary standard, and it applies to AI systems the same way it applies to human staff. The gap is especially acute for AI systems that operate across multiple platforms in a single workflow: a scheduling agent or prior authorization assistant that reads screens, navigates EHRs and payer portals, and processes patient context at each step creates a data-flow footprint that traditional BAA language was never built to address, because those templates were written for an era when vendors managed data in isolation.

The subprocessor chain: why a signed BAA with the primary vendor does not close the compliance gap

A BAA with the primary AI vendor still leaves a covered entity exposed if that vendor's own infrastructure, including cloud hosts, model providers, inference APIs, and analytics layers, handles PHI without equivalent contractual protections flowing down through the chain. The obligation here is not a matter of best practice. Under 45 CFR § 164.308(b)(4), a business associate is legally required to execute BAAs with any subcontractors who will create, receive, maintain, or transmit PHI on the BA's behalf.

In a typical AI deployment, the primary vendor's product will rarely be working alone. Scheduling and voice-agent workflows illustrate this clearly: the scheduling vendor's own BAA may say nothing about the speech-to-text provider, the underlying language model, the call recorder, the analytics platform, the CRM, or the QA tool sitting downstream, and any one of those parties can receive PHI in the course of the workflow running. This gap appears more than almost any other in HIPAA compliance engagements, because many BAAs still let the primary business associate subcontract without requiring it to flow down equivalent security and privacy obligations to those subcontractors.

The threshold question in evaluating any of this turns on what the system actually does with PHI during operation: whether it transmits data to external servers, logs prompts containing patient identifiers, retains session context between tasks, or processes information locally on a practice's own infrastructure. What a covered entity cannot see is just as dangerous as what it can. If an AI vendor adds a new model subprocessor after the BAA is signed and does not notify the covered entity, the entire workflow can become non-compliant while the practice stands by. That risk points directly to the kind of clause the next section specifies: a contractual requirement that the vendor disclose subprocessor changes as they happen, not years later during an audit.

The specific BAA provisions that adequately address AI vendor risk in 2026

A defensible BAA for an AI vendor in 2026 combines the HIPAA-required baseline provisions with a set of negotiated, AI-specific controls layered on top. The distinction between the two matters because meeting the legal minimum does not, by itself, close the gaps the previous sections describe.

The baseline, required under 45 CFR § 164.504(e), has to include a specific description of permitted uses and disclosures, since vague language here is the single most common BAA deficiency found in HIPAA compliance audits. And it has to require return or destruction of PHI at termination when feasible, with continuing protections if return or destruction is not feasible, along with a defined right to terminate for material breach.

That baseline is the floor, not the ceiling. An adequate AI-era BAA adds an explicit, written prohibition on using PHI to train, fine-tune, evaluate, or improve the vendor's own models or any third party's models. A practice deploying an AI agent across its EHR and payer systems should require explicit language addressing prompt retention, local versus cloud processing, encryption in transit and at rest, session-level data isolation, and the vendor's data-deletion timelines, because generic cloud-storage language leaves exactly this kind of detail unaddressed.

The agreement should also require the vendor to disclose its current subprocessor list at signing, say which subprocessors handle PHI, and set a notice window for any future change. It should give the covered entity a defined right to request security evidence, most often a SOC 2 Type II report or a HITRUST certification, and it should spell out the permitted service-delivery uses clearly enough that the vendor needs approval before it expands the product into new territory. None of this substitutes for actual security review. A signed BAA is a contract, and a contract does not by itself establish that a product is configured or operated securely. Security review, correct configuration, workforce training, and ongoing vendor oversight stay separate obligations that run alongside the agreement, not inside it.

Evaluating an AI vendor's BAA before PHI moves: a practical review sequence

You get the best results if you review an AI vendor's BAA as a documented sequence completed before any PHI is permitted to flow, not as a retroactive cleanup once a tool is already in daily use.

The first step confirms business associate status before the agreement itself is even reviewed. That means mapping the data flow and asking directly whether the vendor will create, receive, maintain, or transmit PHI while providing its service, then checking that flow against the recurring patterns that trigger BA status: voice agent, document reader, prior authorization service, EHR-connected assistant, analytics or transcription tool. The conclusion, whichever way it lands, should be documented along with the reasoning behind it.

That means confirming the HHS-required provisions are present (permitted uses, safeguards, breach reporting, subcontractor flow-down, individual rights support, return or destruction at termination, right to terminate), verifying that retention and deletion terms name prompts, transcripts, audio, logs, and backups specifically rather than referring vaguely to "PHI," and checking that the incident notification clause sets a concrete timeline, targeting no more than 72 hours, along with the required content of that notice.

That means requesting the vendor's SOC 2 Type II report and confirming its scope actually covers the services and infrastructure that will handle PHI, verifying encryption standards against the current reference points of AES-256 at rest and TLS 1.2 or higher in transit, confirming multi-factor authentication and role-based access controls are in place, confirming audit logging of PHI access and modifications is maintained, and requesting the current subprocessor list to assess which parties will touch PHI.

The fourth step documents a vendor-specific AI risk assessment. Keep the risk assessment, the signed BAA, and the security documentation review together in a single vendor file, so OCR can examine it if a breach investigation happens. Certain scenarios should trigger this entire sequence immediately: staff adopting a new AI tool before IT or compliance even knows about it, or a vendor quietly adding AI features to a product that was deployed under a BAA signed before those features existed.

Compliant AI Deployment: Computer-Use Agents Versus SaaS Tools

The BAA provisions that matter most for a given AI vendor depend heavily on how that vendor's product is architected. Computer-use agents that operate existing software the way a human staff member would present a different risk profile than SaaS platforms that ingest and centrally store PHI, and the review process should reflect that difference.

SaaS AI platforms pull clinical notes, transcripts, or scheduling data into a centralized cloud environment, so they concentrate PHI inside a system the vendor controls. For that architecture, the model training prohibition, the retention and deletion clauses, and the subprocessor chain are the highest-priority items in any BAA review, since the vendor's own cloud environment is where the exposure lives. This is a legitimate and widely used approach, and many reputable platforms in healthcare operate this way successfully with the right contractual protections in place.

Computer-use agents take a different path. They interact with systems a practice already controls, including its EHR, its payer portals, and other third-party software, by reading screens, clicking, and typing, the same actions a staff member would take. This approach eliminates the need to transmit PHI into a separate vendor-controlled cloud environment for processing, which directly reduces subprocessor chain risk. The BAA review for this kind of architecture focuses less on a central data repository and more on what the agent stores locally in the form of session logs, screenshots, and caches, how access to the agent's own configuration is controlled, and whether the agent's actions are captured in the audit logs of the practice's existing systems. Because the agent operates through the practice's own login and access structure, the minimum necessary analysis is grounded in the same role-based access controls already applied to human staff: the agent can do what a staff member with that login can do, and nothing more.

Novoflow builds computer-use agents specifically for healthcare operations, including scheduling, prior authorization, claim-denial appeals, and cancellation recovery, and those agents interact with a practice's existing EHRs, payer portals, and third-party software the way a human staff member would, by reading screens, clicking, typing, and navigating. That approach removes the need for API integrations or workflow overhauls. PHI stays inside the systems the practice already governs rather than moving into a new environment to be processed. For multi-location groups, private-equity-managed portfolios, and enterprise health systems, this same architecture scales to highly customized, protocol-heavy workflows across dozens of coordinated agents without altering the underlying compliance posture, since PHI continues to stay inside systems the organization already controls.

Regardless of which architecture a vendor uses, the right question to put to them is not "are you HIPAA-compliant?" That phrase is a marketing claim. The more useful request is to ask for the BAA itself, the SOC 2 Type II report, the subprocessor list, and the model training policy, since those four documents actually verify the claim.

Applying these requirements across a vendor portfolio

The review sequence described above has to be applied across every AI vendor already embedded in a practice's operations, not only at the moment a new tool is being onboarded. Most organizations that have grown quickly carry gaps in their existing vendor agreements that no one has gone back to check.

The highest-risk gap tends to sit in BAAs that were drafted before a vendor added AI features to an existing product. Agreements drafted even two or three years ago often contain language that no longer meets current regulatory expectations, so an annual BAA review is the minimum reasonable cadence for catching these shifts before they become breach findings.

For multi-location groups, practices managed by outside ownership or management entities, and enterprise health systems, the more vendor relationships you have, and the more the tools vary across locations, the harder governance gets. When new AI tools are under evaluation for deployment across multiple locations, the BAA review and the risk assessment should happen once, at the portfolio level, before any single location is allowed to onboard the vendor, rather than repeating the process location by location after rollout has already begun.

Certain provisions require active monitoring well after the contract is signed. Subprocessor change notifications only matter if the organization has a process ready to receive and act on them. The 72-hour incident notification window written into a BAA is only useful if a response process is standing by to receive and act on that notice within the window. If you periodically review AI agent access logs, you confirm that minimum necessary access is being kept up in daily practice, not just promised on paper.

The 2025 proposed Security Rule amendments, if finalized, would add stronger verification requirements for business associates and expand the documented risk analysis obligations covered entities already carry. The practices positioned best already know what their vendors are doing with patient data, and can prove it.