Personal data is governed per column, not per policy paragraph. The model ships with each column’s classification and anonymization technique, generates the views for non-production environments and takes the classification into the database catalog.
The problem
The privacy policy lives in a PDF and the database lives in production, with no link between the two. Staging gets a production dump "just this once", and nobody can say which columns are personal without opening table after table.
The classification is born inside the model: public, internal, personal or sensitive personal, with the anonymization technique declared per column. A personal column without a technique becomes a warning on top of the DDL, so it never ships in the clear by accident.
How it works
Each column carries a classification and a technique: mask, hash, tokenize, aggregate, pseudonymize. The DDL takes the classification into the database catalog as comments, and the dbt export inherits the tests.
The anonymization view is generated per column, with the right expression for each technique, and an explicit warning when a personal column was left without a declared technique.
clientes: column-by-column classification
LGPD per column, with the anonymization technique declared
| Column | Type | Classification | Anonymisation |
|---|---|---|---|
| id | uuid | internal | |
| varchar(160) | personal | hash | |
| cpf | char(11) | sensitive personal | mask |
| cidade | varchar(80) | public |
View generated for non-production environments
CREATE OR REPLACE VIEW clientes_anon AS
SELECT id, encode(digest(email, 'sha256'), 'hex') AS email, …
The classification travels down to the database catalog, and the view populates staging without real personal data.
The LGPD impact report is born from the model itself: purposes and legal bases, retention and disposal, data subject rights, sharing and risks with mitigation.
And it enters the same verification regime as every other deliverable, with a seal and with the pending items declared before going live.
Project / Analytics layer / Deliverables
Execution prompt: create the analytics schema
Version 3 · for the client agent or the DBA
Environment assumptions
PostgreSQL 16 · user without SUPERUSER
run inside a transaction · no embedded credentials
if any check fails, apply the rollback and stop
Checks after applying
Under the hood
How LGPD descends from the document into the database.
What comes next
PDF, spreadsheet, Word, CSV and SQL dumps, with the role declared by whoever uploads and a summary of what was understood.
See it from the inside →DeliveryExecution promptThe deliverable that closes the engagement without touching your database: environment assumptions, verification and rollback, ready for your agent or your DBA.
See it from the inside →Track recordProject track recordProjected cost against the real invoice, assumptions with state, open objections and the environment’s drift, in one place.
See it from the inside →Paste the structure, get the most serious findings in about two minutes, and decide later whether an engagement is worth opening. No account, no card.