Data Governance

When an auditor asks "which databases hold personal data, and who answers for them?", the answer cannot be a treasure hunt through spreadsheets. With DATTA's Data Governance, every dataset in the Knowledge Catalog gets an owner, a steward and a sensitivity classification — assigned from a single screen, with an audit trail of who changed what and when. It is the foundation for LGPD/GDPR compliance, for explicit accountability per data product and for sensitivity reports in a few clicks.

What it enables:

• LGPD/GDPR compliance: knowing which datasets contain personal data and who is responsible for them.
• Data mesh: an explicit data product owner per dataset.
• Rules by classification (future): policies like "personal data only for the DPO", without case-by-case access lists.
• Audit: a complete trail of who assigned or changed what and when.

Classification levels

Hierarchy, from the most permissive to the most restricted:

How to assign governance to a dataset

1. Open the Governança de Dados page (/governanca.html).
2. Type the Dataset ID — for example neo4j:processos:Documento or opensearch:datta_processos_chunks.
3. Click Carregar: the dataset's current governance appears on screen.
4. Edit the three fields:
   • Owner — the user responsible for the dataset;
   • Steward — the governance steward user;
   • Classification — a list with the 5 levels.
5. Click Salvar.

To undo it, the platform also lets you remove a dataset's governance: it falls back to the INTERNAL default, with no owner and no steward. That operation is available in the API reference, along with reading, assigning and listing datasets by classification level.

Automatic classification (AI)

The Classificar via IA button triggers a two-step classification:

1. Personal-data heuristic: column names with classic terms (cpf, cnpj, email, telefone, ssn, address, ...) classify the dataset IMMEDIATELY as PII — without spending an AI call.
2. AI as a second opinion: if no term matches, the language model (Gemini by default, a local model in environments without internet access) receives the dataset's metadata — name, columns, type and samples — and returns the level.

Automatic classification is not definitive: you can override it manually. The result is always persisted, preserving the current owner and steward, and the interface prompts you to save in order to confirm.

Hands-on example — preparing an LGPD report

1. The DPO asks for the inventory of databases with personal data. Open the Governança de Dados page.
2. Load neo4j:processos:Documento with Carregar. The dataset is INTERNAL and has no owner.
3. Click Classificar via IA: the heuristic finds the cpf column and suggests PII right away, without consulting the model.
4. Fill Owner with maria@yourorg and Steward with carlos@yourorg, confirm the PII classification and click Salvar.
5. Repeat for the other datasets of the context. Listing every dataset at a given level (for example, all the PII ones) is available through the API reference — ready to feed the report.
6. Every assignment is audited: who assigned it, when and what changed.

Where the governance is stored

The attributes live on the Knowledge Catalog dataset itself, in the datta-datacatalog graph database, as properties of the (:Dataset {id, ...}) node:

• owner (text)
• steward (text)
• classificationLevel (text — one of the 5 levels)
• assignedAt (ISO 8601 date/time)
• assignedBy (text — who made the assignment)

An idempotent migration creates the indexes for owner, steward and classificationLevel, so queries by owner, by steward and by classification level stay fast even with many datasets.

To avoid hitting the graph on every read, governance is served by a two-tier cache — the service's own memory plus the platform's distributed cache, with a 30-minute TTL — with the graph as the source of truth. Every write (assignment or removal) invalidates the cache immediately, so the screen never shows a stale owner.

Audit

Every change emits an audit event, stored as (:AuditEvent) in the graph:

• OWNERSHIP_ASSIGNED — when the owner or the steward changes.
• OWNERSHIP_ASSIGNED_RECLASSIFIED — when the classification also changed.
• OWNERSHIP_REMOVED — when the governance is removed.

Who can use it

Access follows the catalog permissions: the interface hides what you cannot do, and the rule also holds on the server — without the permission the action is refused with a message in Portuguese, and the denial is audited.

The mapping below is the suggested default — adjust it to your organization's roles following the roles and permissions guide.

Known limitations

• No complex attribute-based access policies (Casbin/OPA): we use a simple list of levels. A conscious MVP decision, with future expansion if justified.
• No two-step approval for classification changes — left for the future.
• Data samples in the automatic classification are best-effort: if the sampling fails, the analysis runs with the column names only. The personal-data heuristic still works.

Roadmap

• Export to external privacy and governance tools (Privacera, BigID, Collibra).
• Governance editing integrated into the Data Catalog (screens/catalogo.html) — today the page is standalone.
• Automatic notification when the classification changes (for example, alerting the DPO's channel).
• Approval workflow for downgrading PII to PUBLIC.