HIPAA-compliant LLM API
Using LLMs on protected health information is entirely achievable, and the hard part is not the model — it is guaranteeing that a request containing PHI can never reach a provider you have no BAA with. That is an enforcement problem, and enforcement in application code is how accidents happen.
The four requirements
- A signed BAA with every entity that touches PHI. Including the gateway, not only the model provider. If a proxy sees the prompt, it is in scope.
- Zero retention on the inference path. No training on your data, no prompt logging by the provider, defined retention windows everywhere else.
- Access controls and audit trail. Who sent what, when, to which model, under which policy — reconstructable after the fact.
- Encryption in transit and at rest, with key management you can describe to an auditor.
Enforce eligibility in the router, not the app
The pattern that holds up: mark the workload, not the request. Issue a dedicated API key for PHI traffic, attach a policy to that key restricting it to BAA-covered, zero-retention providers in eligible regions, and let the router refuse anything else. A developer who ships a new feature on that key inherits the constraint automatically rather than having to remember it.
- Provider allow-list limited to BAA-covered vendors
- Zero-retention enforcement, failing closed if no eligible provider is available
- Region pinning so inference stays in-jurisdiction
- Prompt redaction and log suppression on the PHI path
- Immutable audit record per request
De-identification helps but does not eliminate scope
Stripping identifiers before the model call reduces exposure and is good practice. Treat it as defense in depth rather than a way out of the BAA requirement — re-identification risk in free text is real, and Safe Harbor de-identification is stricter than most redaction implementations achieve.
Related: zero-retention and residency, security and compliance, and data residency controls.