HIPAA-Compliant AI Agent Platforms: BAAs, Access Control, and Audit Evidence

57% of healthcare professionals use unauthorized AI to process PHI, including SOAP notes and diagnostic plans, without a Business Associate Agreement in place, per Cloud Radix. That number describes a clinician pasting a patient encounter into a chat window at 7pm between appointments, on a tool the covered entity never contracted for. When a compliance officer starts shopping for a sanctioned replacement, the search term is usually "HIPAA-compliant AI agent platforms," and the results mix two very different kinds of product. I want to separate them, because the label "HIPAA compliant" carries less weight than most buyers assume.

What HIPAA compliance requires from an AI platform

A vendor cannot make a platform "HIPAA compliant" as a product property. HIPAA obligations attach to the covered entity and its business associates, and the platform either helps you meet them or it does not. Three requirements decide whether a given platform helps.

The first requirement is a signed Business Associate Agreement. Under 45 CFR 164.502(e), any vendor that creates, receives, maintains, or transmits PHI on your behalf is a business associate and needs a BAA before it touches PHI. No BAA means the moment a diagnostic note enters the prompt, you have a reportable disclosure.

The second requirement is access control. The Security Rule's technical safeguards at 45 CFR 164.312(a)(1) require you to permit ePHI access only to authorized persons and software, with unique user identification under 164.312(a)(2)(i). A shared API key that any service can call fails this standard because it collapses every caller into one identity.

The third requirement is audit controls. Under 45 CFR 164.312(b), you need mechanisms that record and examine activity in systems that contain or use ePHI. Encryption sits alongside these as an addressable specification at 164.312(a)(2)(iv) for data at rest and 164.312(e)(2)(ii) for transmission. A HIPAA program that satisfies the BAA and the encryption line but leaves 164.312(a) and 164.312(b) thin is the one that struggles in an OCR review.

The model platforms that sign BAAs: Bedrock, Azure OpenAI, Vertex AI

The three hyperscaler model platforms all sign BAAs in 2026, and they are the foundation most healthcare AI agents run on.

AWS Bedrock is a HIPAA-eligible service. You accept the AWS business associate addendum in AWS Artifact at no cost, and it covers Bedrock-hosted models like Claude when you deploy in BAA-eligible regions with the right configuration. Azure OpenAI is covered under Microsoft's standard HIPAA BAA once you are on a qualifying agreement. Google Vertex AI falls under the Google Cloud BAA, which extends to the Gemini family accessed through Vertex.

The caveat that sinks first-time reviews is that BAA coverage is feature-specific and configuration-dependent. A model endpoint may be covered while a preview feature, a logging option, or a sub-processor in the chain is not. Signing the addendum is the start of the diligence, and the boundary of what it covers is where the reading has to be careful.

Healthcare-built tools that advertise HIPAA compliance

A second tier of products wraps those model APIs in a clinician-facing interface and sells the BAA plus a HIPAA posture as the core offer.

Hathr AI runs Claude inside AWS GovCloud in a FedRAMP High environment and includes a signed BAA on every plan, which fits organizations handling Controlled Unclassified Information or federal work. BastionGPT runs on Microsoft Azure, holds HITRUST CSF certification and a SOC 2 Type II attestation, offers GPT, Claude, and Gemini model options, and signs a BAA on every plan. CompliantGPT markets itself to clinician documentation workflows on the same premise of a signed agreement and a HIPAA posture; confirm its current BAA terms and hosting directly, since the smaller tools iterate faster than their marketing pages.

These tools solve a real problem for a solo practice or a clinic that wants a sanctioned chat surface fast. My honest opinion is that the BAA checkbox is the most oversold artifact in healthcare AI procurement, because it answers one question (is there a contract) and stays silent on the two that OCR actually probes.

A signed BAA leaves the access-control and audit gap open

Here is the part the platform sales motion skips. When your model vendor signs a BAA, it accepts responsibility for how it, the business associate, handles PHI. It says nothing about how your own clinicians and agents use the tool inside your walls.

Consider how the request actually flows. A logged-in physician's assistant sends a prompt containing a full patient chart to a model the covered entity approved for de-identified summaries only. Authentication succeeded and the BAA is in force, yet the disclosure still happened, and it happened above the layer any vendor BAA governs. This is the post-authentication gap: identity at login stops traveling with the request by the time it reaches the model. The same gap widens when an AI agent acts on a service credential, because the audit trail records the service account rather than the person who delegated the task. I walk through carrying user identity onto each downstream call in the piece on AI agent identity management.

The model provider's logs make this worse for an auditor, because they belong to the provider and record the provider's view of the API call. They lack the covered entity's policy state at the moment of decision, and they are written by the same system whose behavior is under review. 45 CFR 164.312(b) expects your audit controls over your ePHI activity, produced independently of the application making the call. A vendor invoice-style access log answers a different question. The requirements a BAA has to spell out, and the residual obligations that stay with you after signing, are covered in HIPAA BAAs for AI vendors.

So the shortlist for a healthcare AI agent program has two layers. The BAA-signing model platform or clinical tool is one. An access-control and audit layer that governs your own users and agents against your own policy is the other, and it is the layer buyers most often assume the BAA already covered.

DeepInspect

This is the gap DeepInspect closes. DeepInspect is a stateless proxy that sits inline between your authenticated clinicians and agents and the LLM endpoints they call, whether that endpoint is AWS Bedrock, Azure OpenAI, Google Vertex AI, or a self-hosted model. For every request it evaluates who is asking, what role they hold, what data classification is in play, and organizational policy, then returns a pass or block decision before the prompt reaches the model. Enforcement runs under 50 milliseconds in internal testing, invisible against the 500 milliseconds to several seconds a model takes to respond. That is the 164.312(a) access-control decision made on the live call instead of assumed.

For every decision it commits a per-decision, identity-bound audit record before the response returns, written by something other than the application that made the call. That write-path independence is what turns a log into the kind of evidence 164.312(b) expects your program to hold, months after the encounter, when someone asks who sent which PHI to which model under what ruling.

Two boundaries belong on the record here. DeepInspect does not store your PHI, it is not an EHR or a covered-entity system of record, and it does not encrypt data at rest inside your systems, which stays your responsibility and your vendors'. It also does not sign your BAAs for you. It governs one slice: the access-control and audit-trail layer on AI traffic, sitting underneath whichever BAA-covered platform your agents run on. For a healthcare compliance team building an AI agent program against the Security Rule, that slice is usually the part no one has built yet. Book a demo today.