Databricks com Unity Catalog governa bem o que está dentro da plataforma: permissão, linhagem e catálogo por configuração. O problema está na fronteira, na entrada de dados vindos de sistemas legados e fornecedores, e na saída para relatórios e modelos de IA, que depende de desenho humano, não de licença. Por isso, comprar a ferramenta não é comprar governança: falta o trabalho que define dono do dado, critério de qualidade e contrato de dado entre sistemas

A linha exata entre o que o Unity Catalog resolve e o que continua sendo decisão humana

O Unity Catalog resolve, por configuração, o que é técnico e repetível. O que exige julgamento de negócio continua sendo trabalho humano, projeto a projeto.

O que a plataforma entrega por configuração: permissão, linhagem, catálogo e trilha de auditoria

Por desenho, o Unity Catalog centraliza o controle de acesso a tabelas, arquivos e modelos, registra a linhagem de ponta a ponta e mantém um catálogo único para dados e IA . A arquitetura de governança do Azure Databricks reforça esse papel: o Unity Catalog é a camada que unifica metadados, políticas de acesso e auditoria dentro do lakehouse. Isso significa que, uma vez configurado, o acesso a uma tabela obedece a uma política central, e quem consultou o quê fica registrado automaticamente.

Esse é o ganho real da plataforma: ela elimina a necessidade de replicar permissão em cada ferramenta de consumo, porque a política vive em um único lugar . A guia de governança de dados da Databricks também situa o Unity Catalog como parte de um conjunto maior, que inclui descoberta, qualidade e conformidade como práticas, não apenas como recursos do produto.

O que nenhuma licença decide: dono do dado, nomenclatura, critério de qualidade e regra de retenção

Nenhuma configuração do Unity Catalog decide quem é o dono de uma tabela, como ela deve se chamar, o que conta como dado válido ou por quanto tempo um registro deve ser mantido. A própria Databricks descreve a governança como um conjunto de práticas que envolve qualidade, política e cultura de dados, além da ferramenta. Ou seja, o produto oferece o mecanismo, mas o critério continua sendo definido por pessoas.

Uma empresa pode ativar o Unity Catalog inteiro e ainda ter duas áreas chamando o mesmo indicador de nomes diferentes, porque nomenclatura é acordo organizacional, não parâmetro de sistema. O mesmo vale para retenção: a plataforma pode aplicar uma política de expiração, mas alguém precisa decidir qual prazo é correto para cada tipo de dado, e essa decisão nasce fora da licença.

O sintoma de quem comprou a ferramenta achando que comprou a governança

O sintoma mais comum é o catálogo cheio e vazio ao mesmo tempo: tabelas catalogadas, mas sem dono definido, sem descrição de negócio e sem classificação de sensibilidade. A empresa tem o Unity Catalog ativo, paga pela licença, e ainda assim o time de dados continua resolvendo por e-mail quem pode acessar o quê.

Isso acontece porque a implantação tratou a ferramenta como projeto de TI, não como mudança de processo. O resultado é previsível: o acesso técnico está correto, mas a decisão de negócio sobre o dado nunca foi tomada, e ninguém percebe até o primeiro incidente de auditoria.

Onde a governança quebra de verdade: na passagem entre os sistemas

A governança raramente quebra dentro do Unity Catalog. Ela quebra na borda, no momento em que o dado entra vindo de outro sistema ou sai para ser consumido fora do lakehouse.

O campo renomeado na origem que derruba o indicador dias depois

Um sistema de origem muda o nome de um campo, e a ingestão continua rodando sem erro aparente, porque a estrutura ainda é válida tecnicamente. O indicador que depende daquele campo some ou passa a somar errado, e ninguém percebe até o fechamento do período.

A arquitetura de governança descrita para o lakehouse trata justamente esse ponto: linhagem e qualidade precisam ser monitoradas na ingestão, e não apenas no consumo, porque é ali que a maioria das quebras silenciosas começa. Sem um contrato de dado na entrada, a plataforma registra a mudança, mas não impede o impacto.

