Can a vendor make an AI tool "HIPAA compliant" for me?

No. Compliance obligations attach to the covered entity and its business associates. A vendor can sign a BAA and provide features that help you meet 45 CFR 164.312, but the responsibility for access control, minimum-necessary handling, and audit evidence over your own users stays with you.

Is a signed BAA enough to add an AI tool to the approved list?

A BAA is the entry requirement, not the finish line. It governs how the business associate handles PHI. It says nothing about how your own clinicians and agents use the tool inside your walls, which is where the post-authentication gap lives and where access control under 164.312(a) applies.

What does 45 CFR 164.312(b) actually require for AI tools?

It requires mechanisms that record and examine activity in systems that contain or use ePHI. For AI traffic, that means a record of which identity sent which prompt to which model under which policy, produced independently of the application making the call, and retained long enough to answer an OCR inquiry.

Do ambient scribe tools change the analysis?

They raise the stakes. A scribe ingests an entire encounter, so minimum-necessary under 164.502(b) and audit controls under 164.312(b) matter more than for a tool that handles narrow fields. Confirm what the scribe sends to the model and whether its record of who generated each note survives on your side.

How is this different from HIPAA-compliant AI agent platforms?

The platforms guide names the specific vendors that sign BAAs and host models. This guide gives the criteria you apply to any tool and the categories you assemble, including the access-control and audit layer that governs your own users regardless of which platform sits beneath it.

HIPAA-Compliant AI Tools: The Criteria That Decide Whether a Tool Qualifies

A HIPAA compliance officer building an approved-AI-tools list works from three sections of the Security Rule: business associate agreements under 45 CFR 164.502(e), access control under 164.312(a)(1), and audit controls under 164.312(b). A vendor's "HIPAA compliant" badge speaks to the first and stays quiet on the other two. I want to give you the test I would apply to any AI tool before it touches PHI, then walk the categories of tool a covered entity ends up assembling, because the word "tool" covers products that do very different jobs against the same regulation.

The three-part test for any AI tool

"HIPAA compliant" is not a property a vendor can stamp on a product. The obligations attach to the covered entity and its business associates, and a given tool either helps you meet them or it does not. Three questions settle the matter in order.

First, is there 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 in place before the first prompt carries a patient detail. No BAA means a reportable disclosure the moment a SOAP note enters the context window.

Second, does the tool support access control at the identity level? The technical safeguards at 45 CFR 164.312(a)(1) require access to ePHI to be limited to authorized persons and software, with unique user identification under 164.312(a)(2)(i). A shared API key that any internal service can call fails this outright, because it flattens every caller into one identity.

Third, does the tool produce audit controls? 45 CFR 164.312(b) requires mechanisms that record and examine activity in systems that handle ePHI. A vendor's own API access log records the vendor's view of the call, not your policy state at the moment a clinician sent PHI to a model.

Category 1: General-purpose AI assistants with a BAA

The first tool on most lists is a sanctioned replacement for the ChatGPT tab a clinician was already using. The three hyperscaler model services (AWS Bedrock, Azure OpenAI, Google Vertex AI) all sign BAAs in 2026, and clinician-facing wrappers such as BastionGPT and Hathr AI package a BAA with a chat interface. The vendor-by-vendor detail sits in the companion piece on HIPAA-compliant AI agent platforms; the point here is that a BAA-backed assistant clears question one and leaves questions two and three to you.

Category 2: Clinical documentation and scribe tools

Ambient scribe and documentation tools (the products that turn a recorded visit into a draft note) are the fastest-growing category, and they process the richest PHI in the building. A scribe tool ingests an entire encounter, so the BAA is only the entry ticket. What decides the OCR outcome is whether the tool records which clinician generated which note against which patient, and whether that record survives independently of the tool that produced it. Minimum-necessary under 45 CFR 164.502(b) also applies: a scribe that sends the full chart when the summary needed three fields is over-disclosing by design.

Category 3: The access-control and audit layer

The third category is the one buyers rarely search for by name, and it is the layer that answers questions two and three for every other tool on the list. It sits between your authenticated clinicians and agents and whichever model endpoints they call, evaluates each request against identity and data classification, and writes an independent record of the decision. This is the layer that governs your own people against your own policy, which no vendor BAA does.

The evaluation checklist

Run every candidate tool against this before it joins the approved list:

A signed BAA under 45 CFR 164.502(e), with the covered feature set named in writing.
Unique user identification under 164.312(a)(2)(i), not a shared service credential.
An access-control decision made on the live request, per 164.312(a)(1).
An audit record written independently of the application making the call, per 164.312(b).
Minimum-necessary handling under 164.502(b): the prompt carries only the fields the task needs.
Encryption in transit and at rest under 164.312(e)(2)(ii) and 164.312(a)(2)(iv).

A tool that satisfies the BAA and encryption lines but leaves access control and audit thin is the one that struggles when the Office for Civil Rights asks who sent which PHI to which model under what ruling.

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.

For every decision it commits an 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 evidence 164.312(b) expects your program to hold months after the encounter. DeepInspect does not store your PHI, sign your BAAs, or replace your EHR. It governs one slice: the access-control and audit-trail layer on AI traffic, sitting underneath whichever BAA-covered tools your teams run on. For a healthcare compliance team assembling an approved-tools list against the Security Rule, that slice is usually the part no one has built yet. Book a demo today.