An LLM is not HIPAA compliant by itself. A model can be used inside a HIPAA-regulated workflow only when the full system around it—contracts, infrastructure, applications, data flows, configuration, access controls, operations, and users—satisfies the applicable requirements.
That is why asking whether GPT, Claude, Gemini, or an open-source model “is HIPAA compliant” is incomplete. The same model can sit behind a consumer chat product, a covered enterprise service, a healthcare-specific workspace, or a self-managed application. Those deployments do not have the same legal or technical boundaries.
Evaluate the system, not the model name
The model is one component in a longer chain. Patient information may pass through a browser, mobile app, authentication provider, API gateway, PHI detection layer, model endpoint, database, logging service, analytics tool, support system, and EHR integration. Any component that creates, receives, maintains, or transmits ePHI on behalf of a regulated organization may affect the compliance analysis.
HHS does not certify or endorse particular cloud products. Its cloud guidance instead focuses on the relationship, BAA, risk analysis, safeguards, and actual handling of ePHI. A marketing label attached to the underlying LLM cannot replace that system-level review.
1. Contractual coverage and the BAA chain
A covered entity or business associate generally needs an appropriate BAA with a cloud provider that handles ePHI on its behalf. The agreement must cover the service actually being used, and business associates must extend the required restrictions to relevant subcontractors.
Model vendors often limit BAA coverage to named products, account configurations, endpoints, or features. OpenAI, for example, publishes a list of HIPAA-eligible products and ties API eligibility to specified retention configurations. Anthropic publishes separate coverage tables for Enterprise, API, Claude Code, connectors, and beta features. Procurement should archive those boundaries with the executed agreement.
2. A complete PHI data-flow map
The prompt is only the visible start. A defensible architecture records every place PHI can enter, move, persist, or reappear:
- typed prompts, audio, images, scanned documents, and imported records;
- temporary processing, queues, caches, model inputs, and generated outputs;
- application databases, logs, monitoring, support tools, and backups;
- web search, connectors, actions, MCP servers, and other third-party calls;
- exports to an EHR, file store, email, patient portal, or local device;
- deletion, incident investigation, and data returned after contract termination.
The review should identify the responsible party, permitted purpose, retention period, access path, encryption boundary, and contractual coverage for each stage.
3. De-identification and tokenization are layers, not exemptions
Removing or replacing identifiers before model processing can reduce exposure. A tokenization layer may substitute names, dates, record numbers, and other detected identifiers, then restore them after the model returns a response. That architecture can limit what the underlying model sees.
It should not be presented as perfect. Detection can miss context, attachments may follow a different processing path, and aggressive removal can reduce clinical usefulness. The system needs documented scope, representative testing, failure handling, monitoring, and an honest explanation of what remains visible to each provider.
4. Encryption does not remove business-associate obligations
Encryption protects confidentiality in transit and at rest, but it does not address every requirement. HHS states that a cloud provider maintaining encrypted ePHI can still be a business associate even if it does not hold the decryption key. Integrity, availability, authentication, contingency planning, and administrative safeguards still matter.
A useful architecture description therefore names where encryption starts and ends, who holds keys, where plaintext exists during processing, how secrets are managed, and which people or services can access administrative tools.
5. Identity, access, retention, and audit controls
- Organization-managed identities and appropriate authentication.
- Role-based permissions and least-privilege access.
- Documented sharing, export, and offboarding rules.
- Retention settings aligned with the approved purpose.
- Audit evidence sufficient to investigate access and policy violations.
- Backups, recovery, availability, and secure termination procedures.
Defaults should be verified in the real environment. A policy document describing strong controls is not evidence that the deployed account has those controls enabled.
6. HIPAA compliance does not establish clinical accuracy
Privacy and security controls do not make an LLM output clinically correct. Generative systems can omit details, invent facts, produce unsupported citations, or frame uncertainty poorly. Clinical validation, human review, permitted-use policies, escalation paths, and ongoing monitoring belong alongside the HIPAA controls.
NIST’s AI Risk Management Framework and Generative AI Profile provide a voluntary structure for identifying, measuring, managing, and governing AI risks beyond privacy alone. They do not certify HIPAA compliance, but they help organizations avoid reducing the review to a BAA and an encryption checklist.
A HIPAA-compliant LLM deployment checklist
- Define the intended users, clinical or administrative purpose, and prohibited uses.
- Identify every vendor and subcontractor that may handle ePHI.
- Execute appropriate BAAs and record exact eligible services and exclusions.
- Map prompts, files, outputs, logs, integrations, support, retention, and deletion.
- Document de-identification, tokenization, and encryption boundaries without overstating them.
- Configure identities, permissions, sharing, retention, and audit controls.
- Test privacy failures and output quality with representative nonproduction cases.
- Assign human review, incident response, monitoring, and periodic reassessment.
The bottom line
“HIPAA-compliant LLM” is useful shorthand, but it can hide the real unit of analysis: the deployed workflow. A healthcare organization needs contractual coverage, a complete data-flow map, appropriate safeguards, controlled features and integrations, trained users, clinical review, and evidence that the configuration works as documented.
Our security ledger and privacy journey apply that same system-level approach to this workspace, separating confirmed controls from items that still require validation.