HIPAA Does Not Certify Products. That Badge Is Not a BAA.

> TL;DR: HIPAA does not certify software, models, or chat windows. HHS has said it does not endorse private "certifications" of the Security Rule, and those certificates do not take the legal obligation off you. What people treat as a "HIPAA-compliant" product is usually a specific SKU (often an API or enterprise plan) plus a signed Business Associate Agreement plus settings the vendor names in writing. The consumer app with the same logo is a different product. A signed BAA still does not make your use compliant. Run the questions below before PHI moves.

Someone on the floor found a chatbot that felt finished. The vendor's site mentioned HIPAA. A SuperGrok plan, a ChatGPT Plus seat, a Claude Pro login, a Gemini tab. It looked like the covered channel.

It usually isn't.

I get it. The word is on the page. The product looks like work software. Staff are trying to go faster, not leak a patient. The gap is quieter than a bad actor: HIPAA never created a product stamp, so marketing had to invent one. The legal pages, if you read them, are often more honest than the badge.

This is the same paperwork-versus-reality problem I've watched across 500+ organizations. New coat of paint. Same test.

HIPAA does not certify products

HIPAA applies to covered entities and business associates, not to a model name on a pricing page.

A business associate is a person who, on behalf of a covered entity, creates, receives, maintains, or transmits protected health information, or who provides services that involve a disclosure of PHI. That definition includes a subcontractor that handles PHI for the vendor you hired. (Source: 45 CFR 160.103.)

If you put PHI into an AI tool so it can draft, summarize, code, or answer on your behalf, that vendor is in the business-associate world. You do not get to skip the contract because the interface is a chat box.

HHS is direct about the certificate people wish existed. There is no Security Rule standard that requires an organization to "certify" compliance. A covered entity may hire an outside firm to evaluate its program. That evaluation is a business decision. HHS does not endorse or otherwise recognize private organizations' "certifications" regarding the Security Rule, and those certifications do not absolve covered entities of their legal obligations. Performance of an outside "certification" also does not stop HHS from later finding a security violation. (Source: HHS OCR FAQ 2003, content last reviewed July 26, 2013.)

Google Cloud says the same thing in its own HIPAA guide: there is no certification recognized by HHS for HIPAA compliance, and complying is a shared responsibility. (Source: Google Cloud, HIPAA Compliance, updated August 27, 2026.)

Microsoft says it too: there is currently no certification standard HHS approves to demonstrate HIPAA or HITECH compliance by a business associate. (Source: Microsoft, HIPAA & HITECH.)

When a landing page says "HIPAA," it is not a government mark. It is a vendor describing a path they may support: a BAA, a product surface, and a configuration. Read it that way and the rest of this gets simpler.

The actual test, in the regulation's words

You may disclose PHI to a business associate only if you obtain satisfactory assurance that the associate will appropriately safeguard the information (45 CFR 164.502(e)(1)(i)). The Security Rule says the same for electronic PHI (45 CFR 164.308(b)(1)). The written contract is how you document those assurances (45 CFR 164.308(b)(3), 164.502(e)(2)). (Source: 45 CFR 164.502; 45 CFR 164.308.)

Order matters. Assurance first. Contract documents it. A "HIPAA" line in a footer documents nothing.

The BAA also has required pieces: permitted uses, safeguards, subcontractor flow-down, breach notice, return or destroy. Those live at 45 CFR 164.504(e). We walked through them in Business Associate Agreements: What They Are and Why You Need One.

A signed BAA is still not the program. We wrote the longer version in A Signed BAA Isn't "Satisfactory Assurance". Short version for an AI tool: the PDF is not evidence the chat window you are about to use is the product the PDF describes.

Your own obligations stay. Risk analysis when the environment changes, including when someone adds a model. Unique users. Activity review. Training that names the tools staff may not paste a patient into. Minimum necessary. That is the living program. The vendor agreement does not run it for you.

Same logo, two products

This is the trap I keep seeing on evaluation calls.

The brand will sign a BAA for one surface: an API, an enterprise workspace, a listed "HIPAA-eligible" service. The consumer chat with the same name, on a personal card, is a different product. Staff do not experience them as different. The legal pages do.

I am not picking a fight with any of these companies. Several of them say the split out loud if you leave the marketing page. The system problem is that the badge and the SKU do not travel together, and a practice under 1,000 employees is the buyer most likely to miss that.

Vendor terms change. Confirm the current legal page and the signed paper before PHI moves. Accurate as of August 27, 2026.

