HIPAA-compliant AI tools

By Mat Steinlin, Head of Information Security

Last updated: July 2026

Every healthcare team building AI features asks the same question: which AI vendors can we actually use?

The short answer is that several major vendors offer HIPAA Business Associate Agreements. The longer answer is that a BAA is the starting point, not the finish line. Getting one means the vendor has agreed to handle your data responsibly. It doesn't mean your system is compliant.

This guide covers the full AI vendor landscape: which vendors offer BAAs for which products, how to get them, what each one covers, and what you still need to build regardless of which vendor you use.

One distinction worth making before the table: vendors describe their products as "HIPAA eligible," not "HIPAA compliant." Eligible means the vendor's infrastructure can support HIPAA-covered workloads and they will sign a BAA. Whether your implementation is compliant depends on how you configure it and what your team builds around it. The two terms are not interchangeable, and vendors use "eligible" deliberately. HIPAA compliance is also self-attested, not certified by any third party. There is no HIPAA certificate. Your organization assesses and documents its own compliance posture.

Which AI vendors offer HIPAA BAAs

What a BAA doesn't cover

Every BAA in the table above covers the same thing: the vendor's handling of your data. It does not cover what happens before the request is sent or after the response returns.

The infrastructure between your application and the model is your responsibility:

• Audit logging. Who accessed what data and when. HIPAA requires this; no LLM vendor generates it for you.

• Encrypted log storage. The logs you create contain PHI. They need encryption at rest and controlled access.

• Log retention. Six years under HIPAA. Most operational log pipelines aren't designed for this.

• Key management. Scoped, rotatable API keys with proper attribution across environments.

• Access controls. Who in your organization can send PHI to which models, under what conditions.

• Third-party service coverage. Any analytics, logging, or monitoring tools that process your application's data also need BAAs. Gaps here are one of the most common compliance failures practitioners report.

• PHI de-identification (optional). Removing identifiers before prompts and restoring them after responses is not required by HIPAA or any vendor BAA, but reduces exposure if other controls fail.

A consistent architectural mistake is applying these controls post-processing, after PHI has already reached the AI layer, rather than enforcing them upstream before any model call is made. By the time you're de-identifying a prompt, the data has already been exposed.

And the technical surface is a fraction of overall compliance. The vendor management, documentation, and employee training obligations that HIPAA requires tend to be underestimated by engineering-led teams.

For the full breakdown, see What an AI BAA actually covers.

Chapters

The compliance infrastructure underneath it all

A BAA with any vendor in this guide is necessary but not sufficient.

Aptible LLM Gateway is a managed compliance layer that sits between your application and all supported LLM providers. One Aptible BAA covers all supported models. Audit logging, PHI de-identification, and key management are handled. You don't build them. When you switch models, your compliance posture doesn't restart.

For teams building with agentic AI and MCP, the MCP security guide covers the specific compliance and security requirements for tool-calling architectures where PHI can flow through model-driven workflows.

__

For BAA requirements broadly, see What is a HIPAA BAA. For the technical requirements that apply to any LLM usage in a HIPAA-covered environment, see HIPAA-Compliant AI: What Developers Need to Know.