A permissão que se perde quando o dado sai do lakehouse para o relatório

A permissão definida no Unity Catalog vale dentro do ambiente governado. Quando o dado é extraído para uma planilha, um extrato ou uma ferramenta de BI fora do escopo de governança, essa política não viaja junto automaticamente.

O modelo de arquitetura de dados e IA recomenda que o controle de acesso seja pensado de ponta a ponta, incluindo o caminho até o consumo final, exatamente porque a saída é onde a política mais se perde. Uma consultoria que só configura o catálogo e não desenha o caminho até o relatório deixa esse ponto aberto.

O dado legado que o modelo de IA lê sem entender o contexto

Um sistema legado armazena um campo com um significado que só faz sentido para quem viveu a história daquele sistema. Um modelo de IA lê o valor, mas não lê o contexto, e gera uma resposta tecnicamente correta e substantivamente errada.

A recomendação de governança para arquiteturas de dados e IA é explícita sobre isso: dado usado por modelos precisa de metadados e documentação de contexto, não apenas de estrutura técnica. Sem esse trabalho, a IA aplicada ao dado legado reproduz o erro de interpretação em escala.

Quem responde pelo dado que vem de fornecedor terceiro ou de sistema legado

A responsabilidade pelo dado que entra de fora não desaparece porque o fornecedor ou o sistema legado está fora do controle direto da empresa. Alguém internamente precisa assumir essa fronteira, por contrato e por processo.

Contrato de dado na ingestão: o que exigir de quem envia

Um contrato de dado formaliza o que é aceitável antes do arquivo entrar no ambiente: estrutura esperada, tipos de campo, valores obrigatórios e janela de entrega. Sem isso, qualquer mudança do lado do fornecedor vira um problema que só aparece depois, no relatório.

Exigir esse contrato de um fornecedor terceiro costuma ser mais difícil do que de um sistema interno, porque o fornecedor não tem o mesmo incentivo para avisar sobre mudanças. Por isso o contrato de dado precisa estar na condição comercial, não apenas na documentação técnica.

Quarentena e rejeição: o que fazer quando o arquivo chega fora do padrão

Quando um arquivo chega fora do padrão combinado, a prática correta é colocá-lo em quarentena antes que alimente qualquer tabela de consumo, em vez de deixar passar e corrigir depois. Rejeitar na entrada custa menos do que corrigir um indicador que já circulou em relatório.

Esse mecanismo precisa existir como etapa do pipeline, não como exceção manual. Sem uma camada de quarentena, cada arquivo fora do padrão vira um incidente tratado individualmente, o que não escala.

A diferença entre responsabilidade técnica e responsabilidade de negócio pelo erro

Quem opera o pipeline responde pela execução técnica: o dado chegou, foi processado, está disponível. Quem responde pelo negócio é quem decide se aquele dado pode ser usado para uma decisão, e essa é uma responsabilidade diferente.

Misturar as duas é um erro comum: o time técnico é cobrado por um erro de interpretação que nunca foi dele para decidir. Separar essas responsabilidades por escrito, antes do incidente, é parte do desenho de governança que a plataforma sozinha não define.

LGPD traduzida em controles concretos dentro do Databricks

A lei de proteção de dados pessoais vira operação quando cada direito do titular corresponde a um controle técnico específico dentro do ambiente, e não apenas a uma política escrita.

Mascaramento e filtros de linha para dado pessoal

O Unity Catalog permite aplicar mascaramento de coluna e filtros de linha, de forma que o mesmo conjunto de dados mostre informações diferentes conforme quem consulta. Isso permite que um analista veja o indicador agregado sem ver o CPF ou o nome por trás dele.

Esse controle precisa ser desenhado por classificação de sensibilidade, o que exige primeiro decidir quais campos são pessoais e sensíveis, uma decisão que a ferramenta não toma sozinha.

Linhagem como resposta à pergunta de onde veio e quem acessou

