HIPAA-Compliant AI: How to Use AI With PHI Legally

No AI tool is "HIPAA compliant" by itself. HIPAA regulates organizations and how they handle Protected Health Information (PHI), not software products.

To use AI with PHI legally, you need a signed Business Associate Agreement (BAA) with the AI vendor, plus your own privacy and security controls. Without a BAA, sending PHI to an AI service is a HIPAA violation.

This guide explains the BAA gate, the difference between covered entities and business associates, how de-identification lets you skip HIPAA entirely, and which major AI vendors will sign a BAA. It is practical guidance, not legal advice, so confirm the details with counsel and the official sources cited below.

Why No AI Tool Is "HIPAA Compliant" by Itself

HIPAA does not certify software, so no AI tool is "HIPAA compliant" on its own. The law applies to covered entities and business associates and to how they use PHI.

The rules come from three parts of HIPAA. The Privacy Rule limits how PHI is used and shared. The Security Rule sets safeguards for electronic PHI. The Breach Notification Rule sets what happens when protected data leaks.

A vendor can offer HIPAA-eligible settings and sign a BAA. That makes the tool usable with PHI. It does not make you compliant on its own.

Compliance is a shared job. The vendor secures its side. You control access, training, configuration, and how staff actually use the tool. Both sides have to hold.

So when a vendor markets a tool as "HIPAA compliant," read it as a claim about their side of the work. Your obligations do not go away because the marketing page says the word compliant.

Covered Entities vs Business Associates: Where AI Vendors Fit

A covered entity is a health plan, health care clearinghouse, or health care provider that transmits health data electronically. Most clinics, hospitals, and insurers are covered entities.

A business associate is any outside party that creates, receives, maintains, or transmits PHI on behalf of a covered entity. Billing firms, cloud hosts, and analytics vendors are common examples.

An AI vendor becomes a business associate the moment it handles PHI for you. If your staff send patient data to an AI service to summarize, transcribe, or analyze it, that vendor is a business associate under HIPAA.

This matters because business associates are directly liable under HIPAA. They must apply safeguards and can face enforcement, which is why serious vendors will negotiate a BAA before touching PHI.

Healthcare-adjacent nonprofits and NGOs can be caught too. If your organization handles PHI for a covered entity, you may be a business associate even if you do not think of yourself as a healthcare company.

The BAA: The Gate Before Any PHI Goes to an AI Vendor

The Business Associate Agreement is the legal gate you must clear before sending PHI to any AI vendor. No signed BAA means no PHI, full stop.

A BAA is a written contract required by the Privacy and Security Rules. It binds the vendor to protect PHI and to use it only as the contract and the law allow.

A HIPAA BAA has to describe permitted uses of PHI, require appropriate safeguards, require breach and security-incident reporting, bind subcontractors to the same terms, allow you to terminate for material breach, and require return or destruction of PHI when the relationship ends.

For AI specifically, the BAA should address model training. Make sure the agreement stops the vendor from using your PHI to train or improve its models unless you give explicit written permission.

In our AI-compliance work with healthcare-adjacent and nonprofit clients, the failure mode we see most is staff pasting client data into consumer AI tools that have no BAA in place. The contract gap, not the technology, is what creates the violation.

What Counts as PHI: The 18 HIPAA Identifiers

PHI is health information that can be tied to a specific person and is held by a covered entity or business associate. It covers diagnoses, treatment, payment records, and more.

HIPAA lists 18 categories of identifiers that make data personally identifiable. These include names, geographic detail smaller than a state, all dates tied to a person except the year, phone and fax numbers, email addresses, and Social Security numbers.

The list continues with medical record numbers, health plan numbers, account numbers, certificate and license numbers, vehicle and device identifiers, web URLs, IP addresses, biometric identifiers, full-face photos, and any other unique identifying number or code.

The practical takeaway is simple. If the text you want to feed an AI tool contains any of these identifiers alongside health information, treat it as PHI and require a BAA.

When in doubt, assume it is PHI. The identifier list is broad on purpose, and guessing wrong on the side of caution costs you nothing.

Note that health data alone is not always PHI. It becomes PHI when a covered entity or business associate holds it and it can be linked to a person. Strip the link and the same clinical facts may fall outside HIPAA.

De-Identification: Use AI Without Triggering HIPAA

De-identified data is not PHI, so HIPAA does not apply to it. This is the cleanest way to use almost any AI tool without a BAA.

HIPAA gives two official methods under 45 CFR 164.514. Both are set by the HHS Office for Civil Rights, and you may use either one.

The Safe Harbor method works by removing all 18 identifier categories from the data. You also must not have actual knowledge that the remaining information could still identify someone.

The Expert Determination method works differently. A qualified statistical expert reviews the data and certifies in writing that the risk of re-identifying anyone is very small, then documents how they reached that conclusion.