| Vendor | Not the BAA path | The path they describe | |---|---|---| | xAI (Grok) | grok.com, the X app, personal SuperGrok | API: BAA questionnaire, reviewed case by case. Enterprise FAQ: support under some circumstances. ZDR is an optional API setting, not a HIPAA rule. | | OpenAI (ChatGPT) | Free, Plus, Pro, and ChatGPT Business (OpenAI says no BAA for Business) | API BAA via baa@openai.com (no enterprise contract required). ChatGPT Enterprise/Edu: sales-managed. Listed HIPAA-eligible products. (Help) | | Anthropic (Claude) | Claude Free, Pro, Max | HIPAA-ready API or Enterprise. Primary Owner must activate HIPAA and accept the BAA. Many features stay out of scope. (Help) | | Google (Gemini) | Consumer Gemini; Gemini in Chrome | Cloud: execute the BAA and use covered products only. Workspace Gemini: only under the Workspace BAA and included-functionality list. | | Microsoft | A personal Copilot / consumer chat login | BAA sits in the Product Terms / DPA for in-scope services (Azure, including Azure OpenAI; Microsoft 365 Copilot on commercial). Using Microsoft does not on its own achieve HIPAA compliance. |

Sources for the table: xAI API security and Enterprise FAQs; OpenAI, Anthropic, Google Cloud HIPAA, and Microsoft pages linked above.

Read that table as a pattern, not a shopping guide. We are not ranking these vendors. We are showing that the honest answer is almost always: which product, which agreement, which settings, in writing, before PHI.

SOC 2 Type 2 belongs in this paragraph because it gets used as a substitute stamp. A SOC 2 report is an auditor's opinion on a vendor's controls against the AICPA Trust Services Criteria. It is useful diligence. It is not a HIPAA certification, and a Trust Center sitting behind an NDA is not a BAA.

How to read one vendor's own legal page (without picking a fight)

xAI is a clean worked example because the legal pages already do the distinguishing. I am using them because I read them. The same reading works on the others.

The API security page does not say "Grok is HIPAA compliant." It says: to inquire about a BAA, complete the questionnaire; a team reviews it and follows up. (Source: xAI API security FAQ.)

The enterprise FAQ, aimed at API customers, answers "Is xAI HIPAA compliant?" with: under some circumstances, they can support a customer's HIPAA obligations. (Source: xAI Enterprise FAQs.)

That is a path. It is not a blanket stamp on grok.com.

Zero Data Retention, on xAI's own docs, is an optional team-wide API switch. They warn that it disables Files, Collections, Batch, stored conversation state, and more, and they do not recommend it for most customers. If a BAA or a lawyer tells you to turn it on, that is a contract and configuration choice. HIPAA's text does not say "zero data retention." Treating a vendor feature as if it were a required implementation specification is the same sloppiness we criticize when someone stamps encryption "REQUIRED." Encryption at rest and in transit is addressable under 45 CFR 164.312(a)(2)(iv) and 164.312(e)(2)(ii). Addressable means implement it if reasonable and appropriate, or document why not and use an equivalent alternative (45 CFR 164.306(d)). It does not mean optional. Get the label right.

I use AI tools to draft. A marketing outline in a consumer chat is not a patient chart. The line is the data, not the logo.

Seven questions before PHI moves

Print these. Run them on the tool already sitting in a browser tab. If you are vetting a new app someone generated last week, use the ten-question PHI App Readiness worksheet too. These seven are the SKU test. The worksheet is the program test. You want both.

1. Which product is this, exactly? Consumer chat, team workspace, API, or a named "healthcare" SKU? Same logo does not mean same contract.
2. Is there a signed BAA in our files that names this product surface? A questionnaire in progress is not a BAA. A BAA for "the API" does not cover the consumer app.
3. What is in scope, and what is carved out? Anthropic publishes feature-level exclusions. OpenAI publishes eligible products and endpoints. Google publishes covered products and included functionality. If the vendor cannot show the list, you cannot give satisfactory assurances about it.
4. What happens to prompts and outputs? Training, default retention, deletion, ZDR or "modified retention" if the vendor requires it. Read their current terms. Do not assume.
5. Who else sees this data? Host, model, plugins, connectors, logging, support. Subcontractors that handle PHI need to be bound (45 CFR 160.103; 164.308(b)(2)). A Drive connector or an MCP that ships PHI to a third party is often your problem even when the model vendor's BAA is silent on that hop.
6. Did we redo the risk analysis when this tool showed up? Adding an AI workflow is an environmental change. 45 CFR 164.308(a)(1)(ii)(A) still wants an accurate and thorough assessment of ePHI in the environment you actually have.
7. Who is allowed to paste what? A policy nobody can find, and a chatbot every staff member can open, is how shadow-AI starts. There is still no AI exemption. The map of what already applies is at AI in healthcare: the rules, in plain English.

