HIPAA Compliant AI: What It Takes and How to Get There

There is no such thing as a HIPAA certified AI tool. A system becomes HIPAA compliant only when three things line up: the vendor signs a Business Associate Agreement (BAA), the tool is configured so protected health information (PHI) is not retained or reused, and your organization has done its own risk analysis, access controls and staff training. If any one of those is missing, the label on the vendor's website does not help you.

This guide is for owners and administrators of practices, clinics, home care agencies, billing companies and other businesses that handle PHI and want to use AI without creating a violation. It covers what the rules say, where companies go wrong, and a practical order of operations.

TL;DR

No software, AI included, carries an official HIPAA certification. "HIPAA-eligible" only means a vendor will sign a BAA and offers controls that can support a compliant setup.
HIPAA has no separate AI rule. The existing Security Rule, Privacy Rule and Breach Notification Rule apply to every AI tool that creates, receives, maintains or transmits PHI.
A BAA is necessary, not sufficient. Configuration, data retention, logging and every component in the AI's workflow matter as much as the signature.
Staff using unapproved AI tools is one of the most common ways PHI leaks. Policy and training have to cover tools you did not buy.
Start with an inventory of where PHI flows, then add AI one narrow workflow at a time.

What "HIPAA compliant" means for an AI tool
HIPAA has no AI rule, so the old rules apply
The BAA: when you need one and what it must say
Where AI deployments actually break HIPAA
A risk analysis built for AI
Checklist for evaluating an AI tool before PHI touches it
Training and shadow AI
Perspective: what we see at Krastor
A sensible order of operations
How Krastor can help
FAQ
Sources

What "HIPAA compliant" means for an AI tool

Compliance is a property of how you use a tool, not of the tool itself. The AWS machine learning team states it plainly: there is no official HIPAA certification for software, and "HIPAA-eligible" is a vendor designation that does not make your implementation compliant. The same post describes a shared-responsibility model: the vendor provides the foundation, while the covered entity performs the risk analysis, configures the security controls and trains staff.

So when a marketing page says "HIPAA compliant AI," read it as a claim about the vendor's willingness and technical capability. Whether your use is compliant depends on what you do with it.

Two terms matter here:

Covered entity: a health plan, clearinghouse or health care provider that transmits health information electronically. Most clinics, dental practices and therapists fall here.
Business associate: a company that handles PHI on a covered entity's behalf. Billing firms, IT providers, answering services and, yes, AI vendors usually qualify.

HIPAA has no AI rule, so the old rules apply

The HIPAA Security Rule sets national standards for protecting electronic health information through administrative, physical and technical safeguards. It was written to be technology neutral, which is why it reaches AI without mentioning it.

In practice, that means an AI system that sees PHI must meet the same expectations as any other system: access control, audit logging, integrity protection, transmission security, and a documented risk analysis.

One thing worth knowing about timing: HHS proposed a major overhaul of the Security Rule in January 2025. According to a July 2026 analysis from the law firm Clark Hill, HHS moved that proposal to its long-term agenda with July 2027 as the anticipated timeframe for final action. Agenda dates are planning estimates, but the takeaway for now is that the current rule is the one you are held to. Build to it today, and expect that a stricter version may arrive later.

The BAA: when you need one and what it must say

If an AI vendor creates, receives, maintains or transmits PHI for you, it is a business associate and you need a signed BAA before any PHI goes in. HHS's guidance on cloud computing makes the same point for cloud providers, and it applies even when the provider only stores encrypted data and does not hold the key. A "no-view" arrangement does not remove the vendor from HIPAA.

A useful BAA for an AI tool should spell out:

What the vendor may do with PHI. It should rule out training models on your data and rule out use for the vendor's own purposes.
Security incident and breach reporting. HHS confirms that a cloud provider must report security incidents involving ePHI to the covered entity, and your BAA can set stricter timelines than the defaults.
Subcontractors. If the vendor passes PHI to another model provider, hosting company or transcription service, that party needs to be bound too.
Return or deletion of data when the relationship ends.
Who handles which security task. HHS advises getting in writing which responsibilities, such as user authentication, sit with you and which with the vendor.

Be wary of the plan tier. Industry write-ups note that many vendors only sign a BAA for enterprise plans with restricted configurations, such as no data retention and no training on your inputs. Turning on a consumer or low-tier account and assuming the BAA covers it is a common trap.

Where AI deployments actually break HIPAA

Most violations are not dramatic. They come from ordinary shortcuts.

Consumer chatbots and free tools

A front desk employee pastes a patient message into a free chatbot to draft a reply. A nurse uploads a visit summary to get it reformatted. No BAA exists, the data may be retained, and you may not even know it happened. HHS's 405(d) Task Group, in its AI-focused guidance, recommends reviewing BAAs for AI data handling and training staff to recognize AI tools in use, including ones nobody approved.

Default settings

The same guidance flags reliance on default vendor settings as a primary risk factor for unauthorized PHI exposure. Defaults are tuned for convenience: chat history on, logs kept, sharing links enabled. Compliance usually requires turning several of these off.

The forgotten parts of the workflow

Modern AI agents are not a single model. A scheduling or intake agent might use a speech-to-text service, a vector database that stores embedded notes, a tracing tool that logs full conversations, and external tools it calls. The Scrutineer write-up on agents notes that your organization is responsible for the whole chain, and that each component touching PHI needs its own coverage. A BAA with the model provider does nothing for a logging tool that stores transcripts in the clear.

The AWS post makes a related point: agentic AI changes what it means for software to touch PHI, because agents work across structured and unstructured data and can take actions, not just return answers.

No monitoring after launch

