Is ChatGPT HIPAA compliant? What healthcare teams must check

ChatGPT is not automatically HIPAA compliant. OpenAI now offers several products and configurations that are eligible to support HIPAA-regulated work, but eligibility is not attached to the ChatGPT name as a whole. A healthcare organization has to use an eligible service, execute the applicable Business Associate Agreement (BAA), configure the environment correctly, and operate it with appropriate safeguards.

The useful question is therefore not simply “Is ChatGPT HIPAA compliant?” It is: “Can our organization use this exact ChatGPT product, under this exact contract and configuration, for this specific workflow involving protected health information?”

The short answer depends on which ChatGPT you mean

OpenAI’s currentHIPAA-eligible products listincludes ChatGPT for Healthcare, ChatGPT Enterprise with a Regulated Workspace, ChatGPT FedRAMP, ChatGPT for Clinicians, and specified API configurations with Modified Retention. Coverage is limited to the services and functionality identified in the applicable agreement.

A free or personal ChatGPT account is not listed as a HIPAA-eligible service. A familiar chat interface, business privacy settings, or a statement that customer data is not used for model training does not by itself make an account appropriate for PHI.

A practical account-by-account screening table

• Personal ChatGPT accounts: not listed by OpenAI as HIPAA eligible. Do not enter PHI into a personal account.
• ChatGPT Business: do not assume that general business privacy controls equal HIPAA eligibility. Confirm the current BAA position directly with OpenAI before any PHI use.
• ChatGPT Enterprise: OpenAI lists Enterprise with a Regulated Workspace, not every ordinary Enterprise deployment. Verify the workspace type, BAA, and covered features.
• ChatGPT for Healthcare: designed to support HIPAA-compliant use, with enterprise security and a BAA path. The organization still has to configure and govern it.
• ChatGPT for Clinicians: listed as an eligible product. Follow its specific BAA process and verify whether the intended feature and workflow are covered.
• OpenAI API: certain API configurations with Modified Retention may be eligible under an applicable BAA. The application owner remains responsible for the rest of the system around the API.

Product names, features, and contract terms change. Treat this table as a screening aid and check the executed agreement and current vendor documentation before approving a workflow.

A BAA is necessary, but it is not the whole answer

The U.S. Department of Health and Human Services explains that a cloud provider that creates, receives, maintains, or transmits electronic PHI on behalf of a regulated entity is generally a business associate. The parties must enter into an appropriate BAA, and the healthcare organization must also perform its own risk analysis and risk management.

A signed agreement establishes responsibilities. It does not automatically configure user permissions, disable an uncovered integration, select an appropriate retention setting, or stop a staff member from pasting the wrong patient’s information into a chat. Those are operational controls, and they still belong to the organization using the service.

Map every place PHI can travel

A review should cover more than the text box. In a modern AI workspace, PHI may appear in a prompt, uploaded file, audio transcript, generated response, shared conversation, connector, support request, audit log, export, or backup. A feature covered in the primary chat surface does not automatically mean every connected service is covered by the same agreement.

Before enabling a workflow, document at least:

• what data enters the service and why it is necessary;
• where prompts, files, outputs, logs, and backups are processed or retained;
• which people and service accounts can retrieve that data;
• which connectors, actions, or external tools can receive it;
• how access is removed when a staff member changes role or leaves;
• how an output is reviewed before it enters an EHR or reaches a patient;
• how incidents, deletion requests, and vendor changes are handled.

“Not used for training” is not the same as HIPAA compliant

A commitment not to train models on business data is meaningful, but it answers only one question. It does not explain retention, access, subprocessors, feature exclusions, deletion, incident handling, or whether the vendor has signed a BAA covering the service in use.

The same distinction applies to encryption. Encryption protects data in transit or at rest; it does not remove the need for a BAA or the organization’s own safeguards. HHS notes that a cloud provider can still be a business associate even when it stores only encrypted ePHI and does not hold the decryption key.

A seven-step approval checklist

1. Name the exact service. Record the product, plan, workspace, enabled features, API project, and intended users.
2. Define the workflow. Specify whether staff will draft notes, summarize referrals, analyze files, answer messages, or perform another approved task.
3. Execute and archive the BAA. Confirm that it covers the exact service and functions involved before introducing PHI.
4. Map the data journey. Include inputs, outputs, retention, support access, integrations, exports, and deletion.
5. Configure identities and permissions. Use organization-managed accounts, least privilege, appropriate authentication, and a documented offboarding process.
6. Test with nonproduction cases. Check wrong-patient context, accidental identifiers, oversharing, unsupported claims, and what happens when users invoke optional features.
7. Assign human review and reassessment. Identify who verifies each output and when the approval must be revisited after product, contract, model, or workflow changes.

What if someone already entered PHI into an unapproved account?

Do not assume that deleting the conversation resolves the issue. Stop further use of the account for PHI and follow the organization’s privacy and security incident process. Preserve only the evidence needed to understand what happened, notify the appropriate privacy or security contact, and document the account, data, recipients, integrations, and timestamps involved.

Whether the event is reportable depends on the facts and applicable law. That determination should be made through the organization’s established process, not by the employee who noticed the mistake or by the AI vendor’s marketing copy.

When a healthcare-specific AI workspace may be simpler

Some practices do not want to procure and configure a regulated enterprise deployment or build an application around an eligible API. A healthcare-focused workspace can package clinical workflows, administrative controls, a BAA path, and PHI safeguards into a product that is easier for a small team to operate.

That does not remove the practice’s responsibilities. The same questions still apply: what the agreement covers, how PHI is handled, which features are enabled, how long data remains, who can access it, and where human review occurs. Our security ledger,data journey, and BAA brief document those questions for this workspace so a practice can review specifics instead of relying on a badge.

The bottom line

Some ChatGPT products and configurations can support HIPAA-regulated work. ChatGPT as a brand is not universally HIPAA compliant, and a personal account should not be treated as a safe place for PHI. A defensible approval identifies the exact product, signed agreement, covered features, configuration, data journey, user controls, and human review process.

If any one of those elements is unknown, pause before entering patient information. The right answer is specific enough to document, test, and revisit—not a yes-or-no claim applied to every account carrying the ChatGPT name.