If you cannot answer 1–3 with paper, do not put a patient name in the box while you "just try it."

What a signed BAA still does not do

Suppose you did it right. Enterprise SKU. Signed BAA. Eligible features only. Retention set the way the agreement describes.

You still own the workflow. Google's BAA does not make an external Drive share compliant. Microsoft says using its services does not on its own achieve HIPAA compliance. OpenAI's API BAA does not write your acceptable-use policy. That is the satisfactory-assurances point: the contract covers their obligations. Your staff, your prompts, your connectors, your review of logs, your incident clock. Those stay yours.

A polished new app with a "HIPAA" footer is a different trap. We covered that in Would You Bet an Audit on an App That Looked Ready?. This post is the badge. That post is the demo. Both fail the same way: visual maturity is not a program.

The program this actually sits in

Live Compliance is built for the part a vendor badge cannot fake. Vendor attestations and BAA tracking so "satisfactory assurance" is a record, not a folder. Risk analysis that has to be redone when someone adds a tool. Training that can name the AI your staff are not allowed to paste a patient into. Policies that match the practice. Continuous monitoring of system activity, so logs are reviewed instead of stored. Incident workflow with a clock.

The AI tool, if it is a real business associate on a real SKU with a real BAA, can sit inside that program. The program is what tells you whether it belongs there.

We have spent 16 years watching the gap between what a product page promises and what a vendor can actually show — across 500+ organizations, with a 100% audit success rate. See how the platform fits together, or talk to us before the next chatbot on your floor gets a patient name.

If you only do one thing this week: pick the AI tool your staff already opened, and answer questions 1–3 in writing.

Frequently Asked Questions

Does HIPAA certify software as "HIPAA compliant"?

No. HIPAA applies to covered entities and business associates. HHS has said it does not endorse or otherwise recognize private organizations' certifications regarding the Security Rule, and those certifications do not take the legal obligation off the covered entity (HHS OCR FAQ 2003). Google Cloud and Microsoft state the same point in their HIPAA materials: HHS does not recognize a HIPAA product certification.

Is Grok HIPAA compliant?

Not as a brand-wide stamp. xAI's public API docs point HIPAA questions to a BAA questionnaire reviewed case by case. The enterprise FAQ says they can support a customer's HIPAA obligations under some circumstances. Consumer Grok (grok.com, the X app, personal SuperGrok) is not that path. Confirm the signed BAA and the product surface in writing before any PHI. (Source: xAI API security FAQ; xAI Enterprise FAQs.)

Is ChatGPT HIPAA compliant?

Not the consumer apps, and not ChatGPT Business. OpenAI offers a BAA for API use (request via baa@openai.com) and for sales-managed ChatGPT Enterprise or Edu, plus listed healthcare products. Eligible endpoints and features are listed by OpenAI and can change. (Source: OpenAI BAA help article.)

Can I put PHI into Claude or Gemini?

Only on the SKU the vendor's BAA actually covers, after the BAA is in place, and only with the features they list as eligible. Anthropic requires a Primary Owner to activate HIPAA on a HIPAA-ready Enterprise org (or a HIPAA-ready API org) and still excludes many features. Google Cloud requires an executed BAA and covered products; Workspace Gemini is a separate included-functionality analysis. Consumer Claude and consumer Gemini are not those products.

Does a SOC 2 report make a vendor HIPAA-compliant?

No. SOC 2 is a third-party examination of a vendor's controls. It is useful evidence in due diligence. It is not a HIPAA certification, and it does not replace a BAA or your risk analysis.

Does a signed BAA make our use of the tool compliant?

No. The BAA documents satisfactory assurances for the vendor's side of the relationship (45 CFR 164.502(e), 164.308(b), 164.504(e)). You still need the safeguards, the right product surface, workforce rules, and a risk analysis of the workflow. See satisfactory assurances.

Is Zero Data Retention required by HIPAA?

No. Some vendors offer ZDR or modified retention as a condition of their BAA path or as an extra control. That is their contract and architecture. HIPAA does not name "zero data retention" as an implementation specification. Confirm what your agreement requires before you treat a toggle as the rule.

> Accuracy & legal note. This article is a plain-language summary of HIPAA requirements as of August 27, 2026, based on the HIPAA Rules (45 CFR Parts 160 and 164) and HHS guidance current as of that date, plus each named vendor's public legal or help pages as of that date. Regulations, OCR guidance, enforcement priorities, and vendor SKUs, BAA scopes, and feature lists change. This is general educational information, not legal advice — verify current requirements at hhs.gov/hipaa, at the vendor's current legal pages, or with your compliance counsel before acting. Platform capabilities described reflect Live Compliance as of the publish date. Last updated: August 27, 2026.