Nos últimos anos, as organizações investiram fortemente na coleta de informações. Implementaram CRM, ERP, plataformas de comércio eletrônico, ferramentas de análise, sistemas de atendimento ao cliente e aplicativos internos. Cada nova solução prometia maior visibilidade das operações, mas também criava uma fonte de dados adicional, novas definições e mais integrações que precisavam ser mantidas.
O resultado é uma frequente contradição. A empresa possui milhões de registros, mas os departamentos continuam a discutir sobre qual número está correto. O marketing apresenta um número de clientes, as vendas outro, e o financeiro utiliza uma terceira definição. A mesma métrica muda dependendo do sistema consultado, do momento da coleta de dados ou da pessoa que preparou o relatório.
Essa fragmentação era problemática quando os dados eram usados principalmente em relatórios. Com o advento da inteligência artificial e dos agentes empresariais, o risco aumenta. Um sistema automatizado não pode interromper uma reunião para perguntar qual definição usar. Ele processa as informações disponíveis e gera uma resposta, recomendação ou ação.
Portanto, o desafio não é mais simplesmente armazenar dados. Trata-se de transformá-los em ativos confiáveis que possam ser descobertos, compreendidos e usados de forma consistente. Esse é o propósito de... produtos de dados.
Um produto de dados é um conjunto de informações projetado para atender a uma necessidade específica do usuário. Pode assumir a forma de uma tabela, uma API, um modelo analítico, um fluxo de eventos, um painel de controle ou uma combinação de vários componentes. A diferença em relação a um conjunto de dados tradicional é que ele é gerenciado como um produto com responsabilidades, usuários, documentação, critérios de qualidade e um ciclo de vida definidos.
O Google Cloud descreve a abordagem de malha de dados como uma estrutura arquitetônica e organizacional que trata os dados como produtos desenvolvidos pelas equipes que melhor compreendem cada domínio de negócios. Essas equipes devem aderir a padrões de governança comuns para que as informações possam ser descobertas e consumidas de forma consistente em toda a organização.
Vamos considerar um produto chamado "360 Customer". Não deve ser apenas uma tabela com nomes, e-mails e compras. Precisa definir o que constitui um cliente ativo, quais sistemas fornecem informações, com que frequência é atualizada, qual o nível de qualidade oferecido e quem é o responsável quando ocorre um erro.
O produto faz mais do que apenas fornecer registros. Ele oferece uma capacidade confiável para tomar decisões sobre os clientes.
Em muitos sistemas empresariais, os dados surgem como um subproduto das operações. Um CRM registra oportunidades porque precisa gerenciar as vendas. Um ERP armazena faturas porque precisa dar suporte aos processos financeiros. Uma plataforma de suporte retém conversas para gerenciar chamados. As informações existem, mas não foram necessariamente projetadas para serem reutilizadas por outros departamentos.
Quando uma equipe de análise precisa combinar essas fontes, inicia-se um processo de interpretação. É necessário descobrir o que cada campo representa, quais registros estão incompletos, quais regras o sistema utiliza e como uma entidade se relaciona com a outra. Uma parte significativa do esforço não se concentra na análise, mas sim na compreensão.
Esse modelo fomenta a dependência do conhecimento informal. Uma pessoa sabe que determinada coluna não deve ser usada após certo ano. Outra se lembra de que alguns registros estão duplicados. Uma terceira sabe a consulta correta para excluir testes internos. Quando essas pessoas trocam de função, a organização perde parte do significado por trás de seus próprios dados.
Uma abordagem focada no produto exige que esse conhecimento seja tornado visível. As informações devem ser documentadas, testadas e mantidas para que outros consumidores possam utilizá-las sem depender constantemente de conversas informais.
Quando os dados são tratados como lixo técnico, sua qualidade muitas vezes deixa de ser responsabilidade de alguém. A equipe de origem alega que apenas gerencia o aplicativo. A equipe de análise recebe informações incompletas e tenta corrigi-las. As unidades de negócios usam relatórios diferentes e os problemas só surgem no final do processo.
Um produto de dados precisa de uma definição clara de responsabilidades. A equipe responsável deve compreender o domínio de negócios, quem utiliza as informações e manter um nível de serviço adequado. Isso não significa que uma única pessoa deva resolver todos os problemas técnicos e funcionais. Significa que deve haver uma clara responsabilidade pela confiabilidade do produto.
O modelo de malha de dados propõe precisamente uma estrutura de propriedade orientada ao domínio. A área de Vendas pode ser responsável por produtos relacionados a oportunidades e clientes potenciais. A área Financeira pode gerenciar informações sobre faturamento, receita e pagamentos. A área de Recursos Humanos pode gerenciar produtos relacionados a talentos e estrutura organizacional.
A descentralização não elimina a governança. Ela transforma sua forma. As equipes passam a ser responsáveis por seus dados, mas operam sob padrões comuns que permitem interoperabilidade, segurança e controle.
Uma das diferenças mais importantes entre armazenar dados e construir um produto é entender para quem ele se destina. Um produto sem usuários definidos corre o risco de se tornar apenas mais uma coleção de informações que ninguém sabe como usar.
Os consumidores podem ser analistas, aplicativos, executivos, modelos preditivos ou agentes de IA. Cada um requer recursos diferentes. Um analista pode precisar de detalhes históricos e flexibilidade. Um sistema transacional precisa de respostas rápidas e contratos estáveis. Um agente de IA precisa de contexto compreensível, permissões claras e dados suficientemente confiáveis para embasar uma decisão.
Projetar a partir da perspectiva do consumidor exige que se façam perguntas específicas. Que problema ele está tentando resolver? De que nível de atualizações ele precisa? Qual o impacto de uma resposta incorreta? Quais campos são essenciais? Quais definições precisam ser explicadas?
O Google Cloud recomenda que as arquiteturas de malha de dados permitam diferentes padrões de consumo e que os usuários possam avaliar se um produto é adequado com base em sua finalidade, qualidade e condições de acesso.
O valor de um produto não está na quantidade de colunas que ele contém, mas sim na sua capacidade de facilitar uma decisão ou um processo específico.
Um produto de software não é considerado finalizado simplesmente porque funciona uma vez. Ele precisa de documentação, suporte, métricas, controle de versão e mecanismos para gerenciar mudanças. Produtos de dados exigem uma disciplina semelhante.
Eles precisam ser facilmente encontrados para que os usuários saibam que existem. Precisam de uma descrição clara, informações de propriedade visíveis e exemplos de uso. Também precisam ser interoperáveis, ou seja, usar padrões que permitam sua combinação com outros produtos sem modificações excessivas.
A confiabilidade é igualmente importante. Os consumidores precisam saber a frequência das atualizações, a integridade, a disponibilidade e quaisquer limitações. Se uma fonte parar de receber informações por dois dias, o produto deve comunicar isso antes que um relatório ou agente utilize dados incompletos.
Martin Fowler destaca que o desenvolvimento de produtos de dados envolve a automatização da governança e a garantia de que equipes independentes sigam práticas comuns que permitam a interoperabilidade em grande escala.
O produto de dados não deve ser avaliado apenas por sua existência técnica. Ele deve ser avaliado por sua utilidade, confiabilidade e experiência do usuário.
Um dos maiores problemas na arquitetura de dados ocorre quando um sistema muda sem notificar seus usuários. Uma equipe pode modificar o nome de uma coluna, alterar um tipo de dado ou remover um valor que parecia desnecessário. O aplicativo original continua funcionando, mas os relatórios, modelos e automações que dependiam dessa estrutura começam a apresentar mau funcionamento.
Um contrato de dados define formalmente o que um consumidor pode esperar. Ele pode incluir esquema, campos obrigatórios, tipos, frequência de atualização, regras de qualidade, proprietário e políticas de compatibilidade. Seu objetivo é evitar que as dependências permaneçam ocultas.
A Virgin Media O2 explicou como utilizou contratos de dados como uma camada de qualidade e garantia para assegurar que os conjuntos de dados publicados fossem confiáveis, documentados e prontos para uso.
O contrato não precisa ser um documento manuscrito que ninguém atualiza. Ele pode ser expresso em formatos legíveis por máquina e validado automaticamente dentro dos fluxos de trabalho. Se uma alteração violar uma condição acordada, o sistema pode interromper a publicação ou alertar as partes relevantes antes que isso afete os consumidores.
A confiança não depende mais apenas de conversas. Ela se torna uma propriedade verificável.
Toda organização precisa evoluir. Novos campos surgem, processos são modificados e definições de negócios mudam. O objetivo de um contrato de dados não é congelar permanentemente a estrutura, mas sim gerenciar a mudança de forma responsável.
Quando uma modificação é compatível, ela pode ser implementada sem afetar os consumidores. Quando ela viola o contrato existente, a questão deve ser resolvida por meio de uma nova versão, um período de transição ou um aviso prévio. Isso dá às equipes de suporte dos consumidores tempo para adaptar seus processos.
Essa abordagem reduz falhas silenciosas. Sem contratos, uma coluna pode continuar existindo, mas mudar seu significado. O fluxo de trabalho continua funcionando e o problema aparece no relatório errado. Com regras semânticas e de qualidade, a organização consegue detectar quando as informações deixam de atender às condições esperadas.
O controle de versões também melhora a rastreabilidade. Uma equipe pode saber qual modelo uma versão específica de um produto utilizou e reconstruir por que um resultado mudou.
Estabilidade não significa ausência de mudança. Significa que a mudança ocorre sem perturbar inesperadamente o ecossistema.
Muitas organizações descobrem problemas de qualidade quando um executivo questiona um número ou um cliente recebe informações incorretas. Nesse momento, inicia-se uma investigação que pode envolver múltiplos sistemas, consultas e equipes. A empresa corrige o incidente, mas nem sempre modifica o processo que permitiu que ele ocorresse.
Os produtos de dados exigem monitoramento contínuo. Isso pode incluir validações de integridade, unicidade, consistência, atualização e conformidade com as regras do domínio. Uma tabela de clientes não deve aceitar identificadores duplicados sem justificativa. Um produto de faturamento precisa detectar valores negativos inesperados. Um fluxo de estoque deve gerar um alerta quando parar de atualizar.
Martin Fowler propõe o uso de funções de aptidão ou funções de condicionamento físico Automatizar regras de governança e verificar continuamente se os produtos atendem aos padrões organizacionais.
A qualidade não é uma atividade final realizada por uma equipe separada. Ela deve ser integrada ao processo de desenvolvimento e implantação. O objetivo é evitar que dados defeituosos se tornem uma dependência confiável para outros sistemas.
Os modelos generativos podem produzir respostas convincentes mesmo quando as informações disponíveis são incompletas ou contraditórias. Isso torna a qualidade do contexto especialmente importante. Um agente conectado a fontes fragmentadas não adquire inteligência simplesmente por usar um modelo avançado. Ele adquire uma maneira mais rápida de combinar inconsistências.
A Microsoft destaca que os agentes sintetizam informações em vez de criarem os fatos comerciais de que precisam. Por esse motivo, sua precisão depende da qualidade, acessibilidade e governança das fontes subjacentes. Informações fragmentadas ou não controladas podem levar a respostas enganosas e riscos de segurança.
Um produto de dados fornece um contexto definido. Um agente de vendas pode consultar um produto de oportunidades ativas em vez de se conectar diretamente a várias tabelas não documentadas. Um assistente financeiro pode usar um produto de receita validado com regras e responsáveis conhecidos.
Isso reduz a ambiguidade e facilita a avaliação. A empresa pode analisar se o agente utilizou o produto correto, qual versão consultou e quais limitações a informação apresentava.
A IA não elimina a necessidade de arquitetura de dados. Ela a torna muito mais urgente.
Conectar um modelo a todos os bancos de dados da empresa pode parecer uma maneira rápida de construir um assistente poderoso. No entanto, essa abordagem cria problemas de segurança, semântica e manutenção. O agente encontra campos não documentados, dados sensíveis e estruturas projetadas para necessidades internas que não deveriam ser usadas diretamente.
A camada de produto permite controlar quais informações são disponibilizadas para consumo. Cada produto pode expor apenas os campos necessários, aplicar políticas de privacidade e oferecer definições adequadas tanto para humanos quanto para máquinas.
Essa separação também protege os sistemas operacionais. Em vez de executar consultas imprevisíveis em aplicativos críticos, os agentes consomem interfaces controladas, réplicas ou serviços projetados para análise e IA.
As arquiteturas modernas para agentes empresariais recomendam acesso seguro e controlado a fontes estruturadas e não estruturadas, especialmente quando os sistemas precisam operar em diferentes plataformas ou nuvens.
O objetivo não é limitar artificialmente a IA, mas sim oferecer a ela uma superfície de informação que possa ser usada com confiança.
Um dos projetos mais comuns envolve a criação de uma “fonte única de verdade”. A organização reúne informações de vários sistemas em uma plataforma central e espera resolver automaticamente as inconsistências. No entanto, consolidar dados não elimina as diferenças de significado.
A área de vendas pode considerar como cliente qualquer empresa com uma oportunidade em aberto. A área financeira pode reconhecer apenas as organizações que já receberam uma fatura. O suporte pode trabalhar com usuários finais mesmo que não haja um relacionamento contratual direto. Nenhuma dessas definições está necessariamente incorreta. Elas simplesmente refletem contextos diferentes.
Um produto de dados deve declarar qual definição utiliza e para quais decisões ela é apropriada. Em vez de fingir que existe uma visão única e universal, a arquitetura pode oferecer produtos relacionados, mas semanticamente claros.
Essa disciplina é especialmente importante para a IA. Uma pergunta como "Quantos clientes temos?" precisa de contexto. Sem uma definição explícita, o agente pode selecionar um número tecnicamente disponível e apresentá-lo com uma confiança que a empresa não deveria conceder.
A qualidade semântica importa tanto quanto a qualidade estrutural. Um campo de estudo pode ser completo e, ainda assim, totalmente inútil se ninguém souber o que ele significa.
O conceito de malha de dados ganhou popularidade, mas também foi simplificado em excesso. Algumas organizações o interpretam simplesmente como fornecer a cada departamento sua própria plataforma ou conjunto de tabelas. O resultado pode ser uma fragmentação ainda maior.
A malha de dados combina quatro princípios: propriedade orientada a domínio, dados como produto, infraestrutura de autosserviço e governança federada. A descentralização só funciona quando as equipes compartilham padrões, plataformas e mecanismos de interoperabilidade.
A governança federada permite que as decisões sejam tomadas mais próximas do domínio, sem sacrificar a consistência dos negócios. Uma equipe pode ter um melhor entendimento da lógica de vendas, mas ainda assim precisa seguir regras comuns em relação à segurança, identificação, documentação e acesso.
A infraestrutura de autosserviço reduz o custo de conformidade com essas regras. Se cada domínio tiver que construir seus próprios pipelines, catálogos e controles, a estratégia se tornará proibitivamente cara. Uma plataforma comum transforma as melhores práticas em funcionalidades reutilizáveis.
A malha de dados não é uma tecnologia específica. É um modelo organizacional e arquitetônico para escalar a responsabilidade sem perder o controle.
Um catálogo tradicional pode exibir nomes técnicos, localizações e diagramas. Isso ajuda a encontrar informações, mas não indica necessariamente se o produto deve ser usado. Dois produtos podem conter dados semelhantes, mas oferecer diferentes níveis de qualidade ou atualizações.
Um catálogo orientado a produtos precisa incluir finalidade, proprietário, consumidores, qualidade, linhagem, políticas de acesso e exemplos. Também deve indicar se o produto está ativo, em desenvolvimento ou próximo de ser descontinuado.
A capacidade de descoberta reduz a duplicação. Quando as equipes não sabem quais informações existem, elas criam novas extrações e versões paralelas dos mesmos dados. Cada cópia introduz custos adicionais, regras diferentes e novas oportunidades para inconsistências.
Para agentes de IA, o catálogo pode se tornar uma camada semântica que lhes permite selecionar fontes apropriadas. No entanto, essa capacidade requer metadados confiáveis e governados.
Uma organização não obtém valor catalogando milhares de tabelas que ninguém entende. Ela obtém valor quando um usuário ou sistema consegue encontrar rapidamente a fonte correta e entender as condições em que ela deve ser usada.
Quando cada produto precisa passar por extensos processos manuais, as equipes buscam atalhos. Elas criam conjuntos de dados temporários que acabam se tornando permanentes, compartilham arquivos fora das plataformas oficiais ou desenvolvem integrações que ninguém registra.
A governança deve ser integrada às ferramentas e aos fluxos de trabalho. Classificações sensíveis podem ser aplicadas automaticamente. Contratos podem ser validados durante a entrega. Políticas de acesso podem ser configuradas com base em domínios e responsabilidades.
O Google Cloud define governança de dados como uma abordagem que abrange todo o ciclo de vida, desde a aquisição e uso até o descarte seguro, e enfatiza que o valor da informação depende de ela ser confiável, localizável e governada.
A automação permite que a escolha certa seja também a mais simples. As equipes não deveriam precisar concluir dezenas de etapas para publicar um produto básico se a plataforma puder aplicar os padrões por padrão.
Uma governança eficaz não impede que as pessoas usem dados. Ela possibilita o uso de dados em larga escala sem sacrificar a segurança ou a confiança.
Mesmo um produto bem projetado pode apresentar degradação. Uma fonte pode parar de enviar registros, uma integração pode começar a duplicá-los ou uma atualização pode modificar uma distribuição crítica. O pipeline pode continuar funcionando tecnicamente, embora as informações não sejam mais válidas para a finalidade pretendida.
A observabilidade de dados analisa comportamento, volume, frescor, distribuição e linhagem. Ela permite a identificação de anomalias antes que elas afetem relatórios, modelos ou agentes.
Isso também facilita a avaliação do impacto. Se um produto apresentar um incidente, a linhagem do produto ajuda a identificar quais painéis, aplicativos e modelos dependem dele. Sem essa visibilidade, a organização descobre os consumidores afetados de forma gradual e reativa.
Para sistemas de IA, essa capacidade é fundamental. Um agente pode continuar respondendo mesmo que sua fonte de dados tenha parado de atualizar. A arquitetura precisa comunicar o status do produto e, quando o risco justificar, desativar temporariamente seu uso.
A confiança não deve ser binária. Os consumidores precisam saber o estado atual das informações e decidir se elas podem ser usadas para uma recomendação, automação ou uma decisão crítica.
As organizações costumam se concentrar na criação de novas fontes de dados, mas poucas eliminam aquelas que não deveriam mais ser usadas. Com o tempo, surgem produtos duplicados, versões abandonadas e conjuntos de dados cujos proprietários foram transferidos para outros departamentos.
Todo produto precisa de um ciclo de vida definido. Deve haver uma fase de projeto, lançamento, operação, evolução e descontinuação. Quando uma versão não for mais recomendada, os consumidores devem ter à disposição um caminho de migração.
Remover a plataforma impede que ela se torne um catálogo de opções conflitantes. Também reduz os custos de armazenamento, suporte e governança.
Antes de descontinuar um produto, a empresa precisa entender suas dependências. Este é mais um motivo pelo qual a linhagem e os contratos são importantes. Um conjunto de dados aparentemente inativo pode estar alimentando uma automação mensal ou um processo que ninguém se lembra.
A gestão de produtos exige decisões sobre continuidade. Manter tudo indefinidamente não é uma estratégia de dados, mas sim um acúmulo tecnológico.
O primeiro passo não deve ser reorganizar todas as equipes ou migrar imediatamente para uma nova plataforma. O ideal é identificar um domínio com problemas claros de confiança, duplicação ou acesso. Clientes, vendas, estoque ou faturamento costumam ser bons candidatos, pois geram valor transversal para todas as áreas.
Em seguida, deve-se selecionar um caso de uso específico. Em vez de criar um produto muito abrangente, a empresa pode projetar um que atenda a uma necessidade específica. Isso facilita a definição de usuários, qualidade esperada e métricas.
Em seguida, são definidos a propriedade, a documentação, o contrato e os controles automatizados. O produto é publicado em um catálogo e o uso pelo consumidor é monitorado. Esse feedback permite ajustes no projeto antes de estender o modelo a outros domínios.
O sucesso inicial não é medido pela quantidade de dados centralizados. Ele é medido pela redução do tempo gasto na busca de informações, pela diminuição de erros e pela reutilização do produto em diferentes processos.
A estratégia deve ser desenvolvida a partir de valores comprovados, e não de uma transformação teórica grande demais para ser executada.
Na The Cloud Group, ajudamos organizações a transformar informações fragmentadas em uma arquitetura confiável para análise, automação e inteligência artificial. Nosso trabalho começa com a compreensão dos processos, sistemas de origem e decisões que a empresa precisa aprimorar.
Criamos produtos de dados, integrações, contratos, plataformas em nuvem e modelos de governança que permitem o uso consistente de informações provenientes de CRM, ERP, aplicativos internos e fontes externas. O objetivo não é simplesmente migrar dados para uma nova plataforma, mas sim preservar seu significado, qualidade e rastreabilidade.
Também ajudamos a preparar as fontes para agentes de IA e aplicações generativas, estabelecendo camadas de acesso, controles de segurança e contextos de negócios claramente definidos. Um agente não deveria ter que navegar por sistemas conflitantes na esperança de encontrar a verdade. Ele precisa de produtos confiáveis, criados especificamente para sua função.
A inteligência artificial pode acelerar decisões e automatizar processos, mas não pode compensar indefinidamente uma arquitetura de dados fragmentada.
Porque, antes de construir uma empresa orientada por IA, é necessário construir uma empresa capaz de confiar em suas próprias informações.
Trata-se de um conjunto de dados concebido e gerido para atender a uma necessidade específica dos seus consumidores. Inclui informações, documentação, responsáveis, regras de qualidade, políticas de acesso e um ciclo de vida definido.
Um conjunto de dados é uma coleção de informações. Um produto de dados adiciona propósito, propriedade, padrões de qualidade, documentação, suporte e condições de consumo. Seu objetivo é gerar valor recorrente e confiável.
Trata-se de um acordo formal entre quem produz e quem consome informação. Ele define esquemas, campos, tipos, frequência de atualização, regras de qualidade e condições de compatibilidade. Pode ser validado automaticamente em fluxos de trabalho.
Os produtos fornecem aos sistemas de IA fontes de informação confiáveis, documentadas e controladas. Isso reduz a probabilidade de modelos e agentes utilizarem informações incorretas, desatualizadas ou fora de contexto.
Trata-se de uma abordagem arquitetônica e organizacional que distribui a responsabilidade pelos dados entre os domínios de negócios. Ela se baseia na propriedade descentralizada, em dados como produto, em plataformas de autoatendimento e em governança federada.
Não. A arquitetura de malha de dados geralmente faz mais sentido em organizações com múltiplos domínios, equipes e desafios de escalabilidade. Empresas menores podem aplicar os princípios de produtos de dados sem passar por uma transformação organizacional completa.
Deve haver um responsável visível dentro do domínio que compreenda sua importância para o negócio. Engenheiros de dados, analistas, especialistas em segurança e gestores de plataforma também podem estar envolvidos.
Por meio de dimensões como completude, precisão, consistência, singularidade, frescor e disponibilidade, as métricas devem estar relacionadas às reais necessidades dos seus consumidores.
A alteração deve ser avaliada em relação ao seu contrato. Caso seja incompatível, poderá ser necessária uma nova versão, aviso prévio e um período de transição para que os consumidores adaptem seus processos.
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
