5.4 Protecting PII & Sensitive Data in ML Workflows

Google Cloud Professional Machine Learning Engineer PMLE

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Exam Overview & the Agent Platform Map

1.1 PMLE Exam Facts, Policies & the June 2026 Blueprint 1.2 From Vertex AI to Gemini Enterprise Agent Platform: The Product Name Map

2 Chapter 2: Low-Code ML with BigQuery ML

2.1 Choosing, Training & Predicting with BigQuery ML Models 2.2 Feature Engineering & Feature Selection in BigQuery ML 2.3 Fine-Tuning & Evaluating Gemini Models from BigQuery

3 Chapter 3: AutoML & Google Cloud AI APIs

3.1 Training Models with Agent Platform AutoML 3.2 Building with Document AI, Vision, Translation & Other AI APIs

4 Chapter 4: Foundation Models in Model Garden

4.1 Evaluating & Selecting Models in Model Garden 4.2 Building & Tuning Solutions with Gemini, Imagen, Veo & MaaS 4.3 Optimizing Gemini Applications for Cost, Latency & Availability

5 Chapter 5: Exploring, Preprocessing & Protecting Data

5.1 Organizing & Exploring Tabular, Text & Image Data 5.2 Choosing a Preprocessing Tool: BigQuery, Dataflow, Spark or Python 5.3 Creating & Consolidating Features in Agent Platform Feature Store 5.4 Protecting PII & Sensitive Data in ML Workflows

6 Chapter 6: Notebooks, Prototyping & Experiment Tracking

6.1 Workbench vs. Colab Enterprise: Secure, Collaborative Notebooks 6.2 Prototyping with PyTorch, scikit-learn, JAX & Model Garden in Notebooks 6.3 Experiment Environments, Tracking & Lineage with Experiments and ML Metadata

7 Chapter 7: Evaluating Predictive & Generative AI Solutions

7.1 Evaluation Metrics for Predictive Models 7.2 Evaluating Gen AI: Computation Metrics, Rubrics & LLM-as-a-Judge

8 Chapter 8: Choosing the Modeling Approach

8.1 Choosing the Model Type: ARIMA, Trees, DNNs & LLMs 8.2 Choosing the Product & Deployment Strategy 8.3 Modeling Techniques for Interpretability Requirements

9 Chapter 9: Training Data & Training SDKs

9.1 Organizing & Ingesting Training Data from Cloud Storage & BigQuery 9.2 Custom Training on Agent Platform: Containers, Jobs & Worker Pools 9.3 Kubeflow on GKE, AutoML & Tabular Workflows as Training Choices

10 Chapter 10: Troubleshooting, Hyperparameter Tuning & Fine-Tuning

10.1 Troubleshooting ML Training Failures 10.2 Hyperparameter Tuning on Agent Platform 10.3 Fine-Tuning Foundation Models & When to Tune

11 Chapter 11: Training Hardware & Distributed Training

11.1 Choosing CPUs, GPUs & TPUs for Training 11.2 Distributed Training: Data & Model Parallelism

12 Chapter 12: Deploying Models for Inference

12.1 Batch vs. Online Inference on Agent Platform 12.2 Serving Beyond Agent Platform Endpoints: Model Garden, Cloud Run & GKE 12.3 Prebuilt & Custom Serving Containers

13 Chapter 13: Model Versions, Rollouts & Inference Logic

13.1 Organizing & Versioning Models in Model Registry 13.2 Rollout Strategies: A/B Tests, Canaries & Traffic Splits 13.3 Inference Preprocessing & Postprocessing

14 Chapter 14: Scaling Online Serving

14.1 Serving Features Online with Feature Store 14.2 Public, Dedicated & Private Endpoints 14.3 Serving Hardware & Autoscaling for Throughput 14.4 Tuning Models for Production Training & Serving

15 Chapter 15: End-to-End ML Pipelines

15.1 Validating Data & Models in Pipelines 15.2 Agent Platform Pipelines with KFP: Components, Templates & Caching 15.3 Ensuring Consistent Preprocessing Between Training & Serving

16 Chapter 16: Orchestration with Managed Airflow & Ray

16.1 Orchestrating ML Workflows with Managed Service for Apache Airflow 16.2 Ray on Agent Platform for Distributed ML Workloads

17 Chapter 17: Automating Retraining & CI/CD/CT

17.1 Choosing a Retraining Policy 17.2 CI/CD/CT for ML with Cloud Build

18 Chapter 18: Securing AI Systems, Responsible AI & Explainability

18.1 Protecting AI Systems from Data & Model Exfiltration 18.2 Defending Gen AI Apps: Safety Filters, Model Armor & Regex Guardrails 18.3 Responsible AI: Detecting & Monitoring Bias 18.4 Model Explainability on Agent Platform

19 Chapter 19: Monitoring AI Solutions

19.1 Configuring Model Monitoring on Agent Platform 19.2 Training-Serving Skew, Data Drift, Concept Drift & Attribution Drift 19.3 Monitoring, Testing & Evaluating Gen AI Solutions in Production

5.4 Protecting PII & Sensitive Data in ML Workflows

Key Takeaways Explain This Topic AI

Sensitive Data Protection finds sensitive data with built-in infoType detectors, custom dictionaries, and regular expression detectors.

Sensitive Data Protection de-identification techniques include redaction, replacement, masking, crypto-based tokenization, bucketing, date shifting, and time extraction.

Deterministic tokenization with CryptoDeterministicConfig (AES-SIV) preserves joins across tables and can be reversed with the original key.

