Glossário de governança de dados

"Dados são um ativo" é a frase mais repetida da área e normalmente a mais vazia. Ela só significa algo quando muda uma decisão, e o teste é o mesmo que você aplicaria a um prédio ou a uma frota: um ativo tem dono, valor registrado, custo de manutenção e um ciclo de vida que termina. Uma tabela que não é de ninguém, que ninguém sabe avaliar e que ninguém nunca vai apagar não é um ativo. É armazenamento. O DMBOK define governança como autoridade sobre a gestão dos ativos de dados, então a palavra faz um trabalho real nessa definição.

Na prática. Comece pelos dez conjuntos de dados que alimentam o reporting executivo e responda quatro perguntas para cada um: de quem é, quanto vale, quanto nos custa quando está errado e quando deixa de existir. Registre as respostas no inventário ou no catálogo. A medida útil é o percentual de ativos que têm ao mesmo tempo dono e definição aprovada, e a tendência desse número.

Onde dá errado. Um crawler enche o catálogo com todas as tabelas do parque, e tudo o que ele encontrou passa a se chamar ativo. Ninguém sabe qual percentual tem dono. Enquanto isso nada é aposentado, porque apagar dá medo e guardar não tem custo visível. Um registro de ativos que só cresce é um inventário de passivos.

Um comitê existe para que a governança tenha de onde tirar autoridade. Os donos dos dados conseguem acordar o que é um cliente e quem aprova o acesso a ele, mas não conseguem aprovar um orçamento, assumir um risco regulatório em nome da empresa nem dizer a outro executivo que o projeto dele atrasa porque os dados não estão prontos. É por isso que a sala é maior do que o time de dados: o patrocinador de nível C que responde pelo resultado, o encarregado de proteção de dados (DPO), o diretor de cibersegurança e, em geral, jurídico, auditoria interna e os donos dos domínios que estão na pauta.

Na prática. Reúne-se trimestralmente, não todo mês, porque decide coisas maiores e em menor número que um conselho: o conjunto de políticas, o financiamento, o apetite a risco, os domínios prioritários e as escalações que o conselho não conseguiu fechar. Cada item chega com uma recomendação e sai com um nome atribuído. O DPO e o responsável pela segurança são membros, não revisores — é isso que evita que uma objeção de privacidade apareça três semanas depois de uma decisão já tomada.

Onde dá errado. Só aparece gente de dados. Um comitê formado pelo CDO, dois analistas e um consultor pode recomendar qualquer coisa e financiar nenhuma, e em duas reuniões vira acompanhamento de projeto com título executivo. A falha oposta é igualmente comum: trinta convidados, cinquenta slides e um registro de decisões vazio desde o kickoff.

O Data Management Body of Knowledge é o mais próximo de um livro-texto compartilhado que a profissão tem. Define onze áreas de conhecimento — governança, arquitetura, modelagem, armazenamento e operações, segurança, integração e interoperabilidade, documentos e conteúdo, dados mestres e de referência, data warehousing e business intelligence, metadados e qualidade de dados — e as desenha como uma roda com a governança no centro. É um framework de verdade, e bem completo. A crítica mais comum é que ele soa muito teórico: diz o que existe e para que serve cada parte, mas está longe de ser óbvio como aplicá-lo dentro da sua própria empresa, e o sequenciamento fica com você.

Na prática. Sua função mais útil é como mapa de lacunas. Compare um programa com as onze áreas e as duas ou três que ninguém possui ficam visíveis imediatamente, o que normalmente informa mais do que qualquer nota de maturidade. Também encerra discussões sobre palavras, e é por isso que a certificação CDMP é construída sobre ele.

Onde dá errado. Os times tratam a roda como um plano e tentam levantar onze capacidades ao mesmo tempo. A roda é um mapa do território, não uma rota por ele. Um primeiro ano que faz governança, metadados e qualidade bem feitos em um único domínio vale mais que um primeiro ano que abre onze frentes e não fecha nenhuma.

Um framework é a lista de peças da governança de dados. Quase todos se reduzem a quatro componentes: papéis e responsabilidades (donos, stewards, custodiantes), políticas e padrões, instâncias de decisão como um conselho, e uma supervisão que mede se alguma dessas coisas está acontecendo. Frameworks de referência como DAMA-DMBOK e DCAM descrevem como é fazer bem em toda a disciplina. O seu é a versão dessa estrutura que você decidiu construir. Não é o modelo operacional, que diz quem ocupa cada peça na sua organização e como as decisões realmente circulam.

Na prática. Pegue emprestado o vocabulário cedo e o escopo tarde. Usar as palavras padrão para dono, steward e elemento de dados crítico não custa nada e encerra toda uma categoria de discussões. Sequenciar é outra história: um framework apresenta suas áreas como iguais, e a ordem em que você as constrói deve vir de onde chegam os seus escalonamentos, não da ordem dos capítulos.

Onde dá errado. O diagrama do framework vira o entregável. Ganha um slide, uma carta de constituição e um lançamento, e cada caixa é ocupada por um papel que ninguém exerce. Um framework diz o que um programa completo contém. Enquanto as caixas não tiverem nomes dentro, nada foi governado.

Gestão de dados é o trabalho de execução: modelar, integrar, armazenar, proteger, mover, arquivar e por fim excluir dados. É o que fazem engenheiros de dados, DBAs, arquitetos e analistas. A governança decide as regras; a gestão constrói e opera dentro delas. O DAMA-DMBOK coloca a governança como o eixo central de onze disciplinas de gestão exatamente para evitar que as duas sejam confundidas.

Na prática. A diferença fica mais clara em um único pedido. "O e-mail do cliente nunca deve estar vazio" é uma decisão de governança: alguém com autoridade sobre o domínio de cliente a declarou. Adicionar a restrição NOT NULL, corrigir as 40.000 linhas que a violam e monitorar novas violações é gestão de dados.

Onde dá errado. As organizações contratam gestão de dados e chamam isso de governança. A plataforma é construída, os pipelines rodam, e ninguém decidiu o que os números significam, então o mesmo campo é carregado de três formas para três consumidores que cada um acreditava que a sua era a definição. A falha inversa é mais silenciosa e igualmente comum: uma função de governança que produz políticas que nenhum time de engenharia teve orçamento para implementar.

Governança de dados é o exercício de autoridade e controle sobre a gestão dos dados. Ela não gerencia os dados: decide quem os gerencia, o que essa pessoa está autorizada a decidir, quais regras deve seguir e quem responde quando algo dá errado. Todo o resto que as pessoas chamam de governança — um catálogo, um painel de qualidade, um fórum de stewards — é ou um instrumento para tomar essas decisões ou a evidência de que elas foram tomadas.

Na prática. Parece uma lista curta de pessoas com nome e sobrenome, cada uma com decisões concretas associadas. Quem aprova uma mudança na definição de "cliente ativo". Quem autoriza que um dataset saia do domínio de finanças. Quem é chamado quando um relatório e um sistema não batem. Quando um programa de governança funciona, essa lista está escrita, está atualizada e é conhecida pelas pessoas que ela obriga.

Onde dá errado. A governança é comprada como ferramenta e montada como comitê, e nenhuma das duas coisas cria um direito de decisão. Um catálogo sem dono registrado ao lado de cada termo é um diretório; um conselho sem autoridade é uma reunião. Se ninguém consegue apontar uma decisão que o programa realmente tomou no último trimestre, ainda não existe governança: existe só a documentação dela.

Se uma política diz "os dados de contato do cliente devem ser utilizáveis", o padrão diz o que utilizável significa: o e-mail atende a um formato válido, o código de país é ISO 3166-1 alfa-2, o telefone é armazenado em E.164, o endereço é validado contra o arquivo postal de referência. Um padrão é escrito para ser verificado por uma máquina. Aí está a diferença em relação a uma política: uma política é um compromisso, um padrão é uma especificação.

Na prática. Padrões são o ponto em que a governança deixa de ser abstrata, porque cada um pode se tornar uma regra de qualidade com limite e painel. A sequência útil é curta: nomeie o elemento de dados crítico, escreva o padrão dele, implemente como regra, reporte a taxa de violação.

Onde dá errado. Escrevem-se padrões para tudo em vez de para o que importa, o que produz um documento que ninguém consegue implementar e um backlog que ninguém vai financiar. Vinte padrões cobrindo os campos que aparecem no reporte regulatório e nos painéis da diretoria valem mais que duzentos cobrindo cada coluna do armazém.

Uma política de dados enuncia um requisito e nomeia quem responde por cumpri-lo. "Dados pessoais não são retidos por mais tempo do que a finalidade para a qual foram coletados exige." "Todo elemento de dados crítico tem um dono com nome." Políticas são deliberadamente poucas, deliberadamente curtas e deliberadamente sem graça: são a camada que não muda quando a ferramenta muda. O detalhe de como cumprir fica em um padrão ou procedimento abaixo.

Na prática. Um conjunto de políticas viável para uma organização de porte médio ocupa de cinco a dez páginas no total, com cada política em uma única página, com dono, data de aprovação e data de revisão. Se não puder ser lido em uma tarde por alguém a quem se aplica, não será lido.

Onde dá errado. Duas formas de falhar, ambas fatais. A primeira é a política de quarenta páginas escrita para satisfazer um auditor, que ninguém lê e que portanto não governa nada. A segunda é uma política aprovada pelo time de dados e não pela área de negócio que ela obriga: no momento em que custa um prazo a alguém, descobre-se que nunca teve autoridade por trás.

Um programa é a forma como a governança de dados chega a uma organização: um patrocinador executivo, um escopo, pessoas com nome e tempo acordado, e um plano para os próximos dois trimestres. O primeiro é menor do que quase todo mundo espera. Ele se apoia em seis fundamentos: tratar dados como ativo de um jeito que mude decisões, dividir o parque de dados em domínios, nomear donos e stewards, escrever um conjunto de políticas curto o bastante para ser lido, manter um inventário simples e corrigir um pouco de qualidade de dados onde as pessoas vejam. Nada disso exige uma plataforma.

Na prática. Dois domínios, donos e stewards com nome, cinco políticas, uma planilha, três atributos medidos. Isso é um primeiro trimestre completo, e a ordem importa: domínios antes de papéis, papéis antes de políticas, políticas antes do catálogo, catálogo antes da medição. Consiga que o gestor de cada steward aceite o tempo por escrito, porque um trabalho do dia a dia com prazos sempre vence uma governança sem prazos.

