Is AI HIPAA Compliant? A Guide for Medical Practices

The question every healthcare practice asks before it deploys AI is the same one. "Is AI HIPAA compliant?"

The honest answer: no AI model is compliant or non-compliant on its own. The same API call can sit inside a defensible setup in one practice and create a violation in another. The model is not the unit of compliance. The deployment is: the agreements you have with each vendor, how the system is configured, who can access what, and how your team uses it.

That answer is unsatisfying, so here is the version a practice administrator or operations lead actually needs before talking to vendors. It is a framework, not legal advice. Your privacy officer or healthcare counsel should sign off on the specifics.

Who HIPAA applies to

HIPAA applies to covered entities (health plans, clearinghouses, and providers that conduct standard electronic transactions such as insurance billing) and to their business associates. Most medical, dental and chiropractic practices that bill insurance are covered entities.

Veterinary clinics are not. Animal health records are not PHI under HIPAA. Vet practices still have state record-confidentiality rules and ordinary data-security obligations, but the HIPAA framework below does not apply to them.

What HIPAA actually covers

HIPAA protects Protected Health Information (PHI). PHI is broader than most people expect. It includes diagnoses, treatment notes and prescriptions. It also includes appointment times tied to a patient name, insurance information, billing data, photos that identify a patient, and any combination of data that could identify a specific person receiving care.

The compliance question is not "does this AI tool know about medicine." It is "does this tool create, receive, store or transmit information that could identify a patient."

Most operational AI in a practice sits close to that line:

• An AI receptionist that answers calls and books appointments handles PHI the moment a patient gives their name and the reason for the call.
• An automated recall sequence that texts patients about their next visit handles PHI, because the message is tied to a specific person's care.
• Treatment plan follow-up handles PHI.
• A public FAQ chatbot on your website may not, until someone types "should I take my medication tonight."

The architecture has to respect that line.

Two common architectures

There are two broad ways to deploy AI in a practice. Many practices end up with a mix.

Cloud AI under a Business Associate Agreement

Several major AI providers offer certain enterprise or API products that are eligible for a signed Business Associate Agreement (BAA). So do many of the platforms built on top of them.

A BAA is necessary, not sufficient. It is a contract in which the vendor agrees to safeguard PHI, use it only for permitted purposes, report breaches and pass the same obligations to its subcontractors. It does not make your setup compliant. Your practice still owns the risk analysis, access controls, minimum-necessary use, staff training and how the tool is actually configured. Every vendor in the chain that handles PHI needs its own BAA: the AI provider, the voice platform, the CRM, the texting service.

What to verify before you rely on a cloud setup:

1. The BAA is signed and on file. Not a checkbox in a settings panel.
2. The specific product and tier you use is covered. Many vendors cover only certain products.
3. Data retention and training terms are clear. Know whether your data is retained and whether it can be used to train models.
4. Audit logging is enabled and you can access it.
5. Subcontractors that touch PHI are covered by their own agreements.
6. Where the data is stored. Texas now has its own rules on this (see below).

Local models on practice hardware

The other option is a model running on hardware your practice controls. This keeps data off third-party AI services, which simplifies the vendor picture and suits sensitive work such as clinical documentation drafting or analysis of intake documents and reports.

A local model is not automatically compliant either. It removes one category of risk, data leaving your network to an outside AI vendor, but the HIPAA Security Rule still applies in full: access controls, encryption, audit logs, backups, patching and physical security of the machine. A local server with weak access controls is a liability, not a safe harbor. And if any vendor installs, monitors or maintains that system with access to PHI, that vendor needs a BAA too.

The tradeoffs are real. Local models need hardware, setup and tuning time, and ongoing maintenance, and open models can trail the frontier cloud models on some tasks. For many practices that gap does not matter for the workloads that belong on-premise.

Texas rules that sit on top of HIPAA

If your practice is in Texas, HIPAA is the floor, not the ceiling. Three state laws are worth raising with counsel:

• Texas Medical Records Privacy Act (HB 300). Texas defines "covered entity" more broadly than HIPAA and adds its own training and patient-notice requirements. Organizations that are outside HIPAA can still be inside the Texas law.
• SB 1188 (2025). Addresses where electronic health records are stored, including by cloud and other third-party providers, and sets conditions for practitioners using AI in diagnosis, including reviewing AI-generated records and disclosing that use to patients.
• Texas Responsible AI Governance Act (TRAIGA, HB 149). In effect since January 1, 2026. Among other things, it requires health care providers to disclose to patients when AI is used in connection with their care.

The practical takeaway: ask every vendor where data is stored, and plan for patient-facing AI disclosure (on calls, in intake paperwork, on your website) before launch. Have counsel confirm how each law applies to your specific workflows.

How practices typically split the work

An illustrative split, not a rule. Your compliance counsel should confirm each row for your practice.

What to ask any AI vendor before you sign

1. Will you sign a BAA covering the specific product we will use?
2. Where does our patient data go, through which services and subcontractors?
3. Where is the data physically stored, and for how long?
4. Is our data ever used to train models?
5. Can we delete data on demand, with an audit trail?
6. Who at your company can access our data, and under what controls?
7. What happens to our data if we cancel?
8. What audit logs can we show our compliance counsel?
9. How does the system disclose to patients that they are interacting with AI?

If a vendor cannot answer these concretely and in writing, you are looking at a demo, not a deployment-ready system.

A decision framework

• Workflow touches PHI and is routine? A cloud system with a BAA from every vendor in the chain can work. Verify the coverage, the configuration and the logging.
• Workflow touches PHI and is clinical or highly sensitive? Consider a local model, or a cloud setup with tighter controls. Either way, a practitioner reviews the output.
• Workflow does not touch PHI? No BAA is needed, but configure the tool so it cannot collect PHI by accident.
• Not sure? Treat it as PHI until your privacy officer or counsel says otherwise.

Bring counsel into the architecture discussion before a vendor is selected, not after.

Where practices get tripped up

The demo with no BAA behind it. The practice signs, launches, and only later learns the vendor's BAA covers a different product tier than the one in use.

"We'll get the BAA later." The BAA comes before any PHI flows, not after launch.

Treating the BAA as the finish line. A signed BAA with a misconfigured system, shared logins or PHI in text messages is still a problem.

Over-engineering. Putting appointment booking on a local server when a properly contracted cloud service handles it well adds cost without much benefit. The split should be deliberate.

Forgetting Texas. Data location and AI disclosure are now state-law questions, not just HIPAA questions.

How we approach it

We design healthcare engagements with compliance in the first conversation, not as an afterthought. We document the architecture so your privacy officer or counsel can review it, coordinate BAAs with the vendors involved, and, where a workflow calls for it, set up local models through our local LLM installations. Compliance decisions stay with your practice and its counsel.

For the broader picture of operational AI in a practice, see our guide to AI in healthcare. For specialty context, see the pages for DFW dental practices, Frisco medical groups and DFW chiropractors.

The short answer

Is AI HIPAA compliant? The model is not. A deployment can be defensible: BAAs with every vendor that handles PHI, careful configuration, appropriate use of local models for the most sensitive work, and, in Texas, attention to data location and patient disclosure. Without those pieces, it is not.

To see where automation would return the most in your practice, take the AI Opportunity Score. It asks a few questions about your operation and estimates where automation would have the biggest impact, which gives you a concrete starting point for the architecture conversation with your compliance team.