Feature Store and Protecting Sensitive Data

What it is

Gemini Enterprise Agent Platform Feature Store is a central place to define, share and serve ML features. Teams register features once and reuse them, instead of each team rebuilding "customer spend in the last 30 days" in its own way.

Training data often contains personally identifiable information (PII) such as names, emails, card numbers and addresses. The engineer must find it, remove or transform what the model does not need, and limit who can see the rest.

How it works

How Feature Store is organized

In the current Feature Store, BigQuery is the offline store. You do not copy data into a separate system; you register BigQuery tables or views.

Online stores use Bigtable online serving, the recommended type, which handles large data volumes and supports scheduled or continuous sync. Optimized online serving is the only type with embedding (vector) management, but it is deprecated and due to retire in February 2027.

-- A BigQuery source table that can be registered as a feature group
-- (append each day's snapshot instead of replacing it to keep history for point-in-time training)
CREATE OR REPLACE TABLE features.customer_daily AS
SELECT
  customer_id,
  CURRENT_TIMESTAMP() AS feature_timestamp,
  AVG(amount) AS avg_spend_30d,
  COUNT(*) AS orders_30d
FROM sales.orders
WHERE order_ts >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY customer_id;

Creating and consolidating features

• Define features once, in SQL or a pipeline, and register them so other teams can discover them.
• Consolidate duplicates: when two teams compute the same feature differently, agree on one definition and retire the other.
• Use point-in-time values for training, so each training example only sees feature values that existed at the label's timestamp.
• Serve the same features online through a feature view, so training and serving read one definition.

Finding and protecting PII

The best protection is data minimization: if a field does not improve the model, drop it before training. Free text such as support notes often hides PII; inspect it, do not assume it is clean.

A worked example

A hospital network wants a readmission model. Records include names, phone numbers, exact birth dates and free-text notes. The engineer runs Sensitive Data Protection inspection on the tables and notes. Names and phone numbers are dropped, patient IDs are tokenized so records still join, birth dates become age bands, and identifiers in notes are redacted.

Only the de-identified tables are registered in Feature Store. The raw tables stay in a separate project inside a VPC Service Controls perimeter with policy tags on sensitive columns.

How the exam asks about this

• "Fraud features are needed for training in BigQuery and for online prediction within milliseconds, with one definition." Register the BigQuery features in Feature Store and serve them through a feature view in an online store.
• "Data scientists must join records by customer without seeing real customer IDs." Tokenize the IDs with Sensitive Data Protection (pseudonymization).
• "Analysts may query a table, but only the privacy team may see the email column." Apply a BigQuery policy tag to the column.