This domain is about 13% of the exam. It asks what can go wrong after launch (attacks, bias, data change, bad predictions, outages) and which Google Cloud feature detects it. The key distinction is training-serving skew versus prediction drift, and knowing what to do about each.
Identifying risks to AI solutions
Securing AI systems
| Threat | Description | Defence |
|---|---|---|
| Data exfiltration | Training data or model artifacts copied out | VPC Service Controls, private endpoints, IAM least privilege, CMEK, audit logs |
| Data poisoning | Attacker injects bad training examples | Validate data and provenance, restrict write access to training data, anomaly checks, version datasets |
| Model theft / extraction | Repeated queries reconstruct a model | Authentication and quotas, rate limiting, monitoring unusual query patterns, limit output detail (no raw logits) |
| Membership inference / model inversion | Probing reveals training records | De-identify data, differential privacy, regularisation, don’t overfit |
| Adversarial inputs | Crafted inputs that flip predictions | Input validation, adversarial training, anomaly detection on inputs |
| Prompt injection and jailbreaks (generative AI) | Instructions hidden in user input or retrieved documents override the system prompt | Separate system and user content, input and output filters, Model Armor and safety filters, least-privilege tools for agents, human approval for risky actions, treat retrieved content as untrusted |
| Sensitive data leakage in outputs | Model reveals PII or secrets | Sensitive Data Protection on inputs and outputs, grounding with access-controlled retrieval |
| Supply chain | Malicious packages, images or pretrained weights | Artifact Registry with vulnerability scanning and Binary Authorization, pinned dependencies, trusted model sources |
| Credential leaks | Keys in notebooks | Service accounts, Workload Identity, Secret Manager |
Secure-by-design checklist: dedicated service accounts per pipeline and endpoint, least privilege, private connectivity (PSC), encryption at rest (CMEK) and in transit, audit logging turned on, separate projects per environment, and the Secure AI Framework (SAIF) principles as Google’s guideline. Questions with “unintentional exploitation of data or models” want these controls, not more accuracy.
Responsible AI
Google’s AI Principles ask that systems be socially beneficial, avoid creating or reinforcing unfair bias, be built and tested for safety, be accountable to people, incorporate privacy design, uphold high scientific standards and be available for appropriate uses.
Practices:
- Define fairness for the use case with stakeholders. Metrics differ: demographic parity (equal positive rate), equal opportunity (equal true-positive rate), equalised odds (equal TPR and FPR), calibration within groups. They can conflict, and you must choose.
- Evaluate by slice: compute metrics per subgroup (region, age band, device). An overall metric can hide a failing group.
- Look at the data first: representation, label bias, proxies for protected attributes (postcode proxies for ethnicity), historical bias, sampling bias.
- Mitigate: rebalance or reweight data, collect more data for under-represented groups, remove or constrain proxy features, adjust thresholds per group where lawful, use fairness-aware training, and review with humans.
- Document: Model Cards (intended use, metrics, limits) and Data Cards. Vertex AI Model Registry and evaluation can hold them.
- Human oversight for high-stakes decisions.
- Safety for generative AI: safety filters and thresholds (hate, harassment, sexually explicit, dangerous content), grounding to reduce hallucination, content provenance (SynthID watermarking), red-teaming, and output evaluation.
- Tools: What-If Tool, Vertex model evaluation slices and bias metrics (the Vertex Model Evaluation fairness metrics), Explainable AI, TensorFlow Model Analysis (TFMA) for sliced metrics, and Fairness Indicators.
Assessing readiness
Before launch ask: Does performance beat a baseline and meet the business threshold on fresh, representative data? Are slice metrics acceptable? Are explanations sensible (do the top features make domain sense, no leakage)? Is the fairness assessment done and signed off? Has it been load-tested for latency and cost? Are monitoring, alerting, rollback and an owner in place? Are privacy and compliance reviews done? Was it validated on out-of-distribution and edge cases? A gradual rollout with a champion/challenger test lowers risk.
Explainability on Vertex AI
- Vertex Explainable AI gives feature attributions per prediction (and aggregated global importance). Methods:
| Method | Model types |
|---|---|
| Sampled Shapley | Any model, including non-differentiable (trees, ensembles). Approximate and slower |
| Integrated gradients | Differentiable models (neural networks), tabular or images |
| XRAI | Image models. Highlights contiguous regions |
| Example-based | Nearest training examples |
| AutoML tabular | Built-in feature importance |
- Enable by supplying explanation metadata (input and output tensors, baselines) and parameters at model upload. Request with
endpoint.explain()or batch prediction with explanations. For BQML useML.EXPLAIN_PREDICTandML.GLOBAL_EXPLAIN. - A baseline (reference input, for example average value or black image) defines what “no information” looks like. A poor baseline gives misleading attributions.
- Use explanations to debug (find spurious features and leakage), build trust with users and regulators, and to monitor attribution drift (below).
- Explanations show correlations used by the model, not causal truth.
Monitoring, testing and troubleshooting
Vertex AI Model Monitoring
Model Monitoring watches deployed models for input changes. It compares feature distributions and raises alerts (email, Cloud Logging, Pub/Sub) when a distance metric crosses a threshold you set per feature.
| Concept | Meaning | Reference compared with | Typical cause |
|---|---|---|---|
| Training-serving skew | Serving feature distribution differs from training data | The training dataset (BigQuery table, Cloud Storage file, or the managed dataset) | Different preprocessing pipelines, a bug, a feature missing or defaulted, a different data source in production |
| Prediction (input) drift | Serving feature distribution changes over time | Earlier serving data (a past window) | Seasonality, new user mix, upstream changes, real-world change |
| Feature attribution drift | The importance of features (Explainable AI attributions) changes between baseline and now | Training-time or earlier attribution values | The model relies on different features than before. Early warning even when single-feature drift is small. Requires explanations enabled |
| Output / prediction drift | The distribution of predictions changes | Earlier predictions | Shift in inputs or behaviour |
Details to remember:
- Metrics: Jensen-Shannon divergence for numerical features and L-infinity distance for categorical features. You set a threshold per feature (defaults exist) and monitor only the features you care about to reduce noise.
- Sampling rate (percentage of requests logged) and monitoring interval (for example every 24 hours, minimum 1 hour) control cost.
- Skew detection needs a training data source so the baseline can be computed. Drift needs only serving logs.
- Alerts go to email, Cloud Logging, Cloud Monitoring and Pub/Sub. A Pub/Sub alert can trigger the retraining pipeline (see the previous domain).
- Works for online endpoints (request-response logging) and batch predictions, and tabular models (AutoML and custom). Model Monitoring v2 extends to models served anywhere, with monitoring jobs scheduled over BigQuery or Cloud Storage data, so a model on GKE or Cloud Run can be monitored too.
- Labels are delayed, so skew and drift are leading indicators. They can detect trouble before accuracy drops. Skew says “production data isn’t what we trained on.” Drift says “the world is changing.”
What to do: Skew points to fixing the pipeline or preprocessing consistency (an engineering bug), and drift points to retraining on recent data. Retraining does not fix skew caused by a bug.
Establishing continuous evaluation
- Model evaluation with ground truth: collect actual outcomes (clicks, repayments, returns) and join with logged predictions. Run continuous evaluation (Vertex AI Model Evaluation on batches or a scheduled pipeline) to compute accuracy, precision, recall, AUC and business KPIs over time and by slice.
- Log predictions (endpoint request-response logging to BigQuery) so you can join with later labels, with a sampling rate to control cost. Include model version, features, prediction and a request ID.
- Human labelling / review for a sample when ground truth is not automatic (Vertex AI data labelling, human-in-the-loop). For generative AI use autorater metrics, user feedback (thumbs up/down), groundedness checks and golden-set regression tests.
- Set alerts in Cloud Monitoring with thresholds, and dashboards for model quality next to system health.
Performance against baselines, simpler models and time
- Baseline comparison: keep a simple model or business rule running to compare. If the complex model’s lift disappears, retire or retrain it. The original champion is another baseline.
- Simpler model benchmark: a logistic regression or a recent-average forecast shows whether the complexity still pays.
- Time dimension: plot metrics by day or week, compare against the launch value, watch for seasonality (not every dip is drift), concept drift (relationship between features and label changes), and data drift (inputs change). Use rolling windows and statistical tests.
- Slice monitoring: evaluate by segment over time, because one segment may degrade while the aggregate looks fine.
- Business metrics: monitor the KPI the model exists for (conversion, fraud loss), not just AUC.
| Kind of change | What changes | Detect with | Fix |
|---|---|---|---|
| Data (covariate) drift | Input distribution | Model Monitoring drift | Retrain with recent data |
| Concept drift | Relationship of input to label | Performance against ground truth | Retrain, redesign features |
| Label shift | Class proportions change | Output distribution and labels | Recalibrate, reweight |
| Skew | Serving differs from training | Model Monitoring skew | Fix preprocessing, shared transforms |
| Data quality | Nulls, new categories, schema break | Data validation, null-rate alerts | Fix upstream, add validation |
Common training and serving errors
| Area | Symptom | Check |
|---|---|---|
| Serving | Latency high | Hardware too small, cold starts, large payloads, no batching, a slow feature lookup, replicas too few. Look at the latency metrics, autoscaling, and profile |
| Serving | HTTP 429 | Quota or capacity exceeded, throttling. Raise max replicas, quotas or use provisioned throughput |
| Serving | HTTP 5xx / container crash | Container fails health check, out-of-memory, wrong port or route, model artifact missing, a dependency missing. Read the container logs in Cloud Logging |
| Serving | Deployment fails | Machine type unavailable or no quota, bad image or service account permissions to pull from Artifact Registry or read the model bucket |
| Serving | Input schema mismatch (400) | Wrong feature order, names or types in the request |
| Serving | Sudden accuracy drop | Upstream schema change, feature null or default, skew, a bad model version. Roll back through traffic split |
| Serving | Costs too high | Over-provisioned min replicas, GPUs for small models, idle endpoints (undeploy), no batching |
| Training | Job error status | Logs in Cloud Logging, quota exhaustion, IAM, image or entry point failures |
| Training | Metrics worse than expected | Data quality, leakage, wrong split, class imbalance |
| Pipelines | Step fails or never runs | Service account permissions, component I/O type mismatch, caching serving stale results, missing parameter |
Tools: Cloud Logging (container, job, request logs), Cloud Monitoring (latency, replicas, utilisation, error rates, alert policies, dashboards), Cloud Trace and Profiler for latency, Error Reporting, TensorBoard profiler, and Vertex AI Model Monitoring.
Exam checklist
- Secure AI with VPC-SC, private endpoints, least privilege, CMEK, audit logs, scanning and rate limits. For LLMs add Model Armor, safety filters and treating retrieved content as untrusted.
- Responsible AI means defining fairness, slicing metrics, examining data bias, documenting with model cards, and human oversight.
- Explainable AI: Sampled Shapley (any model), Integrated Gradients (differentiable), XRAI (images). Baselines matter.
- Skew compares serving with training. Drift compares serving with earlier serving. Attribution drift watches feature importance changing.
- Model Monitoring uses Jensen-Shannon for numeric and L-infinity for categorical features, with per-feature thresholds and a sampling rate. Alerts through Pub/Sub can start retraining.
- Skew means fix the pipeline. Drift means retrain.
- Log predictions to BigQuery and join to delayed labels for continuous evaluation. Compare with baselines, simpler models and over time and slices.
- 429 is capacity, 5xx is container or model failure, schema mismatch is 400. Use Logging and Monitoring first.