Do AI Agents Need a BAA?

Yes, if an AI agent or the vendor running it creates, receives, maintains, or transmits protected health information on your behalf, HIPAA requires a business associate agreement before the agent handles any PHI. The test is not whether the system is AI. It is whether a third party is handling PHI for a covered entity or another business associate. An agent that reads charts, answers patient portal messages, or files claims is doing exactly that, so the vendor behind it is a business associate and needs a signed BAA.

The mistake teams make is treating the BAA as a procurement formality to sort out later. Under HIPAA, disclosing PHI to a business associate without a compliant agreement in place is itself a violation, independent of whether any data is ever mishandled. The paperwork gates the deployment, not the other way around.

When is a BAA required for an AI agent?

Run the decision in two steps. First, does the agent touch PHI at all? Second, who is operating the part of the system that touches it? Answering the first honestly usually means knowing exactly which records the agent can reach, which is a scoping problem before it is a paperwork problem, and one that AI data leak prevention controls are built to settle.

The chain matters. If your agent calls a hosted model and that call carries PHI, the model provider receives PHI and needs to be under a BAA, and any subcontractor it uses needs one too. A BAA with the agent vendor does not automatically cover a downstream model provider unless the flow-down terms and their own agreements account for it. Map the whole path the data takes.

What a BAA for an AI agent has to cover

A HIPAA-compliant BAA has required elements regardless of the technology, but a few take on extra weight when the business associate is running an agent that acts on PHI rather than just storing it.

• Permitted uses and disclosures. Spell out exactly what the agent may do with PHI, and confirm it may not use PHI for anything you have not authorized.
• A no-training clause. This is the one people forget. If the vendor could use your PHI to train or improve its models, that is a use you must control. Get an explicit commitment that PHI is not used for model training absent authorization.
• Safeguards. The business associate must implement administrative, physical, and technical safeguards, which for an agent means access controls, audit logging, and leakage prevention on outputs.
• Subcontractor flow-down. Any subcontractor that touches PHI, including model providers, must agree to the same restrictions.
• Breach notification. Timelines and process for reporting an incident, which matters more when the system acts autonomously and a bad action can compound quickly.
• Return or destruction of PHI. On termination, including PHI held in logs, caches, and vector stores, which agents accumulate quietly.

A BAA is necessary but not sufficient

Signing the agreement satisfies a legal precondition. It does nothing, by itself, to stop the agent from disclosing PHI it should never have surfaced. HIPAA's Security Rule still expects the technical safeguards to be real: access control scoped to the minimum necessary, an audit trail of every PHI access, and integrity and transmission protections. For an agent, those translate into runtime controls, because a crafted patient message or poisoned document can steer an unguarded agent into leaking data that no contract clause would have prevented.

That is the gap the BAA does not close. A vendor can be fully willing to sign, and the agent can still be unsafe if it reaches PHI beyond its task, or repeats one patient's information in another conversation. The contract assigns responsibility; the controls are what actually protect the data. This same pattern shows up wherever agents handle sensitive intake, from clinical documentation to the automated intake conversations that gather patient information before a visit, where scoping and logging matter as much as the paperwork.

How to deploy a PHI-handling agent correctly

1. Map the PHI flow first. Trace every place PHI travels, including the model API, logs, and vector stores, and identify every party that receives it.
2. Sign BAAs across the whole chain. Cover the agent vendor and any subcontractor or model provider in the path, with flow-down terms and the no-training clause.
3. Scope the agent to minimum necessary. Limit it to the specific patients and tools its task requires through AI agent access control, so a failure affects one record rather than the database.
4. Inspect inputs and prevent leakage. Check ingested documents and messages for injection, and apply data-loss prevention to outputs.
5. Log every access immutably. The Security Rule expects audit controls, and the trail is also your evidence during an audit or breach investigation.

For the full Security Rule mapping, see our AI agent security for healthcare page, and HIPAA compliance for AI agents for the controls the rule expects end to end.

The short answer

If a third party handles PHI on your behalf through an AI agent, you need a BAA, and you need it before any PHI moves. Get it across the entire data path, insist on a no-training clause, and then remember that the agreement is the floor. The controls that keep the agent from leaking PHI in the first place are what actually protect your patients.