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 comes from how a tool is set up and run — the agreements, where the data goes, who can see it, and the log of everything the AI looked at — not from a sticker on the tool. A practice can put a capable AI system in place compliantly, and can set up 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 enough, because most HIPAA risk lives in how your practice uses the tool: what PHI goes in, who can see what comes out, where transcripts live, and whether anyone can answer those questions six months later.

The setup 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. A clear picture of where the data goes. Where does PHI go, in what form, kept how long, deletable on request? If the vendor can't draw you the picture, you can't defend the setup.

4. Minimum-necessary access. The AI should see the PHI a task needs — not the whole chart, every time. This is a question of how the system was built: systems that hand the AI only what each task needs were built for it; systems that swallow everything were not.

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

6. Rules for the people. Who in the practice can use the tool, from which accounts, and how they prove who they are. 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. a private setup

The consumer tier of the big AI chatbots fails the checklist at step 1 — no BAA, no PHI, full stop (the tier-by-tier detail for the most-asked one is in Is ChatGPT HIPAA compliant?). Enterprise tiers of major platforms can clear steps 1–2, which moves the burden to your side of the checklist: who has access, what the AI is shown, the log, how long data is kept. A private setup — AI running on a server dedicated to the practice, shared with no one else — is the strongest position for steps 3–7, because where the data goes is yours to decide and to check. That's how Edgekeeper is built: a private AI brain on a server we provide, dedicated to your practice and run by us, HIPAA-ready by design, with a BAA from our side, and your data and the brain's memory yours in the contract. What "ready" means: the way it's built clears the checklist; compliance is achieved in how we set it up with you, documented step by step.

What this looks like in a real practice

The same checklist governs every healthcare AI job we set up — 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 set one compliance standard and hold every AI purchase to it, automation platforms included (Zapier, Make, and n8n get their own per-tool answers here). The broader operational picture is on the AI for healthcare practices page.