AI EHRs and HIPAA: what compliance actually requires

There's no special HIPAA exemption for AI. Covered entities and business associates using AI on protected health information — including an EHR that uses AI to draft notes or handle scheduling — have to meet the same Privacy and Security Rule requirements as any other. Here's what that actually means when you're evaluating an AI EHR, and why some common vendor claims should make you look harder.

This is a category-level explainer, not legal advice. For your practice's specific obligations, talk to a qualified compliance professional.

The foundational point: AI doesn't get a pass

HIPAA's core framework — the Privacy Rule, the Security Rule, and the Breach Notification Rule — was written before modern AI, and it hasn't been rewritten for it. But the foundational principles still apply, unchanged: PHI can only be used and disclosed for permitted purposes, the minimum-necessary standard limits uses, disclosures, and access where it applies, and responsibility for the security of ePHI falls on covered entities and business associates alike, regardless of which technology processes it. An AI vendor is a business associate when it creates, receives, maintains, or transmits PHI on your behalf — the same test that applies to any other vendor, not an AI-specific rule. Where it does meet that test, HITECH means it carries Security Rule obligations directly, not merely by contract.

The practical translation: the same standards that apply to your staff and your software apply to an AI agent. An AI system stepping into a clinical or administrative role does not step out of HIPAA's frameworks. There's no AI exemption.

What compliance requires from an AI EHR

When an EHR uses AI on PHI, these requirements are the baseline:

1. A Business Associate Agreement (BAA). Any vendor that creates, receives, maintains, or transmits PHI on your behalf is a business associate and needs a signed BAA. For AI specifically, a standard BAA may not be enough — it should address whether your data can be used to train models, how long prompts and data are retained, and how subcontractors are handled.

2. Minimum necessary, applied to the AI. Where the minimum-necessary standard applies, an AI system should only access the PHI required for its specific task — an AI handling scheduling doesn't need a patient's full clinical history. The standard governs uses, disclosures, and requests, and it carries exceptions: disclosures for treatment, disclosures to the individual, and uses made under a valid authorization are among those HHS lists as outside it. Within its scope, the principle that limits staff access limits AI access too.

3. Audit controls. The Security Rule requires mechanisms that record and examine activity in systems containing ePHI (45 CFR 164.312(b)); it does not prescribe a particular set of fields. In practice, a strong audit trail captures things like who accessed what, when, and from where, and is complete enough to survive a compliance review. Integrity controls must ensure ePHI hasn't been improperly altered.

4. Encryption, in transit and at rest. Protecting ePHI as it moves and as it's stored is a Security Rule expectation, and the direction of regulation is toward making it explicit.

5. Access controls. Under 45 CFR 164.312(a)(2), unique user identification (no shared logins) and emergency access procedures are required implementation specifications, while automatic logoff is addressable. All of them apply to how the AI is accessed, too.

6. Inclusion in your risk analysis. A Security Risk Analysis is a current Security Rule requirement, and AI tools that process PHI belong in the scope you assess. Separately — and not yet in force — HHS published a Notice of Proposed Rulemaking in 2025 that would make the treatment of AI tools in risk analysis and management explicit. Keep the two categories straight: of the controls above, unique user identification and emergency access procedures are required specifications, while automatic logoff and encryption are addressable. Addressable does not mean optional: you assess whether the specification is reasonable and appropriate for your environment and implement it if it is. If it is not, 45 CFR 164.306(d)(3)(ii) requires you to document why — and to implement an equivalent alternative measure where that alternative is itself reasonable and appropriate. Documenting the decision is part of the path, not a substitute for it. The AI-specific expansion, by contrast, is proposed, and worth tracking rather than treating as settled law.

Why "consumer AI" is a compliance trap

A specific warning worth stating plainly: pasting PHI into a general-purpose consumer AI tool can be an impermissible disclosure. Whether it is depends on the circumstances — whether the tool is acting on behalf of a covered entity or business associate, whether a BAA or another permitted basis is in place, and whether the individual themselves directed the disclosure. What makes the practice risky by default is that consumer tools typically don't offer BAAs, may use input to train models, retain prompts, and lack required security controls, so a well-meaning clinician pasting a patient detail into one usually has no permitted basis to point to. An AI capability that handles PHI has to be built for healthcare from the ground up — not a consumer chatbot pointed at a chart.

The claim to distrust: "HIPAA certified"

Here's a phrase that should make you pause: "HIPAA certified." No official government HIPAA certification exists. HHS and the Office for Civil Rights don't issue or endorse certification programs. Organizations can pursue third-party audits or attestations — SOC 2, HITRUST — to demonstrate program maturity, but those aren't a HIPAA certification, and they don't provide safe-harbor protection from OCR.

So "HIPAA certified" is at best an ambiguous label and at worst a misleading one. A vendor using it may mean a private assessment they genuinely hold — or may mean nothing precise at all. It doesn't necessarily mean they're insecure — but it does mean their compliance language is loose, which is a reason to scrutinize the rest of what they claim. The precise vendors reference the specific framework they actually hold ("SOC 2 Type II," "HITRUST"), not a certification that doesn't exist. Compliance is a program, not a badge.

What to ask a vendor

• Will you sign a BAA, and does it cover model training, data retention, and subcontractors?
• What PHI does your AI actually access, and how is minimum-necessary enforced?
• How is PHI access logged, and can you produce those audit records?
• Is PHI encrypted in transit and at rest?
• Which specific attestations do you hold — and are you naming the framework, or just saying "HIPAA certified"?

Where Zenthea fits

Zenthea is built for the HIPAA reality this post describes: an EHR that uses AI on PHI has to meet the Security and Privacy Rules like any other system, with the clinician kept in the loop. We'd rather point you to the questions above — and encourage you to ask them of every vendor, us included — than reach for a badge that doesn't exist. Compliance in this space is a program you run continuously, not a label you print, and the vendors worth trusting talk about it that way.