GDPR was enforced in the SELECT statement

The €100 Lakehouse — 3/12

The column that never reaches the lake is the only one whose GDPR erasure costs zero.

Minimization runs inside the extraction SELECT — before a byte lands:

→ email → email_hmac, birth date → birth_year, postal code → 4-digit region
→ domain-separated HMAC-SHA256 with a pepper ("phone:" vs "nif:") — four spellings of one phone join across funnel, member, payment; a NIF that looks like a phone can't collide
→ the rename lives in SQL, not Python — deferred reflection would create the raw column in bronze: empty, frozen, auditor-visible

Fail-closed: on a PII table, every allowlisted column declares a treatment (KEEP included) or the source refuses to build. Checked against the live schema too — it once named a column that didn't exist; dlt drops unknown entries silently. Without that guard: green fiction.

The legal gate was code as well. Until legal basis + DPA were decided, one non-PII table could land — 17 rows — enforced by an assert on every non-offline destination. Authorization changed one derived constant — 1 table became 42, zero treatments relaxed.

Refused: the "hashed data isn't personal" shortcut. Art. 4(5) — the hash buys no exemption; hashed rows stay in erasure scope.

A gate in a document is an intention. A gate in an assert is a system property.

Where does GDPR live in your pipeline — in a document someone has to remember, or in an assert that refuses to run?

Databricks · dbt · Airflow · Terraform · AWS

P.S. New tech post every Wednesday.

#100EuroLakehouse #GDPR #DataEngineering