If PHI reaches an AI vendor without a signed BAA, that is an active compliance exposure. Here is how to check whether your AI stack is actually covered.
If any AI feature in your product sends patient names, clinical notes, diagnoses, or message content to a large language model, the question of whether you have a Business Associate Agreement with that vendor is not a legal formality. It is the difference between a compliant integration and an ongoing unauthorized disclosure.
Under HIPAA, a business associate is any entity that creates, receives, maintains, or transmits protected health information on behalf of a covered entity or another business associate. There is no exception for AI. If your platform sends PHI to a model provider's API, that provider is functioning as your business associate, or as your subcontractor if you are a business associate yourself, which most healthcare software vendors are. A written agreement has to exist before that relationship is allowed. Sending PHI without one is not a paperwork gap you can quietly fix later. Each transmission is an impermissible disclosure, and a pattern of them is exactly the kind of issue that turns a routine complaint into a full enforcement action.
The good news is that major AI providers have moved fast here, and BAAs are now available for many API and enterprise products that were not offered even two years ago. The bad news is that availability is not the same as coverage, and that gap is where most teams get caught.
HHS has settled cases specifically over missing business associate agreements, not just data breaches. In one case, a business associate paid a $350,000 settlement after failing to have a signed BAA with a subcontractor that exposed PHI for more than 230,000 people. HHS has also flagged a $1.55 million settlement specifically for underscoring how important it is to actually execute these agreements, not just draft them. A missing or misapplied BAA is treated as its own violation, independent of whether the data was ever misused.
The consumer product versus the API. A vendor offering a BAA for its API platform tells you nothing about its consumer chat product. Consumer tiers are usually excluded from BAA coverage entirely and may retain or train on whatever is typed into them. If clinicians are pasting notes into a free chatbot because your product's own AI feature is too slow or too limited, that is a shadow AI problem no BAA of yours can solve, but customers will still connect it to your platform.
Coverage for some services, not the whole vendor. BAAs with AI providers are usually scoped to specific services or deployment tiers. A team signs a BAA covering the core model API, then adopts the same vendor's transcription tool or a new beta feature, assuming coverage that was never actually extended. Every time an integration expands, the scope question has to be asked again.
Signed but not configured. A BAA is a legal document. It does not reconfigure your integration on its own. Many providers require specific settings for covered workloads, things like zero data retention, disabled training, or particular regions. If your agreement assumes those settings and your production environment is still running on defaults from the prototype stage, the contract describes a system you are not actually running.
The wrapper vendor problem. Plenty of healthcare AI features run through an intermediary platform, an orchestration tool or analytics layer, that itself calls a large model provider behind the scenes. Your BAA chain has to be complete all the way down. You need an agreement with your direct vendor, and your vendor needs one with whatever it relies on. A line on a marketing page claiming HIPAA compliance is not the same as a signed agreement and a documented subprocessor list.
Nobody owns the inventory. The deepest gap is organizational. AI integrations accumulate quietly, a feature here, an internal tool there, an engineer's own workflow that happens to touch production data. Without one owned list of every place PHI meets a model, coverage cannot be verified because nobody has the full list of vendors to check.
If the data reaching an AI vendor is properly de-identified under HIPAA's Safe Harbor method or a formal expert determination, it is not PHI, and no BAA is required for that specific flow. This is a legitimate approach, and sometimes the right one. The word to pay attention to is properly. Free text clinical content, especially behavioral health notes, resists reliable de-identification. Nicknames, family details, small town context, and unusual circumstances can make a record identifiable even after standard identifiers are removed. If de-identification is the compliance strategy, it needs real engineering rigor and testing against actual data patterns, because a failure here means PHI has been going to a vendor with no BAA in place the whole time.
For teams that shipped an AI feature first and are reviewing it now, a straightforward sequence works. Start with an inventory of every point where product workflows or internal tools send data to an AI vendor. For each one, determine honestly whether PHI is present, including in free text fields. For each PHI flow, confirm a signed BAA exists, that it covers the specific service and tier actually in use, and that the technical configuration matches what the agreement assumes. Close the gaps in order of exposure, starting with any PHI flow that has no agreement at all, then misconfigurations, then documentation. Once the current state is clean, put a control in place so new AI integrations get added to the inventory before launch, not discovered afterward.
One more habit is worth building on top of this. Re-verify on a schedule. AI vendors add services, change tiers, and update terms faster than almost anything else in a typical stack. A BAA posture that was accurate in January can be stale by summer. Put the inventory review on a quarterly calendar with a named owner, and treat any new model, endpoint, or vendor adoption as its own trigger for a fresh check. Teams that manage this well are not the ones with the best lawyers. They are the ones with a list, an owner, and a repeatable cadence.
Do OpenAI, Anthropic, Google, and Microsoft offer BAAs? The major providers offer BAAs for at least some of their API or enterprise products, and cloud hosted routes through major platforms' HIPAA eligible services are common choices for covered workloads. Coverage and required configuration change often, so verify current terms for the exact service and tier in use rather than relying on anything read more than a few months ago, including this post.
We only send PHI to the model briefly and do not store it. Do we still need a BAA? Yes. Transmission alone is enough to create a business associate relationship. Retention affects your overall risk, not whether a BAA is required in the first place.
What if our AI vendor will not sign a BAA? There are three real options. Move to a vendor or tier that will sign one. Properly de-identify the data flow so PHI never reaches them. Or re-architect the feature so PHI does not need to leave your own environment.
Does a BAA cover every feature we build with that vendor? Not automatically. Coverage is usually scoped to specific services or tiers, so every new feature or endpoint built on top of an existing vendor relationship needs its own scope check.
Resolve Health Tech runs an AI Acceleration Sprint that maps every AI data flow in a product, verifies the agreement and configuration behind each one, and hands your team a prioritized fix sequence, with the first critical finding addressed within 14 days. Our services and pricing pages break down exactly what is included, and our FAQ covers the questions teams ask most before starting. Contact us to find out where your own AI stack actually stands.
Sana is a Technical Content Specialist at Resolve Health Tech. She specializes in breaking down complex architectural patterns, nearshore hiring trends, and software engineering workflows into actionable, human-friendly guides. Working alongside Resolve Health Tech's tech team, Sana ensures every piece of content is both highly readable and technically precise.