The complete guide to HIPAA-compliant AI

What “HIPAA-compliant AI” actually means

HIPAA — the Health Insurance Portability and Accountability Act — does not regulate software. It regulates covered entities (providers, health plans, clearinghouses) and their business associates, and it sets rules for how protected health information is used, disclosed, and protected. A tool cannot be compliant on its own because compliance depends on facts the tool's vendor does not control: who uses it, for what, under which contract, with which safeguards configured.

That is why “HIPAA-compliant AI” is a deployment question, not a shopping question. The same AI product can be part of a compliant deployment at one organization and a violation at another — the difference is the contract scope, the data flows, and whether the required safeguards are actually in place. When a vendor says their AI is HIPAA compliant, the honest translation is “our product can be used as part of a compliant deployment if you do the following things.” The useful question is always: what are those things, and which of them does the vendor handle versus leave to you?

Three documents do most of the work. The HIPAA Privacy Rule governs which uses and disclosures of PHI are permitted. The HIPAA Security Rule sets the administrative, physical, and technical safeguards for electronic PHI. And the Business Associate Agreement is the contract that extends both down the chain of vendors. A compliant AI deployment satisfies all three at once. Most failures happen when one of them is assumed rather than verified.

The BAA: necessary, not sufficient

A Business Associate Agreement is the contract that lets a covered entity share PHI with a vendor. Getting one signed has become easier than most compliance officers expected — major cloud providers sign them, and a growing number of AI vendors will too. The problem is that a signed BAA is not the same as a compliant deployment.

A BAA covers the services described in it — not the vendor's entire product line. HHS is explicit that the agreement defines the scope of the business associate relationship. If your AI vendor's BAA covers an enterprise tier but a staff member uses the consumer plan on the same laptop, the work done on the consumer plan is outside the BAA. If the BAA covers cloud infrastructure but the language model API that processes your prompts is a separate service, your PHI is flowing through an uncovered path. The signature is real; the coverage is not.

The questions worth asking are never “will they sign?” They are: which services are explicitly named, is the AI inference path in scope, and who is the actual entity processing the prompt at inference time. We cover this in depth in BAA-included AI and in what a HIPAA BAA actually covers when AI is involved. For the two questions buyers ask most — about specific consumer tools — see whether ChatGPT can be HIPAA-compliant and the same question for another leading AI assistant.

Where your PHI actually goes

A single AI API call moves through more infrastructure than most buyers picture. Your application sends a request to the AI vendor. The vendor routes it to one or more inference providers — the entities that actually run the model. The response comes back along the same path, often through edge networks and logging systems on the way.

Every hop that touches PHI is a potential business associate. The vendor you contracted with may not be the entity handling your data at inference time. HIPAA's coverage has to follow the data, not the logo on the invoice — which means either your BAA names every entity in the path, or your vendor holds its own BAAs with each of them and your arrangement relies on that chain. A gap anywhere breaks the chain.

This is the single most common place AI compliance quietly fails: the buyer has a BAA with the AI vendor and assumes that covers everything, when the model provider behind the tool was never named anywhere. Ask for the inference path in writing — every entity, what each one does, and which BAA covers it. A vendor that cannot produce that diagram has not done the work. A vendor that holds the BAAs itself, so your one agreement covers the whole chain, has removed the problem rather than handed it to you.

Handling PHI before inference

There are three things you can do with PHI in a prompt before it reaches a model: send it through under a BAA, redact it first, or block the request. All three are legitimate. The mistake is treating redaction as the only safe option.

Redaction is lossy. Strip the identifiers out of a clinical note and you often strip the context the model needs to be useful — and imperfect redaction gives a false sense of safety, because free-text notes carry quasi-identifiers that no scanner catches perfectly. True de-identification under HIPAA's Safe Harbor or Expert Determination methods is a high bar — “we removed the name” does not meet it. For most regulated teams, sending real PHI under a BAA that covers the full path is both compliant and more useful than degrading every prompt.

PHI scanning still matters even when you are not redacting. Scanning is what enforces your organization's policy at the moment a prompt is submitted, flags PHI in a flow that should not contain it, and produces the evidence an auditor will ask for. Scanning is detection; redaction is one action you can take on what is detected. The two are not substitutes — PHI scanning vs. redaction walks through the difference and where each one belongs.

