Can a practice legally use AI? The HIPAA answer in plain English

This is the second question every practice owner asks, right after "what does it cost." It usually arrives in a slightly anxious tone, because the honest state of most people's understanding is "I know there are rules, I know they're serious, and I don't know where the line is."

Here's the line, without lawyer words. This is a practical explanation, not legal advice — get your own counsel before you sign anything. But you should be able to hold the shape of it in your head.

HIPAA does not mention AI, and it doesn't need to

The rule predates all of this and has held up better than most technology law, because it was written about information rather than about technology. Three ideas carry the whole thing:

One: anyone who handles protected health information on your behalf must be under a business associate agreement. A BAA. It's a contract that binds a vendor to protect the information and makes them liable if they don't. This applies to your billing company, your cloud backup, your practice management software — and to any AI tool that sees patient information. Nothing special about AI here. It's just another business associate.

Two: minimum necessary. Share only the information required to do the job. This one is chronically under-applied, and I think it is the most useful principle in the whole rule. I will come back to why.

Three: you have to be able to show who accessed what. Access controls and audit logs. Without a record of what a system did and what it saw, you cannot demonstrate compliance. "We're fairly sure it was fine" has never worked as a defence.

That is the whole substance of it, and AI fits inside it without much trouble.

The one question that decides everything

"Will you sign a business associate agreement?"

Ask it first, before the demo, before the pricing conversation. If the answer is no, that tool cannot touch patient information, no matter how impressive it looked and no matter how much your office manager loves it. There is no clever workaround and no acceptable level of "we'll be careful."

The wrinkle worth knowing: several very popular AI products answer no on their consumer and free tiers and yes on their business or enterprise tiers. Same brand, same model, same interface, completely different contractual position. This catches out a lot of well-run practices, because someone tried it on a personal login, it worked beautifully, and the practice rolled it out without anyone re-asking the question at the point where it became official.

The risk that's already in your building

Here's the part I'd worry about more than any vendor.

Somewhere in most practices, someone is quietly pasting patient details into a free AI tool. Not maliciously — the opposite. They're trying to draft a letter faster, or summarize a long note, or work out how to word a difficult message to a patient. It makes their day better and they have no idea they've done anything wrong.

That is the single most common real HIPAA exposure involving AI right now, and it has nothing to do with any system anybody bought. It's also the cheapest to fix. You need two things:

1. A sanctioned tool that's covered by a BAA, so the useful thing your staff wanted to do is available to them legitimately.
2. A one-paragraph written policy naming that tool and saying plainly that patient information doesn't go anywhere else.

Banning it outright without providing a sanctioned alternative doesn't work. People found it useful; they'll just stop telling you.

Minimum necessary is an architecture decision

This is the part that gets skipped, and it's where the real safety comes from.

The most secure design is the one where the sensitive data was never in the pipe at all. Encryption around it is a distant second.

An AI that books appointments needs a name, a phone number, a reason for the visit, and your schedule. It does not need a medical history. An AI that answers billing questions needs a balance and a payment link. It does not need clinical notes. An AI that fills your unscheduled treatment list needs a procedure code and a patient contact. It does not need the chart.

When someone designs one of these systems properly, most of the compliance risk evaporates before any security control is applied, because the risky information simply isn't there to leak. When someone designs it lazily — pipe everything in, let the model sort it out — you inherit a permanent problem that no amount of policy will cover.

This is the single best question to ask whoever is building your system: what does it not have access to, and how do you know?

If you can't draw it, it's wrong

Every system we build ships with a one-page data map: each piece of information, the systems it passes through, who can see it, how long it's kept, how it gets deleted.

That document isn't compliance theatre. It's a design test. If it can't be drawn simply on one page, the architecture is too tangled to reason about, which means nobody can honestly promise anything about it. When the map is complicated, we change the system, not the map.

Ask any vendor for theirs. The speed and confidence of the response tells you almost everything.

A few things people get wrong

"It's fine, the data is anonymized." Usually it is not. Names and dates of birth are the obvious identifiers, but the rule lists eighteen, and a date of service plus a zip code plus a rare condition will re-identify somebody comfortably. Treat "anonymized" as a claim to check rather than a state to assume.

"The vendor is HIPAA compliant." Arrangements are compliant. Companies are not. A vendor perfectly capable of a compliant setup can still be sitting in a non-compliant one, because nobody signed the BAA or somebody enabled a feature that ships data somewhere else. Ask what your specific configuration does.

"We'll deal with the privacy piece at the end." This is the most expensive mistake on the list, because it means discovering at the final meeting that the whole approach has to change. Handled at the start, privacy costs nothing. Handled at the end, it is a rebuild.

"Recording calls is fine, it's for quality purposes." Several states have consent rules that go further than HIPAA on recorded calls, and a few now have specific requirements around disclosing that a caller is speaking to an AI. Check your state. Disclosure should be standard in anything you deploy anyway — patients care far less than people expect, and the ones who do care deserve to know.

---

The privacy answers for your specific setup — state rules, vendors, existing tools, what your staff are already doing — are part of the audit, in writing, before anything is built. Or read how we approach HIPAA-compliant AI.