AiAI for Doctors
← All articles
Compliance By the AI for Doctors editors Published Jun 12, 2026 7 min read

HIPAA & AI: A Practical Guide for Doctors

You don't need to become a privacy lawyer. You need to understand one contract and ask five questions. This is that guide.

The fastest way to get burned by an AI tool isn't a dramatic breach — it's a quiet one. You sign up for a scribe or a scheduling bot, you start feeding it patient information, and somewhere in a settings page you never read is a clause letting the vendor keep that data to train its models. HIPAA — the federal law that governs how patient health information is handled in the United States — exists precisely to stop that. The good news for a busy clinician is that you don't have to master the whole statute. You have to get one contract right and learn to interrogate a vendor in plain language.

Everything below is practical guidance, not legal advice — when a contract or a real compliance program is on the line, run it past someone qualified. But for deciding whether an AI tool is even worth a demo, this is enough to keep you out of trouble.

The one contract that matters

The single most important thing to understand is the BAA — the business associate agreement. In plain words: it's a contract that legally binds any vendor handling your patients' protected health information (PHI) to safeguard that data, use it only for the agreed purpose, and answer for it if something goes wrong. PHI is anything that ties a health detail to an identifiable person — a name with a diagnosis, a recording of a visit, an appointment tied to a phone number.

Here's the rule that does the most work for you: if a vendor will touch PHI and won't sign a BAA, you cannot use them. Full stop. It doesn't matter how good the product is or how reassuring the marketing page sounds. "We take security seriously" is not a contract. A signed BAA is. If a tool genuinely never sees PHI — say, it only handles fully de-identified data — that's a different conversation, but assume any clinical AI tool touches PHI until the vendor proves otherwise.

The product demo tells you what a tool can do. The BAA tells you what happens when it does it wrong. Read the second one more carefully than the first.

Where does the data actually go?

A BAA covers the legal exposure. Architecture covers the actual exposure — and the two are not the same thing. The question to keep asking is simple: where does the patient data physically go, and how long does it stay there?

Broadly there are two answers. With cloud tools, the data — audio, transcripts, records — leaves your device and is processed on the vendor's servers. That can be done responsibly under a strong BAA, but every place the data lands is one more place it can be exposed. With on-device tools, the sensitive work happens locally and the raw data never leaves the phone or computer in the first place. You can't breach what was never transmitted. Voti, for example, transcribes medical visits on-device for exactly this reason — privacy by architecture rather than by promise. We unpack the full tradeoff in On-Device vs Cloud AI Scribes.

Neither model is automatically "the safe one." On-device shrinks your exposure; a reputable cloud vendor with a real BAA and a clean retention policy can be perfectly appropriate. What you want to avoid is not knowing which one you've signed up for.

Five questions to ask any AI vendor

You don't need a security questionnaire. Email these five questions before you sign anything, and read how the vendor answers as carefully as what they answer:

  1. Will you sign a BAA? If the answer is anything other than a clean "yes, here it is," stop here.
  2. Where is patient data processed and stored — on-device, in your cloud, or somewhere else? You want a specific answer, not a brochure line.
  3. Do you use our patient data to train your models? The answer you want is "no, never" — or at minimum a clear opt-out that's off by default.
  4. How long do you retain the data, and can we delete it on request? Indefinite retention with no delete path is a red flag.
  5. Who else can access it — subcontractors, sub-processors, support staff? Every additional party should itself be under a BAA.

Red flags

If you see any of these, slow down — or walk away:

  • No BAA, or a vague promise to "send one later." The contract should exist before you upload a single patient's data.
  • Training on your data by default. Your patients' information should never be quietly absorbed into a model.
  • "Military-grade encryption" as the whole answer. Encryption is table stakes, not a compliance program — it tells you nothing about retention, access, or training.
  • No clear way to delete data or close the account. If you can't get the data out, you've lost control of it.
  • Evasive or hand-wavy answers to the five questions above. A vendor that's done this properly answers in one paragraph, not three meetings.
An example of doing this right

Phiclaw — built for the BAA, not around it

Phiclaw is a HIPAA-aligned AI practice-automation agent that runs intake, scheduling and follow-up and connects your EHR, CRM, website and social — on web, iOS and Android. It ships with a signed BAA, so the compliance question is answered before you start.

See Phiclaw
The one-line version

No BAA, no deal — and always know whether your patient data lives on the device or in someone's cloud. This is practical guidance to help you vet tools, not legal advice; loop in qualified counsel before you sign a real compliance program.

Where to start

You now have the whole test: insist on a signed BAA, understand where the data goes, ask the five questions, and watch for the red flags. When you're ready to see tools we'd actually deploy under that bar, they're on the shortlist — and the broader picture of how a privacy-respecting practice fits together is in The 2026 AI Stack for a Modern Private Practice.

Disclosure: Voti and Phiclaw are built by the team behind this publication. We recommend them because we'd run them ourselves; see our editorial standards.