The HIPAA AI Compliance Checklist for 2026

There is no such thing as a HIPAA compliant AI product. There is only a covered entity running AI in a compliant way, and the difference matters more than any vendor page will tell you. HHS does not certify software. OCR enforces behavior: your risk analysis, your access controls, your audit logs, your contracts. This checklist is written for healthcare compliance officers who already know the Security Rule and now need to apply it to an AI stack their clinicians are already using. It maps each technical safeguard in 45 CFR 164.312 to the layers of a modern AI deployment, covers what a business associate agreement with an AI vendor actually buys you, and separates what HHS has said from what the market claims it said.

The stakes are not abstract. OCR's annual report to Congress for calendar year 2024 counted 663 large breaches affecting roughly 242.9 million individuals, with hacking and IT incidents driving 81% of them (OCR report summary). Breach volume is the context in which your AI risk analysis will eventually be read.

What HHS has actually said about AI

OCR has not published a rule titled "AI." Three documents do the work instead, and every compliance officer should be able to cite them from memory.

The HIPAA Security Rule, 45 CFR 164.308-164.312. Still the operative text. It is technology-neutral by design, which means an LLM endpoint that stores prompts containing ePHI is just another information system in scope. The five technical safeguard standards in 164.312 apply to your AI stack exactly as written: access control, audit controls, integrity, person or entity authentication, transmission security.

The Security Rule Notice of Proposed Rulemaking, January 6, 2025. The proposed rule would remove the required/addressable distinction and make encryption and MFA mandatory, require a technology asset inventory and network map, and it explicitly names ePHI in AI training data, prediction models, and algorithm data as protected when maintained for covered functions. It also tells regulated entities to fold AI tools into their risk analyses. As of mid-2026 the rule is still proposed and its timeline has slipped, but read it as the direction of enforcement, not as optional.

The Section 1557 Dear Colleague letter, January 10, 2025. OCR's letter on ensuring nondiscrimination through the use of AI applies the ACA's nondiscrimination rule to "patient care decision support tools," explicitly including AI used in clinical decision-making. Covered entities must make reasonable efforts to identify tools that use protected characteristics and mitigate the risk. Different statute than HIPAA, same enforcement agency, same risk register.

The pattern across all three: HHS regulates how you govern the tool, not which tool you bought.

The HIPAA compliant AI checklist: 164.312 mapped to your stack

This is the artifact to keep. Each row maps one Security Rule standard to the AI stack layer where it actually lives, with the check an auditor would run. Use it as your next risk analysis worksheet.

Then the surrounding items the table does not capture:

1. Risk analysis updated for AI. Every AI system that creates, receives, maintains, or transmits ePHI is in the 164.308(a)(1) analysis. The NPRM says this explicitly; do not wait for the final rule.
2. Data flow map per use case. From clinician input through gateway, model, retrieval store, logs, support tooling, and deletion. If you cannot draw it, you cannot defend it.
3. Minimum necessary enforcement. Strip PHI at the gateway where the use case does not need it. Scheduling reminders do not need diagnoses.
4. Prompt and output retention policy. Where do prompts live, how long, who can read them, and do they feed training. Get the answer in writing from the vendor.
5. Model and prompt version register. What ran in production when, so an incident or a malpractice question can be answered with evidence.
6. Eval gate for clinical output. Human review defined before any generated text enters the record. The 1557 letter makes this a nondiscrimination issue, not just quality assurance.
7. Subprocessor inventory. Your AI vendor's cloud, their model provider, their logging stack. Each is a potential subcontractor BA.
8. Incident response runbook with AI cases. Prompt injection, model leak of memorized PHI, vendor breach notification. Tabletop these, not just ransomware.
9. Workforce rules for shadow AI. A clinician pasting a chart into a consumer chatbot is a reportable event under your policies, and your policies must exist and be trained on.
10. Termination plan. If the vendor changes terms or is acquired, how do you export logs, delete retained data, and re-route within your BAA's notice window.

BAAs with AI vendors: what the contract buys and what it does not

A BAA is the entry ticket, not the compliance. It makes the vendor contractually liable for safeguarding PHI and triggers breach notification duties. It does not make your access controls, your logging, your training, or your minimum-necessary enforcement their problem. Those stay with you.

The market has matured since 2023, which makes the details more important, not less. OpenAI now signs BAAs for qualifying API and enterprise healthcare customers through an application process. Microsoft covers Azure OpenAI under the standard Azure BAA in its Data Protection Addendum. Anthropic offers BAAs on enterprise and API arrangements. Consumer tiers of all of these remain out of scope, and that is where the violations happen: the same clinician, the same chart, the wrong login.

Five questions to put to any AI vendor before signature:

• Which exact services, models, features, and regions does the BAA cover, and which are excluded (betas, side tools, console features)?
• Is any customer data used for training or product improvement, and is that opt-in, opt-out, or contractually excluded?
• What is the retention behavior for prompts, outputs, and logs, and can you set it to zero or near-zero?
• Who are the subprocessors, and does PHI leave the United States?
• What are the breach notification timelines, and are they shorter than HIPAA's outer bounds?

If the vendor answers any of these with marketing language instead of contract language, that is your answer.

The case against the checklist

The strongest criticism of articles like this one deserves a fair hearing: checklists produce checkbox compliance, and checkbox compliance is what OCR keeps penalizing.

The critics have evidence. HIPAA has no certification regime, so "HIPAA compliant AI" as a product claim is marketing by construction, and any checklist built around vendor claims inherits the flaw. The deeper argument is that most of the risk is not in the AI stack at all. It is in the workforce. A clinic can pass every row of the table above and still get breached because a physician pasted a discharge summary into a personal chatbot account, an event no technical safeguard catches. On this view, the checklist optimizes the auditable 20% and ignores the human 80%.

A second, sharper version: the correct answer for most AI use cases is not compliance engineering but de-identification. Under 164.514, properly de-identified data is not PHI, and the entire apparatus above becomes unnecessary. Routing a summarization task through a de-identification step is cheaper, safer, and faster to approve than building compliant PHI plumbing. Compliance teams that default to "make the PHI path compliant" instead of "remove the PHI" are solving the harder problem for no clinical gain.

Both points are right, as far as they go. Where they fall short: shadow AI and de-identification are complements to the checklist, not substitutes for it. Some use cases genuinely need PHI, clinical decision support chief among them, and for those the 164.312 mapping is the law, not a preference. And the workforce problem is not an argument against the checklist; it is item nine on it.

Our read

The compliance officers who will do well under the next Security Rule are the ones treating AI as infrastructure, not procurement. A signed BAA and a vendor's SOC 2 report are inputs to your risk analysis. They are not the analysis. Build the controls once at the gateway and identity layer, where every model and every vendor passes through the same chokepoint, and each new AI use case becomes a configuration review instead of a new compliance project. That is what we mean by controls as architecture: the safeguard lives in the path the data must travel, not in a policy PDF.

Also, stop waiting for the final rule to act on the NPRM. Mandatory MFA, encryption everywhere, an asset inventory, AI in the risk analysis: these are cheap relative to one breach, and OCR's 2024 numbers say the threat is already here.

What this means for you

• Run the 164.312 mapping table as a gap analysis this quarter. Nine rows, one hour per row with your platform team. The gaps you find are your 2027 budget request, documented in OCR's own vocabulary.
• Inventory every AI surface with PHI access, including the unofficial ones. Your exposure is the union of the sanctioned stack and whatever clinicians signed up for with a work email. Both are yours under the rule.
• Re-paper your AI vendor BAAs against the five questions above. Coverage scope, training use, retention, subprocessors, breach notice timing. Vendors changed their terms repeatedly through 2025; contracts signed in 2024 may not describe the product you run today.
• Add a de-identification gate to your AI intake process. For every proposed use case, the first question is whether the task can run on de-identified data under 164.514. Most summarization, drafting, and analytics workloads can.
• Update the risk analysis to name AI explicitly. The January 2025 NPRM tells you this is what OCR will look for. A risk analysis that predates your AI deployments is a finding waiting to be written.

For the control-by-control deep dive, see our companion piece on HIPAA 164.312 technical safeguards for AI, the audit trail requirements behind row six, and our AI readiness guide for healthcare providers. If you want a scored baseline before your next OCR-facing review, the Systemics Score measures exactly these dimensions.

Book a free assessment: systemics.ai.

References

1. 45 CFR 164.312, Technical Safeguards. Electronic Code of Federal Regulations, current as of 2026.
2. HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information. Notice of Proposed Rulemaking, 90 FR 898, Federal Register, January 6, 2025.
3. HHS Recent Guidance on AI Use in Health Care. Reed Smith, January 31, 2025 (summarizing OCR's Dear Colleague letter, Ensuring Nondiscrimination Through the Use of Artificial Intelligence and Other Emerging Technologies, January 10, 2025).
4. How can I get a Business Associate Agreement (BAA) with OpenAI for the API Services?. OpenAI Help Center, accessed August 2026.
5. HHS OCR 2024 Breach Report: Healthcare IT Lessons. Datapath, June 2026 (citing HHS OCR, Annual Report to Congress on Breaches of Unsecured Protected Health Information for Calendar Year 2024).
6. Healthcare Data Breach Statistics. HIPAA Journal, updated 2026.
7. HIPAA-Compliant AI APIs: BAA and Architecture Guide. Glass Health, July 2026.