HIPAA AI compliance checklist: what your team actually needs to implement

Key points

A BAA is necessary but covers only the legal relationship — it does not replace technical safeguards
§164.312 technical safeguards are your responsibility as the covered entity or developer
Safe Harbor de-identification (§164.514(b)) requires removing all 18 identifiers — not just “most” of them
The minimum necessary standard applies to AI prompts: send only what the model needs
Architecture that prevents PHI from reaching the provider is more reliable than any policy

Building AI features in a healthcare context means navigating a compliance surface that’s simultaneously broader and less defined than most teams expect. The HIPAA Security Rule was written before large language models existed, which means applying it correctly requires interpretation — and most guidance circulating online focuses on the wrong things.

This checklist covers what actually needs to be in place. It’s organized by layer: administrative first, then technical, then architectural. Print it out or copy it into your compliance tracker. Each unchecked item is a potential gap.

Layer 1: Administrative and legal

Business associate agreements

You have a signed BAA with every AI provider that processes PHI on your behalf (OpenAI, Anthropic, Google, AWS Bedrock, Azure OpenAI, etc.)
Your BAA explicitly covers the specific endpoints and use cases you’re deploying — a general BAA may not cover fine-tuning or embeddings
You have confirmed your AI provider has BAAs with their subprocessors (GPU cloud, monitoring services, distributed inference networks)
Your BAA specifies data retention limits — default provider retention (30 days for OpenAI) may be acceptable; ZDR (zero data retention) should be considered for PHI workflows
BAA termination and data destruction clauses are specific and enforceable

Privacy policy and workforce training

Your organization’s privacy policy has been updated to reflect AI-assisted processing
Clinical staff and developers who interact with AI features have received HIPAA training covering AI-specific risks (inference logs, prompt injection, data minimization)
You have a documented AI use policy covering permitted use cases, prohibited data types, and escalation procedures

Risk analysis

You have conducted or updated your §164.308(a)(1) risk analysis to include AI components
The risk analysis documents threat agents, vulnerabilities, and likelihood/impact ratings for AI-specific scenarios (PHI in prompts, model hallucination, re-identification from model output)

Layer 2: Technical safeguards (§164.312)

This is where most teams have gaps. The Security Rule’s technical safeguards were written for electronic health records systems, but they apply equally to AI pipelines.

Access controls (§164.312(a)(1))

Unique user identification: every user accessing the AI feature has a unique identifier — no shared service accounts
Automatic logoff: sessions that have access to PHI-adjacent AI features time out after inactivity
Encryption/decryption: all PHI transmitted to AI providers uses TLS 1.2+; keys are managed by your organization
Role-based access: access to AI features processing PHI is restricted to roles that require it

Audit controls (§164.312(b))

This is the section most teams underinvest in.

Every AI request that involves PHI generates an audit record containing: timestamp, user or service account, model/endpoint called, and token counts
Audit records do not contain prompt content — storing PHI in audit logs creates a second PHI store that requires its own safeguards
Audit logs are tamper-evident and retained for at least six years (§164.316(b)(2)(i))
Audit logs are reviewed periodically — not just stored
You can reconstruct what PHI was accessed, by whom, and when — even if you can’t reconstruct the exact prompt

Integrity (§164.312(c))

PHI cannot be altered or destroyed without authorization at any point in the AI pipeline
Tokenization mapping (if used) is stored with integrity controls — the map that translates [PERSON_1] back to a real name is as sensitive as the PHI itself

Transmission security (§164.312(e)(1))

All transmission of PHI to AI providers uses encryption in transit (TLS)
You do not transmit PHI over unencrypted channels at any point in the pipeline (including internal service-to-service calls in the same VPC)
Network segmentation isolates AI processing components from general application traffic where feasible

Layer 3: De-identification (§164.514)

De-identified data is not PHI — it falls outside HIPAA’s scope. Getting this right is the cleanest way to reduce your compliance surface with AI.

Safe Harbor method (§164.514(b)) — the 18 identifiers

For Safe Harbor de-identification, all 18 identifier categories must be removed or transformed:

Expert Determination method (§164.514(b)(1))

Use Expert Determination when Safe Harbor is too aggressive for your use case — for instance, when rare diseases or specific geographic regions are clinically relevant.

