HIPAA-compliant AI: what it actually requires

Search for "HIPAA-compliant AI" and you'll find a wall of vendors claiming the label. Here's the uncomfortable truth that makes this guide useful: no AI tool is HIPAA-compliant by itself. HIPAA compliance is a property of a deployment — the agreements, data paths, access controls, and audit trails around the tool — not a sticker on the tool. A practice can deploy a capable AI system compliantly, and can deploy a "compliant" vendor's product in a way that violates HIPAA before lunch. This guide is the checklist that actually matters.

Why the vendor label is the wrong test

HIPAA regulates covered entities and their business associates — it doesn't certify software. There is no official "HIPAA-compliant" certification for an AI product. When a vendor says it, they mean some subset of: they'll sign a BAA, they encrypt data, they don't train on your inputs. Those are necessary. They are not sufficient, because most HIPAA risk lives in how your practice uses the tool: what PHI goes in, who can see the outputs, where transcripts live, and whether anyone can answer those questions six months later.

The deployment checklist

1. A signed BAA. Non-negotiable. If the vendor won't sign a business associate agreement, PHI cannot touch the tool. This is the test that rules out consumer AI chatbots immediately.

2. Training-data exclusion. In writing: your data is not used to train models — theirs or anyone's. "We may use data to improve services" is the phrase to hunt for and reject.

3. Data-path clarity. Where does PHI go, in what form, retained how long, deletable on request? If the vendor can't draw the diagram, you can't defend the deployment.

4. Minimum-necessary access. The AI should see the PHI a task needs — not the whole chart, every time. This is an architecture question: systems that route scoped context per task were built for it; systems that ingest everything were not.

5. Audit logging. Every AI interaction involving PHI, logged with what it saw and produced. When the question comes — from an auditor, a patient, or your own compliance officer — the log is the answer.

6. Access controls on the humans. Who in the practice can use the tool, from which accounts, with what authentication. The breach headlines are usually a shared login, not a model failure.

7. Retention and deletion. Transcripts, recordings, and intermediate data on a defined clock, provably deleted.

Public chatbots vs. private deployment

The consumer tier of the big AI chatbots fails the checklist at step 1 — no BAA, no PHI, full stop. Enterprise tiers of major platforms can clear steps 1–2, which moves the burden to your side of the checklist: access, scoping, logging, retention. Private deployment — AI running on infrastructure the practice controls — is the strongest posture for steps 3–7, because the data paths are yours to define and audit. That's the architecture behind our Hosted Private AI: HIPAA-ready by design, BAA from our side, on infrastructure you own. What "ready" means: the architecture clears the checklist; compliance is achieved in how we deploy it with you, documented step by step.

What this looks like in a real practice

The same checklist governs every healthcare AI use case we deploy — insurance verification (PHI in payer data), AI receptionists (PHI in calls), documentation and coordination (PHI everywhere). The practices that get this right don't buy "compliant AI" — they run one compliance posture and hold every AI purchase to it. The broader operational picture is on the AI for healthcare practices page.