O problema que ninguém quer admitir
Toda empresa de médio e grande porte no Brasil tem o mesmo problema — e quase nenhuma o admite abertamente: seus dados são, em alguma medida, ruins. Duplicados, desatualizados, inconsistentes entre sistemas, preenchidos incorretamente, com campos obrigatórios em branco. Não é uma crítica — é uma realidade estrutural de qualquer organização que cresceu ao longo do tempo, adquiriu sistemas diferentes, passou por migrações e integrou dados de múltiplas fontes. O problema não é a existência dos dados ruins. O problema é que a maioria das empresas não sabe quanto isso custa.
O Gartner, em seu relatório mais recente sobre gestão de dados, estima que a baixa qualidade de dados custa à empresa média US$ 12,9 milhões por ano — o equivalente a aproximadamente R$ 65 milhões na cotação atual. Mais impactante: organizações que tentaram quantificar o impacto internamente relataram perdas de 15% a 25% da receita anual atribuíveis a decisões tomadas com base em dados incorretos ou incompletos. E com a explosão do investimento em IA — que o Gartner projeta superar US$ 2 trilhões em 2026 — o custo de dados ruins escala proporcionalmente: cada pipeline de machine learning alimentado por dados de baixa qualidade multiplica os erros, em vez de apenas perpetuá-los.
Onde os dados ruins causam mais dano nas empresas brasileiras
Os vetores de dano da baixa qualidade de dados são múltiplos, mas alguns padrões se repetem com alta frequência nas empresas brasileiras. O primeiro e mais custoso é no CRM: dados de clientes desatualizados, duplicados ou incompletos levam a campanhas de marketing desperdiçadas, equipes de vendas trabalhando com informações erradas sobre clientes e análises de churn que não refletem a realidade. Uma empresa de varejo com 2 milhões de clientes ativos no CRM e 30% de registros com inconsistências significativas está basicamente gerindo um terço da sua base no escuro.
O segundo vetor é no financeiro e na cadeia de suprimentos: dados de precificação inconsistentes entre sistemas, informações de fornecedores desatualizadas, registros de estoque que não refletem o físico real. Esses problemas têm impacto direto no resultado: margens calculadas incorretamente, pedidos com fornecedores baseados em demanda projetada com dados ruins, pricing dinâmico que reage a sinal de mercado que não corresponde à realidade. Em setores de margens estreitas — varejo, distribuição, manufatura — esses erros podem ser a diferença entre lucro e prejuízo em uma linha de produto inteira.
O terceiro vetor, crescente em 2026, é no treinamento e operação de modelos de IA. Um modelo de propensão à compra treinado com dados de clientes duplicados vai superestimar determinados segmentos e subestimar outros. Um modelo de detecção de fraude alimentado com dados de transações com campos nulos vai ter taxa de falso positivo sistematicamente alta em categorias específicas. O problema não aparece no treinamento — aparece em produção, semanas depois, quando os resultados não correspondem às expectativas e a equipe de dados começa o doloroso processo de rastrear a origem do problema.
Data observability: de monitoramento reativo a prevenção proativa
A resposta que o mercado construiu para o problema de qualidade de dados é a categoria de “data observability” — ferramentas e práticas que monitoram continuamente a saúde dos pipelines e repositórios de dados, detectando problemas antes que eles se propaguem e causem dano. Em 2026, essa categoria atingiu maturidade suficiente para ser considerada infraestrutura essencial em qualquer empresa que dependa de dados para decisões críticas — que é, na prática, qualquer empresa acima de certo porte.
O que diferencia data observability da qualidade de dados tradicional é a abordagem proativa e em tempo real. Ferramentas tradicionais de qualidade de dados funcionavam como auditorias periódicas: uma vez por semana, um processo verifica se os dados estão dentro dos critérios estabelecidos e gera um relatório. Quando o problema é identificado, dados ruins já foram consumidos por dashboards, modelos e decisões por dias ou semanas. Data observability monitora continuamente o fluxo de dados, usando machine learning para detectar anomalias estatísticas — uma distribuição de valores que mudou de padrão, um campo que começou a ter taxa de nulidade incomum, uma tabela que deixou de ser atualizada no horário esperado — e alerta as equipes de dados imediatamente.
A Monte Carlo Data, referência do setor, reportou em seu Data Reliability Report de 2026 que empresas com data observability implementada reduziram o “tempo de detecção” de problemas de dados de uma média de 9 dias para menos de 4 horas. A diferença entre descobrir um problema de dados em 4 horas e em 9 dias é a diferença entre um impacto contido e um impacto sistêmico. Em empresas com pipelines de dados alimentando decisões de crédito, precificação dinâmica ou recomendação de produtos, 9 dias de dados ruins podem representar perdas milionárias.
O ecossistema de ferramentas de data observability open-source também amadureceu significativamente. O DataKitchen publicou em 2026 um mapeamento completo do landscape open-source, destacando ferramentas como Great Expectations, dbt tests e Apache Griffin como soluções viáveis para empresas que querem começar sem investimento em soluções proprietárias. Para equipes de dados brasileiras que precisam construir fundação de qualidade com orçamento limitado, o caminho open-source tem se mostrado não apenas viável, mas frequentemente mais adaptável às necessidades específicas do negócio do que soluções de prateleira.
A disciplina de dados que os projetos de IA tornaram obrigatória
Se existe um catalisador que transformou qualidade de dados de prioridade “nice to have” para “não negociável” nas empresas brasileiras, foi a expansão dos projetos de IA. Em 2023 e 2024, empresas lançaram projetos de machine learning e IA generativa com entusiasmo — e muitos falharam silenciosamente não por limitações dos modelos, mas pela qualidade dos dados com que foram treinados e operados. O custo desses fracassos começou a aparecer nos resultados e na confiança da liderança em projetos de IA.
A lição que o mercado aprendeu — e que está sendo consolidada em 2026 — é que a arquitetura de qualidade de dados precisa ser anterior e paralela a qualquer projeto de IA, não um afterthought. O conceito de “data contracts” — acordos formais entre produtores e consumidores de dados que definem esquema, qualidade mínima e SLAs de atualização — está se tornando prática padrão nas equipes de engenharia de dados mais maduras. Um data contract funciona como um contrato de API, mas para dados: o produtor garante que o dado vai chegar com a qualidade e o timing acordados; o consumidor consome com confiança. Quando o contrato é violado — dado chegou tarde, campo estava nulo, distribuição mudou — um alerta é gerado e o pipeline consumidor pode pausar, em vez de processar dados ruins.
Para as empresas brasileiras que estão escalando projetos de IA em 2026, a pergunta crítica não é “qual modelo de IA usar” — é “meus dados são bons o suficiente para alimentar esse modelo de forma confiável?” Responder sim a essa pergunta exige um programa estruturado de qualidade de dados: inventário dos ativos de dados críticos, definição de métricas de qualidade por domínio, implementação de monitoramento contínuo e um processo claro de remediação quando problemas são detectados.
Construindo uma cultura de dados confiáveis na empresa brasileira
A dimensão mais complexa da qualidade de dados não é tecnológica — é cultural. Dados ruins geralmente são sintoma de processos operacionais mal desenhados, incentivos que não incluem a qualidade dos dados como critério, ou simplesmente falta de consciência de que o dado que você insere hoje vai alimentar uma decisão importante amanhã. Nenhuma ferramenta de observability resolve um problema cultural de dados.
As organizações que mais avançaram em qualidade de dados em 2026 têm em comum uma característica: tornaram a qualidade dos dados uma responsabilidade explícita distribuída pela organização, não apenas do time de dados central. O conceito de “data stewardship” — onde cada domínio de negócio tem um responsável pela qualidade dos dados que produz — é a contrapartida organizacional do data mesh técnico. O estewart de dados não é necessariamente um especialista técnico: é alguém que entende profundamente o domínio de negócio e tem autoridade e responsabilidade para garantir que os dados daquele domínio sejam precisos, completos e atualizados.
Para CDOs e líderes de dados no Brasil, o caminho prático começa com visibilidade. A maioria das organizações não tem uma visão consolidada de onde seus dados ruins estão e quanto custam. O primeiro projeto de qualidade de dados mais transformador que já vi em empresas brasileiras foi simplesmente um “custo da má qualidade de dados” — um exercício de quantificação financeira do impacto dos problemas de dados conhecidos. Quando um CEO vê que dados ruins estão custando R$ 20 milhões por ano em decisões equivocadas, campanhas desperdiçadas e retrabalho operacional, o projeto de data observability deixa de competir por orçamento com outras iniciativas — vira prioridade.
Publicado em 18 de março de 2026 · thinq.news