Google advises against format-preserving encryption (CryptoReplaceFfxFpeConfig) unless the input's alphabet and length must be preserved, because it is slower and more limited.

Bucketing generalizes values such as exact ages into ranges, lowering re-identification risk while keeping signal useful for models.

Last updated: September 2026

The exam guide asks you to ensure data privacy and handle sensitive information (for example, PII) during data exploration and preprocessing. ML raises the stakes: a single customer table can end up in training snapshots, notebook caches, evaluation exports, request logs, tuning datasets, and LLM prompts. Model-level threats (exfiltration, prompt attacks) are covered in Chapter 18. This section is about the data itself.

Principle 1: Minimize Before You Protect

Don't collect or copy what the model doesn't need. Direct identifiers (name, email, phone, national ID) rarely improve predictions and create risk.

Aggregate where possible. "Number of transactions last 30 days" is usually more useful and safer than raw transactions.

Separate identity from features. Keep a secured mapping table and give the ML team pseudonymous IDs.

Principle 2: Discover Sensitive Data Automatically

Sensitive Data Protection (formerly Cloud Data Loss Prevention, with the DLP API keeping its name) inspects content using infoType detectors :

Detector type Use

Built-in infoTypes Common global and country-specific data: emails, phone numbers, credit card numbers, national IDs

Regular custom dictionary A word list up to tens of thousands of entries (for example, internal project code names)

• Stored custom dictionary Very large lists (up to tens of millions) stored in Cloud Storage or BigQuery
• Regular expression detector Pattern-based identifiers such as internal account formats

Specify only the infoTypes you need. Otherwise the scan uses a broad default set, which adds latency. Use discovery scans on BigQuery and Cloud Storage to find which tables hold sensitive columns before a training project begins.

Principle 3: De-identify in a Way That Keeps ML Signal

Technique Example Reversible Keeps joins ML impact

Redaction Remove the SSN from free text No No Loses the value entirely. Fine for identifiers with no predictive value

Replacement / infoType replacement "Call Jane at 555-0100" becomes "Call [PERSON_NAME] at [PHONE_NUMBER]" No No Keeps sentence structure for NLP and LLM training

Masking 4111-XXXX-XXXX-1111 No No Keeps partial patterns for display

Crypto hash ( CryptoHashConfig ) Customer ID becomes a 32-byte hex pseudonym No Yes Consistent pseudonymous key for joins

Deterministic encryption ( CryptoDeterministicConfig , AES-SIV) Customer ID becomes a token, re-identifiable with the key Yes Yes Joins plus authorized re-identification

Format-preserving encryption ( CryptoReplaceFfxFpeConfig ) 16-digit number becomes another 16-digit number Yes Yes Only when downstream systems require the same format. Google warns it's slow and limited

Bucketing Age 37 becomes "30-39", income becomes a band No No Keeps coarse signal and lowers re-identification risk

Date shifting Shift each patient's dates by a random offset Consistent per entity N/A Keeps intervals between events for longitudinal models

Time extraction Keep only year or hour No N/A Keeps seasonal signal

Tokenization in practice: A hospital analytics team needs to join admissions, lab, and pharmacy tables by patient. Deterministic encryption of the patient ID gives the same token in every table, so joins work. Only a small, authorized team holding the key in Cloud KMS can re-identify a patient when clinically required.

Principle 4: Govern Access Around the Data

IAM least privilege: grant data scientists access to de-identified datasets, not raw ones. Use service accounts for pipelines.

BigQuery column-level security with policy tags, and dynamic data masking , so the same table shows masked values to most users.

VPC Service Controls perimeters around BigQuery, Cloud Storage, and Agent Platform to reduce exfiltration risk.

Customer-managed encryption keys (CMEK) when policy requires control over encryption keys.

Audit logs for data access.

Data residency: keep datasets, training, and serving in approved regions.

Principle 5: Watch the ML-Specific Leak Paths

Leak path Mitigation

Notebook outputs and saved notebooks containing raw rows Work on de-identified samples. Clear outputs before sharing (Chapter 6)

• Prediction request and response logging Log de-identified payloads, or restrict and expire log tables
• Tuning datasets for Gemini Redact or tokenize PII before building JSONL or BigQuery tuning tables

Prompts and RAG corpora Scan documents before indexing, and screen prompts and responses (Model Armor, Chapter 18)

Models memorizing rare records Remove direct identifiers, aggregate, and test for memorization of unusual values

• Evaluation exports shared with vendors Share only de-identified evaluation sets
• Choosing a Technique by Column Type

• Column Needed by the model? Typical treatment
• Name, email, phone No Drop, or redact in free text
• Customer or patient ID used for joins As a key only Deterministic tokenization or crypto hash
• Exact age, income, ZIP code Coarse signal only Bucketing, or truncating ZIP to fewer digits
• Event dates Intervals matter Date shifting per entity, or time extraction
• Free-text notes Language structure matters InfoType replacement with placeholders
• Card number shown in UI Partial visibility Masking
• Worked Scenario

A telecom company wants a churn model plus an LLM that summarizes call-center transcripts. A privacy-safe design:

Run Sensitive Data Protection discovery on the customer tables and transcript bucket.

For the churn features, drop names and addresses, tokenize customer_id deterministically for joins, and bucketize age and tenure.

For transcripts, apply infoType replacement for names, phone numbers, and card numbers before summarization or tuning.

Restrict raw tables with policy tags, and let the ML project read only de-identified views.

Put BigQuery, Cloud Storage, and Agent Platform inside a VPC Service Controls perimeter.