Jun 23, 2026
5 Min
HIPAA Compliant AI: A Framework for Evaluating Tools
How to evaluate any AI tool under HIPAA: map PHI flows, verify the BAA chain, apply minimum necessary, get the training-data answer, demand audit logs.
TL;DR: HIPAA-compliant AI means an AI tool deployed under HIPAA's rules: a signed business associate agreement (BAA), PHI encrypted in transit and at rest, access limited to the minimum necessary, a written answer on whether the vendor trains models on your data, and audit logs that prove all of it. No tool is compliant out of the box. Compliance is a property of how you configure and govern the tool. This guide is a six-step framework for evaluating any AI vendor before patient data moves.
"HIPAA compliant" is on nearly every AI vendor's website, and the phrase alone tells you almost nothing. You need a repeatable way to test the claim, because HIPAA never mentions AI and governs it anyway. (Not legal advice: run your specifics past your privacy officer or a healthcare attorney.)
Vendors Sell HIPAA Eligible. You Build HIPAA Compliant.
There is no official government stamp for HIPAA compliance. HHS does not certify software, does not endorse or recognize private organizations' HIPAA "certifications," and a certification does not absolve a covered entity of its legal obligations, per HHS Office for Civil Rights. When a vendor says "HIPAA compliant," the honest version of the claim is "HIPAA eligible": the vendor will sign a BAA and offers the safeguards a covered entity needs. Whether the deployment is compliant depends on what you do next.
That split is the shared responsibility model. The vendor secures the service: infrastructure, encryption, its own staff. You control who gets access, what data goes in, how staff use it, and whether anyone watches the logs.
That is why you need a HIPAA framework for AI: a fixed set of checks run against every tool, from the voice agent on your phones to the PDF editor at the front desk.
Step 1: Map Where PHI Actually Flows
You cannot evaluate what you have not inventoried. Before any vendor conversation, list every AI tool in use or proposed, then trace the data through it. What goes in: prompts, uploaded documents, call audio, transcripts, chat logs. What comes out. Where each lives, for how long, and who can open it.
Be conservative: treat a call recording that identifies a patient and touches their care or billing as PHI, along with the transcript and the AI summary. Derived data inherits the sensitivity of its source.
Two flows get missed most often:
Shadow AI. Staff pasting patient details into free consumer chatbots nobody approved. No BAA covers those tools, so your framework has to reach software nobody bought.
Embedded AI in tools you already own. Assistants are being switched on inside document editors, browsers, and office suites. Each one is a new PHI flow, which is why whether Adobe Acrobat is HIPAA compliant is now a live question at the front desk.
Map by use case, too. Patient communication tools such as appointment reminders carry their own HIPAA rules around what a message or voicemail may contain.
Turn the Map Into a Risk Assessment
A map tells you where PHI goes; a risk assessment tells you where it can leak. The Security Rule already requires an accurate and thorough assessment of the risks to electronic PHI, per 45 CFR § 164.308(a)(1)(ii)(A), so treat each AI tool as new rows in the risk analysis you already maintain. These exposure vectors show up in nearly every AI evaluation:
PHI exposure vector | How it goes wrong | Mitigation | Step |
|---|---|---|---|
Call recordings and transcripts in the vendor's cloud | Kept longer, and opened by more people, than the job requires | BAA retention and access terms; encryption at rest; audit logs | 2, 5 |
Staff prompts to unapproved consumer chatbots | PHI leaves your control with no BAA and a possible training default | Approved-tools list; bright-line rule; workforce training | 1, 6 |
Vendor model training | Patient data absorbed into models you cannot audit or recall | No-training commitment, or a named de-identification method | 4 |
Subprocessors (hosting, telephony, transcription, model APIs) | PHI sits with a company you have no agreement with | Named subprocessor list; BAA chain verified end to end | 2 |
Over-scoped EHR integration | The AI reads the whole chart when the task needs four fields | Field-level scoping; least-privilege service account | 3, 5 |
AI outputs: summaries, notes, logs | PHI in a summary visible to every login | Role-based access on outputs, not just inputs | 3, 5 |
Messages and voicemails the AI leaves | More clinical detail than the purpose requires | Minimum-necessary message templates, reviewed before launch | 3 |
Offboarding | Your data lingers in a former vendor's storage | Contractual deletion, with evidence, at contract end | 2, 4 |
Score each row against each tool on your map for likelihood and impact. The high-risk rows become your first vendor questions.
Step 2: Verify the Whole BAA Chain
A business associate agreement makes an AI vendor legally accountable for your PHI: safeguard the data, use it only for the services you hired them for, report breaches. Any vendor that creates, receives, maintains, or transmits PHI on your behalf needs a signed BAA before the first byte moves; that four-verb test is the regulatory definition of a business associate, per 45 CFR § 160.103. No BAA, no pilot.
The BAA you sign is only the first link. Almost every AI product sits on other companies' services: a model provider, cloud hosting, telephony, transcription. HIPAA extends downstream: a business associate may hand PHI to a subcontractor only after obtaining written satisfactory assurances that the subcontractor will safeguard it, per 45 CFR § 164.502(e). Ask the vendor to name its subprocessors and confirm coverage end to end.
Read the AI-specific terms, not just the boilerplate: whether prompts, recordings, and outputs can be used for "product improvement," what retention applies, and what happens to your data when you leave.
Finally, breach notification. After a breach of unsecured PHI, affected individuals must be notified without unreasonable delay and no later than 60 calendar days after discovery, per 45 CFR § 164.404; breaches involving 500 or more individuals are reported to HHS at the same time, smaller ones in an annual log filed within 60 days of year end, per 45 CFR § 164.408. Your BAA should require vendor notice fast enough to meet those deadlines, and name who calls whom.
Step 3: Hold Every Tool to the Minimum Necessary Standard
The Privacy Rule requires covered entities and business associates to make reasonable efforts to limit PHI to the minimum necessary to accomplish the intended purpose of a use, disclosure, or request, per 45 CFR § 164.502(b). Applied to AI, it does most of the compliance work by forcing one question: what is the least data this system needs to do its job?
A scheduling agent needs a name, a callback number, appointment context, and insurance details. The full chart stays out of scope. A billing follow-up tool needs the balance and the visit date; the clinical notes stay closed. Purpose limitation is the contract version: data collected to book appointments cannot quietly become data for anything else.
Push vendors on the mechanics:
Can the integration be scoped so the AI reads only the fields it needs rather than the whole record?
Are outputs access-controlled by role, so a summary containing PHI is not visible to every login?
Does the system filter or redact stray PHI, like a diagnosis volunteered in a transcript that only needed a reschedule?
A vendor with real healthcare experience answers these in specifics. Push again if what comes back is "our platform is fully secure."
Step 4: Get the Training-Data Answer in Writing
One question separates consumer AI from healthcare-grade AI: does the vendor train its models on your data? Many consumer tools do by default: OpenAI may use consumer ChatGPT content to train its models unless you opt out, per OpenAI's data-usage documentation, and Google's consumer Gemini apps use saved conversations, with human review, to improve its services, per Google's Gemini Apps privacy notice. Patient data flowing into model training is a use of PHI nobody signed up for, and the fastest way to fail this framework.
The acceptable answers are narrow. Either the vendor commits contractually to not training on your data, or training happens only after de-identification that meets one of HIPAA's two recognized methods: Safe Harbor, which removes the enumerated identifiers, or Expert Determination, where a qualified expert determines and documents that the re-identification risk is very small, per 45 CFR § 164.514(b). "We anonymize it" is not one of them. Make the contract name which method applies.
Retention rides along: how long are recordings, transcripts, and prompts kept, can you set the window, and what is deleted (and evidenced) when you offboard? For a deeper treatment of prompts, model behavior, and PHI, see our guide to HIPAA-compliant generative AI.
Step 5: Demand Audit Logging and Technical Safeguards You Can Inspect
The Security Rule requires safeguards across administrative, physical, and technical categories, per 45 CFR Part 164, Subpart C. For an AI evaluation, three technical checks carry most of the weight.
Access control. Unique logins, role-based permissions, multi-factor authentication. Least privilege applies to the AI itself as much as to staff: its service account should hold the narrowest EHR permissions that still let it work.
Encryption. In transit and at rest, everywhere PHI lives, including recordings and transcripts in the vendor's storage. Non-negotiable.
Audit logging. For AI systems, this is the load-bearing safeguard. Every conversation, every record the AI read, every booking it wrote to the EHR, every human who opened a transcript: logged with who, what, and when, and exportable. Without logs you cannot investigate an incident, answer a patient's accounting request, or prove minimum necessary is holding. Ask to see the audit trail for a sample interaction; if the vendor cannot produce one, the safeguard does not exist.
Ask for the report itself: a SOC 2 report or an ISO 27001 certificate means an outside auditor has checked the controls. Confirm a defined path for the AI to hand off to a human.
Want the compliance homework already done? Central's AI front desk for healthcare is HIPAA compliant with a signed BAA, SOC 2 audited and ISO 27001 certified, encrypts data in transit and at rest, and doesn't train AI models on your data. Book a demo, or hear it live: +1 (833) 545-5994.
Step 6: Extend HIPAA Awareness Training to Cover AI
HIPAA requires you to train every workforce member on your PHI policies, bring new hires in within a reasonable period, and retrain when policies materially change, per 45 CFR § 164.530. Those policies have to exist in writing. The Security Rule adds a security awareness and training program, per 45 CFR § 164.308(a)(5). AI does not change the obligation; it adds new material.
Fold AI into your existing HIPAA awareness training. Staff need to know four things cold: which AI tools are approved, what may never be pasted into anything unapproved, how to recognize an AI-related privacy incident, and where to report one. This is the control that stops shadow AI, because policy without training is just a document.
Decide the patient-facing questions, too: how the practice discloses that an AI answers calls or sends messages, and whether your privacy notice needs updating or any consent applies, including under state AI-disclosure laws — Utah, for example, requires anyone providing the services of a state-licensed occupation to prominently disclose when a person is interacting with generative AI, verbally at the start of a call and before a written exchange, per Utah S.B. 149 (2024). Write the disclosure line before the tool goes live and put it in the call script.
The Framework on One Page
Run every AI tool, current or proposed, through this scorecard:
Every PHI flow mapped, including transcripts, summaries, and logs?
BAA signed before any PHI moves?
Subprocessors named, BAA chain covered end to end?
Contract addresses AI-specific uses: product improvement, retention, offboarding deletion?
Breach notification duties and timelines written down?
Data access scoped to the minimum necessary for the use case?
Training-data answer in the contract, de-identification method named if any training occurs?
Role-based access controls with MFA, for humans and for the AI's own credentials?
PHI encrypted in transit and at rest, with SOC 2 or ISO 27001 evidence?
Vendor can show a complete audit trail for a sample interaction?
Defined human-escalation path?
Staff trained on approved tools, banned uses, and incident reporting?
Twelve yeses and the tool earns a pilot. Any no is a conversation with the vendor before it becomes a conversation with a regulator.
Applied to a real category: an AI front desk answers patient calls and chats around the clock, verifies insurance on the line, and books into the EHR, so it touches PHI on nearly every interaction. Full disclosure: Central is our product, so hold us to the same bar: HIPAA compliant with a signed BAA, a SOC 2 report and ISO 27001 certification, encrypted in transit and at rest, and we don't train AI models on your data. The same scorecard applies whether you are comparing medical answering services or anything else that wants a seat near your patients' data.
What Failure Actually Looks Like
Vendor A is invented for this walkthrough. It is not a real company, and the answers below are the kind you should expect to hear when you run the scorecard for real.
A four-provider orthopedic group runs the framework on Vendor A, an AI phone agent that would answer overflow calls, book appointments, and text intake forms. Most of the twelve items pass. Three do not.
The subprocessor list has a hole. Vendor A signs the BAA, and its list names a cloud host and a transcription provider. The model API behind the AI summaries is missing from it. Get that in writing before the pilot.
The default integration is over-scoped. The standard build asks for read access to the full chart, because that is easier to ship. The job needs name, date of birth, appointment history, and coverage. Scope it down or walk.
Sales and the contract disagree. Sales says "we don't use your data." The contract says "aggregated product improvement." Only the written one counts.
One more gap is internal. The flow map catches two staff pasting patient questions into a free chatbot to draft replies, and no policy covers it. Write the rule, then run a short session at the next staff meeting.
Three vendor gaps and one internal fix, all of them settled before PHI moves.
FAQ: HIPAA-Compliant AI
What makes an AI tool HIPAA compliant?
An AI tool is HIPAA compliant when its deployment is compliant: a signed BAA, PHI encrypted in transit and at rest, access scoped to the minimum necessary, a contractual answer on model training, complete audit logs, and trained staff under written policies. Remove any one and the claim fails, whatever the marketing page says.
What is a HIPAA framework for AI?
A repeatable set of checks a practice runs before adopting any AI tool that might touch PHI, so nothing slips in on the strength of a demo. The six steps and the twelve-point scorecard above are one version you can use as written.
Is there an official HIPAA certification for AI tools?
No. HHS does not certify products, does not endorse or recognize private HIPAA certifications, and a certification does not absolve a covered entity of its obligations, per HHS Office for Civil Rights. Third-party audits like SOC 2 and ISO 27001 are real evidence to weigh inside your own evaluation.
Do we need a BAA with every AI vendor?
With every vendor that creates, receives, maintains, or transmits PHI on your behalf. A tool that genuinely never touches PHI does not need one. The trap is tools adopted for non-PHI work that drift into patient data; the flow map catches those.
Can staff use free consumer AI chatbots at work?
Not with patient information. Free consumer plans generally do not come with a BAA. OpenAI, for example, offers BAAs only for its API and sales-managed ChatGPT Enterprise or Edu accounts, per OpenAI's BAA policy. Many consumer tools also use inputs for model training unless you opt out, per OpenAI's data-usage documentation. The workable policy is a short approved-tools list plus a bright line: nothing identifying a patient goes into anything off the list.
What HIPAA awareness training do staff need before using AI?
The same required privacy and security training, extended to cover AI: the approved-tools list, banned uses (starting with pasting PHI into consumer chatbots), handling AI outputs that contain PHI, and reporting a suspected incident. Refresh it whenever the approved-tools list changes.
Who should run this evaluation in a small practice?
Your designated privacy official, even when that is the practice manager wearing a second hat. HIPAA requires a covered entity to designate a privacy official, per 45 CFR § 164.530(a)(1), and to identify a security official, per 45 CFR § 164.308(a)(2). The manager can handle the flow map, the minimum-necessary questions, and the workforce training; hand the BAA and the subprocessor terms to whoever reads your contracts. Nobody needs to be a security engineer to ask a vendor for an audit trail.
Run the Framework Before the Pilot
AI is worth adopting. Treat the compliance work as the buying process itself, and run every tool through the scorecard before patient data moves.
See the framework pass in practice. Central's AI front desk for healthcare answers every call and chat 24/7, verifies insurance and copay on the line, and books straight into your EHR: HIPAA compliant with a BAA, SOC 2 audited and ISO 27001 certified, and it never trains AI models on your data. Book a demo, or hear it live: +1 (833) 545-5994.
