DATA QUALITY: O PRÉ-REQUISITO QUE NINGUÉM QUER RESOLVER ANTES DE USAR IA

A qualidade dos dados é o gargalo real — não o modelo, não o framework, não o orçamento

Antes de discutir arquiteturas de LLMs, estratégias de fine-tuning ou qual plataforma de machine learning adotar, é preciso enfrentar uma verdade desconfortável: a maioria esmagadora dos projetos de inteligência artificial falha não por limitações algorítmicas, mas pela precariedade dos dados que os alimentam. Segundo a McKinsey, até 70% do esforço total em projetos de IA é consumido por preparação, limpeza e transformação de dados — uma proporção que revela o quanto subestimamos a fundação sobre a qual tentamos construir. A Gartner estima que o custo médio de dados de baixa qualidade para uma organização é de US$ 12,9 milhões por ano, um número que contempla retrabalho, decisões equivocadas e oportunidades perdidas. Não se trata, portanto, de um problema lateral ou de um inconveniente operacional; trata-se do pré-requisito estrutural que determina se um projeto de IA entregará valor ou consumirá recursos sem retorno.

Neste artigo, apresentamos as cinco dimensões fundamentais da qualidade de dados, os problemas mais recorrentes em empresas brasileiras, a distinção entre data quality e data governance — que frequentemente se confundem — e as estratégias práticas de remediação que aplicamos na Frame8 através da fase de Scan da metodologia SMAECIA.

O princípio "garbage in, garbage out" amplificado pela IA

Por que modelos de IA são mais sensíveis a dados ruins do que sistemas tradicionais

O conceito de "garbage in, garbage out" existe na computação há décadas, mas a inteligência artificial — especialmente os modelos generativos e os sistemas de machine learning — amplifica esse problema de maneira exponencial. Em um sistema convencional de regras, dados incorretos produzem saídas incorretas de forma previsível e rastreável. Em um modelo de machine learning, dados ruins contaminam os padrões aprendidos durante o treinamento, gerando vieses, alucinações e correlações espúrias que se propagam por todas as inferências subsequentes de forma muito menos transparente.

Quando alimentamos um LLM com documentos desatualizados, inconsistentes ou incompletos em um pipeline de RAG (Retrieval-Augmented Generation), o modelo não tem como distinguir informação válida de ruído — pois a qualidade semântica depende inteiramente da qualidade do corpus de origem. Quando treinamos um modelo preditivo com dados históricos que contêm duplicatas, campos nulos não tratados ou categorias inconsistentes, o modelo aprende padrões que refletem os erros dos dados, não a realidade do negócio. A pesquisa da IBM sobre o impacto da qualidade de dados em projetos de IA demonstra que modelos treinados com dados de baixa qualidade podem apresentar degradação de performance entre 25% e 40% em relação ao seu potencial teórico, o que transforma investimentos milionários em projetos que entregam resultados medíocres.

O custo composto da negligência

O problema se agrava porque os custos da má qualidade de dados são compostos, não lineares. Uma base de clientes com endereços desatualizados não apenas compromete campanhas de marketing — quando utilizada para treinar um modelo de propensão, contamina também a segmentação futura, as projeções de LTV e as decisões de alocação de budget. O dado ruim, uma vez incorporado a um modelo, gera decisões ruins que geram novos dados ruins, em um ciclo que se retroalimenta. É por isso que a remediação precisa acontecer antes da modelagem, não depois; corrigir dados na origem é ordens de magnitude mais barato do que corrigir as consequências de modelos treinados sobre fundações precárias.

As cinco dimensões da qualidade de dados

Para abordar data quality de forma estruturada, utilizamos um framework de cinco dimensões que permite diagnosticar, medir e remediar problemas de forma sistemática. Cada dimensão representa um eixo distinto de avaliação, e a fragilidade em qualquer uma delas é suficiente para comprometer um projeto de IA.

Accuracy (Acurácia)

