O RGPD aplicado no SELECT de extração

The €100 Lakehouse — 3/12

A coluna que nunca chega ao lake é a única cuja erasure RGPD custa zero.

A minimização corre no SELECT de extração — antes de um byte aterrar:

→ email → email_hmac, data de nascimento → birth_year, código postal → região de 4 dígitos
→ HMAC-SHA256 com pepper, por domínio ("phone:" vs "nif:") — 4 grafias do mesmo telefone fazem join no funil, membro e pagamento; um NIF que parece telefone não colide
→ o rename vive no SQL, não em Python — a reflexão diferida criaria a coluna crua em bronze: vazia, visível ao auditor

Fail-closed: em tabelas com PII, cada coluna declara tratamento (KEEP incluído) ou a source recusa-se a construir. Validado contra o schema vivo — já nomeou coluna inexistente; o dlt descarta desconhecidas em silêncio. Sem o guard: ficção verde.

O gate legal também era código: até haver base legal + DPA, aterrava UMA tabela sem PII — 17 linhas — por assert em cada destino vivo. A autorização mudou uma constante derivada — 1 tabela virou 42, zero tratamentos relaxados.

Recusei o atalho "dados hasheados já não são pessoais". Art. 4(5) — o hash não compra isenção; fica no âmbito da erasure. Nos marts fiscais, o scrub apaga colunas, nunca factos: Lei do IVA, 10 anos.

Um gate num documento é uma intenção. Um gate num assert é propriedade do sistema.

No vosso pipeline, onde vive o RGPD — num documento que alguém tem de lembrar, ou num assert que se recusa a correr?

Databricks · dbt · Airflow · Terraform · AWS

P.S. Novo post tech todas as quartas-feiras.

#100EuroLakehouse #GDPR #DataEngineering