A setup that was compliant in March can drift by October. Someone adds an integration, a vendor changes a retention default, a model version changes behavior. The AWS guidance describes compliance as something you operationalize through continuous monitoring that maps evidence, such as system logs and access reports, to HIPAA controls. A one-time checklist does not hold.

A risk analysis built for AI

The Security Rule already requires a risk analysis. For AI, extend it so it maps every data flow: what goes into the model, where outputs are stored, which databases hold embeddings or memory, who can view logs, and which outside services get called.

AI also differs from ordinary software in ways that matter for risk. Comments filed with NIST by the Connected Health Initiative note that machine learning systems have complex data dependencies and require up-front risk itemization, with the risk plan updated frequently as model capabilities change. In plain terms: review your AI systems more often than you review your email.

For a leadership-level view of structuring that oversight, this AI governance compliance roadmap lays out a risk-based way to organize it.

Checklist for evaluating an AI tool before PHI touches it

Question	What a good answer looks like
Will the vendor sign a BAA for the exact plan and features you will use?	Yes, in writing, covering the specific product tier
Is your data used to train models?	No, and the BAA says so
How long is input and output retained?	None, or a short, documented window you can control
Who can access your data inside the vendor?	Limited, logged and role-based
Are subprocessors disclosed and bound by BAAs?	A current list, with notice of changes
Can you export audit logs?	Yes, with user, time and action recorded
Where does processing happen?	Documented region or, if needed, your own infrastructure
What is the breach notification timeline?	Stated in the BAA, ideally tighter than the defaults
Are all connected tools covered?	Transcription, storage, logging and plugins included

If a vendor cannot answer these without hedging, treat that as an answer.

Training and shadow AI

Policies fail when people do not know them. Train staff on three things: which AI tools are approved, what may never be entered into an unapproved one, and how to report a mistake quickly. Document the training the way you document security awareness sessions.

The habits matter as much as the rules. Locking down accounts, using individual logins instead of shared ones, and getting signed privacy acknowledgments are basic hygiene in any care setting, as this piece on caregiver data privacy steps shows for in-home care. The same discipline applies when an AI tool is added to the mix.

Perspective: what we see at Krastor

Most of the small and mid-sized businesses we work with are not hospitals. They are specialty practices, home service companies with a health-adjacent line of work, billing and admin firms, and property or hospitality operators that occasionally touch health information. They share a problem: they are buried in manual admin and want automation, but they have nobody whose job is to read a BAA.

Our view is that the safest AI is the AI with the smallest footprint. Before we build anything, we map the workflow and ask a blunt question: does PHI need to enter this system at all? Lead follow-up, invoicing and scheduling can often be automated with PHI stripped out or never collected. Where PHI is unavoidable, we prefer to keep it inside systems you already govern, or to run models in your own environment. That is the reasoning behind private and on-premise AI deployment, and we have written about why regulated industries want control over where their intelligence lives.

We also think compliance should be visible after launch. That is why our engagements include ongoing monitoring rather than a handoff, with no vendor lock-in or tool markups, so you can see what the system does and what it costs. A document in a drawer is not a control.

We are not your lawyer or your privacy officer, and we will say so. Your counsel and compliance lead should sign off on the BAA and the risk analysis. What we do is make the AI side concrete enough for them to review.

— Greyson

A sensible order of operations

Inventory where PHI lives and moves. Systems, spreadsheets, inboxes, phone recordings, and vendors.
Find the AI already in use. Ask staff directly, without blame. Check browser extensions, note-taking apps and meeting transcription tools.
Pick one narrow workflow. Appointment reminders, intake summaries or claim follow-up beats a sweeping rollout.
Decide if PHI is needed. If not, design it out.
Vet the vendor with the table above, then get the BAA signed for the exact plan.
Configure deliberately. Disable retention and training where possible, set role-based access, turn on logging.
Update your risk analysis and policies, then train staff and document it.
Monitor and review on a schedule, and again whenever a vendor, model or integration changes.

The dental front desk is a good example of how narrow scoping helps. We outline what is realistic in our piece on AI at a dental front desk, including the tasks to keep with humans.

How Krastor can help

If you are in the Southeast and want AI in your operations without guessing about risk, we start with a diagnostic to find the costly manual work and see where sensitive data is involved. The Blueprint, from 1500 USD one-off, turns that into a plan you can hand to your counsel or compliance lead. From there we can build and run the system, with monthly reports on costs and savings. You can see the full list on our services page, or use our AI integration checklist to prepare.

FAQ

Is ChatGPT HIPAA compliant?

The free and standard consumer versions should not be used with PHI, because there is no BAA covering them. Some vendors, OpenAI among them, offer business products with a BAA under specific configurations. Confirm the exact product, plan and settings in writing before any patient data is entered.

Is AI prohibited by HIPAA?

No. HIPAA does not ban AI or mention it specifically. The existing Privacy, Security and Breach Notification Rules apply, so you need a BAA with vendors that handle PHI, safeguards on access and logging, and a documented risk analysis.

Does my business need a BAA if the AI vendor only processes encrypted data?

Yes. HHS guidance on cloud services says a provider that stores encrypted PHI without the key is still a business associate. It must meet Security Rule requirements and sign a BAA.

Can I use AI for scheduling or billing without touching PHI?

Sometimes. If the workflow can run on information that is not PHI, such as generic reminders without clinical details, risk drops considerably. Appointment details tied to a patient's identity can still be PHI, so check each data field with your compliance lead.

Is there a HIPAA certification for AI products?

No. No official body certifies software as HIPAA compliant. Terms such as "HIPAA-eligible" describe what a vendor will sign and support, and your organization remains responsible for how the tool is configured and used.