Um data lake armazena dado bruto de várias origens em um repositório central. Um pântano de dados é o mesmo repositório depois que ninguém mais sabe o que há dentro dele: tabelas sem documentação, sem dono, sem origem conhecida, e quarenta versões de “cliente” sem que se saiba qual é a confiável. A diferença entre os dois não é o volume nem a tecnologia, é a navegabilidade: catálogo, linhagem, propriedade e significado. Na era da IA, isso deixou de ser um problema de produtividade do analista e virou um problema de confiabilidade do modelo, porque um agente que não sabe qual tabela usar escolhe uma e responde com confiança sobre a errada. Não por acaso, a Databricks descreve o Unity Catalog como a camada unificada de governança para dados e IA, reunindo controle de acesso, linhagem, auditoria e descoberta de dados, e posiciona o catálogo como o que ajuda pessoas e agentes a encontrar, entender e confiar nos ativos certos.

Como um lago vira pântano (sem que ninguém decida isso)

Nenhuma empresa decide construir um pântano. A degradação é gradual e cada passo parece razoável no momento em que acontece. Um time novo precisa de dados e cria seu próprio recorte. Um projeto urgente despeja uma extração sem documentar. Uma tabela temporária de uma migração fica. Alguém sai da empresa e leva o conhecimento de quais colunas eram confiáveis. Multiplique isso por três anos e por dez times.

O resultado tem sintomas reconhecíveis. Analistas perguntam no chat qual tabela usar, porque a busca não responde. Existem várias versões da mesma entidade e ninguém sabe qual é oficial. Ninguém consegue dizer de onde veio determinado número sem abrir código. Uma mudança de schema quebra dashboards que ninguém sabia que dependiam daquela tabela. E o mais caro: times recriam pipelines que já existiam, porque não encontraram o que já estava pronto.

A tese deste guia: um data lake sem catálogo é uma biblioteca sem índice, tem tudo e não serve para nada. E a IA transformou esse problema conhecido em um risco novo: o analista humano que não encontra o dado certo pergunta ao colega ou desconfia do resultado; o agente de IA não desconfia. Ele escolhe a tabela que parece plausível e entrega a resposta com fluência. Navegabilidade deixou de ser conforto de time de dados e virou pré-requisito de confiabilidade de IA.

Por que a IA amplifica o problema em vez de resolvê-lo

Existe uma expectativa comum de que a IA resolveria a bagunça do lago: bastaria perguntar em linguagem natural e o modelo acharia o que interessa. A prática inverte a lógica. A IA depende da mesma navegabilidade que falta, e sem ela amplifica o erro por três motivos concretos.

•     O agente não hesita. Um analista experiente que encontra três tabelas parecidas para de trabalhar e pergunta. Um agente escolhe uma delas conforme o que parece mais relevante e segue adiante, sem sinalizar a ambiguidade.

•     O erro escala. O analista consulta a tabela errada uma vez. O agente consulta em cada uma das centenas de interações do dia, e o erro se espalha por relatórios, respostas e decisões antes de alguém notar.

•     A fluência esconde a fragilidade. Resposta bem escrita sobre dado errado é mais perigosa que resposta obviamente quebrada, porque ninguém a questiona. É o modo de falha mais caro de um projeto de IA sobre dado desorganizado.

Os quatro elementos que tornam um lago navegável

Navegabilidade não é uma ferramenta, é a soma de quatro camadas de contexto sobre o dado. Cada uma responde a uma pergunta que tanto o analista quanto o agente precisam responder antes de usar uma tabela:

Linhagem: o elemento que a plataforma entrega de graça e quase ninguém usa

Dos quatro elementos, a linhagem é o que exige menos esforço manual em ambiente Databricks e o mais subaproveitado. Segundo a documentação, o Unity Catalog captura a linhagem em tempo de execução automaticamente, para consultas rodadas na plataforma, com suporte a todas as linguagens e granularidade até o nível de coluna, incluindo os notebooks relacionados à consulta. A visualização acontece no Catalog Explorer em tempo quase real, e a linhagem é agregada entre todos os workspaces ligados ao mesmo metastore, respeitando as permissões de cada usuário: quem não tem ao menos a permissão BROWSE sobre o objeto não consegue explorar sua linhagem.