The audit trail HIPAA requires

The Security Rule's Audit Controls standard requires covered entities and business associates to implement mechanisms that record and examine activity in information systems containing PHI. Most AI vendors log API traffic for operational reasons. Very few produce records that meet the integrity bar a compliance officer expects.

The distinction is between application logs and a compliance audit trail. Application logs are built for engineers — they can be searched, modified, and deleted by whoever operates the system. A compliance audit trail is built for regulators: it captures every relevant event, ties each one to a specific user identity, and is tamper-evident, so alteration is detectable rather than silent. For an AI system that means every prompt, every model response, every access event — recorded against a real identity, on a timeline an administrator cannot quietly rewrite.

“We have logs” does not satisfy the standard. “We have tamper-evident, complete, access-controlled records, retained for the required period, that an auditor can verify without trusting us” does. AI with a tamper-evident audit trail covers what that looks like in practice, and why a record an auditor can independently verify is worth more than a vendor's assurance.

The Security Rule, applied to AI

When you put an AI vendor into a workflow that touches PHI, that vendor becomes a business associate — and the Security Rule's Administrative Safeguards are the lens to evaluate it through. The most-cited failure in HIPAA enforcement is not exotic: it is the missing or inadequate risk analysis. Before any PHI moves, someone has to have mapped where it flows, what could go wrong, and what controls address each risk. Deploying AI without that step is the modern version of the oldest mistake in the rule.

The other Administrative Safeguards translate directly into vendor questions. Workforce security and access management: who at the vendor can see PHI, and is that access logged? Security awareness, contingency planning, evaluation: does the vendor actually operate these programs, or just claim them? Business associate contracts: does the vendor hold written assurances from every entity below it? The HIPAA Security Rule and AI vendors works through § 164.308 point by point.

Regulators have not yet published an enforcement action that names an AI tool as the cause of a violation — but that is a lag, not an all-clear. The failures the HHS Office for Civil Rights does penalize — impermissible disclosure to an uncovered vendor, no risk analysis, unmanaged business associates — map exactly onto how AI deployments go wrong. Real HIPAA violations from AI covers what has actually been penalized and how each case maps to an AI failure mode.

How to evaluate a HIPAA AI vendor

Evaluating a HIPAA AI vendor comes down to refusing to accept “it's HIPAA compliant” as an answer. Every claim should resolve to something specific you can check. Does the BAA name the AI inference service, not just the infrastructure it runs on? Does the vendor hold BAAs with every entity in the inference path? Does PHI get scanned against a policy you control before it leaves your environment? Is the audit trail tamper-evident, and can you verify a sample yourself? What can the vendor's own staff see, and is that access recorded?

A vendor that answers each of those with specifics is worth a closer look. One that redirects to a trust badge is not. The 20-point HIPAA AI vendor checklist turns this into a usable scorecard you can take into an evaluation.

Two patterns are worth weighing while you compare. The first: a vendor that has done the PHI handling work itself — owning the scanning, holding the BAAs, building the audit trail — has removed problems from your plate. A vendor that signed a BAA and left the rest as “your responsibility” has only relabeled them. The second: compliance that covers one product surface but not another is a trap. If your team uses AI for chat today and an API tomorrow, the controls should follow you across both.

HIPAA-compliant AI with HASP

HASP is built so a regulated team does not have to assemble the deployment described above from parts. A BAA is included on every paid plan — and HASP holds its own BAAs with the inference providers behind it, so a single agreement covers the full path your PHI takes. There is no separate model provider to chase down and no uncovered hop in the chain.

Every prompt passes through PHI handling before it reaches a model. Your organization sets the policy: allow PHI through under your BAA, redact it before it reaches a provider, or block the request. Scanning runs on HASP-operated infrastructure inside HASP's own compliance boundary — it is not handed to a third party. Every prompt, response, and access event is written to an append-only audit trail that is cryptographically hash-chained and anchored to trusted timestamps, so an auditor can verify the record without trusting HASP's word for it. That record is retained for seven years on every paid plan.

The same controls apply across every way a team uses AI — Assistant chat and document work, Studio internal apps, and the programmatic API — under one contract and one audit trail. If you want to see how this maps to real clinical and practice workflows, AI for healthcare teams covers prior authorization, intake, documentation, and more.