Ask whether ChatGPT is HIPAA compliant and you get a yes-or-no answer that is wrong either way. A model is not a covered entity, and a chat product does not become compliant because a vendor checks a box. Compliance is a property of the workflow — the data flow, the contract, the logging, and the access control you build around the model. That distinction matters because the question is usually asked at the wrong altitude. Someone wants to paste a patient note into a chat box and summarise it, and they want a single sentence that tells them it is safe. There is no such sentence. HIPAA does not regulate language models; it regulates how protected health information (PHI) is created, received, maintained, and transmitted. ChatGPT — or any large language model (LLM) — is just one component sitting inside that flow. The right question is not “is this tool compliant” but “what does the workflow around this tool have to do, and which of those things has the vendor actually agreed to do for me?” Why “Is ChatGPT HIPAA Compliant?” Is the Wrong Question HIPAA’s Security Rule and Privacy Rule apply to covered entities and their business associates. A business associate is an organisation that creates, receives, maintains, or transmits PHI on behalf of a covered entity — and that relationship is established by a signed Business Associate Agreement (BAA), not by a marketing label. OpenAI does offer a BAA for ChatGPT Enterprise and certain API arrangements; the consumer ChatGPT product does not come with one. So the same model, accessed two different ways, lands on opposite sides of the compliance line. That is the core reframe. The model is identical. What changes is the contractual and technical envelope around it. Without a BAA in place for the specific deployment you are using, any PHI you send is being disclosed to a third party who has made no enforceable commitment to safeguard it — which is the disclosure HIPAA exists to prevent. With a BAA, the vendor takes on defined obligations, but those obligations cover the vendor’s side of the boundary only. Everything on your side — who can access the workflow, what gets logged, how outputs are stored, whether PHI was even necessary in the prompt — remains your responsibility. We see this pattern regularly: teams treat the BAA as the finish line when it is actually the starting gate. The contract makes a compliant workflow possible. It does not make the workflow you built compliant. The same structural point applies across AI and video systems, which is why it is worth reading alongside what makes an AI or video workflow HIPAA- or GxP-ready and what it doesn’t — the readiness question generalises well beyond chat. What a HIPAA-Ready LLM Workflow Actually Has to Do Pull the question apart into the things HIPAA actually cares about and the picture clarifies. A defensible LLM workflow handling PHI has to satisfy a set of distinct controls, and a chat product satisfies only some of them out of the box. Requirement What it means for an LLM workflow Who owns it Business Associate Agreement A signed BAA covering the exact product tier and access method handling PHI Vendor offers; you must execute it Data flow control PHI travels only to endpoints under the BAA; consumer endpoints are blocked You (network, routing, prompt hygiene) Access control Authenticated, role-scoped access; unique user identity per HIPAA §164.312 You (IdP, SSO, RBAC) Audit logging Records of who accessed what PHI, when, and through which prompt/output Shared — vendor logs API, you log the surrounding app Encryption PHI encrypted in transit and at rest across the whole path Shared — vendor covers their side; you cover yours Training data exclusion Confirmation that prompts are not used to train future models Vendor commits; you verify the tier and setting Minimum necessary Only the PHI genuinely needed reaches the model You (workflow and prompt design) The instructive column is the third one. Most of these obligations are yours, not the vendor’s. A BAA-backed ChatGPT Enterprise deployment closes the contractual gap and the training-exclusion gap, and it covers the vendor’s encryption and infrastructure logging. It does nothing about whether your nurse practitioner is sharing a login, whether your intake form dumps an entire chart into a prompt when only the medication list was needed, or whether the summarised output gets pasted into an unencrypted spreadsheet on the way out. Those failures are common, and none of them are the model’s fault. What does the vendor’s BAA actually cover? A BAA covers the business associate’s handling of PHI: their safeguards, their breach-notification duties, their subcontractor flow-down, and their commitment not to use PHI beyond the agreed purpose. In our experience reviewing these arrangements, three things consistently fall outside it — observed across engagements, not a published benchmark. First, the input decision: HIPAA’s minimum-necessary standard is about what you choose to send, and no vendor controls that. Second, the output handling: once the model returns text, it lives wherever your application puts it. Third, identity and access on your side of the API. The BAA is a floor under the vendor’s behaviour, not a ceiling over yours. The Failure Mode: Treating the Model as the Compliance Boundary The recurring mistake is drawing the compliance boundary at the model. It belongs at the data flow. When teams think “we’re using the enterprise tier with a BAA, so we’re covered,” they have quietly assumed that the model is where PHI risk concentrates. It isn’t. The riskiest points are the seams — where PHI enters the prompt, where the output leaves the system, and where humans touch both. Consider a worked example. A clinic wants to draft visit summaries from dictation. The naive build: a front-end text box, a call to a BAA-covered API, and the response shown to the clinician. It looks compliant. But trace the PHI. The dictation arrives through a transcription step — is that vendor under a BAA? The clinician edits the draft and pastes it into the EHR by hand — is the clipboard path logged? A second clinician reviews it under a shared service account — can you tell who actually accessed the record? Each of these is a HIPAA control failure that the model’s compliance status does nothing to address. This is the same boundary confusion that surfaces in narrower tools, which is why the HIPAA-compliant AI note taker question — what “compliant” actually requires in the workflow ends up at the same answer from a different door. The early warning sign is a one-line vendor claim doing all the work in a procurement deck. When the justification for handling PHI through an LLM is “the vendor is HIPAA compliant” with no accompanying data-flow diagram, no access-control design, and no audit-log plan, the workflow is almost certainly exposed. Compliance that can be expressed in a single sentence is usually compliance that hasn’t been engineered. A Diagnostic Checklist Before You Send PHI to an LLM Run this before any LLM workflow touches real patient data. If you cannot answer yes — with evidence — to every line, the workflow is not ready. BAA executed for this exact tier? Not the vendor’s general policy; the signed agreement covering the product and access path you are using. Training exclusion confirmed in settings? The specific toggle or contract clause that prevents your prompts from training future models, verified, not assumed. Data flow mapped end to end? Every hop PHI takes — transcription, API, storage, downstream paste — with each hop’s BAA status named. Minimum-necessary enforced in prompt design? The workflow sends only the PHI the task needs, not the whole record by default. Unique authenticated identity per user? No shared logins; access is role-scoped and attributable to an individual. Audit logging on the surrounding application? You can reconstruct who accessed which PHI, when, and through what prompt and output. Output handling encrypted and controlled? Model responses don’t land in unencrypted, unlogged, or uncontrolled stores. This is extractable as a standalone gate, and that is the point — it works whether the model behind it is ChatGPT, Claude, Gemini, or a self-hosted Llama variant. The model identity changes the vendor column; it does not change the checklist. Self-Hosting Doesn’t Skip the Work — It Moves It A tempting escape is to self-host an open-weight model so PHI never leaves your infrastructure, sidestepping the vendor BAA entirely. That is a legitimate architecture, and for some clinical settings it is the right one. But it does not remove the work; it relocates it. Running a model on your own GPUs under your own network means you are now the entity that has to satisfy encryption, access control, audit logging, and breach handling end to end. The BAA question disappears precisely because you have absorbed both sides of it. What self-hosting genuinely buys you is control over the data-flow boundary — PHI stays inside your trust zone, and you are no longer reasoning about a third party’s subcontractors. What it costs you is the operational burden of being your own compliant infrastructure provider. For organisations that already run validated computerised systems, that burden is familiar territory — and it is where our healthcare and life-sciences AI work sits; the discipline overlaps heavily with what GxP compliance actually requires for AI software, where the same insistence on documented controls and traceability governs every component. The decision between a BAA-backed managed service and self-hosting is a trade-off about where you want the compliance burden to sit, not a shortcut around it. FAQ Is ChatGPT HIPAA compliant? Not by default, and not as a property of the model itself. The consumer ChatGPT product ships without a Business Associate Agreement, so sending PHI through it is an unprotected disclosure. ChatGPT Enterprise and certain API arrangements can be covered by a BAA, which makes a compliant workflow possible — but compliance is a property of the workflow you build around the model, not of the model. What is a Business Associate Agreement and why does it matter for LLMs? A BAA is the signed contract that establishes a vendor as a business associate, obligating them to safeguard PHI they handle on your behalf. For an LLM workflow it matters because without a BAA covering the exact product tier and access path, any PHI you send is disclosed to a third party with no enforceable safeguards. The BAA covers the vendor’s side of the boundary only; your access control, logging, and data-flow decisions remain your responsibility. What does a HIPAA-ready LLM workflow have to do beyond having a BAA? It has to control the full data flow: enforce minimum-necessary in prompt design, authenticate and role-scope every user, log access on the surrounding application, encrypt PHI in transit and at rest across the whole path, and control where outputs land. The BAA closes the contractual and training-exclusion gaps, but most of these obligations sit on your side of the API, not the vendor’s. Does self-hosting an open-weight model make the workflow automatically compliant? No — it relocates the work rather than removing it. Self-hosting keeps PHI inside your own trust zone and eliminates the vendor BAA question, but it makes you responsible for encryption, access control, audit logging, and breach handling end to end. It is a trade-off about where the compliance burden sits, not a shortcut around it. The honest closing question is not “which LLM is HIPAA compliant” but “have I drawn my compliance boundary at the data flow or at the model?” Draw it at the model and the seams where PHI enters and leaves will quietly carry the risk you thought a vendor label had handled. Draw it at the data flow and the model becomes what it always was — one replaceable component inside a workflow you are accountable for.