A acurácia diz respeito ao grau em que os dados refletem corretamente a realidade que pretendem representar. Um campo de CEP que contém "00000-000" não é apenas incompleto — é inacurado, pois representa uma informação que não corresponde a nenhuma localidade real. Em projetos de IA, a acurácia é particularmente crítica porque modelos de machine learning tratam os dados de treinamento como verdade fundamental; se a verdade fundamental está errada, o modelo aprende a errar com confiança. A mensuração da acurácia tipicamente exige validação contra fontes externas de referência ou regras de negócio bem definidas, o que requer investimento em processos de validação que muitas organizações preferem postergar.

Completeness (Completude)

A completude avalia a proporção de dados presentes em relação ao que deveria estar disponível. Campos nulos, registros faltantes e séries temporais com lacunas são manifestações comuns de incompletude. Para modelos de machine learning, dados faltantes são problemáticos não apenas pela ausência em si, mas pelas estratégias de imputação que exigem — cada técnica de imputação introduz pressupostos que podem distorcer os padrões aprendidos. Uma base de dados de vendas com 30% dos registros sem informação de canal de origem, por exemplo, inviabiliza qualquer modelo de atribuição confiável, pois a ausência não é aleatória — geralmente reflete falhas de integração entre sistemas que correlacionam-se com determinados canais ou períodos.

Consistency (Consistência)

A consistência mensura o grau de concordância dos dados entre diferentes sistemas, tabelas e períodos. Quando o CRM registra "São Paulo" e o ERP registra "SP" e o data warehouse registra "SAO PAULO", temos um problema de consistência que, para um humano, é trivial resolver, mas que para um modelo pode significar a criação de três entidades distintas onde deveria existir uma. A inconsistência é endêmica em empresas que cresceram por aquisição ou que mantêm múltiplos sistemas legados, cenário particularmente comum no mercado brasileiro, onde ondas de fusões e aquisições nos setores financeiro, farmacêutico e de varejo criaram paisagens de dados fragmentadas que resistem a tentativas de harmonização.

Timeliness (Temporalidade)

A temporalidade refere-se à atualidade dos dados em relação ao momento de uso. Dados podem ser acurados, completos e consistentes, mas estarem desatualizados a ponto de serem irrelevantes para a decisão que precisam informar. Em contextos de IA, a temporalidade é especialmente relevante para modelos que operam sobre dados comportamentais ou transacionais, pois padrões de consumo, preferências e riscos mudam com velocidade incompatível com ciclos de atualização lentos. Um modelo de detecção de fraude treinado com dados de 18 meses atrás enfrenta um cenário de ameaças completamente diferente do atual, e sua eficácia degrada proporcionalmente à defasagem temporal dos dados de treinamento.

Accessibility (Acessibilidade)

A acessibilidade avalia a facilidade com que os dados podem ser localizados, compreendidos e utilizados por quem precisa deles. Dados podem existir em alta qualidade em todas as dimensões anteriores e ainda assim serem inúteis se estiverem presos em silos departamentais, sem documentação, sem catálogo e sem APIs de acesso. A acessibilidade é frequentemente a dimensão mais negligenciada porque não aparece nas métricas tradicionais de qualidade, mas na prática é a que mais bloqueia projetos de IA — pois equipes de dados gastam semanas tentando localizar, entender e obter acesso aos dados de que precisam antes mesmo de avaliar sua qualidade nas outras dimensões.

Os problemas crônicos das empresas brasileiras

Silos departamentais e feudos de dados

A realidade que encontramos em praticamente toda empresa brasileira de médio e grande porte é a existência de silos departamentais profundos, nos quais cada área mantém seus próprios repositórios, suas próprias definições e seus próprios processos de coleta, sem qualquer coordenação transversal. Marketing tem sua base de leads no HubSpot, vendas tem o CRM da Salesforce, financeiro opera sobre o SAP, e operações mantém planilhas paralelas que "complementam" o ERP. Quando um projeto de IA precisa cruzar dados dessas fontes, descobre-se que não existe chave comum, que as definições de "cliente ativo" divergem entre áreas e que ninguém sabe ao certo qual base é a "fonte de verdade". Nas organizações em que atuei — no Bradesco Seguros, na TOTVS, em projetos pelo Cubo Itaú —, pude observar que esse padrão se repete independentemente do porte ou maturidade declarada da empresa.

