Google Cloud: the Vertex AI safety stack
Lesson 4 of 5 in Guardrails in the Cloud: Implementing Controls on AWS, Azure, and GCP.
Vertex AI is Google Cloud’s model platform, and its first guardrail layer ships inside the model API itself: configurable safety filters on Gemini models. Responses are scored against harm categories — harassment, hate speech, sexually explicit content, and dangerous content — and you set a blocking threshold per category, from block low and above (strictest) through block medium and above to block only high and, for approved cases, off. Two details matter for governance. First, the API returns the safety ratings with every response, so your gateway can log the scores even for traffic it allows — a running record of how close to the line your application lives. Second, some protections are non-configurable: certain categories of egregious content (child sexual abuse material among them) are blocked regardless of your settings — a floor the customer cannot trade away.
For hallucination control, Vertex offers grounding: anchor Gemini’s answers in Google Search results or in your own data (via Vertex AI Search over your document corpus), with responses carrying citations and grounding-support metadata your application can inspect and threshold. Same governance pattern as AWS and Azure — hallucination handled as a measurable, gateable quantity — with the distinctive option of grounding against the live web.
Around the model sit the familiar companions. Vertex AI model monitoring watches deployed models for input drift and training-serving skew, and Google’s generative AI evaluation tooling scores outputs on quality and safety criteria. Audit trails run through Cloud Audit Logs, and IAM handles least-privilege access to models and their configurations.
One piece of history worth knowing in a governance course: the model card itself is a Google invention — the 2019 paper Model Cards for Model Reporting (Mitchell et al.) proposed the standardised model fact sheet that SageMaker Model Cards, Hugging Face model cards, and half the documentation requirements in modern AI law now descend from. When the EU AI Act demands technical documentation and instructions for use, it is asking, in legal language, for a rigorous model card.
| Capability | AWS | Azure | Google Cloud |
|---|---|---|---|
Harm-category content filtering | Bedrock Guardrails content filters (6 categories, tunable strength) | Azure AI Content Safety (4 categories, severity 0–6 thresholds) | Vertex AI configurable safety filters (per-category block thresholds) |
Injection & jailbreak defense | Prompt-attack filter within content filters | Prompt Shields (direct + indirect/XPIA) | Model Armor prompt screening |
Hallucination / grounding check | Contextual grounding checks (grounding + relevance thresholds) | Groundedness detection (with correction mode) | Grounding with Google Search or your data; grounding-support metadata |
PII / sensitive-data handling | Sensitive-information filters (block or mask; custom regex) | Purview DLP + PII detection via Azure AI Language | Model Armor with Sensitive Data Protection integration |
Model-agnostic policy API | ApplyGuardrail API | Content Safety standalone APIs | Model Armor (model-independent) |
Evaluation & red-teaming | Bedrock model evaluation; SageMaker Clarify | Foundry evaluators, adversarial simulator, AI red-teaming agent (PyRIT) | Gen AI evaluation service |
Invocation logging & audit | CloudWatch metrics, CloudTrail, model invocation logging | Application Insights tracing (OpenTelemetry), Azure Monitor, Purview audit | Cloud Audit Logs, safety ratings returned per response |
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.