Onde dá errado. O programa é conduzido como um projeto com data para acabar. Há uma carta de constituição, uma rajada de atividade e um relatório de encerramento, e o problema original continua intacto: onze políticas aprovadas e duas áreas ainda levando números de receita diferentes para a mesma reunião. Governança se comporta como operação. O programa dá a partida; depois do lançamento, algo permanente precisa sustentá-la.

Um conselho existe para o conflito entre domínios. Duas áreas querem definições incompatíveis da mesma entidade; uma política custaria a um departamento o roadmap do trimestre; um domínio quer expor dados sobre os quais outro domínio é regulado. Isso não se resolve dentro de um domínio, e escalar cada caso a um comitê executivo não escala. O conselho é o lugar permanente onde essas questões são resolvidas, pelas pessoas responsáveis pelos domínios envolvidos.

Na prática. Um conselho que funciona é pequeno — os donos dos dados, presidido por alguém com peso executivo —, se reúne mensalmente e trabalha sobre uma fila de decisões concretas com uma resposta proposta anexada. A ata registra o que foi decidido e por quem, e é isso que o torna autoridade e não conversa.

Onde dá errado. O conselho se torna uma reunião de status. Vinte participantes, uma apresentação, uma rodada de novidades, nenhuma decisão, e em dois trimestres os donos mandam delegados em vez de comparecer. O teste confiável: se a pauta não contém a palavra "aprovar", cancele a reunião e escreva um e-mail.

Um steward é a metade operacional da propriedade. Ele escreve e mantém as definições no glossário de negócio, traduz a política em regras, faz a triagem dos incidentes de qualidade e é a primeira ligação quando um número parece errado. É escolhido por conhecimento, não por hierarquia: normalmente é a pessoa a quem o resto do time já perguntava, informalmente, antes de o papel existir. Os melhores stewards já faziam quase todo o trabalho sem remuneração e sem documentação.

Na prática. Stewardship é um percentual declarado de um cargo real, não um título somado a uma carga de trabalho já cheia. De dez a vinte por cento, protegido e com o respaldo do dono, é a diferença entre uma rede de stewards que funciona e uma que para de se reunir silenciosamente depois de quatro meses.

Onde dá errado. Stewards são nomeados em bloco, recebem um modelo e nenhum tempo, e são cobrados por documentar tudo. Nada é documentado, e o programa conclui que o negócio não está engajado. Capacidade de stewardship é o que mais frequentemente fica sem recursos em um programa de governança, e o mais fácil de corrigir.

Direitos de decisão são a substância da governança. Não "o conselho governa os dados de cliente", mas: quem aprova um novo atributo de cliente, quem aprova uma mudança em uma definição existente, quem concede acesso fora do domínio, quem aceita uma tolerância de qualidade, quem declara um incidente. Cada uma é uma decisão distinta com um decisor distinto, e escrevê-las costuma ser a semana de maior valor que um programa de governança investe.

Na prática. Basta uma tabela de uma página: a decisão nas linhas, o papel nas colunas, um único A por linha. A restrição que a torna útil é que cada linha tenha exatamente um responsável. Dois A em uma linha é uma discussão não resolvida registrada como se fosse um projeto.

Onde dá errado. Direitos de decisão são documentados como um RACI sobre atividades e não sobre decisões, o que produz uma matriz em que todos são consultados sobre tudo e nada fica mais rápido. A outra falha é publicar a tabela sem avisar ninguém de que seu nome está nela.

Um dono dos dados tem senioridade suficiente para que suas decisões se sustentem. Ele aprova definições, autoriza acessos, aceita ou rejeita tolerâncias de qualidade e assume a consequência quando os dados do seu domínio falham com alguém mais adiante. Propriedade é responsabilidade, não custódia: o dono raramente toca os dados e quase nunca os corrige pessoalmente. O que distingue um dono real de um nominal é que ele pode dizer não a um pedido de outra área e ser respeitado.

Na prática. A propriedade fica com o líder de negócio cujos objetivos mais dependem do domínio: comercial para cliente, operações para produto, RH para funcionário. É uma pessoa com nome, nunca um time e nunca um comitê, e aparece nos objetivos dela e não em um slide.

Onde dá errado. A propriedade é atribuída à TI, que tem a custódia mas não a autoridade sobre o significado, ou é distribuída em um "grupo de trabalho", o que significa que a próxima definição em disputa não tem quem a resolva. O sintoma mais claro é um pedido de mudança de definição que circula por seis semanas: isso não é um processo lento, é um dono ausente.

Stewardship é o mecanismo que transforma autoridade em efeito. Um conselho pode decidir que "receita" tem uma única definição; o stewardship é o que encontra os quatro sistemas onde ela é calculada de forma diferente, consegue mudar três e documenta o quarto como exceção conhecida. Como disciplina é pouco glamourosa: manter um glossário, correr atrás de um incidente entre dois times, explicar a mesma definição para um analista novo pela quinta vez.

Na prática. Um modelo de stewardship nomeia, por domínio, quem é o dono, quem são os stewards, como uma mudança de definição é proposta e aprovada e onde os incidentes são registrados. Escrito, isso ocupa duas páginas, e essas duas páginas são o modelo operacional que falta na maioria dos programas.

Onde dá errado. Stewardship é tratado como trabalho de documentação e medido por quantidade de termos no glossário. Quantidade de termos é métrica de vaidade: um glossário de 900 termos que ninguém consulta vale menos que 40 termos que o time de reporte usa de verdade. Meça uso e resolução, não volume.

Um catálogo é um buscador dos seus próprios dados. Ele responde às duas perguntas que de outra forma consomem o tempo dos analistas — já existe um conjunto de dados para isso? e posso confiar nele? — colocando estrutura técnica, definições de negócio e propriedade no mesmo lugar. A maioria dos catálogos consegue coletar a estrutura automaticamente de armazéns, ferramentas de BI e pipelines; nenhum consegue fornecer o significado, e é por isso que um catálogo é um projeto de governança disfarçado de orçamento de ferramenta.

Na prática. A adoção de um catálogo é acompanhada por um único número: o percentual dos ativos que as pessoas realmente buscam que têm dono e definição. Popular bem os 200 principais ativos vale mais que popular 20.000 no vazio, e é a versão que é usada duas vezes.

Onde dá errado. O catálogo é comprado antes de as definições existirem e implantado como o entregável do programa. Seis meses depois ele contém todas as colunas do parque, 3% têm descrição e a organização conclui que catálogos não funcionam. A ferramenta funcionava bem; não havia nada para colocar dentro.

Certificação é uma promessa presa a um ativo específico. Alguém responsável revisou a definição, a origem e a qualidade, e assina embaixo. O selo no catálogo ou na ferramenta de BI é o que torna essa promessa utilizável. Ele permite decidir se confia em um segundo em vez de uma hora, e é o que separa o número de margem governado das quatro versões improvisadas ao lado dele. Algumas organizações usam níveis, como ouro para dados aptos a embasar decisões, em vez de um simples sim ou não.

Na prática. Certifique poucas coisas que importam e publique os critérios: dono, definição aprovada, qualidade dentro da tolerância, consumidores conhecidos. Trate a aposentadoria também como uma decisão, tomada pelo dono da métrica depois de consultar os consumidores registrados e com o uso recente como evidência. Meça se os ativos certificados são reutilizados em vez de reconstruídos, e se as pessoas continuam usando depois dos primeiros 90 dias.

Onde dá errado. A certificação é concedida uma vez e nunca revisada, então o selo sobrevive ao dono, à definição e aos controles de qualidade que o sustentavam. A falha oposta é pedir que as pessoas prefiram dados certificados antes que exista algum. Nos dois casos o selo deixa de significar algo e as pessoas voltam para as próprias planilhas.

Dados mestres são os que aparecem em todos os sistemas: o cliente que existe no CRM, no faturamento, no suporte e no armazém, em quatro versões ligeiramente diferentes. MDM é a prática de resolvê-las em um único registro com um identificador conhecido, e de decidir qual sistema pode alterar qual atributo. É trabalho técnico com um pré-requisito de governança, porque regras de correspondência e de sobrevivência são decisões de negócio disfarçadas de configuração.

Na prática. Projetos de MDM funcionam quando partem de uma dor concreta — clientes duplicados inflando a taxa de churn, um fornecedor pago duas vezes — e cobrem uma única entidade. Fracassam quando partem da ambição de uma visão única de cliente para toda a empresa.

Onde dá errado. O limite de correspondência é definido pelo time de implantação. Alguém tem que decidir se mesclar dois registros com 92% de similaridade é aceitável, e a consequência de uma mescla errada é um cliente vendo os dados de outro cliente. Essa é uma decisão do dono, e delegá-la a uma tela de configuração é como o MDM se torna um incidente de privacidade.

Um glossário de negócio responde "o que esta palavra significa aqui". Não em geral, nem no setor: aqui, nesta empresa, para fins de reporte. Cada entrada tem uma definição, um dono que a aprovou, o cálculo se for uma métrica e, no melhor caso, os sistemas e relatórios onde está implementada. O glossário é onde um programa de governança se torna visível pela primeira vez para quem está fora dele, o que faz sua qualidade importar de forma desproporcional.

Na prática. Um glossário justifica sua existência na primeira vez que encerra uma discussão. Comece pelos vinte termos que aparecem no reporte da diretoria e que se sabe estarem em disputa — churn, cliente ativo, receita, headcount, entrega no prazo — e leve cada um a uma única definição aprovada.

Onde dá errado. O glossário é construído como exercício de exaustividade, em uma ferramenta que ninguém tem no fluxo de trabalho diário, então as definições são escritas uma vez e nunca consultadas. Um glossário que não é alcançável de onde as pessoas trabalham — a ferramenta de BI, a busca da intranet, o catálogo — é um documento, não um controle.

A maioria dos catálogos foi projetada para ser varrida: um scan roda no domingo à noite e, na quarta, o catálogo descreve um warehouse que já não existe. A ingestão ativa inverte isso. Cada execução de pipeline, cada mudança de schema, cada acesso concedido, cada teste que falha e cada consulta a uma tabela emitem um evento, e a plataforma de metadados escuta em vez de perguntar. O ganho não é documentação mais fresca: é que um metadado que chega em segundos pode ser acionado automaticamente, coisa que o metadado passivo nunca permitiu.

