There is no subscription tier called CompliantChatGPT. The term is search shorthand for a question teams have to answer with engineering: what sits around the model call when the text going into it contains protected health information? No configuration of a general-purpose large language model is compliant on its own — compliance attaches to a workflow, not to a model.
That distinction decides how a procurement cycle goes. A team that bought “compliantchatgpt” as a label has a subscription receipt. A team that engineered the wrapper can name each control, point to where it sits in the call path, and show the evidence it emits.
Is “compliant ChatGPT” a product or a search term?
It is a search term. Teams type it because they want a pre-certified, drop-in version of ChatGPT they can safely point PHI at, and vendor pages are happy to let the phrase imply that such a thing exists. It does not. An enterprise or team plan changes the contractual and data-retention posture around the API — which matters — but it does not supply encryption you control, an audit log your reviewer can read, access scoping tied to your roles, a retention and purge policy, or a minimisation step before text leaves your systems. Those are yours to build regardless of which vendor’s API sits in the call path, and the same applies to Gemini, Claude, or anything else you swap in.
The same logic applies to a signed BAA. It allocates responsibility; it does not implement controls.
The control surface the term actually names
| Control | Where it sits | Evidence it emits |
|---|---|---|
| Encryption in transit and at rest | Every hop between your app, your store, and the model API | TLS config, key management records |
| Prompt and response logging | Around the model call — treat logged text as PHI-bearing data | Timestamped, access-controlled audit log |
| Access scoping | Between users/services and the wrapper, not at the model | Role-to-endpoint mapping, denied-access records |
| Retention and purge | Log and cache stores | Documented retention window, executed purge records |
| Minimisation / de-identification | Before text reaches the API | Transform spec plus per-request record of what was stripped |
If you cannot name all five and say where each one lives, the phrase “compliant ChatGPT” is not yet describing anything in your architecture.
Why the label fails at review
Reviewers reject a vendor compliance page as the sole evidence for PHI handling, and they are right to. The vendor attests to their service; the obligation for the workflow sits with the operator. What a reviewer will accept is the boring artefact set — the log sample, the retention policy with an executed purge, the access matrix, the minimisation spec. Named point tools marketed as HIPAA compliant AI are worth evaluating on exactly this basis: ask them which of the five controls they implement and which they leave to you, then ask the same question of your own wrapper.
In our experience with regulated teams, resolving the term early is what stops a procurement cycle being spent evaluating a product category that does not exist. The broader readiness argument — where an LLM belongs in a validated process at all, and when to stop bending a general-purpose model to fit — is developed in our work on HIPAA-ready AI in life sciences.
The open question for most teams is not whether ChatGPT can be made compliant. It is whether the wrapper you would have to build is cheaper than the engineered alternative you have been avoiding.
