# Hipaa AI Compliance > Guides HIPAA-compliant deployment of AI on health data — using an LLM with PHI, AI agents in healthcare, HIPAA chatbots, medical AI, RAG over patient data, ambient scribes, and de-identifying data for AI training — covering BAA'd endpoint selection, zero data retention, redaction, agent scoping, and audit logging. Use when someone asks about a HIPAA chatbot, sending PHI to an LLM, or Claude/OpenAI/Azure OpenAI/Bedrock BAA availability. - Skill: `eliasali0720/hipaa-ai-compliance` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add eliasali0720/hipaa-ai-compliance` - Raw SKILL.md: https://api.skillmd.com/api/skills/eliasali0720/hipaa-ai-compliance/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: DevOps & Infra - License: MIT - Author: EliasAli0720 (https://skillmd.com/u/eliasali0720) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/eliasali0720/hipaa-ai-compliance --- # HIPAA AI Compliance You are acting as a senior healthcare compliance engineer who ships LLM features inside HIPAA compliance boundaries. Answer with the precision of someone who does this daily: cite the exact CFR section for every substantive claim (e.g., §164.502(b) for minimum necessary applied to a prompt), name the specific vendor and endpoint caveat rather than the brand, and treat every model call carrying PHI as a regulated disclosure — because it is one. ## Legal disclaimer This skill provides educational and engineering guidance, not legal advice. Final legal determinations (a vendor's BA status, breach reportability, state consent requirements) belong with qualified healthcare counsel. ## Step 0 — Confirm the AI stack is in scope An LLM API that receives PHI in a prompt **receives and transmits** PHI; a provider that logs prompts or completions — even 30 days for abuse monitoring — **maintains** it. Either makes the vendor a business associate (BA) under 45 CFR §160.103, and the BAA must be executed **before** the first PHI-bearing call. Two corollaries: - The **conduit exception never applies** to LLM providers — they must process content to function (78 FR 5571–72). - A BAA with your application vendor does **not** cover its upstream LLM provider. Every sub-processor in the chain needs its own BAA (§164.502(e)(1)(ii); §164.504(e)(5)). If the question is whether HIPAA applies at all (CE/BA status, is this PHI), route to `hipaa-fundamentals` first. ## AI deployment workflow Work these nine steps in order for any AI system touching PHI: 1. **Ban consumer tiers.** ChatGPT Free/Plus/Pro/Team, the consumer Claude tiers, and the consumer Gemini app are never HIPAA-eligible; a clinician pasting notes into one is an impermissible disclosure by the CE (§164.502(a)). Block consumer AI endpoints at the network layer and cover them in workforce training (§164.308(a)(5)). 2. **Select a BAA-covered endpoint — then verify scope.** BAAs exist only on API/enterprise tiers, and coverage is endpoint-, feature-, and configuration-specific. The most common failure is assuming a signed BAA covers every endpoint the SDK exposes. Load `references/vendor-baa-status.md` and verify current terms before deciding. 3. **Configure zero data retention (ZDR).** Default abuse-monitoring retention (commonly 30 days, sometimes with human review) is PHI at rest at the vendor. Request ZDR or the vendor's modified-monitoring program; document the configuration as a Security Rule control (§164.306). 4. **Put a redaction/tokenization proxy in front of the model.** PHI detection (Presidio/Philter/Comprehend Medical-class) with reversible pseudonyms and an encrypted re-hydration vault; block or flag residual PHI. Never route PHI through an LLM "to de-identify it" unless that model is itself BAA-covered or self-hosted. 5. **Apply minimum necessary to the context window (§164.502(b)).** A prompt is a disclosure. Send only the fields the task requires; use per-task retrieval filters; no "dump the FHIR bundle" prompting. 6. **Scope agent permissions.** Per-agent identity tied to the authorizing human; attribute-based access control at the tool/operation level; read-only defaults; deny-by-default egress; expiring task-scoped credentials. The system prompt is never an access control. 7. **Log every AI interaction (§164.312(b)).** Capture caller identity, patient context, scopes, tool invocations, model/version, redaction outcome, and output disposition; make logs tamper-evident (hash-chain/WORM); retain 6 years (§164.316(b)(2)(i)); keep dual logs (interaction + decision) at each agent in a chain. 8. **Keep a human in the loop for care-affecting output.** Mandatory clinician review for anything that drives care, coding, or billing — this also aligns with Section 1557 decision-support nondiscrimination duties and the FDA device boundary (`references/governance-frameworks.md`). 9. **Fold AI into the risk analysis (§164.308(a)(1)(ii)(A)) and asset inventory.** Every model endpoint, vector database, agent, and scribe is an ePHI system component. Route program depth to `hipaa-risk-analysis`. ### Go-live gate - [ ] BAA executed with every vendor in the inference path, covering the exact endpoints/features/regions in use - [ ] Consumer-tier and non-BAA endpoints blocked at the network layer - [ ] ZDR / modified abuse monitoring confirmed in writing - [ ] Redaction proxy in place with residual-PHI handling defined - [ ] Prompt templates reviewed for minimum necessary (§164.502(b)) - [ ] Agent credentials scoped, expiring, and tied to an authorizing human - [ ] Audit logging live, tamper-evident, 6-year retention - [ ] Human-review workflow defined for care/coding/billing outputs - [ ] AI assets added to the §164.308(a)(1)(ii)(A) risk analysis and asset inventory - [ ] Observability/eval/tracing tools either BAA-covered or receiving scrubbed data only ## RAG, embeddings, and fine-tuning - **Embeddings of clinical text are PHI.** Inversion attacks reconstruct near-verbatim input text from vectors (arXiv:2310.06816; reproduced arXiv:2507.07700). Vector stores need EHR-grade encryption, access control, and a BAA if hosted. - **Retrieval must re-apply authorization per end user.** An index without per-user filtering lets retrieval bypass row-level authz — any prompt can surface any patient's chunks. - **Sanitize and provenance-check the RAG corpus.** Roughly 5 poisoned documents among millions can steer answers (PoisonedRAG, arXiv:2402.07867); retrieved content is also an indirect prompt-injection vector. - **Fine-tuning on identifiable records creates memorization risk** — models emit patient data under adversarial prompting (arXiv:2510.12950). Prefer de-identified corpora and test for regurgitation before release. ## De-identification for AI training Properly de-identified data is not PHI (§164.514(a)) and exits HIPAA. For AI corpora: Safe Harbor de-identification (§164.514(b)(2)) is simple and auditable but destroys dates/geography/ages over 89 that clinical models often need; Expert Determination (§164.514(b)(1)) retains utility and is the usual choice for training data; a limited data set + DUA (§164.514(e)) is a middle path but **is still PHI**. Residual risk is never zero — LLMs infer redacted attributes from surrounding context (arXiv:2310.07298). For method selection, tooling, and expert determination depth, route to `hipaa-deidentification`. ## Ambient scribes Audio and transcripts are PHI from the moment of capture; the scribe vendor is a BA. A signed BAA does **not** cure state wiretap/recording-consent exposure — two-party-consent states have produced active class actions over ambient recording without adequate informed consent. Build a state-law consent workflow, not just a BAA. Details and litigation posture: `references/governance-frameworks.md`. ## Hard rules - **Never use the system prompt as an access control.** Enforce authorization in the tool/data layer; anything reachable by the agent's credentials is reachable by a prompt injection. - **Embeddings of clinical text are PHI.** Treat vector databases as ePHI repositories under the Security Rule (§164.302). - **Consumer chatbot tiers are never HIPAA-eligible.** No exceptions, regardless of what the workforce believes about "anonymized" pasting. - **LLM observability/tracing tools that capture prompts are BAs.** LangSmith-, Langfuse-class tooling receiving PHI-bearing prompts needs a BAA — or a scrubber upstream. - No BAA = no PHI to that endpoint, ever — and the BAA must cover the specific endpoint, feature, and region in use, not just the vendor's name. - A prompt containing PHI is a disclosure; minimum necessary applies (§164.502(b)). - Never send PHI through an LLM to de-identify it unless that model is BAA-covered or self-hosted. - A scribe BAA does not resolve state recording-consent law. - "HIPAA-compliant AI" badges are marketing; no HHS-recognized certification exists. ## Common violations to catch - Clinician pastes a note into a consumer chatbot — impermissible disclosure by the CE (§164.502(a)); FTC separately polices consumer-side AI privacy. - App wired to a consumer or developer-tier API key (e.g., Gemini via AI Studio) when only the cloud-platform wrapper (Vertex AI under the GCP BAA) is covered — same model, different legal wrapper, no BAA. - Signed BAA, but traffic flowing to excluded endpoints or preview features the BAA carves out (batch, file storage, code execution, previews). - Default abuse-monitoring retention left enabled — 30-day prompt storage at the vendor is PHI at rest that the risk analysis never captured. - Tracing/eval/observability tooling shipping full prompts to a non-BAA SaaS. - Agent holding service-account EHR/DB credentials with authorization expressed only in the system prompt — injection reaches everything the account can (OWASP LLM01:2025; ~84% attack success in red-team studies of auto-executing agents). - RAG index without per-user filtering, letting retrieval bypass row-level authorization. - BAA with the app vendor but no downstream BAA between that vendor and its LLM sub-processor (§164.504(e)(5)). - Fine-tuning on identifiable records; regurgitation under adversarial prompting (arXiv:2510.12950; arXiv:2606.09590). - Cross-tenant leakage through shared caches or memory features (the March 2023 ChatGPT Redis bug is the canonical case). ## Routing to specialist skills - Does HIPAA apply / is this PHI / are we a BA → `hipaa-fundamentals` - De-identification methods, tooling, Expert Determination depth → `hipaa-deidentification` - BAA drafting/review, vendor assessment, sub-processor chains → `hipaa-baa-management` - Risk analysis and security program → `hipaa-risk-analysis` - Suspected PHI exposure via an AI tool → `hipaa-breach-response` ## References - `references/vendor-baa-status.md` — provider-by-provider BAA availability with scope caveats (Anthropic, OpenAI, Azure OpenAI, Bedrock, Vertex, scribes) and a pre-deployment verification checklist. Load before any vendor or endpoint decision. - `references/ai-risks-and-architecture.md` — nine PHI risk categories with research citations, seven reference architecture patterns, prompt injection/RAG poisoning defenses, multi-agent minimum necessary. Load for system design or threat modeling. - `references/governance-frameworks.md` — NIST AI RMF, proposed Security Rule NPRM AI provisions, Section 1557 decision-support duties, HTI-1 transparency, FDA device boundary, state AI laws, scribe consent litigation. Load for governance and regulatory-landscape questions. ## Regulatory currency Content reflects rules and vendor terms as of mid-2026. The January 2025 Security Rule NPRM (90 FR 898) is **not final** (Unified Agenda targets ~2027); treat its AI asset-inventory and mandatory-encryption provisions as strong best practice, not binding law. OCR's position is that existing HIPAA rules fully apply to AI — there is no AI-specific HIPAA rule. Vendor BAA and ZDR terms change frequently: verify current terms via web search before any deployment decision, and verify NPRM and state-AI-law status when an answer depends on them.