Na prática. Os conectores assinam o que a plataforma já emite: logs de consulta, eventos do orquestrador, fluxos de CDC, execuções de CI, mudanças de IAM. A linhagem é recalculada a cada execução em vez de deduzida do SQL uma vez por trimestre, uso e custo vêm do consumo real, e o ciclo se fecha do lado operacional: uma regra de qualidade que falha abre um ticket para o dono com nome, uma mudança incompatível de schema quebra o build do produtor, uma tabela sem uso entra na lista de descontinuação e uma coluna nova com cara de dado pessoal é sinalizada antes de alguém consultá-la.

Onde dá errado. Constrói-se o fluxo e não o ciclo. Milhões de eventos entram num catálogo que ninguém abre e a única diferença em relação ao scan semanal é a fatura. O teste é simples: algum evento de metadado muda algo fora do catálogo — um alerta, uma revisão de acessos, um deploy bloqueado? Se não, isto é um projeto de documentação muito caro.

A linhagem responde a duas perguntas que de outra forma são caras. Para cima: este número parece errado, de onde veio e o que o tocou? Para baixo: vamos mudar este campo, o que quebra? A segunda é a análise de impacto e, em organizações com alguma complexidade de pipelines, é a que paga todo o exercício: a alternativa é um congelamento de mudanças ou uma descoberta em produção.

Na prática. Vale a pena capturar a linhagem na granularidade sobre a qual você vai agir. Linhagem tabela a tabela nos pipelines que sustentam os relatórios regulatórios normalmente basta para responder às duas perguntas; linhagem em nível de coluna em todo o parque é um projeto de pesquisa.

Onde dá errado. A linhagem é desenhada à mão em uma ferramenta de diagramas. É exata no dia em que é desenhada e está errada antes de a sprint acabar, e como parece autoritativa as pessoas se apoiam nela depois de deixar de ser verdadeira. Uma linhagem que não é derivada dos próprios pipelines tem validade de semanas.

Metadados costumam ser divididos em três. Metadados de negócio são significado: a definição de "cliente ativo", o dono, a classificação de sensibilidade. Metadados técnicos são estrutura: tabela, coluna, tipo, nulidade, o processo que a alimenta. Metadados operacionais são comportamento: quando a última carga rodou, quantas linhas chegaram, quantas falharam na validação. Um programa de governança precisa dos três, mas só tem orçamento para começar por um.

Na prática. Comece pelos metadados de negócio dos dados que já aparecem em decisões, porque é ali que a ausência dói: um analista que não consegue distinguir qual de duas colunas de receita é a reportada perde uma hora por semana com algo que uma frase resolveria.

Onde dá errado. Metadados são coletados em massa porque uma ferramenta consegue fazê-lo automaticamente, e o resultado é um catálogo com 40.000 entradas técnicas sem significado associado. A coleta automática é a metade barata. A metade cara é uma pessoa decidir o que cada coisa significa, e nenhuma ferramenta nunca fez essa parte.

Um campo quebrado é um sintoma. A causa quase sempre está antes do banco de dados: um formulário que aceita texto livre, uma passagem entre times que ninguém assumiu, uma integração que trunca em silêncio, uma meta que premia preencher qualquer coisa para fechar o chamado. A análise de causa raiz é a disciplina de perguntar por quê até chegar a algo que uma pessoa ou uma mudança de processo consiga corrigir. Os 5 porquês são a ferramenta de sempre e a linhagem é o mapa que se segue. É o passo Analisar do DMAIC, e o que transforma uma limpeza em uma melhoria.

Na prática. Comece pelos escalonamentos, não por um framework. Puxe um ano de incidentes, tickets e achados de auditoria e classifique por causa; a maioria das organizações descobre que quatro ou cinco causas explicam a maior parte, e que ao menos uma se repete há anos sem dono. Cada causa confirmada deve terminar em duas coisas: uma correção onde o defeito nasce e uma regra de qualidade de dados que pegue a próxima ocorrência.

Onde dá errado. A análise para na primeira resposta técnica — "o job de ETL falhou" —, que é onde a culpa é mais fácil de colocar e menos útil. Ou dura um trimestre, produz um lindo diagrama de causa e efeito e não muda nenhum sistema. Uma análise que não muda um processo só documentou o problema com mais detalhe.

O custo aparece em lugares que ninguém rotula como dados: faturas refeitas, entregas impossíveis, analistas reconciliando dois relatórios à mão, gasto de marketing contra contatos duplicados, uma redeclaração regulatória. Cada um é pequeno e cada um tem um responsável que parou de notá-lo, e é por isso que o total é invisível até alguém somar. Somar costuma ser a coisa mais persuasiva que um programa de governança faz.

Na prática. Quantifique três falhas concretas em vez de estimar uma cifra global. Horas × custo carregado × frequência, mais o gasto direto. Três números críveis e defensáveis de processos que o negócio reconhece farão mais por um business case do que um percentual de referência sobre a receita.

Onde dá errado. A cifra é tirada de um estudo de fornecedor — "dados ruins custam às empresas de 15% a 25% da receita" — e apresentada como o número desta empresa. Um diretor financeiro a descarta em uma frase, e a credibilidade não volta. Seus três exemplos próprios, por modestos que sejam, sobrevivem à pergunta "de onde veio isso?".

O mesmo cliente aparece três vezes, com grafias um pouco diferentes, dois endereços e um único e-mail entre eles. A deduplicação encontra esses registros, decide quais pertencem juntos e os mescla ou vincula para que o negócio conte um cliente em vez de três. A parte difícil não é o algoritmo de correspondência; é concordar sobre o que faz dois registros serem a mesma entidade e qual versão de cada atributo sobrevive.

Na prática. Faça o profiling da taxa de duplicados na chave natural do seu conjunto de dados mais usado antes de escolher uma ferramenta: o número defende o caso sozinho. Combine com o dono dos dados as regras de correspondência e de sobrevivência, rode a deduplicação como rotina recorrente e não como limpeza pontual, e declare o registro resultante como fonte da verdade. É uma das vitórias iniciais mais confiáveis de um programa de governança, porque é visível e mensurável.

Onde dá errado. Um projeto de limpeza deduplica a base de clientes, todos comemoram e os sistemas de origem continuam criando duplicados no mesmo ritmo. Seis meses depois, o número voltou. A deduplicação só se mantém por causa da decisão de governança que vem depois dela: uma fonte autorizada e um processo no ponto de entrada que verifica antes de criar.

As dimensões existem para que "os dados estão ruins" se torne um diagnóstico. Completude é se o valor está lá. Validade é se ele obedece ao seu formato. Exatidão é se corresponde à realidade — a única dimensão que normalmente precisa de uma pessoa ou de uma referência externa para ser testada. Consistência é se o mesmo fato concorda entre sistemas. Oportunidade é se chegou em tempo de ser útil. Unicidade é se a entidade aparece uma única vez.

Na prática. A maioria dos problemas reais é de validade, completude e consistência, nessa ordem, porque são as três que um sistema pode gerar em silêncio. Nomear a dimensão diz onde a correção pertence: validade normalmente é um controle de entrada, consistência normalmente é uma integração, oportunidade normalmente é um agendamento.

Onde dá errado. A exatidão é medida com uma regra, e não pode ser. Um CEP que passa na validação de formato e pertence a outra cidade é válido e errado. Testar exatidão significa comparar contra algo autoritativo e, se essa fonte não existe, diga isso em vez de reportar 98%.

O trabalho de qualidade de dados falha de um jeito bem previsível: alguém faz uma limpeza, o painel fica verde e seis meses depois o mesmo campo está quebrado outra vez, porque nada mudou lá em cima. DMAIC é a disciplina que evita isso. Vem da manufatura, encaixa em dados quase sem adaptação e todo o seu valor está na última letra: Controlar é o passo que separa uma melhoria de uma limpeza.

Na prática. Definir escolhe um elemento de dados crítico e a dor de negócio ligada a ele, em dinheiro ou em horas. Medir faz o perfil do estado atual para existir uma linha de base, e não uma opinião. Analisar rastreia o defeito até a origem, que quase sempre é um processo ou um formulário, não um banco de dados. Melhorar corrige onde nasce: um campo obrigatório, uma validação, um handoff redesenhado, um time retreinado. Controlar deixa uma regra de qualidade, um monitor, um limite e um dono com nome que recebe o alerta. Um ciclo por elemento, de seis a dez semanas, uma página de evidência em cada passo.

Onde dá errado. Os times param depois de Melhorar, porque é ali que está a vitória visível e é ali que o patrocinador aplaude. A outra versão é o projeto que passa um trimestre entre Medir e Analisar, produz uma apresentação linda de causa raiz e não muda sistema nenhum.

Criticidade é um mecanismo de triagem. Nenhuma organização consegue governar todos os campos, então a lista de CDE é a resposta honesta a "quais realmente importam". Um campo é crítico se alimenta uma declaração regulatória, uma demonstração financeira, um pagamento, uma decisão de segurança ou uma métrica de diretoria. Isso normalmente fica entre 50 e 300 campos em uma empresa de médio porte, de dezenas de milhares.

Na prática. Derive a lista de trás para frente, a partir da consequência. Pegue os relatórios regulatórios, o material da diretoria e os três principais processos operacionais e rastreie de quais campos eles dependem. Esse rastreio é sua lista de CDE, e vem com a própria justificativa embutida — o que é o que a torna financiável.

Onde dá errado. A criticidade é decidida perguntando a cada departamento quais dos seus dados são críticos. Todos respondem "todos", porque ninguém é premiado por declarar que seus dados não importam. Criticidade precisa ser derivada do uso, não coletada como opinião.

Um limite é o número que transforma uma medição em uma decisão. Completude de 97% não significa nada sozinha; completude abaixo de 98% no endereço de cobrança, que trava a emissão de faturas, significa que o steward recebe um chamado. Quem define é o dono dos dados, porque só o negócio sabe quanto erro um processo absorve antes de custar dinheiro. A engenharia aplica, e o steward cuida do que fica abaixo.

