There is no model you can buy that is HIPAA-compliant by itself. Compliance is a property of the workflow around the model — encryption, audit logging, access control, retention, and how protected health information (PHI) moves through prompts, responses and logs. A general-purpose model API is a component of that workflow, not the workflow. So “best HIPAA-compliant AI” does not resolve to a vendor name; it resolves to whichever deployment option leaves the fewest control gaps unowned for the specific task you are building.
That reframing changes what you compare. Instead of ranking vendors by published compliance posture and BAA availability, you compare four deployment shapes by what each one inherits for you and what it hands back to your engineering layer.
What are the real options to compare?
| Option | Controls typically inherited | Controls left to you |
|---|---|---|
| Hosted general-purpose API under a BAA | Transport and at-rest encryption, vendor-side infrastructure controls, contractual retention terms | Prompt-side PHI minimisation, your own audit trail, access control, log scrubbing, response handling |
| HIPAA-eligible cloud-hosted model (in your cloud account) | Encryption, identity and access tooling, cloud-native audit logging, network isolation primitives | Configuration correctness, retention policy enforcement, application-level audit records, evidence assembly |
| Self-hosted open-weight model inside your boundary | Nothing external — but no PHI leaves your perimeter | Everything: encryption, logging, access control, retention, patching, capacity |
| De-identification before the model call | The compliance question shrinks to the de-identification step | De-identification quality, re-identification risk review, handling of any residual identifiers in output |
The self-hosted row is the honest one. It inherits nothing, which is why teams that pick it for control reasons often underestimate the build. The de-identification row is the one most often skipped, and it is frequently the strongest answer for tasks where PHI is incidental rather than essential.
Wrappers, free tiers, and consumer assistants
Point-solutions that market themselves as HIPAA-compliant AI are usually a wrapper over one of the first two options. Ask which one — a wrapper cannot inherit a control its underlying provider does not offer, and anything it “adds” is a re-declaration you should see evidence for. The useful vendor questions are narrow: will you sign a BAA, what is the retention period for prompts and completions, are inputs used for training, and what audit records can I export? No vendor can give you the one thing that matters most, which is proof that your workflow keeps PHI inside its intended boundary.
Free tiers rarely survive this. Absence of a paid contract usually means absence of a BAA, weaker retention commitments, and no exportable audit evidence — three of the controls you most need to own. Consumer-grade assistants sit in the same place: an enterprise agreement can move encryption and retention into contract, but prompt-side PHI minimisation, your access model, and your audit trail remain unowned no matter how the account is configured.
Narrow high-volume tasks tighten the picture further. In clinical transcription or therapy-note drafting, PHI is unavoidable in both the input audio and the generated output, so de-identification is off the table and the comparison collapses to the first three rows. Agentic workflows tighten it again: once a model calls tools and writes into clinical systems, the audit surface covers every tool call, not one response, and self-hosting or in-account hosting starts to earn its cost.
We work through this comparison the same way in practice — options on the left, inherited controls in the middle, residual engineering on the right — because the residual column is what the eventual review will ask about. The structural argument for why a model API is a component rather than a compliant system is developed in our analysis of what HIPAA-compliant AI actually requires of the surrounding workflow, and the wider regulated-AI delivery context sits on our life sciences practice page.
Doing this before build, rather than after a PHI-exposure finding, is the whole point: the remediation cycle you avoid is the one that starts when someone discovers the retention or logging control was never owned by anyone.
So the question to take into your next vendor call is not which product is compliant. It is: after we choose this option, which controls are still ours — and can we name who owns each one?
