HIPAA-Compliant AI Is a Plumbing Problem, Not a Model Problem: What We Learned Shipping It on Vertex

If you run a healthcare business and you want to put AI on patient data, the question you are actually asking is not "which model is smartest." It is "how do I do this without a compliance problem." And the honest answer is that HIPAA-compliant AI is about 90 percent plumbing and 10 percent model choice. The model is the easy part. Getting the data flow right is the work.

We know this because we shipped it. Smile PreVue, our dental AI product live in the App Store, runs its patient-facing image work on Google Vertex AI Gemini under a signed business associate agreement. Getting there taught us that the compliance lives in where the data is allowed to go, not in the prompt you write. Here is the framework we use, and where the traps are.

What does HIPAA-compliant AI integration actually require?

Three things, in order. A signed business associate agreement (a BAA) with the AI provider. That agreement has to cover the specific surface you are using. And you need your own data controls that keep protected health information off any surface the BAA does not cover.

Notice what is not on that list: picking the "most compliant" model. Compliance is not a property of a model. It is a property of the arrangement around the model, the contract, the surface, and the controls. The same weights can be perfectly compliant in one place and a violation in another. That is why we say compliance lives in the data flow. If you get the flow right, the model choice is a normal engineering decision about capability and cost.

This reframing matters because it changes who owns the problem. It is not a research question for your data scientists. It is an integration question for whoever owns your data path.

The surface trap most buyers fall into

Here is the mistake we see most often. A team tries a model on a free consumer surface, it works great, and they assume they can ship it. But the same model is HIPAA-eligible on one surface and completely off-limits on another.

Gemini is the clean example. It is BAA-covered on Vertex AI and on Google Workspace covered plans. Consumer Gemini and Google AI Studio are not covered (Google Cloud HIPAA guidance, 2026). So a healthcare team can prototype on AI Studio, watch it work, and ship the exact same model in a way that quietly violates HIPAA, because they moved the model but not the coverage.

This is not a Google quirk. It is true across every major lab. The enterprise and cloud API tiers offer BAAs. The free consumer chat surfaces do not. Whatever lab you use, the rule is the same: the surface, not the brand, determines coverage. Prototype wherever you like, but ship only on a surface you have a BAA for.

What we shipped, and which lab we picked and why

We will be specific, because vague case studies are worthless. Smile PreVue lets a dentist photograph a patient and generate a photorealistic preview of a proposed cosmetic outcome. That image work touches patient data, so it has to run on a HIPAA-grade path.

We run it on Google Vertex AI Gemini under a BAA. The decisive constraint was not that Vertex is the "best" AI, it was that we needed a strong multimodal image path on a surface we could get a BAA for, and Vertex gave us both the covered surface and the model we needed in one place. That is the whole reason. We are not crowning a lab. We picked the option that satisfied the hard constraint with the least plumbing.

We say this deliberately, because we are multi-provider by default. The same discipline applies whether you land on Google, Anthropic, or OpenAI. Each of the major labs offers BAAs on covered surfaces, and the right pick is the one whose covered surface carries the model your workflow actually needs. You can read more about how this played out in our work case studies. The lesson generalizes: state the constraint, pick to satisfy it, and move on.

The plumbing checklist, provider-agnostic

Whatever lab you choose, the build looks the same. This is the checklist we run.

• Get the BAA signed before a single byte of PHI moves. Not after the prototype, not "we'll paper it later." Before. The agreement is the foundation, and everything else assumes it exists.
• Pin the covered surface and block the rest in code. Decide which surface you are on (Vertex, a cloud API tier, an enterprise plan) and make it impossible for PHI to reach an uncovered one. This is an engineering control, not a policy hope.
• Minimize the PHI you send. Give the feature the least data it needs to work, and de-identify wherever you can. Data you never sent is data you never have to protect.
• Log access, encrypt in transit and at rest, and write the policy down. The direction of the 2026 rulemaking expects all of it, and it is good hygiene regardless.

That last point is timely. HHS OCR's proposed update to the HIPAA Security Rule is the first significant revision since 2013, and it moves several long-standing "should" items toward "must," including multi-factor authentication, encryption at rest and in transit, vulnerability scanning, and network segmentation, with explicit attention to AI-enabled health technology (HHS OCR NPRM). If you build your data path to that standard now, you are building toward where the rules are heading rather than away from them.

The subtle item on that list is the second one, blocking the uncovered surfaces in code. It is tempting to treat "only use Vertex" as a rule the team remembers. It is not. Under deadline pressure, a well-meaning engineer will reach for whatever surface is fastest to test against, and if that path is technically reachable from your code, PHI will eventually flow through it. So we make the covered surface the only one the production code can call. The credentials for the uncovered surfaces simply do not exist in that environment. A control you can enforce beats a policy you have to remember, especially once more than one person is touching the code.

Build vs buy for HIPAA AI

You do not always have to build this yourself, and we will tell you when not to. Off-the-shelf healthcare AI tools that already carry a BAA can be exactly the right call for a standard workflow. If your need is a common one and a vendor already covers it, buying the covered tool is faster and cheaper than standing up your own path.

You build when the workflow is your product, when you need real control of the data path, or when no vendor covers your exact surface and model combination. Smile PreVue is a build case: the AI preview is the product, so the data path had to be ours. If it had been a back-office task on a standard tool, we would have pointed to a covered vendor and saved everyone the work. Honest either way.

FAQ: HIPAA-compliant AI

Is ChatGPT or consumer Gemini HIPAA compliant? Not on the free consumer surfaces. To use those models with PHI you need the enterprise or cloud API tier with a BAA in place.

Does a BAA make me compliant? It covers the provider's processing of PHI. It does not cover your side. You still owe the data controls, the access logging, and the encryption on your end.

Which lab is the most HIPAA-friendly? All three major labs offer BAAs on covered surfaces. Pick by the surface and model your specific workflow needs, not by brand loyalty.

Get the plumbing right first

The teams that stall on healthcare AI usually stall because they treated it as a model question and got surprised by the compliance one. Flip the order. Decide the data path, get the BAA on the covered surface, block the uncovered surfaces in code, and the model becomes the straightforward choice it should have been all along. That is how we practice AI integration for business, and it is why the Smile PreVue image path shipped clean.

If you are weighing whether to build or buy a HIPAA-grade AI workflow, start a conversation with us and we will help you figure out which side of that line you are on.