A HIPAA-compliant LLM is not a model you can buy with a seal on it. It is a deployment: a language model, the infrastructure it runs on, the contracts around it and the policies your team follows, set up so that protected health information (PHI) is handled the way the HIPAA rules require. No government body certifies a model. Compliance is something your organization demonstrates, and it depends on how you run the system as much as on which model you pick.
This guide is for CTOs, IT leaders and compliance owners who need to put an LLM near patient data. It covers when HIPAA applies, what to demand in a contract, which safeguards to verify, which architectures limit exposure, and how to support the system after launch.
TL;DR
- There is no federal HIPAA certification, seal or registry for LLMs. "HIPAA compliant" is a self-assessment, so you have to vet every vendor claim.
- If a vendor handles PHI for you, you need a signed business associate agreement (BAA) before any PHI goes in. A BAA is necessary but does not make the system compliant on its own.
- Compliance lives in the whole stack: access controls, audit logs, encryption, network isolation, PHI filtering and a documented risk analysis.
- Private or self-hosted deployments give you the most control over where PHI lives, but you own more of the safeguards.
- Plan for hypercare after go-live. The first weeks in production are when misconfigurations and workflow gaps show up.
Table of Contents
- What "HIPAA-compliant LLM" actually means
- When HIPAA applies to your use of an LLM
- Why general-purpose LLM tools fall short
- The contract: what a BAA must cover
- Technical and administrative safeguards to verify
- Architectures that limit PHI exposure
- Deploying across borders
- Hypercare: supporting an LLM after go-live
- A step-by-step path to a compliant deployment
- Our perspective
- Where we can help
- FAQ
- Sources
What "HIPAA-compliant LLM" actually means
HIPAA regulates covered entities (health plans, clearinghouses and most providers) and their business associates. It says nothing about a model's architecture. The question is always whether PHI is created, received, maintained or transmitted by a regulated party, and whether the required protections are in place.
That is why marketing claims deserve skepticism. The HHS Office for Civil Rights does not pre-clear, certify or endorse any LLM or product as HIPAA compliant, and the label is a vendor's own assessment rather than a government determination. When a vendor says its model is compliant, the useful follow-up questions are: compliant under what contract, in what configuration, with which of your data flows, and who is responsible for each control?
A more accurate phrase is "HIPAA-ready" or "HIPAA-eligible": the service can be used in a compliant way if you configure and govern it correctly.
When HIPAA applies to your use of an LLM
The answer turns on who is handling the PHI and on whose behalf.
HIPAA applies when a covered entity, or a business associate working for one, sends PHI to an LLM service. Researchers describe it this way: LLM developers and vendors can be subject to HIPAA when they process PHI on behalf of covered entities, at which point they become business associates or subcontractors.
HIPAA may not apply in the consumer case. The same analysis notes that when a patient types their own health details into a public chatbot for medical advice, the vendor is neither a covered entity nor a business associate. That does not make it safe. It means HIPAA is not the framework protecting that patient, and other laws and the vendor's terms take over.
For an organization, the practical rule is simple. If a clinician, billing team, call center or data scientist might paste PHI into a tool, treat that tool as in scope until your compliance team says otherwise.
Why general-purpose LLM tools fall short
Most public chat products were built for consumers, and their default terms reflect that. Three problems come up repeatedly.
No BAA means no lawful disclosure. When the provider has not signed a BAA, entering PHI is an unauthorized disclosure. JAMA's analysis adds that medical information entered into a chatbot can become part of its training data and be disclosed to other users.
Models can repeat what they have seen. Published work notes that LLMs can sometimes reproduce highly specific or unusual information, such as exact patient names or unique phrasing, even when they were not designed to. Feeding sensitive patient data back into neural networks can also make it accessible to intended and unintended audiences.
Cleanup does not undo a violation. Turning off chat history or deleting conversations may reduce future exposure, but it does not retroactively legalize an unauthorized initial disclosure. Prevention is the only real control, which means blocking PHI from reaching an unapproved tool in the first place.
A practical consequence: write an AI use policy before you roll out any tool. Legal scholars advise that healthcare systems establish clear policies on AI use while the legal framework is still incomplete and evolving.
The contract: what a BAA must cover
If a vendor will touch PHI, the BAA is your first gate. HHS publishes the required elements in its business associate contract guidance. In plain terms, the agreement must:
- Establish the permitted and required uses and disclosures of PHI, and not authorize anything you could not do yourself.
- Prohibit any use or disclosure beyond what the contract or the law allows.
- Require the vendor to implement Security Rule safeguards for electronic PHI.
- Require reporting of breaches and security incidents.
- Make subcontractors agree to the same conditions.
- Give you the right to terminate if the vendor violates the terms.
Beyond those basics, read the BAA against the product's actual behavior. Ask:
- Which services are covered? A BAA often applies to specific endpoints or tiers, not the vendor's whole product line.
- Is your data used for training? The answer should be a contractual no, not a setting you hope stays toggled.
- How long are prompts and outputs retained, and where? Include logs, caches and abuse-monitoring copies.
- Who are the subprocessors? Each one needs to sit inside the chain of obligations.
- What happens at termination? You need deletion or return of PHI with confirmation.
A BAA also does not do everything. It allocates responsibility and sets obligations. It does not configure your environment, train your staff or perform your risk analysis.
Technical and administrative safeguards to verify
The HHS summary of the Security Rule is the baseline. For an LLM deployment, it translates into a checklist like this.
| Safeguard area | What to verify in an LLM deployment |
|---|---|
| Access control | Role-based access to the model, prompts, logs and vector stores; unique user IDs; least privilege |
| Authentication | Single sign-on and multi-factor authentication for users and for service accounts calling the model |
| Audit controls | Logs of who sent what, when, and which data was retrieved, kept somewhere tamper-resistant |
| Transmission security | Encryption in transit between users, applications, retrieval systems and the model |
| Risk analysis | A documented analysis that includes the LLM, its data flows and its vendors |
| Incident procedures | A response plan that names AI-specific events such as PHI leaking into an output |
Two cautions apply here. First, cloud eligibility is not compliance. A major cloud provider's own guidance states that using HIPAA-eligible services alone does not constitute HIPAA compliance, because customers must evaluate their environment and configure the controls. Second, the same guidance describes tooling that can detect and anonymize PHI in inputs and outputs and run grounding checks to block unsupported clinical statements. Filters like these reduce risk, but they are a layer, not a guarantee.
Architectures that limit PHI exposure
There is no single correct design. The right one depends on your data, your volume and how much control your compliance team needs. The reference architecture published by that cloud provider recommends defense-in-depth: private network routing so ePHI stays off the public internet, customer-managed encryption keys, strong identity management, and PHI redaction or filtering at the edges.
Three patterns cover most real projects:
| Pattern | How it works | Strengths | Trade-offs |
|---|---|---|---|
| Managed API under a BAA | A vendor hosts the model; you call it over a private connection | Fastest to start, no hardware to run | Less control over retention and location; you depend on the vendor's controls |
| Private cloud or dedicated tenancy | The model runs in your own cloud account or an isolated environment | Strong network and key control, elastic capacity | You configure and monitor the safeguards; costs scale with usage |
| On-premises or colocated open-weight model | You run the model on your own GPU servers | PHI never leaves your boundary; predictable cost at steady volume | You own procurement, capacity, patching and monitoring |
Whichever you choose, assess these failure modes before launch. They are the ones the reference architecture itself lists: ePHI exposure, clinical hallucinations, gaps in session isolation, gaps in audit trails and misconfiguration.
Two of these deserve extra attention. Session isolation: one user's context must never appear in another user's response, especially with shared retrieval indexes. Hallucination: a fluent but wrong clinical statement is a patient safety issue, not just a quality issue, so keep a human in the loop for anything that influences care.
Why hardware planning matters for private deployments
Self-hosting changes the project. You are now sizing GPU memory for the model and its context length, planning networking and storage for retrieval, sourcing servers and components with real lead times, and accounting for import duties if the hardware crosses borders. A compliance design that assumes capacity you cannot get in time is not a design. Bring infrastructure planning into the compliance conversation early.
Deploying across borders
Many healthcare and life-sciences organizations run workloads, vendors or staff outside the United States. HIPAA does not forbid that. HHS cloud guidance says HIPAA has no requirements specific to ePHI stored outside the United States, but your required risk analysis must consider location-specific risks, including a higher chance of hacking or malware.
HIPAA is rarely the only law in play. If you handle data about people in the United Kingdom, for example, the UK regulator explains that you must assess whether restricted transfer rules apply and identify safeguards such as international data transfer agreements. It also points out that a transfer can happen through remote access by personnel located outside a protected territory, not only by moving files. An offshore support engineer with console access can count.
In practice, map every location where data is stored, processed or viewed, including your vendors' subprocessors and support teams. Then check each against the laws that apply there, and document the result in your risk analysis.
Hypercare: supporting an LLM after go-live
The second question readers often ask is what hypercare means in software development. It is a defined period of extra support and monitoring right after go-live, meant to confirm the new solution works as expected and to resolve issues quickly. One academic study of post-go-live support describes it as a way to support a smooth transition into normal operations.
For an LLM handling PHI, hypercare is where compliance meets reality. Good practice for large systems includes cross-functional leadership, daily issue reviews and formal handover points to the long-term maintenance team. For a regulated AI deployment, we would add these checks to the daily review:
- Audit logs: are they complete, and is anyone reading them?
- PHI filter hits: what is being caught, and what might be slipping past?
- Access: are new users getting only the roles they need?
- Output quality: are clinicians flagging hallucinations or unsafe answers?
- Capacity and latency: is the system holding up under real load?
- Incident readiness: could the team execute the response plan today?
Set an exit rule before launch. Hypercare ends when agreed criteria are met, such as a stable period with no unresolved high-severity issues, not when a calendar date arrives. Then hand over to ongoing support with clear owners for patching, model updates, access reviews and periodic risk analysis.
A step-by-step path to a compliant deployment
- Define the use case and the data. Decide whether PHI is actually needed. De-identified data may remove the problem entirely.
- Inventory data flows. Trace where PHI enters, where it is stored and who or what can see it.
- Choose the deployment pattern. Use the table above and weigh control against operational burden.
- Secure the contracts. Get a BAA from every vendor that touches PHI, including subprocessors, and check scope and retention.
- Build and configure the safeguards. Access control, encryption, logging, network isolation and PHI filtering.
- Complete and document the risk analysis. Include model behavior, vendors and locations.
- Write and train on the AI use policy. Staff need to know which tools are approved and which are not.
- Launch with hypercare. Monitor closely, fix fast and hand over cleanly.
Our perspective
Most failed AI compliance projects we see in principle, and plan around in practice, break at the seams between teams. Legal approves a contract, security approves a design, and nobody owns the gap between them: the GPU order that slips by months, the shipment held up on tariffs, the support handoff that nobody scoped.
We have worked in this space since 2011, and in HPC and AI infrastructure since 2017. Our view is that a HIPAA-ready LLM is an infrastructure project with a compliance outcome, not the other way around. If your risk analysis assumes a private deployment, then sourcing, delivery, data center readiness and support need to be planned as carefully as the model and the BAA.
Our advice is to decide where PHI lives first, and to let that decision drive everything else. Then work backward through hardware, networking, logistics, import and tariff handling and the support model, so the compliant design is one you can actually build on schedule. We do not certify anything, and nobody else can either. What we can do is help you reach a deployment you can defend in front of your own compliance team.
— Dormedia
Where we can help
If you are planning a private or on-premises LLM environment, we design, source, deploy and support the infrastructure behind it. That includes customized server and component configurations, data center solutions, global shipping, tax and tariff handling, project management and ongoing support. See the full range on the Dormedia site, or start a conversation about your project.
Pricing is project-based, and we do not publish rates, so the first step is a scoping conversation about your use case, data and timeline.
FAQ
Is ChatGPT HIPAA compliant?
No consumer chat product is compliant by default, because no model carries a HIPAA certification and PHI cannot lawfully go to a provider that has not signed a BAA. Some vendors offer business or API tiers covered by a BAA, but you still must configure and govern your own use. Check the exact product, tier and contract terms.
Does signing a BAA make an LLM HIPAA compliant?
No. A BAA sets out the vendor's obligations and permitted uses of PHI, but it does not configure your environment or replace your risk analysis. You still need access controls, audit logging, encryption, staff policies and incident procedures on your side.
Can we run an open-source model and call it HIPAA compliant?
You can run one inside a compliant environment, and keeping PHI inside your own boundary is a strong design. The model is not compliant in itself, though. Compliance depends on the hosting, safeguards, policies and documentation around it.
What is hypercare in software development?
Hypercare is a short, intensive support period after go-live in which the team monitors the system closely and fixes issues quickly. It usually includes daily issue reviews and ends with a formal handover to long-term support. For an LLM handling PHI, it should also cover log reviews, filter performance and output safety.
Does HIPAA allow PHI to be stored or processed outside the US?
HIPAA contains no rule specific to ePHI stored abroad, but your risk analysis must account for the added risks of that location. Other countries' privacy laws may also apply, so map every place data is stored, processed or accessed.
Sources
- AI Chatbots and Challenges of HIPAA Compliance for AI Developers and Vendors
- How Healthcare Organizations Must Vet AI Vendors That Overstate Their Compliance
- Health Care Privacy Risks of AI Chatbots, JAMA
- HIPAA and large language models, PMC
- Security Implications of AI Chatbots in Health Care
- Business Associate Contracts, HHS
- Summary of the HIPAA Security Rule, HHS
- Building a HIPAA-ready generative AI architecture for healthcare
- Guidance on HIPAA and Cloud Computing, HHS
- Our Future Health regulatory sandbox final report, ICO
- Hypercare Post Go-Live Support for SAP Projects