Na prática. Defina limites por uso, não por campo no abstrato, e parta da consequência: o que quebra mais adiante e a partir de que taxa começa a doer? Coloque o limite onde o trabalho já acontece — na definição de pronto de um pipeline, nos critérios de lançamento — para que ele seja verificado toda vez, e não revisado uma vez por trimestre. Registre por que cada número foi escolhido; o motivo é o que permite mudá-lo depois sem briga.

Onde dá errado. Os limites são copiados do padrão de um fornecedor ou fixados em 100% porque qualquer coisa menor soa como aceitar dados ruins. Um limite de 100% dispara o tempo todo, é silenciado e não protege nada. A falha oposta é um limite tão frouxo que nunca dispara, o que no painel parece boa qualidade e não é.

Um pipeline que cai dispara um alerta. As falhas caras são as que não disparam: uma tabela que carrega metade das linhas de sempre, uma fonte que para de atualizar, uma coluna de origem que muda de tipo sem aviso. A observabilidade vigia esses sinais continuamente — contagem de linhas, atualidade em relação ao agendamento, deriva de esquema, valores saindo da faixa habitual — e avisa alguém quando os dados se comportam diferente de si mesmos.

Na prática. Monitore primeiro as tabelas por trás das decisões que importam e direcione cada alerta para um steward com nome, não para um canal compartilhado. Combine com a linhagem, para que um alerta em uma tabela de origem mostre na hora quais painéis e modelos dependem dela. A observabilidade é boa em dizer que algo mudou; decidir se a mudança é um problema continua sendo trabalho de alguém que conhece o negócio.

Onde dá errado. Uma ferramenta é ligada no data warehouse inteiro, aprende milhares de linhas de base e dispara a cada pico de fechamento de mês e a cada queda de feriado. O time silencia tudo em semanas. A outra falha é tratar a observabilidade como substituta da validação: ela percebe os dados ruins depois que chegaram, o que é útil, mas não impede que eles entrem.

Perfilamento é como você descobre que o campo de país contém 47 grafias distintas de "Reino Unido", que 8% das datas de nascimento são 01/01/1900 e que uma coluna documentada como obrigatória está vazia em um terço das linhas. É o diagnóstico mais barato do trabalho com dados e o mais frequentemente pulado, porque produz fatos incômodos antes de um projeto ter acordado seu escopo.

Na prática. Perfile antes de prometer. Meio dia de perfilamento nas tabelas por trás de um painel proposto vai dizer se esse painel é um trabalho de duas semanas ou de dois trimestres, e isso é a coisa mais útil que você pode saber no início.

Onde dá errado. O resultado do perfilamento é apresentado cru. Ninguém fora do time de dados tem opinião sobre um relatório de cardinalidade. Traduza: "a tabela de clientes tem 14.000 registros duplicados, e é por isso que a taxa de churn no material da diretoria está superestimada em cerca de quatro pontos". Mesma descoberta, outra consequência.

Toda organização tem: a exportação que o financeiro redigita todo mês, a pasta de trabalho regional com sua própria definição de "cliente ativo", o arquivo em que o analista confia mais do que no painel. Cada uma nasceu como uma gambiarra razoável para um problema real: um acesso lento, um número errado, um relatório que não respondia à pergunta. Juntas, são o lugar onde vivem os números reais da organização, fora de qualquer controle, linhagem ou auditoria.

Na prática. Trate planilhas paralelas como evidência, não como má conduta. Pergunte o que cada uma resolve e você terá uma lista priorizada de pontos de dor: definições que faltam, acessos que levam três semanas, qualidade que ninguém escala. Contá-las é uma aproximação razoável da lacuna de confiança. Aposente-as corrigindo o motivo pelo qual existem e dando aos consumidores um caminho para reportar divergências a um steward, e depois meça quantas desaparecem.

Onde dá errado. A governança proíbe planilhas ou bloqueia exportações sem corrigir o que levou as pessoas até elas. O trabalho vai para um lugar menos visível, o risco é transferido em vez de reduzido e a próxima auditoria encontra os mesmos números em um drive pessoal. Uma planilha de que ninguém mais precisa desaparece sozinha.

Não existe qualidade de dados absoluta. Um endereço de cliente que serve para enviar um e-mail de marketing não serve para entregar um palete, e o mesmo registro pode ser simultaneamente aceitável e inutilizável dependendo de quem o pegou. É por isso que "melhorar nossa qualidade de dados" não é acionável e "nossos dados de endereço precisam ser suficientes para entregar e hoje 12% não são" é.

Na prática. O trabalho de qualidade roda em ciclo: escolha um uso que importa, defina a regra que esse uso exige, meça a taxa de violação, corrija o processo que a gera e continue medindo. O quarto passo é o que muda algo: limpar sem corrigir a origem é uma assinatura, não um projeto.

Onde dá errado. A qualidade é medida contra todas as dimensões para todos os campos e reportada como uma única nota. Um percentual composto não diz a ninguém o que fazer na segunda-feira. Reporte por regra e por dono, nomeie o processo que produziu a violação, e a conversa passa a ser resolvível.

Uma regra tem quatro partes: os dados a que se aplica, a condição que afirma, o limite a partir do qual o resultado conta como falha e a pessoa que faz algo a respeito. Sem o limite, cada regra fica sempre verde ou sempre vermelha. Sem responsável, uma regra que falha é uma notificação que ninguém concordou em receber, o que em um mês é uma pasta de e-mail filtrada.

Na prática. As regras que vale a pena escrever vêm de incidentes. Algo deu errado, alguém investigou, a causa foi uma condição dos dados: codifique essa condição como regra para que a próxima ocorrência seja pega antes da consequência. Um backlog de regras derivadas de incidentes reais tem uma credibilidade que um conjunto gerado nunca tem.

Onde dá errado. Regras são geradas automaticamente a partir do profiling e ligadas em bloco. O resultado são milhares de alertas, a maioria descrevendo condições perfeitamente normais naquele negócio, e o time para de ler todos. Fadiga de alerta não é um problema de ajuste, é uma decisão de projeto tomada cedo demais.

Um SLA de qualidade de dados transforma "os dados deveriam estar bons" em números que alguém assina: a tabela de clientes chega até as 06:00, os campos obrigatórios estão pelo menos 99,5% preenchidos, a precisão do faturamento fica acima de uma linha combinada. Ele fica entre o time que produz os dados e os times que constroem em cima deles, e nomeia um responsável do lado produtor. Sem esse nome, é um desejo com casas decimais.

Na prática. Comece com três dimensões, normalmente atualidade, completude e precisão, no punhado de conjuntos de dados que alimentam as decisões que as pessoas de fato discutem. Cada compromisso precisa de uma medição que rode sozinha e de um tempo de resposta para descumprimentos, não só de uma meta. O SLA útil é aquele que um dono de domínio consegue ver em um painel, ao lado de se ele foi cumprido no mês passado.

Onde dá errado. O SLA é escrito pelo lado consumidor, promete o que ele gostaria e não o que o produtor consegue entregar, e é descumprido desde a primeira semana. Ninguém renegocia, todos param de olhar e o documento sobrevive como prova de que um dia se falou de qualidade. Um SLA que nunca é descumprido geralmente está baixo demais; um que é sempre descumprido não é um acordo.

A validação é o portão. Na ingestão, ela aplica o esquema, rejeita valores de transação negativos e e-mails malformados, e verifica se as chaves obrigatórias estão preenchidas. Na transformação, verifica se uma devolução tem a compra correspondente e se os totais batem entre origem e destino. Registros que falham são rejeitados ou colocados em quarentena em vez de seguir adiante, porque o lugar mais barato para corrigir dados ruins é antes de alguém construir algo em cima deles.

Na prática. Coloque as primeiras verificações onde hoje entram dados sem validação: ingestão via API e uploads manuais de arquivos são os suspeitos de sempre. Comece leve — esquema, completude, algumas verificações de faixa nas tabelas prioritárias — e acrescente validação de regras de negócio onde os incidentes mostrarem que é preciso. Uma verificação que falha deveria interromper a carga ou mandar os registros para uma tabela de quarentena, e alguém deveria ser dono do que cai lá.

Onde dá errado. As verificações registram as falhas e deixam tudo passar, e a validação vira um relatório do que deu errado ontem. Ou a tabela de quarentena existe e ninguém olha para ela, o que é só uma forma mais lenta de perder registros. Validar sem decidir o que acontece na falha é monitoramento com passos a mais.

Alfabetização de dados não é estatística. É a capacidade prática de olhar um gráfico e saber a que pergunta ele responde, de notar que o denominador mudou, de perguntar de onde veio um número antes de repeti-lo e de dizer "isso não sustenta essa conclusão" em uma reunião. É sobretudo ceticismo e vocabulário, mais do que técnica, e é por isso que pode ser ensinada a um time comercial em semanas e por isso que a implantação de uma ferramenta nunca a produz.

Na prática. A alfabetização é construída sobre os dados da própria organização, no contexto de decisões que as pessoas já tomam. Uma sessão de uma hora percorrendo com um time de vendas o próprio relatório de pipeline — o que cada campo significa, onde ele quebra, quais comparações são inválidas — supera um curso genérico com folga.

Onde dá errado. A alfabetização é comprada como licença de uma plataforma de e-learning e reportada como taxa de conclusão. Conclusão mede presença, não capacidade. A medida que importa é se as perguntas feitas nas reuniões de revisão melhoram, e isso é observável em um trimestre se alguém estiver prestando atenção.

A analítica self-service troca a fila de chamados por infraestrutura: um catálogo pesquisável para encontrar os dados, acesso concedido por papel e não por thread de e-mail, conjuntos de dados certificados sobre os quais construir e ferramentas de BI que o pessoal de negócio consegue de fato usar. O que se busca é velocidade para a pergunta rotineira — o gerente de loja olhando o estoque local, a analista de marketing destrinchando a campanha do mês passado — enquanto o time central deixa de ser o gargalo de cada mudança em relatório e passa a manter aquilo sobre o que todo mundo constrói.

Na prática. Funciona em cima da governança, não no lugar dela. O mínimo é um pequeno conjunto de dados certificados com um dono nomeado, definições acordadas para as métricas que as pessoas vão calcular e níveis de acesso que deixem a maioria entrar nos dados operacionais agregados sem uma aprovação a cada vez. Depois, treinamento com os dados dos próprios usuários, porque uma ferramenta que ninguém sabe interpretar só produz números errados com mais confiança e mais rápido.