Há ainda um recurso que fecha o grafo de ponta a ponta e costuma passar despercebido: a linhagem externa. A documentação descreve como registrar, no Unity Catalog, metadados de cargas que rodam fora da plataforma, tanto do lado da origem quanto do consumo, de modo que fontes como Salesforce ou MySQL e ferramentas como Tableau ou Power BI apareçam no mesmo grafo das tabelas governadas. Pipelines gerenciados do Lakeflow Connect registram automaticamente a linhagem das tabelas de origem até o destino, o que vale também para a ingestão de fontes operacionais como o Jira, que já tratamos em artigo próprio deste blog.

O ganho prático dessa camada é responder duas perguntas que costumam travar operação de dados: de onde veio este número, quando a auditoria pergunta, e o que quebra se eu alterar esta tabela, antes de alterar. Times que dependem de fontes de outros times passam a enxergar essa dependência em vez de descobri-la no incidente.

Propriedade: governança não é documento, é trabalho recorrente (e por isso mora no Jira)

Catálogo e linhagem são capacidades da plataforma. Propriedade e semântica são decisões humanas, e é aí que a maioria dos programas de governança morre. A empresa escreve uma política de governança de dados, apresenta em comitê, e nada muda no lago, porque documentar tabela, nomear dono e definir significado é trabalho contínuo que ninguém priorizou.

O que funciona é tratar curadoria de metadado como trabalho gerenciado, com as mesmas regras de qualquer entrega: item com dono, prazo, prioridade e histórico. Na prática, cada domínio de dado sem responsável nomeado é um item; cada tabela crítica sem documentação é uma tarefa; cada definição de métrica em disputa é uma decisão a registrar. Quando esse backlog vive no Jira, com workflow e trilha de auditoria, a governança deixa de ser intenção e vira fila visível que avança e pode ser cobrada. É a razão pela qual a consultoria Jira aparece numa conversa que parece ser só de plataforma de dados: sem um sistema onde o trabalho de curadoria seja acompanhado, ele não acontece.

Por que isso é trabalho de especialista em IA, e não faxina de TI: a Databricks posiciona o Unity Catalog como fundação semântica governada para que times de negócio, times técnicos e agentes de IA operem a partir do mesmo significado. Traduzindo: o mesmo catálogo que faz o analista achar a tabela certa é o que faz o agente escolher a tabela certa. Quem organiza o lago está, na prática, construindo a base de confiabilidade da IA. A CSP Tech atua nas duas frentes, como especialistas Databricks na camada de catálogo, linhagem e governança, e com consultoria Jira na gestão do trabalho de curadoria que sustenta essa camada ao longo do tempo.

Por onde começar quando o lago já está turvo

Catalogar tudo de uma vez é o plano que nunca sai do papel, porque o esforço parece infinito e o retorno demora. A sequência que funciona é inversa e começa pelo uso, não pelo inventário:

•     Comece pelos ativos mais consultados. A linhagem e os registros de acesso mostram o que realmente é usado. Documentar as tabelas que sustentam as decisões de hoje entrega valor imediato; o resto pode esperar ou ser aposentado.

•     Nomeie donos antes de escrever documentação. Sem responsável, a documentação nasce desatualizada. Com responsável, ela se mantém como parte do trabalho do time dono do domínio.

•     Aposente com coragem. Boa parte do pântano é lixo que ninguém removeu por medo. Tabela sem consumo e sem dono, identificada pela linhagem, é candidata a arquivamento, e cada remoção melhora a navegabilidade do que resta.

•     Trate o que a IA vai consumir como prioridade máxima. Se há iniciativa de agente ou modelo no horizonte, os ativos que ele vai consultar precisam estar catalogados, documentados e com dono antes do deploy, não depois.

Quando esse esforço não se justifica agora

•     Poucos ativos e um time só. Com dezenas de tabelas e um único time que conhece todas, o custo de um programa formal de catalogação supera o ganho. Navegabilidade importa quando o conhecimento não cabe mais na cabeça das pessoas.

