← All Google Cloud AI guidesSection 6 · 6.1, 6.2

Security, responsible AI, explainability and monitoring

Section 6: securing AI systems (Model Armor, safety filters, Sensitive Data Protection, VPC Service Controls), responsible AI and fairness, Explainable AI methods, and Model Monitoring for training-serving skew, drift, concept drift and attribution drift, plus monitoring gen AI in production. Includes a monitoring lab.

1. Security, responsible AI and explainability

Securing AI systems

Risk	Control
Prompt injection, jailbreaks, malicious URLs in prompts or retrieved documents	Model Armor: screens prompts and responses for injection and jailbreak attempts, sensitive data, malicious URLs and harmful content; works across models and can be enforced through templates and floor settings
Harmful generated content	Gemini safety filters: harm categories (hate speech, harassment, sexually explicit, dangerous content) with configurable block thresholds; plus non-configurable protections
Users pasting PII or secrets into an LLM, or the model echoing them	Sensitive Data Protection inspection and de-identification (also inside Model Armor), regular expressions for simple fixed patterns, output filtering
Data or model exfiltration	VPC Service Controls perimeters, private endpoints, IAM least privilege, CMEK, organization policies, audit logs
Over-privileged agents and tools	Separate service accounts per agent or tool, scoped permissions, human approval for risky actions
Poisoned training data or supply chain	Data validation, provenance and lineage, trusted base images, Artifact Analysis vulnerability scanning

Regex for patterns, SDP for PII, Armor for prompts, filters for harm, VPC-SC for exfiltration. Pick the narrowest tool that matches the threat in the question.

Responsible AI

Bias enters through unrepresentative data, historical labels and proxies (ZIP code standing in for race). Evaluate metrics per slice and compare groups with fairness metrics such as demographic parity, equal opportunity (equal recall) and equalized odds.
Mitigate: collect better data, reweight or resample, remove proxies, adjust thresholds per policy, and document decisions in model cards and datasheets.
Monitor fairness in production, not only at launch; review gen AI outputs with safety evaluations and red-teaming.

Explainable AI on Agent Platform

Method	Model types	Notes
Sampled Shapley	Any model, including non-differentiable (trees, ensembles), tabular	Approximates Shapley values; more paths = more accurate, slower
Integrated Gradients	Differentiable models (neural networks), tabular or images	Needs gradients; baseline choice matters
XRAI	Images (differentiable models)	Highlights salient regions, easier to read than pixel maps
Example-based explanations	Models with embeddings	Returns nearest training examples; good for spotting mislabelled data and explaining by analogy

Enable explanations when uploading or deploying the model (explanation spec with method and parameters), then call explain on the endpoint, or request explanations in batch inference. Feature attributions are also what Model Monitoring uses to detect attribution drift.

Feature attributions explain what the model used, not causality. A high attribution for "ZIP code" may reveal a fairness problem rather than a business insight.

Fairness metrics in one table

Metric	Equal across groups	Use when
Demographic parity	Positive prediction rate	Outcomes (offers, approvals) should be distributed evenly
Equal opportunity	True positive rate (recall)	Qualified people in every group should be found equally
Equalized odds	True positive and false positive rates	Both kinds of error should be balanced
Predictive parity	Precision	A positive prediction should mean the same in every group

These criteria generally can't all be satisfied at once when base rates differ. Choose with domain and legal input, document the choice in the model card, and monitor it.

2. Monitoring and troubleshooting

What can go wrong after launch

Problem	Meaning	Detect with
Training-serving skew	Production input distribution differs from the training data (often a preprocessing bug or a different source)	Model Monitoring with the training dataset as baseline
Data (prediction) drift	Production inputs change over time compared with an earlier production window	Model Monitoring comparing recent windows
Concept drift	The relationship between inputs and label changes (fraudsters adapt); inputs may look the same	Ground-truth performance tracking (needs labels): precision/recall over time
Feature attribution drift	The features the model relies on change importance	Model Monitoring with Explainable AI enabled
Operational issues	Latency, errors, saturation, cost	Cloud Monitoring metrics and alerts, Cloud Logging, request-response logging to BigQuery

Model Monitoring on Agent Platform

