Governança de Dados

Quando um auditor pergunta "quais bases contêm dados pessoais e quem responde por elas?", a resposta não pode ser uma caça ao tesouro por planilhas. Com a Governança de Dados do DATTA, cada dataset do Knowledge Catalog recebe um owner, um steward e uma classificação de sensibilidade — atribuídos em uma única tela, com trilha de auditoria de quem mudou o quê e quando. É a base para compliance LGPD/GDPR, para responsabilidade explícita por produto de dados e para relatórios de sensibilidade em poucos cliques.

O que você habilita:

• Compliance LGPD/GDPR: saber quais datasets contêm dados pessoais e quem é o responsável por eles.
• Data mesh: um dono de produto de dados explícito por dataset.
• Regras por classificação (futuro): políticas do tipo "dados pessoais só para o DPO", sem lista de acesso caso a caso.
• Auditoria: trilha completa de quem atribuiu ou mudou o quê e quando.

Níveis de classificação

Hierarquia, do mais permissivo ao mais restrito:

Como atribuir governança a um dataset

1. Abra a página Governança de Dados (/governanca.html).
2. Digite o Dataset ID — por exemplo neo4j:processos:Documento ou opensearch:datta_processos_chunks.
3. Clique em Carregar: a governança atual do dataset aparece na tela.
4. Edite os três campos:
   • Owner — usuário responsável pelo dataset;
   • Steward — usuário steward de governança;
   • Classificação — lista com os 5 níveis.
5. Clique em Salvar.

Para desfazer, a plataforma também permite remover a governança do dataset: ele volta ao padrão INTERNAL, sem owner nem steward. A operação está disponível na referência de API, junto com a leitura, a atribuição e a listagem de datasets por nível de classificação.

Classificação automática (IA)

O botão Classificar via IA dispara a classificação em duas etapas:

1. Heurística de dados pessoais: nomes de coluna com termos clássicos (cpf, cnpj, email, telefone, ssn, address, ...) classificam o dataset IMEDIATAMENTE como PII — sem gastar chamada de IA.
2. IA como segunda opinião: se nenhum termo bate, o modelo de linguagem (Gemini por padrão, modelo local em ambientes sem internet) recebe os metadados do dataset — nome, colunas, tipo e amostras — e devolve o nível.

A classificação automática não é definitiva: você pode sobrescrevê-la manualmente. O resultado é sempre gravado, preservando o owner e o steward atuais, e a interface orienta a salvar para confirmar.

Exemplo prático — preparando um relatório LGPD

1. O DPO pede o inventário de bases com dados pessoais. Abra a página Governança de Dados.
2. Carregue neo4j:processos:Documento com Carregar. O dataset está como INTERNAL e sem owner.
3. Clique em Classificar via IA: a heurística encontra a coluna cpf e sugere PII na hora, sem consultar o modelo.
4. Preencha Owner com maria@suaorg e Steward com carlos@suaorg, confirme a classificação PII e clique em Salvar.
5. Repita para os demais datasets do contexto. A listagem de todos os datasets de um nível (por exemplo, todos os PII) está disponível pela referência de API — pronta para alimentar o relatório.
6. Cada atribuição fica auditada: quem atribuiu, quando e o que mudou.

Onde a governança fica guardada

Os atributos ficam no próprio dataset do Knowledge Catalog, no banco de grafos datta-datacatalog, como propriedades do nó (:Dataset {id, ...}):

• owner (texto)
• steward (texto)
• classificationLevel (texto — um dos 5 níveis)
• assignedAt (data/hora ISO 8601)
• assignedBy (texto — quem fez a atribuição)

Uma migração idempotente cria os índices de owner, steward e classificationLevel, para que as consultas por dono, por steward e por nível de classificação respondam rápido mesmo com muitos datasets.

Para não ir ao grafo a cada leitura, a governança é servida por um cache em duas camadas — memória do próprio serviço e cache distribuído da plataforma, com TTL de 30 minutos — tendo o grafo como fonte da verdade. Toda gravação (atribuição ou remoção) invalida o cache na hora, então a tela nunca mostra um dono desatualizado.

Auditoria

Toda mudança gera um evento de auditoria, gravado como (:AuditEvent) no grafo:

• OWNERSHIP_ASSIGNED — quando o owner ou o steward muda.
• OWNERSHIP_ASSIGNED_RECLASSIFIED — quando a classificação também mudou.
• OWNERSHIP_REMOVED — quando a governança é removida.

Quem pode usar

O acesso segue as permissões do catálogo: a interface esconde o que você não pode fazer, e a regra vale também no servidor — sem a permissão, a ação é recusada com mensagem em português e a negativa fica auditada.

O mapeamento abaixo é a sugestão padrão de perfis — ajuste-o às roles da sua organização no guia de roles e permissões.

Limitações conhecidas

• Sem políticas de acesso complexas por atributo (Casbin/OPA): usamos uma lista simples de níveis. É uma decisão consciente do MVP, com expansão futura se houver justificativa.
• Sem aprovação em duas etapas para mudança de classificação — fica para o futuro.
• Amostras de dados na classificação automática são melhor-esforço: se a amostragem falhar, a análise roda só com os nomes de coluna. A heurística de dados pessoais continua funcionando.

Roadmap

• Exportação para ferramentas externas de privacidade e governança (Privacera, BigID, Collibra).
• Edição de governança integrada ao Catálogo de Dados (screens/catalogo.html) — hoje a página é dedicada.
• Notificação automática ao mudar a classificação (por exemplo, avisar o canal do DPO).
• Fluxo de aprovação para rebaixar PII para PUBLIC.