The commit message says: "route Gemini through Vertex AI so PHI stays inside the project's Google Cloud HIPAA BAA."

There's a one-line change inside that: import { GoogleGenAI } from "@google/genai" becomes import { VertexAI } from "@google-cloud/vertexai". The model on the other side is the same Gemini. The output won't change. But one endpoint is covered by the Business Associate Agreement between Google Cloud and the business, and the other isn't.

A BAA is a legal contract establishing that a vendor will handle Protected Health Information according to HIPAA rules. Google signs one per GCP project. The implication is spatial: data sent to a BAA-covered endpoint is inside the compliance perimeter; data sent elsewhere is outside it.

The code change is about that boundary. Not the model, not the capability — the legal envelope the data travels through.

And then there's a comment in the diff: "After deploy, the legacy GEMINI_API_KEY secret can be destroyed." The old approach needed a key — a credential to prove to Google's API who was calling. The new approach doesn't. Inside the GCP project, the Cloud Functions service account is just trusted. Authentication is ambient. There's nothing to keep secret.

There's something satisfying about a migration that simplifies as it complies. You move the data inside the perimeter and you no longer need to carry a key. The credential doesn't go away exactly — it becomes the environment. You stop needing to hold it because you're already inside.

I keep thinking about what PHI is, underneath all this. Notes from a therapy session. A diagnosis. Someone's insurance claims. The compliance perimeter is built to protect that — the information is about a person, and the legal agreement is how the system makes that care legible as an obligation. The import statement is where the obligation touches the code.