Onde dá errado. A ferramenta é implantada antes de tudo isso. Cada departamento cria seus próprios painéis com a própria fórmula para a mesma métrica, os relatórios se multiplicam e em um ano a reunião de diretoria tem três números de receita e não confia em nenhum. Isso não é falha do self-service. É self-service sem glossário.

Cultura é observável em comportamentos pequenos. Se uma reunião começa pelo número ou pela opinião. Se um analista pode dizer que os dados não sustentam o plano sem custo para a carreira. Se um relatório que mostra um fracasso é distribuído ou é revisado. Se as pessoas procuram dados existentes antes de encomendar novos. Nada disso vem de um cartaz; tudo vem do que os executivos são vistos fazendo quando os dados são inconvenientes.

Na prática. A cultura se move quando os incentivos se movem. A intervenção individual mais eficaz é um líder mudar publicamente uma decisão por causa da evidência e dizer que foi esse o motivo. Isso vale mais do que um ano de comunicação interna.

Onde dá errado. A cultura é tratada como o componente subjetivo e não mensurável do programa e entregue à comunicação. Não é subjetiva nem impossível de medir: meça com que frequência os números de um documento de decisão foram reconciliados antes, quantas decisões citam uma fonte, quanto tempo leva para responder "de onde veio isso?". Essas coisas se movem e podem ser acompanhadas.

O oposto da tirania dos dados, aquela situação em que uma pergunta rotineira exige um chamado, uma semana e autorização por escrito da TI. A democratização muda o padrão de "fechado salvo aprovação" para "disponível salvo risco", com a propriedade distribuída entre os domínios de negócio e uma função central que define os padrões de segurança, mantém o glossário e cuida da coerência da arquitetura. Não é terra sem lei. Bem feita, exige mais governança do que o bloqueio exigia, só que de outro tipo.

Na prática. Classifique os dados em níveis. Dados altamente restritos — dados pessoais, livros contábeis, segredos comerciais — mantêm aprovações rígidas, mascaramento e log de auditoria. Dados operacionais de negócio ficam abertos aos usuários autenticados por meio de modelos certificados. Dados exploratórios brutos ficam em sandboxes. Some a isso um catálogo para as pessoas acharem as coisas, acesso baseado em papéis para que ele não dependa da caixa de entrada de alguém e alfabetização para que o acesso vire decisão.

Onde dá errado. É anunciada como valor e entregue como licença: todo mundo ganha a ferramenta de BI, ninguém ganha definições nem dados certificados. Ou as restrições continuam, as pessoas dão a volta nelas e a organização acaba com um mercado negro de dados feito de planilhas exportadas — democratização, tecnicamente, sem nenhum dos controles.

Gestão da mudança é a parte da governança de dados que lida com pessoas, não com dados. A governança redistribui autoridade, cria rotinas e pede que as pessoas parem de fazer coisas que funcionam para elas localmente, como exportar arquivos brutos para as próprias planilhas. A resistência é normal e costuma ter causas comuns: não se entende o que está mudando, há medo de perder o controle dos próprios números ou se enxerga atrito sem nenhum benefício próprio. O DMBOK dedica a ela o último capítulo, que é mais ou menos onde a maioria dos programas também a deixa.

Na prática. Comece por uma história de negócio, não por uma política: a previsão que saiu errada, a campanha que atrasou. Recrute aliados dentro dos domínios, stewards e líderes de time que o resto da equipe já escuta, porque colegas convencem onde um time central não consegue. Traduza o jargão em frases simples, torne visíveis as primeiras vitórias e meça a adoção: quantas pessoas usam dados certificados toda semana e quantas planilhas paralelas foram aposentadas.

Onde dá errado. Ela é tratada como comunicação: um e-mail de lançamento, um PDF com a política, um slide na reunião geral. Todo mundo fica informado e ninguém se comporta de outro jeito. Contar políticas publicadas mede quanto foi escrito, não se alguém mudou o que faz.

O teste não é se os dados aparecem no documento de decisão. É se os dados poderiam ter produzido uma decisão diferente. Uma organização que reúne a evidência depois de escolher não é orientada a dados, é decorada com dados, e todos os envolvidos percebem a diferença. Ser genuinamente orientado a dados também exige aceitar que algumas decisões têm evidência insuficiente e dizer isso, em vez de vestir um julgamento como análise.

Na prática. Escreva, antes da análise, qual resultado faria você mudar de ideia. Esse único hábito converte um exercício de confirmação em uma decisão, e é gratuito.

Onde dá errado. A expressão é usada para dizer "temos painéis". Painéis são oferta. Uma cultura de decisão é demanda, e as duas são independentes — há muitas organizações com reporte excelente do qual nenhuma decisão jamais dependeu. Um trabalho de governança que só melhora a oferta não vai mover isso em nada.

O modelo é a régua; a avaliação é o ato de medir com ela. Você escolhe um framework, reúne evidências em cada uma das dimensões — qualidade, stewardship, metadados, segurança, arquitetura — e atribui um nível a cada uma, de modo que o resultado diz "nível 1 em qualidade, nível 3 em segurança" e não uma nota única. A versão útil tem quatro passos: delimitar o escopo, reunir evidências, mapear os níveis e transformar as lacunas em um plano com responsáveis e datas. É uma linha de base que se repete, não um diploma para pendurar na parede.

Na prática. Evidência ganha de questionário. Peça para ver o glossário, os últimos tickets de incidente, a trilha de aprovação de acessos, e pontue o que é mostrado, não o que é contado. Limite o escopo às perguntas sobre as quais você vai agir: uma leitura rápida para achar a dimensão mais fraca é útil, uma linha de base de quarenta itens sobre todas as áreas de conhecimento é um projeto por si só. E não é preciso uma avaliação para achar a dor: entrevistas e um ano de escalonamentos mostram isso mais rápido.

Onde dá errado. A avaliação vira os primeiros seis meses do programa e seu único entregável. Ou a meta é escrita como um nível, "chegar ao nível 3", que ninguém fora do time de dados consegue avaliar e nenhuma revisão de orçamento vai financiar. Traduza cada lacuna em um resultado de negócio antes de ela entrar no roadmap.

O DCAM é publicado pelo EDM Council (Enterprise Data Management Council), uma associação do setor com raízes profundas em serviços financeiros, e isso aparece: ele foi pensado para organizações que um dia vão ter de mostrar a um auditor ou a um regulador como gerenciam seus dados. Agrupa a gestão de dados em oito áreas de capacidade — estratégia e caso de negócio, programa e financiamento, arquitetura de negócio e técnica, qualidade de dados, governança, ambiente de controle e analytics — e pontua cada uma em seis níveis de realização, de não iniciado a aprimorado. Onde o DAMA-DMBOK descreve o que a gestão de dados abrange, o DCAM foi desenhado para medir o quanto você já avançou.

Na prática. Sua força é a evidência. Uma pontuação DCAM deve se apoiar em artefatos — a política aprovada, o papel com orçamento, o controle que de fato roda —, o que o torna adequado quando o resultado precisa sobreviver a uma auditoria ou ser comparado entre unidades de negócio. Também é detalhado, e o uso completo costuma passar pela associação e pelo treinamento do Council. A maioria dos programas menores pega emprestada a estrutura em vez de aplicá-lo de ponta a ponta.

Onde dá errado. O DCAM é escolhido porque soa rigoroso e depois aplicado como uma planilha autoavaliada pelo próprio time avaliado. O detalhe que o torna confiável vira o motivo de ele nunca terminar. Se ninguém fora do escritório de dados vai olhar as notas, um modelo mais leve e três ações nomeadas farão mais.

Governança proativa significa que os controles ficam onde o dado é feito, não onde ele é consumido. As definições são acordadas antes de a tabela ser construída. As regras de qualidade rodam dentro do pipeline, então uma carga ruim para em vez de chegar. As interfaces carregam um contrato, então uma mudança incompatível quebra o build do produtor e não o relatório de segunda-feira de outra pessoa. Os acessos são revisados por calendário, e não quando um auditor pergunta. A classificação acontece na criação, quando a pessoa que sabe o que o campo contém ainda está na sala.

Na prática. Isso muda o que você reporta. Um programa reativo conta incidentes fechados; um proativo conta o que não aconteceu: cargas bloqueadas antes de publicar, mudanças incompatíveis barradas no CI, acessos removidos no mesmo dia em que alguém mudou de função, datasets novos que já nasceram com dono e classificação. São indicadores antecedentes, são chatos e são a única evidência de que a prevenção está funcionando.

Onde dá errado. A prevenção degenera em pedágio. Cada dataset novo precisa de três aprovações e duas semanas de espera, então as pessoas fazem o que sempre fazem quando a porta da frente é lenta: constroem a coisa numa planilha, numa conta de nuvem pessoal ou num warehouse paralelo, e a função de governança perde de vista exatamente os dados que queria proteger. Se um controle não pode ser automatizado, ele precisa de um acordo de nível de serviço; e se não tem nenhum dos dois, é uma fila, não um controle.

Dá para reconhecer pela agenda. O trabalho chega como incidente: o regulador pergunta, o financeiro encontra dois números de receita, um cliente recebe o extrato de outro, um modelo aparece treinado com dados que jamais deveria ter visto. O time responde bem — às vezes heroicamente — e depois volta ao que estava fazendo até o próximo. Governança reativa não é defeito de caráter: é a cara da governança antes de alguém financiar prevenção, e quase todo programa começa aqui.

Na prática. A saída é usar os incidentes, não apenas sobreviver a eles. Registre cada um com o que custou, quais dados estavam envolvidos e qual controle o teria pegado. Doze registros formam um padrão, e um padrão constrói o business case que nenhum slide de maturidade constrói: os mesmos três domínios, o mesmo dono ausente, a mesma regra de qualidade que não existe. É também o momento de converter um incidente em controle permanente em vez de em mais uma limpeza.

Onde dá errado. Ficar aqui. Um time conhecido por consertar coisas se torna a brigada de limpeza — valorizada, ocupada, nunca financiada para prevenir — e a reputação endurece: governança é quem você chama depois do estrago. O sinal de que isso está acontecendo é simples: ninguém consegue citar uma decisão que a função de governança tomou antes de um incidente forçá-la.