Attach a monitor to a model version (Model Monitoring v2) or an endpoint; it works on endpoints, batch inference and models served elsewhere if you supply the data.
Choose the baseline: training data for skew, or a past production window for drift.
Choose the features, a distance measure (L-infinity for categorical, Jensen-Shannon divergence for numeric), thresholds per feature, a sampling rate and a schedule (monitoring interval).
Alerts go to email, Cloud Monitoring notification channels or Pub/Sub (which can trigger a retraining pipeline).
Request-response logging to BigQuery provides the raw data for analysis and for joining with labels later.

Model Monitoring v1 (endpoint-centric jobs) and v2 (model-centric monitors) both appear in material; default thresholds and APIs differ by version. Learn skew vs drift vs attribution drift and what each baseline is.

Monitoring and testing gen AI

Log prompts, responses, latency, token counts, safety ratings and user feedback (with PII controls).
Run the evaluation dataset on a schedule and on every prompt or model change (regression testing), using Agent Platform Evals with computation and LLM-as-a-judge metrics.
Track groundedness and hallucination rates for RAG, and refusal and safety-block rates.
Watch for model version changes: pin model versions in production and re-evaluate before moving to a new one.
Use Cloud Trace and logging for agent and tool-call traces; Model Armor findings flow to Security Command Center.

Troubleshooting order

Did the system break? Errors, latency, quota, a deployment change, a missing feature.
Did the inputs change? Skew (pipeline bug) vs drift (world changed).
Did the relationship change? Concept drift, confirmed with fresh labels.
Fix the cause: repair preprocessing for skew; retrain on recent data for drift and concept drift; add features if the world changed in a way the model can't see.

Retraining doesn't fix training-serving skew caused by a bug: the new model trains on the same correct data and is served the same broken inputs. Fix the serving pipeline.

3. Lab: Model Monitoring and drift

Using an endpoint from the serving lab, enable request-response logging and create a model monitor with the training table as baseline, a short interval and low thresholds.
Send normal traffic, then traffic with one feature shifted (for example multiply monthly_spend by 3).
Find the skew alert; identify which feature crossed its threshold and the distance value.
Decide whether this is skew or drift, and what you'd do for a pipeline bug vs a real market change.
Enable explanations (Sampled Shapley) on the model and request explanations for five rows; compare the top features with ML.GLOBAL_EXPLAIN or your offline analysis.
Slice evaluation by one group column and compute recall per group (equal opportunity).

Clean up: delete the monitor, undeploy models and delete the endpoint.

4. "Which control or monitor?" chooser

Pick an item to see what it means, why, and the tempting wrong choice.

Pick one above.

5. Sample outputs

What the tools return. Expand an item to see a typical result and what to read in it.

Illustrative output, not captured from a real project. IDs, numbers and some field names are invented or simplified, and formats change between releases. Learn the shape and the fields called out under each one.

Model Monitoring alert (email / Pub/Sub payload, simplified)Feature skew detected

Model monitor: churn-monitor   Objective: FEATURE_SKEW
Baseline: bq://PROJECT_ID.shop.train   Window: last 24h, sampling 50%
feature           distance   threshold   metric
monthly_spend     0.47       0.30        jensen_shannon_divergence   ALERT
plan_type         0.04       0.30        l_infinity                  ok
country           0.36       0.30        l_infinity                  ALERT

What to look at: Two features exceed their thresholds against the training baseline, so this is skew. A jump right after a release suggests a serving pipeline bug (for example spend now in cents instead of dollars); a gradual rise suggests the population changed. Check before retraining.

6. Scenarios

Exam-style situations: how to diagnose each one, the likely cause and the fix.

7. Searchable reference

Item	Meaning

8. Flashcards (click to flip)

9. Common gotchas in one list

Skew baseline is training data; drift baseline is past production.
Concept drift needs labels; input monitoring can't see it.
Retraining doesn't fix a serving bug.
Sampled Shapley for trees; Integrated Gradients for differentiable models; XRAI for image regions.
Aggregate metrics hide group harms: slice evaluation.
Fairness criteria conflict; choose with policy input and document.
Model Armor for prompt attacks and sensitive data; regex for simple fixed patterns.
VPC Service Controls, not IAM alone, stop exfiltration.
Least-privilege identities per agent tool.
Monitor operations too: latency, errors, cost, quota.

10. Practice quiz (18 questions)

Score: 0 / 0