How to Verify a HIPAA-Compliant Chatbot Before Launch

There is no HIPAA certification for a chatbot. No agency at HHS issues one, no auditor stamps a model, and no vendor badge means what it implies. What actually makes an AI agent HIPAA compliant is three layers checked together: a signed Business Associate Agreement, the Security Rule's technical safeguards in place and provable, and an execution trail showing PHI never reached an unlogged model call or an unauthorized log. Most buyer checklists stop after the first layer, and that is exactly why compliance gaps tend to surface after the contract is signed, not before.

That pattern shows up constantly in procurement reviews: legal checks the BAA box, security skims a safeguards list, and the agent itself, the part that actually decides what happens to a patient's message, never gets examined. Here is how to close that gap before you are the one explaining it after launch.

There's No HIPAA Certification for a Chatbot, So What Are You Actually Checking

When a vendor's homepage says "HIPAA compliant chatbot," ask what they mean by it, because the phrase has no regulatory backing. HHS does not certify software, platforms, or vendors under HIPAA. Compliance is a standing you maintain through contracts and configuration, not a credential you earn once.

That reframes the whole evaluation. You are not checking a box for "certified" or "not certified." You are checking whether three independent things are true at the same time: the paperwork exists (the BAA), the technical controls exist (encryption, logging, access restrictions), and the agent's actual behavior respects both. A vendor can pass the first two and still fail the third if PHI ends up in a prompt nobody scoped, or in a log nobody restricted. That third layer is where most checklists stop looking, and it is the one you can only verify by asking to see the system in action, not by reading a compliance page.

The Business Associate Agreement: What It Covers and Who Has to Sign

A BAA is the contract that makes a vendor legally responsible for the PHI it touches on your behalf. If the chatbot vendor processes, stores, or even transiently handles patient information, you need a signed BAA with them before a single real conversation happens, not after your first production incident.

The part teams miss is subcontractors. Your chatbot vendor almost certainly calls other services: a model provider, a transcription service, maybe a cloud logging tool. Your BAA needs to cover those downstream processors too, either directly or through a chain of agreements the vendor manages. Ask for the list of subprocessors that touch PHI and confirm each one is covered. A BAA that only names the primary vendor and ignores the model provider underneath it is a BAA with a hole in it.

This is also the moment to confirm scope. A BAA that covers the vendor's "support platform" in general terms is not the same as one that explicitly covers the AI agent product, its logging, and its integrations. Read the exhibit, not just the cover page.

The Security Rule Safeguards a Vendor Has to Prove, Not Promise

The HIPAA Security Rule names a specific set of technical safeguards, and the ones that come up in nearly every evaluation are encryption in transit and at rest, audit logging, access controls, and least privilege. None of these are exotic. All of them are things a vendor should be able to show you, not just claim.

Voiceflow documents its own security and compliance posture, including SOC 2 Type II, ISO 27001, GDPR, and HIPAA, on its HIPAA compliance page and the underlying SOC 2 and ISO 27001 pages, with supporting documentation available through the Trust Center. The point is not which vendor you pick. The point is that these artifacts should exist and be requestable before you sign anything, for any vendor you are evaluating.

Keeping PHI Out of Prompts and Logs by Design

This is the section most checklists skip, and it is the one that actually determines whether your agent is safe in production. Encryption and access controls protect data at rest. They do nothing to stop PHI from landing somewhere it should not in the first place, like a free-form prompt sent to a model, or a debug log nobody scoped for PHI.

The fix is architectural, not procedural. Instead of letting an agent reason freely over whatever a patient types, you design deterministic steps around the moments PHI actually enters the conversation: collecting a date of birth, confirming an insurance ID, pulling a record. Those steps handle the sensitive fields explicitly, rather than passing them into open-ended model reasoning where they can surface in a prompt, a completion, or a trace you did not intend to keep.

What makes this verifiable, rather than a design promise, is execution tracing. Every API call, every model invocation, every data lookup should be visible after the fact, so you can confirm PHI moved exactly where your design intended it to and nowhere else. Voiceflow's platform traces every call at this level of detail, and the PII redaction add-on masks sensitive fields in production conversations before they reach logs and transcripts, which is the concrete answer to "how do you keep PHI out of logs": you don't trust the model to avoid it, you build the agent so it never has the opportunity to leak it, and you keep the execution trace to prove it.

If a vendor cannot show you a trace of a real conversation, down to the individual call, you cannot verify this layer. You are back to trusting a claim.

Can You Put PHI in Front of a Third-Party LLM?

Sometimes, but only within the specific services the model provider has agreed to cover under a BAA. Major LLM providers offer BAAs for a defined subset of their services, not their entire product line, and a provider's general terms of service do not automatically extend to the enterprise or HIPAA-eligible tier. Verify the exact plan and endpoint your vendor is routing PHI through, not just the provider's name.

This is where the design pattern from the last section pays off twice. If your agent's architecture already limits how much PHI reaches an open model call in the first place, by handling sensitive fields in deterministic steps rather than free-form reasoning, you have fewer prompts to worry about covering under a BAA at all. Less PHI reaching the model means less surface area for a provider's BAA to need to cover, and fewer places a gap in that coverage can hurt you.

The Questions to Bring to a Vendor Review

Walk into the legal and security review with specific questions, not a general request for "compliance documentation." Here is the set that maps to the three layers above.

That last question matters more than it looks. A live agent handoff that passes a full transcript to a support platform is passing PHI too, and the handoff step itself needs the same logging and access discipline as everything upstream of it. A vendor that has answers to the first four questions but goes quiet on handoff has not actually finished the architecture.

Before you sign, run a pilot conversation that deliberately includes a PHI field, and ask the vendor to walk you through where it went, call by call. If they can show you the HIPAA compliance documentation, the safeguards, and the trace in the same meeting, you have something you can actually defend in review. If any one of those three is missing, you have a vendor with a badge and a gap, and you will find the gap after launch instead of before it. For a broader look at what enterprise buyers should expect from AI agents for customer service in regulated environments, and how teams are applying the same scrutiny in healthcare specifically, the questions above are the ones worth bringing to your next vendor call.