A linhagem automática do Unity Catalog documenta a origem e o caminho de uma tabela até o seu uso final. Isso dá uma resposta objetiva à pergunta de onde um dado pessoal veio e por onde ele passou.

A arquitetura de governança do lakehouse reforça que essa rastreabilidade é parte estrutural do ambiente, não um relatório gerado sob demanda. Sem essa configuração ativa desde o início, a linhagem anterior ao ponto de ativação simplesmente não existe.

Retenção e exclusão: o pedido do titular virando operação possível

Um pedido de exclusão de dado pessoal só é cumprível se existir um processo que localize todas as cópias daquele dado e as remova de forma rastreável. A plataforma oferece o mecanismo de retenção e exclusão, mas a lista de onde aquele dado pessoal está replicado precisa ser mantida por quem desenhou o catálogo.

Sem esse mapeamento prévio, o pedido do titular vira uma busca manual, demorada e sujeita a falha, mesmo com o Unity Catalog ativo.

Trilha de auditoria que sustenta uma inspeção

A trilha de auditoria do Unity Catalog registra quem acessou o quê e quando, o que sustenta a resposta a uma inspeção ou a uma auditoria interna. O valor dessa trilha depende de estar ativa desde antes do incidente, porque auditoria retroativa não recupera o que não foi registrado.

Uma consultoria que configura a trilha sem definir o que precisa ser auditado deixa a empresa com dados de acesso, mas sem o relatório que uma inspeção de fato exige.

Migrar um ambiente já em produção para governança sem parar a operação

Migrar um ambiente que já está em produção para um modelo governado é possível sem interromper a operação, desde que a migração seja feita por etapas, não de uma vez.

Sequência de etapas: inventário, catálogo espelho, migração por domínio, corte

A sequência que reduz risco começa pelo inventário completo do que existe hoje, segue para um catálogo espelho que convive com o ambiente antigo, migra domínio por domínio de negócio, e só então faz o corte final de desativação do ambiente anterior. Esse padrão de adoção incremental é consistente com o modelo de arquitetura recomendado para governança de dados e IA no lakehouse, que trata a adoção como processo contínuo, não como projeto de uma etapa só.

Migrar tudo de uma vez amplia o risco de qualquer erro de mapeamento, porque não existe ambiente de comparação enquanto o catálogo espelho não existe.

Riscos de interrupção e como isolar o blast radius

O maior risco de interrupção é um relatório crítico parar de funcionar porque a permissão não foi replicada corretamente no novo catálogo. Isolar esse risco significa migrar primeiro domínios de menor criticidade, validar o padrão, e só depois avançar para os domínios que sustentam decisão de negócio em tempo real.

Esse isolamento limita o blast radius de qualquer falha de migração a uma área específica, em vez de expor toda a operação ao mesmo tempo.

Sinais de que o projeto travou: catálogo parado, acesso ainda por chamado, time pedindo exceção

Três sinais indicam que a migração travou antes do corte final. O catálogo para de ganhar tabelas novas depois de um avanço inicial. O acesso a bases continua sendo resolvido por chamado manual, mesmo com o catálogo configurado. E o time operacional começa a pedir exceção recorrente à política nova, porque o processo antigo ainda é mais rápido.

Quando esses três sinais aparecem juntos, o projeto normalmente não tem um dono de migração dedicado, apenas uma ferramenta configurada e ninguém responsável por forçar a adoção.

Critérios objetivos para comparar propostas de consultoria Databricks

Comparar propostas de consultoria exige critérios que não aparecem no preço nem no nome do parceiro. O programa de parceiros da Databricks certifica empresas em diferentes níveis dentro do próprio ecossistema, mas a certificação descreve o relacionamento com o fornecedor, não o que cada proposta entrega de fato.

Escopo entregue: o que é ambiente configurado e o que é modelo operacional

Uma proposta pode entregar um ambiente Unity Catalog configurado e funcional, o que é diferente de entregar um modelo operacional de governança, com dono de dado definido, processo de ingestão com contrato e rotina de revisão de acesso. A primeira entrega é técnica e termina no go live. A segunda é organizacional e precisa sobreviver ao fim do projeto.