•     Ambiente em migração estrutural. Se a arquitetura vai mudar nos próximos meses, catalogar o que será descontinuado é esforço perdido. Vale catalogar o destino, não a origem que vai sumir.

•     Sem apetite para nomear donos. Se a organização não está disposta a atribuir responsabilidade por domínio de dado, o programa vira documentação órfã que envelhece. Melhor resolver a questão organizacional primeiro.

Perguntas frequentes

Qual a diferença entre data lake e pântano de dados?

O data lake é um repositório central de dado bruto de várias origens. O pântano é esse mesmo repositório quando perde navegabilidade: sem catálogo, sem documentação, sem donos e sem linhagem, com múltiplas versões da mesma entidade e nenhuma indicação de qual é confiável. A diferença não está na tecnologia nem no volume, está no contexto disponível sobre o dado.

Por que a organização do data lake afeta a qualidade da IA?

Porque um modelo ou agente precisa escolher qual dado consultar, e sem catálogo, documentação e propriedade definida ele escolhe pelo que parece plausível. O analista humano que encontra ambiguidade hesita e pergunta; o agente não hesita e responde com fluência sobre a fonte errada. Além disso, o erro se repete em escala, em cada interação, antes que alguém perceba.

O Unity Catalog resolve a descoberta de dados sozinho?

Ele entrega as capacidades: a documentação da Databricks o descreve como camada unificada de governança para dados e IA, com controle de acesso, linhagem, auditoria e descoberta, capturando linhagem automaticamente até o nível de coluna e permitindo estender o grafo a fontes e ferramentas externas. O que a plataforma não faz sozinha é nomear donos, escrever a definição de negócio de cada campo e manter isso atualizado. Essa parte é trabalho humano recorrente, e precisa ser gerenciado como tal.

Por onde começar a organizar um data lake que já está bagunçado?

Pelos ativos mais consultados, identificáveis pela linhagem e pelos registros de acesso, e não por um inventário completo. Nomeie donos antes de produzir documentação, aposente o que não tem consumo nem responsável, e priorize os ativos que alimentarão iniciativas de IA, que precisam estar documentados antes do deploy. É trabalho por onda, com valor a cada onda, não um projeto único de catalogação total.

Próximo passo

Se o seu data lake acumula dado que ninguém encontra, e a iniciativa de IA depende exatamente desse acervo, o problema não é volume nem plataforma: é navegabilidade. Solicite um diagnóstico de navegabilidade do seu data lake com a CSP Tech e receba o mapa dos quatro elementos no seu ambiente: o que está catalogado, o que tem linhagem, o que tem dono e o que precisa estar pronto antes do primeiro agente consultar.

Autor: Guilherme Matos, estrategista de conteúdo e IA, certificado HubSpot, Google, Anthropic e Semrush. Revisão técnica por especialistas de dados e Atlassian da CSP Tech (especialistas Databricks, Atlassian Gold Partner, Microsoft Gold Partner, participante do Anthropic Partner Network, 34 anos de mercado, produto próprio Power BI for Jira).

Fontes (oficiais, acesso ago/2026): Databricks Documentation, “Get started with Unity Catalog”, que define o Unity Catalog como camada unificada de governança para dados e IA com controle de acesso, linhagem, auditoria e descoberta (docs.databricks.com/data-governance/unity-catalog/get-started); Databricks Documentation, “Lineage in Unity Catalog”, sobre captura automática em tempo de execução, granularidade de coluna, visualização no Catalog Explorer, agregação entre workspaces e requisito de permissão BROWSE (docs.databricks.com/data-governance/unity-catalog/data-lineage); Databricks Documentation, “External lineage”, sobre registro de metadados externos de origem e consumo e captura automática por pipelines do Lakeflow Connect (docs.databricks.com/data-governance/unity-catalog/external-lineage); Databricks, página de produto do Unity Catalog, sobre fundação semântica governada compartilhada entre times de negócio, times técnicos e agentes de IA (databricks.com/product/unity-catalog)