Sistemas legados e dívida técnica de dados

O parque tecnológico de muitas empresas brasileiras inclui sistemas legados de 15, 20 ou até 30 anos, que foram customizados ao longo do tempo de formas que ninguém documentou completamente. Esses sistemas armazenam dados em formatos proprietários, com codificações inconsistentes e regras de negócio embutidas em stored procedures que poucos profissionais ainda compreendem. Migrar ou integrar esses dados é um desafio que não se resolve com um conector ETL padrão — requer arqueologia de dados, engenharia reversa de regras de negócio e, frequentemente, decisões difíceis sobre o que preservar e o que descartar. A dívida técnica de dados é tão real quanto a dívida técnica de código, porém muito menos visível e muito mais cara de resolver retroativamente.

Ausência de catálogo e linhagem de dados

A falta de um catálogo de dados (data catalog) e de rastreabilidade de linhagem (data lineage) é talvez o sintoma mais revelador da imaturidade em data quality. Sem catálogo, ninguém sabe que dados existem, onde estão, o que significam e quem é responsável por eles. Sem linhagem, ninguém sabe de onde um dado veio, por quais transformações passou e se pode ser confiado para uma determinada finalidade. Essas ausências transformam cada novo projeto de IA em uma expedição exploratória, na qual a equipe de dados gasta 60-70% do tempo apenas descobrindo e entendendo os dados antes de poder trabalhar com eles — confirmando o dado da McKinsey sobre a proporção desproporcional de esforço em preparação de dados.

Governança de dados vs. qualidade de dados: a distinção que importa

É comum observar a confusão entre data governance e data quality, como se fossem sinônimos ou como se uma substituísse a outra. Na prática, são disciplinas complementares com escopos distintos, e compreender essa distinção é fundamental para estruturar iniciativas eficazes.

Data governance é o framework de políticas, processos, papéis e responsabilidades que define como os dados devem ser gerenciados ao longo de seu ciclo de vida. Trata-se de uma disciplina organizacional que estabelece quem pode acessar quais dados, como decisões sobre dados são tomadas, quem é responsável pela qualidade de cada domínio e como conflitos sobre definições e prioridades são resolvidos. Data quality, por sua vez, é a disciplina operacional e técnica que mensura, monitora e remedia a condição dos dados em relação às cinco dimensões que discutimos, assegurando que estejam em conformidade com os padrões definidos pela governança.

Sem governança, iniciativas de data quality são táticas e insustentáveis — resolvem problemas pontuais sem criar as estruturas que previnem sua recorrência. Sem data quality, a governança é um arcabouço teórico desconectado da realidade operacional. A maturidade em dados exige ambas, em paralelo e de forma integrada, com a governança definindo o "o quê" e o "quem", e a qualidade operacionalizando o "como" e o "quando".

Estratégias práticas de remediação

Profiling e diagnóstico como ponto de partida

Toda iniciativa de remediação de data quality deve começar por um diagnóstico rigoroso — o que chamamos de data profiling. Esse processo envolve a análise estatística de cada campo e tabela relevante para mapear distribuições, identificar anomalias, quantificar nulos, detectar duplicatas e avaliar a conformidade com regras de negócio. O profiling não é um exercício acadêmico; é a base empírica que permite priorizar esforços de remediação de acordo com o impacto nos casos de uso de IA pretendidos. Ferramentas como Great Expectations, dbt tests e Soda Core permitem automatizar esse diagnóstico e incorporá-lo aos pipelines de dados como validações contínuas.

Data contracts e validação na origem

