Gemini 3 Pro for HIPAA-grade AI, what we shipped on Vertex AI for Smile PreVue

Smile PreVue is the dental AI we built that turns a chair-side photo into a treatment preview. It is live on the App Store, it is HIPAA-grade, and the model under the hood is Google Vertex AI Gemini 3 Pro running under a signed Business Associate Agreement.

The decision to go with Gemini specifically, over Claude or GPT-4-class models, was not about which model is smartest. It was about which lab had the compliance posture to be in a dental office, today, without us building the compliance plumbing ourselves.

Here is the build, the trade-offs, and what we would tell you if you were about to make the same call.

Why Vertex AI Gemini, not Claude or GPT

The Smile PreVue brief was specific. A dental practice takes an intra-oral photo of a patient. The platform renders a treatment preview in under ten seconds. The patient leaves with a branded share link or a PDF report. The practice closes more cases because the patient saw the future smile before committing to the work.

Three providers we evaluated and what stopped them:

Anthropic Claude was strong on the reasoning side and the orchestration. The reason it was not the answer: as of the build window, Anthropic did not offer a production-ready BAA for healthcare PHI on hosted Claude. The roadmap was clear and the trajectory is real, but we needed a signed BAA in week one of build, not in quarter three.

OpenAI GPT-4 / gpt-image had similar compliance gaps for a healthcare BAA at the scale we needed. The image quality was excellent. The compliance posture for PHI through the public API was not yet where we needed it.

Google Vertex AI Gemini 3 Pro had what we needed: a signed BAA, FedRAMP-equivalent data handling, regional data residency, and an audit log we could surface to a dental practice's compliance officer. The model itself was as good as the alternatives for our use case (image-to-image transformation of a smile). The decisive constraint was the paperwork, not the model.

The lesson generalizes. If your workflow touches regulated data, the lab you can sign a contract with today beats the lab whose model benchmarks marginally higher.

What we built

The Smile PreVue smile-render pipeline has four pieces:

1. A FastAPI service that accepts an intra-oral photo upload from the iOS app or the web client
2. A pre-processing step that crops, normalizes lighting, and validates the photo is actually a clinical intra-oral shot (Vision API on Vertex)
3. A call to Gemini 3 Pro with a tuned system prompt that describes the treatment goal (veneers, alignment, whitening) and renders the predicted outcome
4. A post-processing step that watermarks the preview, generates the PDF report, and stores the preview in Cloud SQL with patient consent metadata

The full pipeline runs in roughly six seconds end to end. The Gemini call itself is about four of those six. The other two are pre and post processing, the network hops, and the image storage.

The model has a tuned system prompt that we iterated on for three weeks. The first version was clinically inaccurate (it kept rendering teeth as too white). The second version was over-cautious (it would refuse to render aggressive whitening even when the practice asked for it). The third version, which is what is live, threads the needle between clinical realism and the marketing value of "show the patient the outcome."

The compliance layer (the hard part)

The model is the easy part. The compliance layer is what differentiated this build from a weekend hackathon project.

The BAA. Signed with Google. The BAA defines what data Google can store, for how long, and what their audit obligations are. Without this, the entire product is non-deliverable to a dental practice in the US.

Data residency. All Vertex calls go to the US data centers. The PHI never leaves the US. We have written documentation we can hand to a compliance officer that shows the network topology and the regional configuration.

Audit logs. Every model call is logged to Cloud Logging with a tamper-evident retention policy. We retain seven years (HIPAA standard) and we can export the logs on demand. If a practice ever needs to defend a HIPAA audit, we can produce the entire chain of custody for any patient's photo in under an hour.

Patient consent. The iOS app and the web client capture explicit consent before any photo is uploaded. The consent text was reviewed by a healthcare compliance attorney. Yes, this took longer than we expected. Yes, it was worth doing properly.

De-identification. Faces are blurred in any image that ever leaves the practice's account (for marketing previews, share links, or our own internal training). Patient names are never in the model context. The PHI scope is intentionally narrow.

Audit-ready architecture. When the practice's compliance officer asks "where does the photo go and who sees it," we have a one-page diagram and a logged answer. The architecture was designed for that question to be answerable in five minutes.

This is what HIPAA-grade actually means. Not "we used Vertex AI." But "we used Vertex AI, signed the BAA, configured residency, retained the logs, captured consent, narrowed the PHI scope, and documented all of it."

What we would do differently

We have shipped four months of production Smile PreVue. Three things we got right, three things we would change.

Right: picking Vertex first, signing the BAA before writing any code, and building the compliance layer in parallel with the model layer. The team that tries to retrofit compliance onto a working prototype always over-spends.

Right: keeping the model call narrow. We do one thing, render a smile preview, and we do it well. We resisted the temptation to add "AI suggestions for treatment plans" or "AI-generated patient education content" until the core was rock-solid.

Right: investing in the eval harness. We have a test set of 200 anonymized intra-oral photos with expected outcomes. Every model update gets run against the harness before it ships. We have caught two regressions this way that we would otherwise have learned about from a dentist's email.

Would change: we underestimated the prompt iteration time. Three weeks of dental-specific prompt tuning was about a third more than we budgeted. Build the buffer in.

Would change: we should have built the audit-log export tool in week one, not in month two. The first practice that asked for it (during onboarding) was understandably nervous when we said "give us 48 hours." The right answer is "I can show you in five minutes."

Would change: we should have parametrized the system prompt by treatment type from the start. We initially had one prompt for all dental work. By month two we had three (veneers, whitening, alignment). The earlier we had treated prompts as first-class configurable assets, the cleaner the codebase would be today.

What this means if you are about to make the same call

If you are evaluating Gemini 3 Pro on Vertex AI for a healthcare, finance, or regulated workflow, the build is straightforward and the compliance work is the multiplier.

The model is a commodity. The BAA, the audit posture, and the operational discipline around regulated data are not. That is what we sell.

If you want our help running this play for your healthcare or regulated workflow:

Book a consultation · See the Smile PreVue case study · Read the approach