Maturidade é uma afirmação sobre repetibilidade, não sobre ferramentas. Uma organização onde o relatório mensal sai certo porque um analista específico sabe quais três colunas ignorar é imatura por mais orçamento de tecnologia que tenha. Uma onde o mesmo relatório é produzido corretamente por quem estiver de plantão, com as exceções documentadas, é madura. A distinção é se o conhecimento vive nas pessoas ou no processo.

Na prática. Vale a pena avaliar a maturidade por capacidade, não como um número único. Você pode ser genuinamente forte em metadados e fraco em qualidade, e a média das duas não diz nada acionável. Avalie as capacidades, escolha as duas que bloqueiam o resultado de negócio mais próximo e deixe o resto.

Onde dá errado. A maturidade se torna o objetivo. Ninguém jamais recebeu orçamento por passar de 2,1 para 2,6; recebe orçamento por fechar um achado regulatório ou desbloquear um lançamento, e a maturidade melhora como subproduto. Apresente a avaliação como diagnóstico, nunca como objetivo.

O TDWI, organização de pesquisa e educação em dados e analytics, descreve a maturidade analítica em cinco estágios que quase toda organização reconhece em si mesma na primeira leitura. Nascente: o uso de dados é pontual e individual e o reporting é manual. Emergente: a liderança começa a pedir evidência e as definições são inconsistentes, e todo mundo sabe. Em desenvolvimento: o treinamento se formaliza e os dados são consultados rotineiramente nas decisões operacionais. Madura: a fluência vai bem além dos times técnicos e definições padronizadas são o normal. Líder: espera-se evidência e a capacidade analítica é insumo competitivo, não função de suporte. Ele olha para analytics como um todo — organização, infraestrutura, gestão de dados, análise e governança — e não só para a governança de dados.

Na prática. Use-o na conversa sobre como as decisões são tomadas, onde um modelo só de governança ficaria curto; ele combina naturalmente com o trabalho de alfabetização e cultura. As descrições dos estágios são curtas o bastante para ler em voz alta numa reunião de diretoria, e as pessoas se posicionam rápido, em geral com mais generosidade do que a evidência permite.

Onde dá errado. O rótulo do estágio vira o objetivo. "Passar de Em desenvolvimento para Madura" não é resultado de negócio e não sobrevive a uma revisão de orçamento. "Reduzir de quatro para uma as definições de receita em uso" é o mesmo progresso em uma forma que alguém vai financiar. O estágio é um diagnóstico, não um destino.

A maioria dos modelos compartilha um formato de cinco níveis: nada deliberado acontece, algumas pessoas fazem bem, está documentado e é repetível, é medido, é melhorado de propósito. O valor não está na nota, mas no vocabulário: um modelo dá ao time executivo uma forma compartilhada de dizer "estamos no nível 1 em qualidade e no nível 3 em controle de acesso", o que é uma conversa muito mais produtiva do que trocar anedotas.

Na prática. Use o modelo como guia de entrevista, não como questionário. A evidência que determina um nível é o que alguém mostra a você: o glossário real, os três últimos registros de incidentes, a trilha de aprovação de uma mudança de definição. A autoavaliação infla o resultado em cerca de um nível em qualquer organização.

Onde dá errado. O resultado é um diagrama de radar, e o diagrama de radar é o entregável. Uma avaliação de maturidade que não termina com três ações nomeadas, um responsável para cada e uma data produziu um diagnóstico sobre o qual ninguém pode agir. O gráfico é o começo da conversa, não a conclusão dela.

Um modelo operacional tem quatro partes: os domínios e seus donos, os papéis e quanto tempo cada um carrega, os fóruns e o que cada um decide, e as rotas: como uma definição é alterada, como um incidente é escalado, como uma exceção é aprovada. Ele também declara um formato: centralizado, federado ou um núcleo com times de domínio. Federado é a resposta mais comum e a menos especificada, e é por isso que tantas vezes significa ninguém.

Na prática. Ajuste o modelo à organização que você realmente tem. Uma empresa que decide tudo por meio dos responsáveis funcionais não vai sustentar um modelo por domínios, por mais correto que o mapa de domínios seja. Governança que briga com a estrutura de decisão existente perde.

Onde dá errado. O modelo é desenhado para o estado final e lançado de uma vez: todos os domínios, todos os papéis, todos os fóruns, na mesma data. A capacidade não existe, os fóruns não se enchem e dezoito meses depois o modelo é um documento que descreve algo que nunca aconteceu. Dois domínios bem feitos valem mais que doze anunciados.

Todo modelo de maturidade empresta a mesma escada do CMMI, mesmo quando chama os degraus de outra coisa. O nível 1 é ad hoc: funciona porque uma pessoa específica continua na empresa. O nível 2 é repetível: a mesma coisa acontece duas vezes pelo mesmo motivo, normalmente dentro de um único time. O nível 3 é definido: está escrito, tem dono e é igual em todos os domínios. O nível 4 é gerenciado: é medido, e a medição é usada para decidir. O nível 5 é otimizado: melhora de propósito e com cadência, sem um programa empurrando. Repare que nenhuma dessas frases menciona uma ferramenta.

Na prática. Pontue cada capacidade separadamente — metadados, qualidade, privacidade, alfabetização, arquitetura — e espere um perfil desigual. Nível 3 em classificação e nível 1 em qualidade não é contradição: é o seu roadmap, e diz o que os próximos doze meses deveriam comprar. A conversa útil nunca é "em que nível estamos", e sim "o que precisaria ser verdade para esta capacidade ser um 3, e vale a pena fazer isso neste ano".

Onde dá errado. O nível deixa de ser descrição e vira meta. Alguém se compromete com "nível 4 até dezembro", o diagnóstico silenciosamente se transforma numa prova autocorrigida e o programa passa a otimizar a nota em vez do negócio. Nível 5 em tudo também é a ambição errada: a maioria das organizações deveria ficar deliberadamente no nível 2 onde quase nada está em jogo.

Um esquema de classificação é um conjunto pequeno de rótulos — público, interno, confidencial e restrito são os quatro habituais — cada um ligado a regras concretas de manuseio: quem pode acessar, se pode sair do país, se pode ser usado para treinar um modelo, por quanto tempo é retido, como deve ser destruído. O rótulo só vale pelas regras que estão por trás; um rótulo sem consequência é decoração.

Na prática. Quatro níveis é o máximo prático. Cada nível além disso produz discussões sobre casos-limite e rotulagem inconsistente, e a diferença entre "confidencial" e "altamente confidencial" quase nunca é operacionalizada de forma distinta.

Onde dá errado. A classificação é aplicada pedindo aos donos dos dados que rotulem tudo, o que resulta em todo o parque marcado como confidencial: a resposta segura para quem rotula e inútil para todos os outros. Ancore o esquema em exemplos, use "interno" como padrão e exija justificativa para o nível mais alto.

RBAC é uma ideia de governança antes de ser técnica. As permissões ficam presas a um papel — analista de sinistros, analista de crédito, analista de marketing —, o dono dos dados aprova o que aquele papel pode ver, e a pessoa recebe o acesso ao entrar nele. O ganho não são menos cliques: é que a pergunta deixa de ser "por que a Marta tem isso?" e passa a ser "um analista de crédito deveria ver isso?", que é uma pergunta que alguém consegue responder de verdade — e responder uma única vez para todo mundo.

Na prática. Os papéis são nomeados pelo cargo, nunca pela pessoa nem pelo projeto. O dono dos dados aprova o escopo, e o acesso é amarrado ao ciclo de vida de RH: quem entra herda o papel, quem muda de área perde o anterior no mesmo dia, e quem sai é cortado automaticamente. Colunas sensíveis continuam atrás de uma política de mascaramento mesmo dentro de um papel aprovado, e cada papel é recertificado com periodicidade fixa pelo dono que o concedeu — recertificação é a parte pela qual todo mundo compra a ferramenta e que ninguém executa.

Onde dá errado. Explosão de papéis. Cada exceção cria um papel novo e, dois anos depois, há mais papéis que funcionários e ninguém sabe o que nenhum deles significa, o que na prática é o mesmo que não ter modelo. A segunda falha são as movimentações internas: admissões e desligamentos são tratados, mas quem mudou de cargo três vezes acumula a soma de tudo o que já precisou. Quando os papéis não bastam para expressar a regra, a resposta costuma ser somar atributos — região, propósito, classificação — em cima, e não outros cem papéis.

Confidencial é o nível em que quem corre risco é a empresa. Se vaza, um concorrente precifica contra você, uma negociação desanda, um valuation se move ou o seu próprio pessoal descobre quanto os colegas ganham. É um dano real e merece controles reais — mas é um dano comercial, e por isso corre por uma trilha diferente da dos dados pessoais sensíveis, onde o exposto é uma pessoa.

Na prática. A etiqueta sozinha não vale nada; o que a torna útil são as regras de manuseio grampeadas nela. Quem aprova o acesso e por quanto tempo. Onde o dado pode viver: qual plataforma, qual região, qual tenant. Se pode sair da empresa e sob qual acordo. Quanto tempo é retido e o que acontece no fim. E se pode ser colado numa ferramenta de IA externa, que hoje é a pergunta que esta classificação recebe com mais frequência. Um nível sem regras associadas é decoração.

Onde dá errado. Tudo acaba confidencial. Um critério de "restringe, por segurança" produz um warehouse em que 90% das tabelas carregam a etiqueta mais alta, então as pessoas desviam dos controles para conseguir trabalhar e a etiqueta deixa de informar qualquer coisa. Uma classificação que funciona é deliberadamente desigual: a maior parte do dado é interna, uma fatia é confidencial, um conjunto pequeno é restrito, e alguém sênior está disposto a defender onde as linhas foram traçadas.

A distinção que importa é quem se machuca. Dado sensível é a categoria em que o dano recai sobre um ser humano: um diagnóstico, um template biométrico, filiação política ou religiosa, filiação sindical, orientação sexual, origem racial ou étnica, um antecedente criminal, um endereço que alguém mantém em sigilo. A LGPD os chama de dados pessoais sensíveis, o GDPR de categorias especiais, e ambos os tratam como classe separada, com base legal mais estrita — porque a consequência de um vazamento não é vergonha nem multa: é discriminação, exclusão ou risco físico para alguém que nunca escolheu estar na sua base.

