HIPAA-Compliant AI: Who Actually Signs a BAA?

HIPAA-Compliant AI: Which LLM Platforms Actually Sign a BAA

HIPAA-compliant AI shows up on a lot of vendor landing pages as a settled fact, a badge next to the logo. It is not that simple, and treating it that way is how protected health information ends up somewhere it should never have gone. The only thing that actually determines whether an AI tool can legally touch PHI is a signed business associate agreement between your organization and that vendor, covering that specific product tier. Everything else, general security claims, industry awards, a compliance page on the website, is context. The BAA is the actual answer.

What a BAA Covers vs. What General Security Claims Cover

Vendors frequently point to general enterprise security credentials as evidence of HIPAA-compliant AI. Those credentials matter, but they are not the same thing as a signed BAA.

What a Business Associate Agreement Actually Is

A business associate agreement is a legally required contract between a healthcare organization, the covered entity, and any vendor that will create, receive, maintain, or transmit protected health information on its behalf, the business associate. The BAA specifies exactly how that vendor will safeguard PHI, what it is permitted to do with it, how it will report a breach, and what happens if it fails to meet those obligations. Without a signed BAA in place, using an AI vendor with PHI is a HIPAA violation regardless of how secure the vendor's infrastructure actually is.

Why "Enterprise-Grade Security" Is Not the Same as HIPAA-Compliant AI

A vendor can have genuinely excellent security certifications, encryption, access controls, penetration testing, and still not be usable for PHI without a signed BAA, because HIPAA compliance is a legal and contractual question, not purely a technical one. The reverse is also true: a signed BAA does not automatically mean an organization is using the tool correctly, since the healthcare organization still has to follow the terms of that agreement, apply appropriate access controls internally, and avoid pasting PHI into any product tier the BAA does not actually cover.

Why Some AI Vendors Refuse to Sign a BAA

Not every AI vendor offers a BAA, and the reasons are usually structural rather than a simple oversight.

1. Consumer-first product design. A product built primarily for individual consumers often was not architected with the logging, access control, and data handling separation HIPAA compliance requires.
2. Training data practices. A vendor that trains on user conversations by default for its consumer tier cannot extend that same practice to PHI, requiring a genuinely separate enterprise offering to support a BAA at all.
3. Legal and liability exposure. Signing a BAA means accepting specific legal obligations and liability, a decision some vendors have simply not made a business priority yet.
4. Product tier limitations. A vendor may offer a BAA only on its highest enterprise tier, leaving lower tiers, including ones organizations may already be using informally, without coverage.

Pros and Cons of Different HIPAA-Compliant AI Approaches

• Pro of using a vendor with a confirmed BAA: legal clarity. Everyone knows exactly what is permitted and what happens if something goes wrong.
• Pro of de-identifying data before AI use: reduces exposure regardless of vendor status. If PHI never enters the tool, the BAA question becomes less urgent for that specific workflow.
• Pro of a documented vendor review process: catches gaps before they become violations. A formal check for BAA status before any new AI tool gets adopted prevents informal, unapproved use.
• Con: BAA-covered tiers are often more expensive. The enterprise tier that includes compliance coverage frequently costs meaningfully more than the consumer version staff may already be using informally.
• Con: BAA terms still require internal discipline to follow. A signed agreement does not enforce itself; staff still need training on what is and is not permitted.
• Con: shadow use of unauthorized tools is a real risk. Staff frustrated by a slower procurement process for the compliant tool sometimes default back to a familiar, unauthorized one.

“After testing multiple AI models on coding, research, and business prompts, combined outputs produced more reliable results than any single model.” Internal multi-model evaluation, Talkory research team.

Real Scenarios Worth Thinking Through

These scenarios are illustrative, showing how HIPAA-compliant AI questions play out in practice rather than presented as verified case studies.

Consider a clinical documentation team that assumed their AI drafting tool was HIPAA-compliant AI because the vendor's website mentioned enterprise security certifications, without ever confirming a signed BAA existed for their specific account tier. A compliance review found no BAA was on file, meaning months of AI-assisted documentation had technically been generated without the required legal coverage.

Consider a hospital system that negotiated a BAA with its primary AI vendor but discovered staff were also using a different, unapproved consumer AI tool for quick clinical questions, entirely outside the BAA's coverage. The written agreement with one vendor did not prevent informal use of a second, uncovered tool, a governance gap rather than a contract gap.

Consider a healthcare startup evaluating several AI vendors for a new product feature, prioritizing which vendors would sign a BAA before evaluating any other feature, since a vendor without BAA coverage was disqualified from the shortlist regardless of how capable the underlying model was.

A Vendor Due Diligence Checklist

1. Ask directly whether a BAA is available for your specific product tier, not just for the vendor's enterprise offering in general.
2. Get the BAA in writing before any PHI enters the tool, not as a follow-up after adoption has already begun informally.
3. Confirm what happens to PHI in the event of a breach, and whether notification timelines meet your organization's own compliance obligations.
4. Check whether PHI is excluded from model training under the specific agreement, not just under the vendor's general consumer policy.
5. Build a documented approval process for new AI tools, so BAA status gets checked before adoption rather than discovered during an audit.
6. Train staff on what counts as PHI and which approved tools are actually covered, reducing the risk of well-meaning but unauthorized use.

Why Talkory Wins on Enterprise Data Controls

Talkory Enterprise offers custom data residency controls, dedicated infrastructure, and extended query history, the kind of foundational controls a healthcare compliance team evaluates when assessing any AI vendor. For HIPAA-specific requirements, including whether a business associate agreement is available for your account, that is a specific conversation to have directly with the Enterprise team rather than an assumption to make from general product marketing.

Until that coverage is confirmed in writing for your account, the safest practice with any AI tool, Talkory included, is to avoid pasting protected health information into queries and to use de-identified or hypothetical scenarios for research and comparison purposes instead.

Final Verdict: The BAA Is the Answer, Not the Marketing Page

HIPAA-compliant AI is not something a vendor achieves once and advertises forever. It is a specific, current, written business associate agreement covering the specific product tier your organization actually uses, combined with your own internal discipline in following its terms. General security claims, however impressive, do not substitute for that document.

The direct recommendation: before any protected health information touches an AI tool, get written confirmation of a signed BAA covering that exact product and tier, build a documented vendor review process so this gets checked before adoption rather than after an incident, and default to de-identified data for any AI use where BAA coverage has not been explicitly confirmed.