TL;DR: Any AI tool that processes PHI requires a signed BAA before data flows to the vendor. ChatGPT Enterprise and OpenAI API can sign one; ChatGPT Health, Free, Plus, and Team cannot. Claude enterprise and API tiers offer BAAs. Transmitting PHI without a BAA is a breach regardless of whether data leaked, the violation is in the transmission.
The most common HIPAA mistake healthcare organizations make with AI tools is not the one that generates headlines. It is not a massive data breach. It is a clinical coordinator pasting patient notes into ChatGPT to draft a care summary, using a tier that does not have a Business Associate Agreement in place.
No data leaked. The AI generated a useful summary. Nothing went wrong in any outcome-affecting sense. But under HIPAA, the transmission itself was a breach, and it is reportable.
Understanding which AI tools require a BAA, which vendors offer one, and what a BAA actually needs to say is now a basic operational requirement for any healthcare organization using AI tools in clinical or administrative workflows.
The BAA rule in plain English
HIPAA requires covered entities, hospitals, clinics, physician practices, health plans, and their administrative partners, to have a signed Business Associate Agreement with any vendor that creates, receives, maintains, or transmits Protected Health Information on their behalf.
PHI is defined broadly: any individually identifiable health information held or transmitted by a covered entity, including names, dates, geographic identifiers, medical record numbers, diagnoses, treatment information, and billing data.
An AI tool is a business associate if it processes PHI as part of the services it provides to a covered entity. Using ChatGPT to summarize clinical notes, using an AI scribe to document patient encounters, using an AI tool to extract diagnosis codes from discharge summaries, all of these involve an AI vendor processing PHI on behalf of the covered entity.
The BAA is not automatic. It must be requested from the vendor and signed before PHI flows to that vendor's systems. Signing a BAA after the fact does not cure a retroactive HIPAA violation.
Which AI vendors offer BAAs
This landscape has shifted significantly in 2025 and 2026 as major AI vendors clarified HIPAA policies under healthcare customer pressure.
OpenAI / ChatGPT
- ChatGPT Enterprise: BAA available. OpenAI will enter into a Business Associate Agreement for Enterprise customers, enabling HIPAA-eligible workloads.
- OpenAI API: BAA available with zero data retention configuration. Developers building HIPAA-eligible applications on the API can sign a BAA and configure zero data retention.
- ChatGPT Free, Plus, Team: No BAA available. Cannot be used with PHI.
- ChatGPT Health (launched January 2026): OpenAI will not enter into a BAA for this product. The product is designed for consumer health literacy, not regulated healthcare operations. Cannot be used with PHI from covered entities.
Anthropic / Claude
- Claude Enterprise and API: BAA available through Anthropic's enterprise agreements. Organizations using Claude for healthcare workflows should execute a BAA through Anthropic's enterprise or API program before allowing PHI input.
- Claude.ai consumer tiers: Not assessed for HIPAA use. Do not use with PHI without confirming BAA availability.
Microsoft / Copilot
- Microsoft 365 Copilot for Healthcare: HIPAA-eligible under Microsoft's existing Enterprise Agreement BAA for Microsoft 365. Healthcare organizations with an EA already covering Microsoft 365 services are typically covered for Copilot for Healthcare workloads.
- Microsoft Azure OpenAI Service: HIPAA-eligible under the Microsoft Azure BAA, which covers Azure services broadly.
- Copilot in Bing or consumer products: Not covered by enterprise BAAs.
Google / Gemini
- Google Workspace with Gemini: Covered under Google's standard HIPAA BAA for Workspace, for in-Workspace use.
- Gemini API (Vertex AI): Covered under Google Cloud's HIPAA BAA.
- Gemini.google.com (consumer): Not covered. Do not use with PHI.
What the BAA must actually say
A HIPAA-compliant BAA with an AI vendor is not a checkbox. It must establish the following:
Permitted uses and disclosures. The BAA must specify what the vendor can do with PHI. AI vendors routinely include language about using data to improve their models, covered entities must verify whether this is permitted and push back if not. Most enterprise BAAs explicitly prohibit use of PHI for model training.
Security safeguards. The vendor must agree to implement appropriate administrative, physical, and technical safeguards for PHI. For AI vendors, this includes encryption at rest and in transit, access controls, and audit logging. Request specifics, not general assurances.
Subcontractors and downstream vendors. AI vendors often rely on cloud infrastructure providers (AWS, GCP, Azure) that also process the data. The BAA should confirm that subcontractors handling PHI are also bound by equivalent BAA obligations.
Breach reporting obligations. The vendor must agree to report security incidents and breaches to you within the HIPAA-specified timeframes. The Breach Notification Rule requires covered entities to notify HHS within 60 days of discovering a breach. Your BAA with AI vendors must give you enough lead time to meet that obligation.
Return or destruction of PHI. The BAA must address what happens to PHI at contract termination. For AI tools, this includes model weights trained on PHI, cached inputs, and any data retained for abuse prevention or service improvement.
Data residency. Confirm where PHI is stored and processed. Some covered entities have obligations to keep PHI within specific geographic regions, particularly for government healthcare programs.
The model training question every BAA must address
The most important question to put to any AI vendor before signing a BAA is also the one most frequently glossed over: does the vendor use PHI to train or improve its models?
For general-purpose AI tools, the default answer is often yes for consumer tiers and no for enterprise tiers, but "no" should be confirmed in writing in the BAA. The concern is not merely contractual. If a model is trained on PHI, that PHI is arguably retained in the model's weights, creating a re-identification risk that is difficult to quantify and nearly impossible to audit.
Enterprise BAAs from OpenAI, Anthropic, and Microsoft for their respective enterprise tiers generally prohibit use of input data for model training. Confirm this is in your specific agreement, not just assumed from the vendor's general policy page, which can change without notice.
AI scribes and clinical documentation tools
AI medical scribe tools, products that listen to clinical encounters and generate structured notes, present a specific BAA challenge because audio recording of physician-patient conversations is highly sensitive and the processing chain involves multiple vendors.
If you deploy an AI scribe product, trace the data path:
- Who receives the audio recording? (the AI scribe vendor)
- Where is the audio processed? (cloud infrastructure)
- Who provides the transcription model? (may be a different vendor)
- Who generates the structured note? (may be yet another model)
Each layer of this chain that involves PHI requires a BAA. The AI scribe vendor's BAA should flow down to its subcontractors, but verify this. If the scribe vendor is a small startup using third-party transcription and LLM APIs under their own agreements, the downstream BAA coverage may be incomplete.
What to do if employees are already using non-BAA AI tools with PHI
This situation is more common than most healthcare organizations acknowledge. Clinical staff often adopt productivity AI tools on their own, the same behavior that creates shadow AI risk in other industries creates a HIPAA breach risk in healthcare.
The remediation steps:
Conduct an AI tool inventory. Identify every AI tool currently used by clinical and administrative staff, whether organizationally deployed or individually adopted. Ask staff directly, anonymous survey if needed, what tools they use to process or summarize patient information.
Classify each tool against BAA status. For each tool, determine whether a BAA is available and whether one is in place. Tools in active use without a BAA where PHI may have been transmitted should be treated as potential breach events.
Assess breach notification obligations. If PHI was transmitted to a vendor without a BAA, you have a potential reportable breach. Work with counsel to assess whether the disclosure meets the breach definition under 45 CFR 164.402 and what notification obligations apply.
Implement policy and training. Issue written guidance specifying which AI tools are approved for use with PHI, which require organizational accounts with BAAs in place, and which are prohibited in clinical and administrative workflows. Train all staff. Document the training.
For a broader governance framework covering AI tool adoption controls, see the AI governance checklist for healthcare startups and AI data privacy requirements for small teams.
Checklist: HIPAA BAA review for AI vendors
Work through this before authorizing any AI tool for clinical or administrative use:
- Does the tool process, receive, or could it receive PHI in normal use?
- Does the vendor offer a BAA for the tier/product being deployed?
- Is the BAA signed and on file before PHI flows to the vendor?
- Does the BAA explicitly prohibit use of PHI for model training?
- Does the BAA cover downstream subcontractors and cloud providers?
- Has IT confirmed appropriate technical controls (encryption, access logs, MFA)?
- Are users trained on which tiers are authorized and which are not?
- Is there a process to detect unauthorized use of non-BAA AI tools?
- Is there a defined breach response procedure if PHI is transmitted without a BAA?
What happens when a BAA is missing and PHI flows anyway
HIPAA's breach notification rule is triggered regardless of whether data was actually accessed by an unauthorized person. If PHI was transmitted to an AI vendor without a BAA, OCR treats this as a presumed breach and requires notification to affected individuals, HHS, and potentially media (if the breach affects 500 or more individuals in a state). The fact that the vendor used encryption, did not retain the data, and was not hacked is relevant to risk assessment but does not automatically eliminate the notification obligation.
The notification requirement is why the "we did not know" defense rarely works well with BAA compliance. Healthcare organizations are expected to know which of their vendors handle PHI and to obtain BAAs in advance. OCR's enforcement pattern on BAA violations shows consistent findings that covered entities failed to identify business associates or delayed execution of agreements after identifying the need. Auditing your current AI tool stack against this checklist, and documenting the audit results, is the foundational step for any credible HIPAA compliance posture involving AI.
If an employee has already used an AI tool without a BAA for PHI processing, the response is: stop the use immediately, document the incident, conduct a breach risk assessment using HHS's four-factor analysis, and consult legal counsel before making a notification determination. Prompt response and documented risk analysis are the factors that most influence OCR's enforcement posture when issues are self-identified.
Related Reading
- Midjourney's scanner and what FDA SaMD clearance actually requires
- FDA AI medical device SaMD compliance guide 2026
- Clinical AI decision support: FDA January 2026 guidance explained
- AI medical malpractice 2026: who is liable when diagnostic AI gets it wrong
- AI governance for healthcare startups: HIPAA, FDA, and vendor risk
- AI data privacy for small teams: GDPR and CCPA