Na prática. É uma etiqueta em nível de coluna, aplicada na criação do dado e herdada por tudo o que vem depois, com mascaramento ligado por padrão e acesso concedido para uma finalidade declarada, não para um cargo. A retenção é mais curta, compartilhar com terceiros exige base legal com nome, e modelos treinados com esses dados herdam todas essas restrições. O primeiro passo honesto normalmente é menor que uma política: descobrir quais tabelas realmente os contêm, porque o inventário quase sempre está errado.

Onde dá errado. Confundem-se com dados confidenciais e os dois são governados como se fossem a mesma coisa. Salários e preços são confidenciais: a exposta é a empresa. Um prontuário é sensível: o exposto é o indivíduo. Misturar leva a proteger dado comercial como se houvesse vidas em jogo, ou a proteger a saúde das pessoas com o cuidado que se dá a uma tabela de preços. Segunda falha: a etiqueta vive na coluna de origem e a cópia na planilha de alguém não herda nada.

A governança de IA pergunta com o que um modelo foi treinado, se esses dados eram permitidos para aquele propósito, quem aprovou a implantação, o que é monitorado no modelo e quem pode desligá-lo. Quatro dessas cinco perguntas são respondidas por linhagem, classificação, registros de consentimento e propriedade dos dados. É por isso que uma organização sem governança de dados não pode ter governança de IA: não há nada por baixo a que apelar.

Na prática. O caminho mais rápido para uma governança de IA defensável é estender o que já existe. Adicione "aprovado para treinamento de modelos" ao esquema de classificação, exija linhagem para os conjuntos de treinamento, leve a aprovação de modelos à pauta do conselho existente e registre a decisão. São semanas de trabalho, não um programa novo.

Onde dá errado. A governança de IA é construída como estrutura paralela com comitê, conjunto de políticas e vocabulário próprios. Em um ano ela tem outro dono e outra resposta para o mesmo conjunto de dados, e a primeira pergunta regulatória expõe a lacuna. Um único conjunto de direitos de decisão sobre os dados, estendido aos modelos, é o arranjo que se sustenta.

PII é mais amplo do que a maioria dos inventários supõe, porque identificabilidade é contextual. Um CEP não identifica; um CEP mais uma data de nascimento mais um cargo frequentemente identifica. Sob a LGPD e o GDPR o conceito relevante é dado pessoal, que cobre qualquer coisa relativa a uma pessoa identificável, incluindo dados que só a identificam quando cruzados com algo mais que você já tem. É por isso que "removemos os nomes" não é, por si só, anonimização.

Na prática. Encontre os dados pessoais rastreando a finalidade, não varrendo colunas. Pergunte quais processos envolvem uma pessoa, o que foi coletado, o que foi dito a ela na ocasião e em que base a organização está se apoiando. Varreduras de padrões encontram endereços de e-mail; não encontram o cruzamento que torna um conjunto de dados reidentificável.

Onde dá errado. Dados pseudonimizados são tratados como anônimos e movidos para fora dos seus controles originais: para um ambiente de analytics, um sistema de teste, um conjunto de treinamento. Dados pseudonimizados continuam sendo dados pessoais, porque a chave que os reverte existe. Anônimo significa irreversivelmente anônimo, e muito pouco dado de um parque operacional atende a esse limite.

Duas pessoas rodam a mesma consulta na mesma tabela e recebem respostas diferentes, de propósito. O atendente vê um cartão terminado em 4471 e o resto em asteriscos; o analista de fraude vê o número inteiro; o cientista de dados vê um hash consistente, que ainda permite o cruzamento mas não identifica ninguém. Nada foi copiado e nada foi destruído: a política é avaliada enquanto a consulta roda. É aí que ele se separa do mascaramento estático, que produz uma cópia à parte, permanentemente embaralhada, para os ambientes inferiores.

Na prática. A regra é presa à classificação, não ao time: uma coluna marcada como pessoal ou sensível herda uma política de mascaramento, e os papéis recebem o direito de ver através dela. Snowflake, BigQuery, Databricks e SQL Server suportam isso nativamente, o que significa escrever a política uma vez em vez de manter uma view feita à mão por público — e views feitas à mão são o motivo pelo qual uma coluna sem máscara acaba num painel que ninguém lembra de ter criado.

Onde dá errado. O mascaramento é tratado como se fosse o controle inteiro. Um identificador mascarado ao lado de data de nascimento, CEP e valor de transação sem máscara reidentifica pessoas com facilidade, então mascarar sem pensar no que as colunas restantes revelam é teatro. O clássico complementar: produção está bem mascarada e o ambiente de teste guarda uma cópia sem máscara de dois anos atrás que metade da empresa consegue ler.

Privacidade é sobre a pessoa que está nos dados, não sobre a organização que os guarda. Segurança pergunta se os dados estão protegidos de quem não deveria vê-los. Privacidade pergunta se quem pode vê-los deveria usá-los para isso. Leis como a LGPD, o GDPR e a CCPA transformam essa pergunta em obrigações: base legal, finalidade declarada, minimização, limites de retenção e direitos que o titular pode exercer.

Na prática. Privacidade se conecta com classificação e acesso. Campos pessoais são etiquetados na criação, mascarados por padrão e liberados para uma finalidade declarada, não para um cargo. A marcação de finalidade faz a maior parte do trabalho: um dataset coletado para faturamento não fica automaticamente disponível para um modelo de churn, e uma base de treinamento herda os limites de consentimento e finalidade de cada fonte que a alimentou.

Onde dá errado. A privacidade é tratada como documento jurídico em vez de conjunto de controles. A política diz que os dados só são usados para finalidades declaradas; nada no catálogo registra quais eram essas finalidades. Aí um modelo vai para produção e ninguém consegue dizer se os clientes que estão nele consentiram com esse uso. A política nunca esteve errada. Só não tinha nada embaixo dela.

Dados são criados, usados, ficam obsoletos e em algum momento deveriam ser arquivados ou excluídos. Retenção é a decisão sobre quando. Uma regra de retenção utilizável tem três partes: a classe de dados que ela cobre, um prazo e um gatilho — o evento que inicia a contagem, como o fim de um contrato ou o encerramento de uma conta. Prazo sem gatilho é um número que ninguém consegue aplicar.

Na prática. Definir a regra é governança: o dono, junto com o jurídico e a área de privacidade, decide por quanto tempo os registros de clientes são guardados e o que conta como fim do relacionamento. Implementar é gestão: a rotina de retenção que arquiva os registros conforme o prazo legal e os exclui na hora certa, mais a evidência de que ela rodou. A retenção também segue o dado. Cópias, extrações e bases de treinamento herdam a regra da origem, ou a regra vale muito pouco.

Onde dá errado. A retenção é a decisão de governança que a maioria dos programas adia indefinidamente, porque guardar tudo parece seguro e excluir qualquer coisa parece arriscado. É assim que uma organização acaba mantendo dados pessoais por uma década sem base defensável, e descobre isso em uma auditoria ou em um vazamento, não em uma revisão.

Arquitetura de dados é a planta do parque de dados: os modelos, os padrões de integração, as plataformas e os caminhos que os dados percorrem entre elas. No DMBOK ela é uma das áreas de conhecimento ao redor do centro da governança, e a divisão de trabalho é limpa. A governança fornece os limites dos domínios, a fonte autoritativa de cada entidade e os padrões. A arquitetura transforma essas decisões em modelos e desenho de plataforma. É trabalho de gestão de dados, não de governança, mas é onde as decisões de governança viram coisa física.

Na prática. As perguntas de arquitetura que mais importam para a governança raramente são sobre tecnologia. Qual sistema é a fonte autoritativa de cliente? Onde termina um domínio? Que padrão um pipeline novo precisa cumprir antes de ir para produção? Se essas respostas existem e estão escritas, os arquitetos escolhem bem e rápido. Se não, eles mesmos tomam as decisões de governança, de forma implícita, uma integração por vez.

Onde dá errado. Anos de escolhas locais razoáveis produzem um parque fragmentado: mainframes legados, um lakehouse na nuvem e uma dúzia de ferramentas SaaS, cada uma com sua própria definição sobreposta da mesma entidade. Ninguém projetou a bagunça. Cada peça fazia sentido quando foi adicionada, e nenhuma decisão jamais cobriu como elas se encaixam. Uma migração de plataforma não resolve, porque as definições migram junto com os dados.

A maioria dos incidentes de dados não é corrupção: é surpresa. Um engenheiro renomeia uma coluna, restringe um tipo, muda o que "cancelado" significa ou troca uma carga noturna por horária — todas mudanças razoáveis — e onze painéis e dois modelos lá embaixo quebram ou, pior, continuam funcionando e passam a reportar silenciosamente outra coisa. Um contrato de dados torna a promessa explícita, para que a mudança seja uma negociação e não uma queda: este é o schema, isto significa cada campo, este é o frescor, estes são os limites de qualidade, este é o dono e este é o aviso que você recebe antes de qualquer um deles mudar.

Na prática. O contrato vive junto ao código do produtor, em controle de versão, e é testado. Uma mudança incompatível quebra o pipeline do produtor antes de subir, que é exatamente o objetivo: o custo da mudança recai sobre o time que a faz, e não sobre quem descobrir primeiro. Quem consome se registra no contrato, então o produtor vê quem quebraria, e descontinuar passa a ser uma data com caminho de migração em vez de um comunicado. Num anúncio de marketplace, o contrato é o que transforma uma tabela em algo sobre o qual outro time pode construir.

Onde dá errado. O contrato é uma página no wiki. Nada verifica, ele se desvia em um mês e acaba documentando como o dado se comportava antes. A outra falha é prometer demais: frescor ou completude que o produtor não tem como garantir, então o contrato é descumprido toda semana e todo mundo para de ler os alertas.

Um data lake aceita quase tudo: exportações de aplicações, logs, dados de IoT, extrações de ferramentas SaaS, arquivos que ninguém lembra de ter pedido. Diferente de um data warehouse, ele não exige um schema antecipado, o que o torna barato de encher e flexível de usar. Um lakehouse acrescenta tabelas e controles no estilo warehouse sobre o mesmo armazenamento. Nos dois casos, o lake resolve um problema de armazenamento. Sozinho, ele não resolve nenhum problema de significado, propriedade ou confiança.