Uma das estratégias mais eficazes para prevenir degradação de qualidade é a implementação de data contracts — acordos formais entre produtores e consumidores de dados que especificam schema, tipos, faixas de valores aceitáveis, latência máxima e SLAs de completude. Data contracts transferem a responsabilidade pela qualidade para o ponto de geração do dado, evitando que problemas se propaguem downstream e se acumulem no data warehouse ou data lake. Essa abordagem exige maturidade organizacional e patrocínio executivo, mas seus resultados justificam o investimento, pois o custo de correção na origem é exponencialmente menor do que o custo de correção a jusante.

Monitoramento contínuo e observabilidade de dados

Qualidade de dados não é um projeto com início, meio e fim — é uma disciplina contínua que exige monitoramento permanente. Assim como aplicações de software possuem observabilidade (logs, métricas, traces), pipelines de dados precisam de data observability: alertas quando métricas de qualidade degradam, dashboards de saúde dos datasets, rastreamento de linhagem em tempo real e detecção de anomalias nas distribuições. Plataformas como Monte Carlo, Atlan e Elementary oferecem essas capacidades, mas mesmo organizações com orçamento limitado podem implementar monitoramento básico com combinações de dbt tests, Great Expectations e alertas customizados.

Como a fase Scan do SMAECIA endereça data quality

Na metodologia SMAECIA que desenvolvemos na Frame8, a fase de Scan é dedicada especificamente ao diagnóstico do ecossistema de dados da organização, e não por acidente — pois entendemos que sem essa etapa de reconhecimento rigoroso, qualquer projeto de IA subsequente opera sobre premissas não verificadas. O Scan envolve a catalogação dos ativos de dados existentes, o profiling de qualidade nas cinco dimensões, o mapeamento de fluxos de dados entre sistemas, a identificação de lacunas e inconsistências, e a avaliação da maturidade de governança.

O resultado do Scan não é um relatório decorativo — é um plano de remediação priorizado que vincula cada problema de data quality identificado aos casos de uso de IA que ele impacta, permitindo que a organização tome decisões informadas sobre onde investir primeiro. Frequentemente, o Scan revela que a empresa possui dados suficientes para determinados casos de uso mas não para outros, ou que a remediação necessária para um caso de uso de alto valor é surpreendentemente simples enquanto outro caso de uso, aparentemente similar, exigiria meses de trabalho de integração. Essa clareza diagnóstica é o que permite construir roadmaps de IA realistas, que entregam valor incrementalmente em vez de prometer transformações impossíveis.

O caminho não é perfeição — é adequação progressiva

A tentação diante do cenário descrito é concluir que a empresa precisa "arrumar todos os dados" antes de iniciar qualquer projeto de IA, o que na prática equivale a nunca iniciar. O caminho pragmático é diferente: identificar quais dados são necessários para quais casos de uso, diagnosticar a qualidade especificamente desses dados, remediar o suficiente para viabilizar o caso de uso com nível aceitável de confiança e estabelecer as estruturas de governança e monitoramento que garantam melhoria contínua.

Não estamos falando de perfeição, pois perfeição de dados é uma abstração inatingível. Estamos falando de adequação — de garantir que os dados utilizados para cada aplicação de IA atendam aos requisitos mínimos de qualidade que essa aplicação demanda. Um modelo de recomendação tolera mais ruído do que um modelo de scoring de crédito. Um chatbot de FAQ interno tem requisitos de acurácia diferentes de um sistema de diagnóstico médico assistido. A abordagem correta é contextual, não absolutista.

O investimento em data quality é, em última análise, o investimento que determina se os demais investimentos em IA gerarão retorno. Ignorá-lo é construir sobre areia; enfrentá-lo com método e priorização é construir sobre rocha. E como demonstram os números da Gartner e da McKinsey, as organizações que compreendem essa sequência estão sistematicamente entre as que extraem valor real da inteligência artificial.

Qualidade de dados não é um projeto paralelo à IA — é o alicerce que define se os demais investimentos terão retorno. Se a sua organização está planejando escalar inteligência artificial, o primeiro passo é diagnosticar a fundação sobre a qual pretende construir. Na Frame8, esse diagnóstico é onde todo projeto começa.