De-identification has real limits. Stripping identifiers by hand is error-prone, free-text clinical notes hide identifiers in prose, and re-identification risk rises when data is combined with other sources. Treat de-identification as a documented process, not a quick find-and-replace.

Your Side of the Deal: Security Rule Safeguards

A signed BAA is necessary but not sufficient. You still owe your own safeguards under the HIPAA Security Rule, and enforcement often lands on the customer, not the vendor.

Follow the minimum necessary standard. Send the AI tool only the smallest amount of PHI needed for the task, and never dump a full record when a snippet will do.

Put access controls in place. Limit who can use the AI tool with PHI, use unique logins, and apply role-based permissions so people see only what their job requires.

Keep audit logs. Record who accessed PHI, when, and what they did, so you can investigate incidents and prove compliance during an audit.

Encrypt PHI in transit and at rest, and confirm the vendor does the same. Run a documented risk analysis before you deploy, and train staff on what they may and may not paste into any AI tool.

• Minimum necessary: send the least PHI required for the task.
• Access controls: unique logins and role-based permissions.
• Audit logs: track every access to PHI.
• Encryption: protect PHI in transit and at rest.
• Risk analysis and workforce training before go-live.

Which Major AI Vendors Sign a BAA

Several major AI vendors will sign a BAA, but only on specific products and only after you request and execute it. Availability and terms change, so verify each on the vendor's own trust page before you rely on it.

OpenAI will sign a BAA for its API and for sales-managed ChatGPT Enterprise accounts. Consumer ChatGPT and lower business tiers are not covered, so a BAA has to be arranged directly with OpenAI.

Anthropic will sign a BAA covering the Claude API and its HIPAA-ready Enterprise plans. Free, Pro, Max, and Team plans are not covered, and the organization owner must turn on HIPAA settings and accept the BAA.

For Microsoft, Azure OpenAI is HIPAA-eligible under the standard Microsoft BAA, which Microsoft makes available to covered entities and business associates. You still must configure the service correctly and sign the agreement.

Google will sign a BAA covering Vertex AI, where Gemini models run inside your own Google Cloud project. As with every vendor here, the tool is only covered once the BAA is signed and the service is configured for HIPAA use. Confirm current terms and plan names on each provider's trust page rather than trusting a screenshot.

How to Deploy AI With PHI the Right Way

Deploying AI with PHI safely follows a repeatable sequence. Work through it in order, and document each step so you can prove your decisions later.

Start by deciding whether the AI use case truly needs PHI at all. If de-identified data would do the job, use that and skip most of HIPAA.

If you do need PHI, the BAA comes before anything else. Never route real patient data through a tool until the signed agreement is in place and the service is configured for HIPAA use.

Then wire up your own safeguards and train the people who will use the tool. Most breaches trace back to a person, not a system.

• Confirm whether the task needs PHI, or whether de-identified data works.
• Sign a BAA with the vendor before any PHI is sent.
• Enable the vendor's HIPAA-eligible settings and turn off model training on your data.
• Apply minimum necessary, access controls, encryption, and audit logging.
• Run and document a risk analysis for the new workflow.
• Train staff on approved tools and what they may never paste into consumer AI.
• Set up a breach response plan and review it regularly.

Consumer AI vs BAA-Covered AI vs De-Identified Data

There are three ways to bring AI into a healthcare workflow, and only two are legal for PHI. The table below shows when to use each.

Consumer AI with no BAA is fine for general work but never for PHI. BAA-covered AI is the standard path when you must process real patient data. De-identified data lets you use almost any AI tool while staying outside HIPAA entirely.

Most organizations end up using a mix. They de-identify where they can, run a BAA-covered tool where they must, and keep PHI out of consumer chatbots completely.

• Consumer AI (no BAA): use for general, non-PHI tasks only. Verdict: never send PHI.
• BAA-covered AI: use when you must process real PHI. Verdict: the standard compliant path.
• De-identified data: use to unlock general AI tools safely. Verdict: best when identifiers are not needed.
• Overall verdict: de-identify when you can, use a BAA-covered tool when you must, and never paste PHI into a consumer chatbot.

The Breach Risk of Pasting PHI Into a Consumer Chatbot

Pasting PHI into a consumer AI chatbot with no BAA is a HIPAA violation. It is the single most common mistake we see, and it is entirely avoidable.

The problem is a disclosure of PHI to a vendor with no contract to protect it. Once that data leaves your control, you cannot guarantee how it is stored, logged, or used to train a model.

HIPAA treats this as a reportable breach. The Breach Notification Rule can require you to notify affected people and the HHS Office for Civil Rights, and the regulator can pursue enforcement and civil penalties.

The fix is policy plus tooling. Give staff an approved, BAA-covered tool for PHI, block or warn on consumer AI sites, and make the rule clear: if it contains an identifier, it does not go in an unapproved chatbot.