Na prática. Um lake governado é sem graça. Cada zona ou dataset tem um dono com nome, uma classificação e uma entrada no catálogo. Os dados brutos recém-chegados ficam separados dos dados curados sobre os quais se pode reportar, e a diferença fica visível para quem está navegando. Colunas sensíveis são mascaradas por padrão, não depois da primeira reclamação.

Onde dá errado. A ingestão roda sem gestão e tudo entra, porque é fácil. Em alguns anos o lake guarda registros duplicados, três versões da tabela de clientes e uma conta de armazenamento que ninguém sabe explicar, e os analistas voltam discretamente para as suas planilhas. Esse é o pântano de dados, e ele é um resultado de governança, não de tecnologia: ninguém decidiu o que deveria estar ali nem quem respondia por isso.

Um domínio é a forma de dividir a governança em pedaços pequenos o suficiente para terem dono. Cliente, produto, fornecedor, funcionário, finanças, contrato: cada um é um corpo de dados com suas próprias definições, seus próprios sistemas de registro, sua própria exposição regulatória e seu próprio dono natural em algum lugar do negócio. Domínios são a unidade sobre a qual quase todo modelo operacional é construído, porque "quem é dono dos dados" é uma pergunta sem resposta e "quem é dono dos dados de cliente" não é.

Na prática. Bons domínios seguem o negócio, não o organograma nem o banco de dados. São poucos — de oito a quinze em escala corporativa — e cada um tem exatamente um dono responsável, um sistema de registro e uma lista de elementos de dados críticos. O teste de uma fronteira é se um campo em disputa tem um lar óbvio.

Onde dá errado. Os domínios são desenhados em volta dos sistemas, então "dados do Salesforce" se torna um domínio e o registro de cliente que também vive em faturamento e em suporte tem três donos e nenhum dono. Também são desenhados pequenos demais: quarenta domínios significam quarenta donos, o que significa que ninguém responde de verdade e que o conselho não cabe em uma sala.

Bem entendido, isso não é um sistema contendo todos os dados. É uma decisão por atributo: o sistema de RH é autoritativo para a situação de emprego, o CRM para as preferências de contato, o ERP para o valor faturado. Qualquer outro lugar pode ter uma cópia, mas nenhum outro lugar pode divergir e ganhar. Escrito atributo por atributo, esse é um dos artefatos mais valiosos que um programa de governança produz.

Na prática. Declare a fonte autoritativa dos vinte atributos que aparecem nos relatórios em disputa e exija que os sistemas adiante se reconciliem com essas fontes. É uma decisão de governança com consequência técnica, nessa ordem.

Onde dá errado. A expressão se torna a justificativa para consolidar tudo em uma única plataforma, o que é um programa de vários anos com um histórico ruim. Você não precisa de um sistema; precisa de uma resposta por atributo. São orçamentos muito diferentes, e só o segundo realmente resolve a discussão da reunião.

Duas direções, o mesmo conjunto de perguntas de governança. Para dentro, você compra: dados demográficos, firmográficos, score de crédito, geoespaciais, meteorologia, séries de mercado, seja via broker, seja via exchange como Snowflake Marketplace ou AWS Data Exchange. Para fora, você publica: compartilha com parceiros ou vende um agregado que só a sua empresa consegue produzir. Nos dois casos o dado cruza a fronteira onde os seus controles terminam e um contrato começa.

Na prática. O dado que entra recebe o mesmo tratamento do interno mais uma licença: um dono interno com nome, procedência documentada, checagens de qualidade na chegada e condições explícitas sobre o que se pode fazer com ele — se pode treinar um modelo, se pode ser redistribuído a um cliente, o que acontece com os dados derivados quando a assinatura termina. O que sai não sai sem o DPO e o jurídico registrados: qual base legal cobre o compartilhamento, qual agregação ou anonimização é aplicada e quem responde se um parceiro usar além do acordado.

Onde dá errado. Um arquivo comprado no cartão de crédito é cruzado em produção e, dezoito meses depois, ninguém sabe a origem, a licença nem se o contrato ainda existe — mas três relatórios regulatórios dependem dele. No sentido oposto, o acordo é fechado no comercial e a revisão de privacidade acontece depois da primeira entrega, que é a ordem mais cara possível.

Um catálogo diz que o dado existe. Um marketplace entrega o dado. A diferença é o caixa: um anúncio que você pode solicitar, uma aprovação que chega a quem é responsável e um acesso que aparece em horas, não depois de um trimestre de e-mails. Isso importa porque a alternativa não é "as pessoas esperam": é que o analista que não consegue o dataset certificado num prazo razoável reconstrói ele mal a partir de um extrato de origem — e agora a empresa tem duas versões de receita.

Na prática. Cada anúncio é um produto de dados, não uma tabela: tem dono, descrição em linguagem de negócio, contrato cobrindo schema e frescor, uma nota de qualidade visível, números de uso e de custo, e um fluxo de solicitação que termina num papel concedido, não num ticket. Quem consome vê quem mais usa e o que mudou no mês passado. A medida de que funciona é o tempo mediano entre pedido e acesso — e se esse número está na meta de alguém.

Onde dá errado. O marketplace nasce com o warehouse inteiro despejado dentro — dez mil tabelas, sem donos, sem contratos — e vira uma busca mais lenta. Ou a vitrine é real, mas o pedido cai numa fila sem nível de serviço, o que ensina a todos que o atalho é mais rápido. Um marketplace com cinquenta produtos de verdade governados vale mais que um com tudo e ninguém atrás.

Um pipeline é o encanamento entre um sistema de origem e um relatório, um modelo ou outro sistema: ingerir, validar, transformar, carregar e repetir conforme um agendamento. Construir e operar pipelines é trabalho de gestão de dados. A governança não os escreve, mas decide o que eles precisam respeitar: qual fonte é a autoritativa, quais campos estão classificados, qual tolerância de qualidade vale e quem precisa ser avisado quando algo muda na origem.

Na prática. A falha perigosa raramente é a queda. Um pipeline que para dispara um alerta e alguém resolve antes do almoço. O que continua rodando com um nulo no lugar errado ou um código de moeda trocado transforma, em silêncio, um registro ruim em um agregado ruim e depois em uma decisão ruim. As verificações ficam em cada etapa crítica, não só no final, e uma verificação que falha sobre dados críticos deve interromper a execução ou mandar os registros para quarentena, não deixá-los passar com um aviso.

Onde dá errado. Cada time constrói seu próprio pipeline a partir da mesma fonte, cada um com uma lógica um pouco diferente, e ninguém é dono das diferenças. Aí um schema muda na origem sem aviso, metade dos pipelines quebra em silêncio e quem encontra a divergência é um auditor. Consertar o pipeline é gestão. Decidir quem precisa ser avisado antes de o schema mudar é governança.

Tratar dados como produto significa que alguém responde pela satisfação dos consumidores, e não apenas pelo funcionamento do pipeline. Isso implica documentação, uma interface estável, uma frequência de atualização declarada, garantias de qualidade, um caminho para reportar problemas e um plano para alterá-lo sem quebrar quem está adiante. É a mesma disciplina que um time de software aplica a uma API, aplicada a uma tabela.

Na prática. Um produto de dados só é produto se tiver consumidores com nome. Dois times que dependem dele, com uma atualização acordada e um caminho para reclamar, é suficiente. Sem consumidores você tem um conjunto de dados com papelada extra.

Onde dá errado. Todas as tabelas existentes são reetiquetadas como produtos de dados sem nenhuma mudança em propriedade, documentação ou compromisso. Renomear não cria responsabilidade. O teste é simples e implacável: se a carga falhar em um domingo, existe alguém que não seja o time de plataforma que saiba, se importe e tenha obrigação declarada de responder?

Um silo nasce quando, em algum momento, obter a informação compartilhada de forma central era mais difícil do que reconstruí-la localmente. Vendas tem sua lista de clientes, financeiro tem outra, logística uma terceira. Ninguém decidiu criar um silo; cada um foi um atalho razoável. O custo visível é o esforço duplicado. O custo caro é que as cópias divergem, três dashboards dão três respostas para a mesma pergunta e ninguém consegue dizer qual está certa.

Na prática. A resposta da governança não é "consolidar tudo" — isso é um programa de plataforma de vários anos, não um ato de governança. É nomear a fonte autoritativa de cada entidade compartilhada, declarar as outras cópias como derivadas e publicar essa decisão em um lugar onde as pessoas realmente a encontrem. Um catálogo de dados ajuda. A decisão importa mais do que a ferramenta.

Onde dá errado. Os silos são tratados como problema de tecnologia e respondidos com uma migração. Os dados vão para uma plataforma só, as definições vão junto sem mudar nada e a organização passa a ter os mesmos silos em um único lugar, mais caro. Silo se resolve com uma decisão sobre autoridade, não com uma mudança de endereço.

Um domínio é onde mora a responsabilidade; um subdomínio é onde o trabalho realmente cabe na cabeça de alguém. Cliente é um domínio, e é grande demais para um único glossário: prospects, consentimento e preferências, reclamações, situação de crédito e fidelidade têm definições diferentes de "ativo", regras diferentes, sistemas diferentes e pessoas diferentes que se importam. Quebrar Cliente em subdomínios permite governar bem cada uma dessas peças sem inventar cinco domínios novos e cinco donos novos no organograma.

Na prática. Você sabe que precisa de um quando um único steward não consegue responder perguntas de todo o domínio, ou quando a mesma palavra precisa de duas definições dentro dele. Um subdomínio tem steward com nome, suas próprias entradas no glossário de negócio, seus próprios elementos críticos e regras de qualidade, e costuma ser a unidade a partir da qual os produtos de dados são de fato construídos e publicados. O dono do domínio continua respondendo pelo conjunto; o steward do subdomínio opera uma parte.

Onde dá errado. Subdividir até o catálogo virar uma cópia da estrutura de reporte. Cinquenta subdomínios são cinquenta glossários meio mantidos, e a reorganização do ano que vem invalida todos. Divida quando uma definição ou um dono te obrigarem, não para o diagrama parecer completo.