Is ChatGPT HIPAA Compliant? The Answer Depends on the Product Boundary
ChatGPT can support HIPAA-regulated work only inside an eligible OpenAI product, under a signed Business Associate Agreement, with covered features and the healthcare organization's own safeguards in place. Consumer access and a generic enterprise subscription are insufficient answers for a deployment review. This guide traces a PHI-bearing request through the product, contract, feature, minimum-necessary, and audit checks that determine eligibility.
OpenAI publishes a named list of HIPAA-eligible products and functionality. That list includes ChatGPT for Healthcare and ChatGPT for Enterprise with Regulated Workspace. It also includes ChatGPT FedRAMP and ChatGPT for Clinicians, plus eligible API offerings with modified retention. Eligibility is specific to the product and workspace. It is also specific to the functionality and contract. A nurse opening an ordinary ChatGPT window and a hospital application calling an approved API configuration occupy different compliance boundaries, even when both screens show an OpenAI model response.
I would reject any procurement memo that answers "Is ChatGPT HIPAA compliant?" with a bare yes. The useful answer starts with the exact workspace and follows the PHI through every service it touches.
TL;DR
- ChatGPT has specific HIPAA-eligible products; the ChatGPT name alone establishes nothing.
- A signed BAA must cover the selected product and the functionality carrying PHI.
- Third-party apps and connectors require separate review because availability leaves BAA coverage unconfirmed.
- The healthcare organization still owns minimum-necessary use and access policy. It also owns routing and audit evidence.
- DeepInspect can govern deliberately routed HTTP model traffic, but it cannot extend OpenAI's BAA or inspect a vendor-managed path outside that route.
HIPAA eligibility begins with the exact OpenAI product
OpenAI's HIPAA-eligible products and functionality guidance names the offerings that can sit inside a BAA-backed deployment. The current list includes ChatGPT for Healthcare and ChatGPT for Enterprise with Regulated Workspace. It also includes ChatGPT FedRAMP and ChatGPT for Clinicians, plus API offerings configured with modified retention. That wording matters because "ChatGPT" covers several commercial surfaces with different terms and technical paths.
Start the review with the contract name shown in the admin console, then record the workspace identifier and the enabled capability set. A logo in the browser tab proves which brand the employee opened. It says nothing about the agreement governing that session. The same discipline appears in a broader HIPAA BAA review for AI vendors: identify the service first, then map the agreement to the actual flow of PHI. Product eligibility opens the review. The remaining gates decide whether the use is defensible.
A signed BAA covers a defined service boundary
HHS treats a cloud service provider that creates or receives ePHI, or maintains or transmits it on behalf of a covered entity or business associate, as a business associate. Its cloud computing guidance says that status can apply even when the provider lacks the key needed to decrypt the data. The contractual consequence is a HIPAA-compliant BAA before that provider handles ePHI.
For ChatGPT, the organization needs an executed OpenAI BAA that covers the selected offering. OpenAI's product guidance also warns that access to functionality does not place that functionality, or a third-party service reached through it, inside BAA coverage. Record the effective agreement alongside the workspace configuration. A PDF buried in procurement cannot rescue a request sent through excluded functionality.
The practical test has two entries: the named service in the BAA and the route the request actually takes. If they diverge, pause PHI use until legal and privacy teams resolve the mismatch with security.
API eligibility has its own configuration gate
OpenAI publishes separate BAA guidance for API healthcare customers. The API path requires an eligible healthcare customer with a BAA. The applicable zero-data-retention requirements also apply. That creates a different operating model from a clinician working inside a managed ChatGPT workspace.
An API deployment gives the healthcare organization direct control over the application that collects the prompt, attaches user context, and sends the HTTP request. The team must document which endpoint receives PHI, which retention configuration applies, how caller identity reaches the request, and which events enter the audit trail. A shared API credential identifies the application account. It rarely identifies the physician or coder who initiated the action.
The AI and HIPAA compliance guide covers the wider program. For this product decision, keep the evidence narrow: BAA and eligible endpoint. Also keep retention approval and identity path, plus a sample decision record.
Functionality coverage can change the answer inside one workspace
OpenAI's eligibility page separates the approved product from the functionality used inside it. This prevents a common review error: approving a workspace once, then treating every newly enabled connector or app, or other capability as covered automatically. A capability can introduce another processor and data destination under another retention policy.
Inventory each path that may carry PHI. Include file uploads and connected data sources. Add external actions and apps, plus any workflow that hands content to a third party. For every item, write down the service owner and applicable agreement. Also record the destination and retention behavior, along with the administrative control. OpenAI explicitly cautions that availability alone leaves BAA coverage for a use or third-party service unconfirmed.
My opinion is blunt: an app catalog should default to closed in a clinical workspace until every destination has an owner and a contract. Convenience is a poor reason to let a referral note cross an undocumented boundary. Review the list whenever an administrator enables a new integration.
Minimum-necessary policy belongs in the request path
HHS's minimum necessary guidance requires covered entities and business associates to make reasonable efforts to limit PHI to the minimum needed for the intended purpose, subject to the rule's stated exceptions. A BAA establishes duties between parties. It does not decide how much PHI belongs in one prompt.
Translate the requirement into request policy. A scheduling workflow may need a patient identifier and appointment window while a draft-discharge workflow may need a defined portion of the clinical record. Roles and purposes should drive those decisions before content reaches an approved destination. The decision also needs a record of caller identity and data classification. It should also show the approved destination and policy version, plus the timestamp and outcome.
A sticky note saying "remove names before pasting" provides training material. Enforcement requires classification and policy on the content actually being sent. The HIPAA AI control guide explains the deployer obligations around these flows.
Training exclusion helps, but compliance still depends on use
OpenAI says eligible healthcare deployments include a BAA and that organizational data is not used to train its models in its OpenAI for Healthcare announcement. Those statements address how OpenAI contracts for the service and one way organizational data is handled.
The healthcare organization still owns access, purpose, disclosure, and evidence decisions. A covered workspace can receive excessive PHI. An authorized employee can choose the wrong functionality. An application can send every request under one shared service identity. Audit records can omit the internal policy that permitted the disclosure.
Treat the no-training commitment as one row in the review. Other rows cover BAA scope and retention configuration. They also cover functionality coverage and minimum-necessary controls, plus identity and evidence. The HIPAA-compliant AI tools checklist is useful for comparing that complete control set across products without turning a vendor's eligibility statement into a universal certification.
DeepInspect
DeepInspect sits on deliberately routed HTTP traffic between an authenticated user or agent and an LLM. For an eligible OpenAI API deployment, the application can supply identity and role context, then DeepInspect can classify the prompt, apply minimum-necessary and approved-route policy, permit or block the request, and create a per-decision audit record.
That boundary is exact. DeepInspect cannot issue OpenAI's BAA, add excluded ChatGPT functionality to the agreement, or inspect a vendor-managed ChatGPT interaction that never traverses the configured proxy. It governs the routed model request. OpenAI and the healthcare organization retain their respective contractual and operational duties.
Book a demo today.
Frequently asked questions
- Can staff put PHI into consumer ChatGPT?
The official eligibility list controls the answer. Staff should use only the OpenAI product and workspace covered by the organization's executed BAA and approved configuration. A personal account or an unapproved workspace sits outside that documented boundary. Security teams should make the approved entry point visible and enforce access through the organization's identity controls.
- Does ChatGPT Enterprise automatically include HIPAA coverage?
OpenAI names ChatGPT for Enterprise with Regulated Workspace among its eligible offerings. The organization still needs the applicable BAA and must confirm that the specific functionality carrying PHI is covered. The product-and-functionality check requires more evidence than a plan name or invoice provides. A general enterprise control set also falls short.
- Do connectors inherit OpenAI's BAA?
OpenAI warns that third-party service availability leaves BAA coverage unconfirmed. Each connector or app needs its own data-flow and contract review. Record where PHI goes, which party receives it, and which agreement governs that party before enabling the connection for clinical work.