5.4 Protecting PII & Sensitive Data in ML Workflows
Key Takeaways
- 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.
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_iddeterministically 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.
A healthcare analytics team must join patient records across three BigQuery tables for model training, and a small compliance team must be able to re-identify specific patients when legally required. Which de-identification method fits best?
A team is preparing customer support transcripts to fine-tune a Gemini summarization model. The transcripts contain names, phone numbers, and card numbers that aren't needed for summaries. What should they do before creating the tuning dataset?
An engineer proposes format-preserving encryption for all identifier columns in a training dataset. When does Google recommend using CryptoReplaceFfxFpeConfig?