A business associate agreement with an LLM vendor covers how that vendor handles protected health information you send it — and very little else that matters. Signing one does not make a use case compliant. It typically obliges the vendor to safeguard the data, restrict its own use of it, and not train on it, and it usually requires you to be on a specific API tier rather than a consumer product, since consumer chat interfaces are generally not BAA-eligible at all. What it does not address is everything on your side of the boundary: whether the prompt you constructed needed PHI in it, what your own application logs when it records requests and responses for debugging, how long you retain that, and whether a model output is safe to write into a clinical record. Most real exposure in these systems comes from application-side logging and retention rather than from the model vendor, which is precisely what the BAA does not reach.
What Does a BAA With an LLM Vendor Actually Cover?
A BAA with an LLM provider obligates that vendor to safeguard the PHI it receives, restrict how it uses that data, and generally not train future models on it. That’s real and meaningful — but it’s a narrow slice of the actual compliance surface. It says nothing about your own application’s logging, your own retention practices, or whether the underlying use case makes clinical sense. Treat the BAA as necessary and nowhere near sufficient.
Which API Tiers Are Even Eligible
Verify current vendor terms directly before architecting anything — every detail below changes, and a stale claim here is actively harmful. As of this writing, the landscape looks roughly like this: OpenAI offers a BAA on ChatGPT Enterprise and on the API, with zero data retention available on request — but notably, several API features (Assistants, Threads, the Files API, image generation, and image inputs) have at various points been excluded from ZDR coverage, so eligibility is feature-specific, not blanket. Anthropic offers a BAA on Claude through the API and through enterprise plans, but zero-retention is contractually disabled for BAA-covered models, which instead carry a 30-day retention window by default — and BAAs signed before December 2, 2025 cover API usage only, requiring a separate agreement for the HIPAA-ready Enterprise plan. Google’s Vertex AI is a covered service under the Google Cloud BAA, with inference running inside your own GCP project and region once the BAA is accepted and the project-level HIPAA flag is enabled.
The consistent thread across all three: consumer-facing chat products are generally not the BAA-eligible tier, and the specific feature or endpoint you’re using may not be covered even within an otherwise BAA-eligible API.
Zero Retention, and What It Means
Zero data retention, where available, means the vendor doesn’t store your request and response content after processing it. It’s a meaningful setting, and it’s not universal — as the Anthropic example above shows, a BAA-covered model can still carry a default retention window even under a signed BAA, and that retention period is exactly the kind of detail worth confirming explicitly rather than assuming from the general marketing language around “enterprise” or “HIPAA-ready” tiers.
The Exposure a BAA Doesn’t Reach
This is the correction this post exists to make. Your own application almost certainly logs requests and responses for debugging, error tracking, and observability — and if PHI is in the prompt, it’s now sitting in your own logs, under your own retention policy, which the vendor’s BAA and zero-retention setting have no bearing on whatsoever. Map the actual path: your application constructs a prompt, your application may log it, the vendor processes it under whatever retention terms apply, and the response comes back — potentially also logged on your side. The BAA boundary covers exactly one segment of that path. Most real PHI exposure in AI-assisted healthcare tools traces back to the segments the BAA doesn’t touch, not to the model vendor itself.
Do You Actually Need PHI in the Prompt?
This is worth asking before any of the above, because it can remove the compliance question rather than manage it. HIPAA’s minimum necessary standard applies to AI requests exactly as it does anywhere else. De-identification or structured abstraction — extracting the specific clinical concept a prompt needs rather than pasting the full chart — genuinely works for a large share of AI-assisted use cases, and it’s the option most teams skip because sending the full context feels simpler in the moment.
Model Output Is Not a Clinical Source
A generated response is not a validated clinical source, and it shouldn’t be written into a chart without the same review a human-authored note would get. This connects directly to the write-back governance question I cover throughout this site’s EHR integration content — an AI-generated note entering the record still has to clear the same clinical-safety review as any other write, and treating model output as pre-validated because it “sounds clinical” is a real, specific risk worth naming plainly.
A Practical Architecture
Draw the actual BAA boundary explicitly in your architecture documentation — application, your logs, the vendor, the vendor’s logs — and treat every segment outside that boundary with the same scrutiny you’d apply to any other PHI-handling component. Minimize what crosses the boundary in the first place, per the minimum-necessary point above, and configure zero retention wherever it’s genuinely available and covers the specific feature you’re using.
Next Steps
A signed BAA with an LLM vendor is table stakes, not a finish line — the real compliance work is in your own application’s logging, retention, and prompt design, which no vendor agreement touches. For the broader picture on what actually makes any app HIPAA compliant, see our dedicated post. If you’re architecting an AI-assisted healthcare product, talk to our team about drawing the BAA boundary correctly before you build around it.