Uma proposta que não separa essas duas entregas tende a parar na primeira, porque é a mais fácil de medir e fechar.

Transferência de conhecimento: quem mexe no catálogo depois do go live

A pergunta que decide o valor real da consultoria é quem vai conseguir alterar uma política de acesso ou revisar uma classificação de sensibilidade seis meses depois do projeto terminar. Se a resposta for apenas o fornecedor original, a transferência de conhecimento não aconteceu.

O diretório de parceiros da Databricks lista empresas por certificação e especialização, mas não indica quanto de capacitação interna cada uma deixa com o cliente ao final, o que precisa ser perguntado diretamente, fora do diretório.

Modelo de cobrança: squad alocada, escopo fechado ou horas, e o que cada um esconde

Squad alocada cobra pelo tempo do time, independente do resultado entregue, o que esconde o risco de o projeto se estender sem entrega concreta. Escopo fechado cobra por entrega, mas pode esconder corte de qualidade se o escopo for mal definido no início. Cobrança por horas esconde o incentivo de estender atividades que poderiam ser mais diretas.

Nenhum modelo é automaticamente ruim, mas cada um exige uma pergunta diferente: para squad alocada, qual é o critério de saída; para escopo fechado, o que está fora; para horas, qual é o teto.

O que fica com o time interno no último dia do projeto

No último dia do projeto, o que fica com o time interno deveria incluir a documentação do modelo de dados, o processo de ingestão com contrato de dado, e pelo menos uma pessoa capaz de operar o catálogo sem suporte externo. Se nada disso está escrito no contrato, a consultoria termina e a dependência do fornecedor original continua.

Indicadores que provam que a governança foi entregue

Governança entregue se mede por indicador operacional, não pela existência da ferramenta configurada.

Tempo médio para liberar acesso a uma base, antes e depois

O tempo que leva entre o pedido de acesso a uma base e a liberação efetiva é um indicador direto de maturidade. Se esse tempo não caiu depois do projeto de governança, o processo de acesso provavelmente continua dependendo de aprovação manual, e não da política configurada no catálogo.

Cobertura de catálogo: percentual de tabelas com dono, descrição e classificação

Ter o Unity Catalog ativo não equivale a ter as tabelas documentadas. O indicador relevante é o percentual de tabelas que têm dono definido, descrição de negócio e classificação de sensibilidade preenchidos, não apenas o número total de tabelas catalogadas.

Incidentes de dado errado que chegaram ao relatório por trimestre

O número de vezes que um dado incorreto chegou a um relatório usado para decisão, por trimestre, mostra se o contrato de dado na ingestão está funcionando. Uma queda consistente desse número ao longo dos trimestres é evidência de governança, uma contagem estável ou crescente indica que a fronteira continua aberta.

Como medir a linha de base antes de assinar o contrato

Medir esses três indicadores antes de contratar qualquer consultoria é o que permite comparar o antes e o depois de forma honesta. Sem uma linha de base registrada no início, qualquer promessa de melhoria feita pelo fornecedor fica sem como ser verificada depois.

A fundação de dados decide o resultado antes da ferramenta, e é por isso que comparar propostas pelo nome do parceiro ou pela licença contratada deixa de fora a pergunta que mais importa: o que essa consultoria vai medir, e como vai provar.

Gostou do conteúdo? Fale com um especialista da CSP Tech sobre governança de dados.

Autor: Guilherme Matos, estrategista de conteúdo e IA, certificado HubSpot, Google e Anthropic. CSP Tech, Microsoft Gold Partner com 34 anos de mercado.



Fontes

https://www.databricks.com/partners

https://www.databricks.com/br/discover/data-governance
https://www.databricks.com/br/partners/partner-directory

https://learn.microsoft.com/pt-br/azure/databricks/lakehouse-architecture/data-governance/ https://www.databricks.com/product/unity-catalog