A qualified statistical or scientific expert has determined the risk of identification is very small
The expert’s methodology and results are documented

Practical note

Most AI use cases in healthcare should use Safe Harbor as the baseline. If your clinical use case requires dates or geographic precision beyond what Safe Harbor permits, Expert Determination provides a documented path — but it requires a qualified expert, not a self-assessment.

Layer 4: Minimum necessary standard (§164.502(b))

The minimum necessary principle requires that PHI use be limited to the minimum needed to accomplish the intended purpose. Applied to AI, this means being deliberate about what you put in the prompt.

You have defined, for each AI use case, exactly which PHI fields the model actually needs to produce a useful result
System prompts do not include full patient records when only specific clinical context is required
RAG retrieval is scoped — you retrieve the relevant clinical facts, not the full patient history
You do not include PHI in prompts used for testing, evaluation, or prompt engineering — use synthetic data

Common violations of minimum necessary in AI systems:

Putting the full patient chart in the system prompt when only the current visit note is relevant
Embedding entire medical records in a vector store when only summaries are needed
Including patient name and DOB in prompts when the model only needs to answer a clinical question (not identify the patient)

Layer 5: Breach notification readiness (§164.400–414)

You have a documented process for detecting a breach involving AI-processed PHI
You have identified who is responsible for breach notification decisions and communications
Your team knows the 60-day deadline: covered entities must notify affected individuals within 60 days of discovering a breach
For breaches affecting 500 or more individuals in a state, HHS and prominent media notification are also required within 60 days
You have identified your breach threshold — unsecured PHI accessed by unauthorized persons is presumed a breach unless you can demonstrate low probability of compromise
Your AI provider’s BAA includes breach notification obligations to you within a timeframe that allows you to meet the 60-day deadline

Layer 6: Architectural checklist

The administrative and technical layers above protect you on paper. The architectural layer protects you in practice.

The most reliable HIPAA posture for AI is one where PHI never reaches the external AI provider in the first place. If the model never processes patient names, dates, or identifiers, the scope of your compliance obligations shrinks considerably.

Implementation pattern

[Clinical data source]
       ↓
[Intercept layer: detect and tokenize PHI]
  - Names → [PERSON_1]
  - MRNs  → [MRN_1]
  - Dates → [DATE_1]
       ↓
[Tokenized prompt → AI provider]
       ↓
[Response from AI provider]
       ↓
[Rehydrate: replace tokens with real values]
       ↓
[Clinical result delivered to authorized user]

PHI is intercepted and tokenized before leaving your infrastructure
The token-to-PHI mapping is stored in your infrastructure only — never transmitted to the AI provider
The rehydration step is applied only to authorized response paths
De-anonymization audit events are logged with the same rigor as the original access

Privedge implements this pattern as infrastructure — the intercept, tokenize, route, and rehydrate flow runs at the edge before any AI provider call. See the HIPAA use case guide and the healthcare compliance guide for implementation details.

Common gaps this checklist catches

Gap 1: BAA covers the wrong scope. A BAA signed for the Chat API doesn’t automatically cover the Embeddings API or fine-tuning. Check your BAA against your actual usage.

Gap 2: Audit logs contain PHI. Teams sometimes log full prompts “for debugging.” Those logs are now a PHI store requiring their own HIPAA controls, retention limits, and access restrictions.

Gap 3: Fine-tuning on real patient data. Fine-tuning transmits your training data to the provider. Unless you have explicit BAA coverage for fine-tuning data and understand the provider’s data handling for training jobs, this is high risk.

Gap 4: Minimum necessary applied only to storage, not prompts. Teams focus on minimum necessary for database queries but send full patient context to AI models by default.

Gap 5: No breach detection for AI-specific scenarios. Classic breach detection looks for database exfiltration or unauthorized logins. AI-specific scenarios — model inversion attacks, prompt injection that leaks other users’ data, training data extraction — require additional detection logic.

Use this checklist as a living document. AI capabilities and HIPAA guidance both evolve, and the intersection of the two is an area regulators are actively developing guidance for. The OCR (Office for Civil Rights) has signaled increased enforcement attention on AI and health data — treating this as a one-time exercise rather than ongoing hygiene is itself a compliance risk.