Map data and purpose
Identify what data enters the system, why it is needed, who can access it, where it is stored, and how long it is retained. Include raw sources, feature tables, notebooks, training snapshots, model artifacts, evaluation examples, prompts, responses, and logs. Minimize collection and access for each stage. A feature that helps a metric may still be inappropriate for the intended decision or expose information through proxies.
Draw the path of a support ticket from ingestion to model evaluation and serving. Mark where names, account numbers, and free-text descriptions could appear, including notebook output and error logs.
Inspect and transform deliberately
Google Cloud Sensitive Data Protection supports inspecting data for configured information types and applying transformations such as masking or tokenization. Choose detectors and transformations for the actual data and test them on representative examples; detection is not perfect. Masking can remove detail needed for a task. Deterministic tokenization can support joins but preserves linkability, and reversible methods require strict key and re-identification controls. Transformed data can still be sensitive.
A training dataset joins support tickets to customer outcomes. Compare replacing customer IDs with consistent tokens against removing them entirely. Explain the utility and privacy tradeoff and who should control any re-identification capability.
Control access at each boundary
Use separate identities and least-privilege permissions for data preparation, training, deployment, and prediction. Restrict access to raw and transformed datasets, artifacts, and evaluation results. Avoid putting credentials or sensitive examples in source code or broadly accessible logs. For a generative assistant, enforce document authorization before retrieval and review which prompts and responses are retained. Screening and redaction are additional controls, not substitutes for access checks.
A model evaluation report contains example prompts with account details. List the people and services that need access, propose a retention period owned by the organization, and describe a safer report for a broader audience.
Test the controls and monitor failures
Create synthetic examples for common and difficult sensitive-data patterns, measure missed detections and false positives, and review results by language or format where relevant. Define behavior when inspection or redaction fails, especially before data leaves a trusted boundary. Monitor data access, policy changes, unexpected exports, and retention enforcement. Document residual risks and involve the appropriate data and security owners before expanding use.
A redaction service times out before a prompt is sent to an external model. Describe a fail-safe application response, an audit event that avoids logging the sensitive prompt, and a test for the recovery path.
A dataset has been deterministically tokenized so records can still be joined. Which statement is most accurate?
Keep exploring
Use the official certification page and its linked resources to validate your coverage. For guided labs, explore the Google Skills learning path. Revisit the practical exercise and explain your decision in your own words before moving on.