Seus dados estão prontos para IA? Um diagnóstico honesto antes de investir

Existe uma frase que circula em projetos de inteligência artificial e que é verdadeira apenas pela metade: "sem dados bons, não há IA". A metade verdadeira é óbvia. A metade enganosa é a conclusão que muitas empresas tiram dela — a de que é preciso um projeto de governança de dados de dois anos antes de fazer qualquer coisa com IA.

Não é assim. Diferentes casos de uso exigem diferentes níveis de maturidade de dados, e a maior parte dos projetos de IA generativa corporativa exige muito menos do que se imagina. Ao mesmo tempo, existem lacunas específicas que efetivamente inviabilizam um projeto e que precisam ser identificadas antes de qualquer investimento.

Este artigo é sobre fazer esse diagnóstico com honestidade e proporção.

Diferentes casos, diferentes exigências

O primeiro erro é tratar "dados prontos para IA" como um estado único. Compare:

Assistente que responde sobre políticas internas. Precisa de documentos acessíveis, versão vigente identificável e permissões conhecidas. Não precisa de data warehouse, de histórico longo nem de dados estruturados.

Triagem de solicitações. Precisa de exemplos históricos rotulados — algumas centenas bastam — e de uma taxonomia definida.

Previsão de demanda. Precisa de série histórica consistente de 24 a 36 meses, com registro de eventos que explicam anomalias. Exigência muito mais alta.

Recomendação personalizada. Precisa de identificação confiável de cliente entre sistemas, o que costuma ser o calcanhar de Aquiles das empresas com cadastro duplicado.

Agente que executa operações. Precisa de dados transacionais corretos em tempo real e de integrações estáveis. A exigência mais alta de todas.

A conclusão prática: um diagnóstico de dados só faz sentido contra um caso de uso específico. Avaliar a maturidade de dados "em geral" produz um relatório grande e uma lista de melhorias sem prioridade.

As seis dimensões do diagnóstico

1. Existência e acessibilidade

O dado existe em formato digital consultável? Parece básico, mas é onde muitos projetos param.

Situações comuns que reprovam nesta dimensão: contratos apenas em papel ou como imagem digitalizada sem camada de texto; informação crítica em planilhas locais no computador de alguém; histórico armazenado em sistema legado sem interface de consulta; conhecimento operacional que existe apenas na cabeça de pessoas experientes.

O teste prático: peça a alguém para extrair uma amostra dos dados necessários. Se levar mais de dois dias ou exigir a intervenção de uma única pessoa específica, há um problema de acessibilidade.

2. Qualidade

Quatro verificações objetivas, feitas sobre uma amostra:

Completude. Qual percentual dos registros tem os campos necessários preenchidos? Campos obrigatórios preenchidos com valores de fuga — "não informado", "0", "a definir" — contam como vazios.

Consistência. O mesmo conceito é representado da mesma forma? Unidades de medida, formatos de data, categorias com nomes divergentes entre sistemas.

Precisão. O dado corresponde à realidade? Verificação por amostragem contra a fonte original. Cadastros de clientes e produtos são onde mais aparece divergência.

Duplicidade. Quantos registros representam a mesma entidade? Cadastro de cliente duplicado é o problema de qualidade mais comum e o que mais compromete casos de uso personalizados.

Não busque perfeição. Estabeleça o limiar necessário para o caso de uso e meça contra ele.

3. Identificação e vínculo

Existe uma forma confiável de conectar o mesmo cliente, produto ou contrato entre os diferentes sistemas?

Esta é a dimensão que mais frequentemente reprova projetos de análise e personalização. A empresa tem os dados, mas não consegue relacioná-los porque cada sistema usa uma chave diferente e não há tabela de correspondência confiável.

Quando falta, o projeto precisa incluir uma etapa de reconciliação de identidades — trabalho não trivial, mas que costuma gerar valor muito além do projeto de IA.

4. Histórico e granularidade

Há profundidade temporal suficiente? E o dado está registrado no nível de detalhe necessário?

Um erro comum: a empresa guardou totais mensais consolidados e descartou o detalhe transacional. Para previsão, isso reduz drasticamente o que é possível fazer. Se o dado detalhado ainda existe em algum lugar — backups, sistema legado —, recuperá-lo pode valer o esforço.

Verifique também mudanças de sistema ou de regra ao longo da série. Um histórico que muda de metodologia no meio precisa ser tratado, não ignorado.

5. Documentação e significado

Alguém sabe o que os campos significam? Existe alguma documentação, mesmo informal?

O cenário típico: uma tabela com 80 colunas, nomes abreviados e uma única pessoa que entende o que cada uma representa. Isso é risco operacional e gargalo de projeto.

O mínimo viável não é um catálogo corporativo completo. É uma planilha com as tabelas e campos relevantes ao caso de uso, o significado de cada um, a origem, a regra de atualização e o responsável. Duas semanas de trabalho que economizam meses.

6. Permissões e classificação

Está definido quem pode acessar o quê? Os dados estão classificados por sensibilidade? Há dados pessoais e, se sim, com que base legal?

Sem isso, qualquer sistema de IA que consulte dados corre o risco de expor informação a quem não deveria vê-la. E é a lacuna que mais atrasa a aprovação jurídica de projetos.

O diagnóstico em quatro semanas

Um levantamento proporcional, ancorado em um caso de uso definido:

Semana 1 — Escopo. Definir o caso de uso e listar exatamente quais dados ele exige. Não mais do que isso. A tentação de mapear tudo é o que transforma o diagnóstico em projeto.

Semana 2 — Localização e extração de amostra. Encontrar as fontes, obter amostras reais, registrar quanto esforço isso custou — o esforço de extração é, em si, um indicador de maturidade.

Semana 3 — Medição. Aplicar as verificações de qualidade sobre a amostra, com números. "O cadastro é ruim" não é diagnóstico; "31% dos registros de cliente não têm documento válido e há 12% de duplicidade estimada" é.

Semana 4 — Plano. Classificar cada lacuna em três grupos: bloqueadora (o projeto não funciona sem corrigir), degradante (funciona pior, corrigir em paralelo) e tolerável (registrar e seguir).

Esse último passo é o que dá utilidade ao diagnóstico. Sem a classificação, toda lacuna vira pré-requisito e o projeto não começa nunca.

A pergunta que orienta a priorização não é "os dados estão bons?", e sim "quais problemas de dado impedem este caso de uso específico de funcionar?".

Como corrigir sem parar tudo

Corrija na origem, não no destino. Limpar dados no pipeline resolve para um consumidor e deixa o problema para todos os outros. Quando possível, corrija a captura: validação no formulário, campo obrigatório, lista fechada em vez de texto livre.

Priorize por uso, não por volume. A tabela com 4 milhões de registros que ninguém consulta importa menos que a de 8 mil que sustenta a operação.

Aceite correção incremental. Regra prática eficaz: todo registro tocado por um processo é corrigido naquele momento. Em alguns meses, a parte ativa da base está limpa, sem projeto de mutirão.

Instrumente antes de corrigir. Painel simples com os indicadores de qualidade dos campos críticos, atualizado automaticamente. Torna o problema visível e permite acompanhar a melhora — e o que é medido publicamente melhora.

Nomeie donos por domínio. Alguém do comercial responde pelo cadastro de clientes; alguém das operações, pelo cadastro de produtos. Sem dono de negócio, qualidade de dado é responsabilidade da TI, que não tem como saber se um endereço está correto.

Os quatro problemas de dados que mais aparecem no Brasil

Alguns padrões se repetem com tanta frequência em empresas brasileiras de médio porte que vale tratá-los individualmente.

Duplicidade de cadastro de clientes. É o campeão. A mesma empresa aparece três vezes com grafias diferentes da razão social, ou o mesmo cliente pessoa física com e sem pontuação no documento. A origem costuma ser a ausência de validação no momento do cadastro combinada com múltiplos pontos de entrada — comercial, atendimento, e-commerce, importação de lista.

A correção tem duas frentes. Na origem, validação de documento com verificação de dígito e busca de duplicidade antes de permitir a criação. No acervo, uma rotina de agrupamento por similaridade que apresenta os candidatos para confirmação humana — automatizar a fusão sem revisão gera erros piores do que a duplicidade.

Campos de texto livre onde deveria haver lista. Motivo de cancelamento, categoria de produto, tipo de solicitação. Quando o campo é aberto, surgem centenas de variações da mesma coisa, e qualquer análise agregada se torna impossível. A correção é rápida: transformar em lista fechada, mapear as variações existentes para as novas categorias e manter um campo de observação separado para o texto livre que continua sendo útil.

Datas e valores sem padrão. Data como texto em formatos mistos, valores monetários com separadores inconsistentes, campos numéricos armazenados como texto para acomodar exceções. Costuma vir de importações antigas ou de integrações por arquivo. Precisa de normalização única e de validação de tipo na entrada para não recorrer.

Histórico interrompido por troca de sistema. A empresa migrou de ERP há três anos e o histórico anterior ficou no sistema antigo, que ainda roda em uma máquina no canto da sala, ou foi exportado para arquivos que ninguém sabe ler. Para casos de uso que exigem série histórica longa, isso é bloqueador. A decisão precisa ser tomada conscientemente: recuperar e normalizar o histórico antigo, ou aceitar trabalhar apenas com o período posterior à migração.

Nenhum desses quatro problemas exige tecnologia sofisticada para resolver. Todos exigem uma decisão sobre quem é o dono do dado e um período de trabalho dedicado — que é exatamente o recurso que costuma faltar.

O que não vale a pena fazer antes

Alguns esforços costumam ser propostos como pré-requisito e raramente se justificam antes do primeiro caso de uso:

Construir um data lake corporativo completo. Projeto longo, caro, e que frequentemente entrega um repositório de dados que ninguém consome. Construa a partir da necessidade real.

Implantar uma ferramenta de catálogo antes de ter o que catalogar. A planilha resolve no início e não custa licença.

Buscar qualidade de 100%. Custo cresce exponencialmente e o retorno cai. Defina o suficiente e siga.

Reescrever integrações legadas por elegância. Se funciona e é estável, adie.

O efeito colateral positivo

Um aspecto pouco comentado: projetos de IA são excelentes catalisadores de melhoria de dados, porque tornam o problema visível e com patrocínio.

Iniciativas de governança de dados isoladas sofrem por falta de urgência — todo mundo concorda que é importante e ninguém prioriza. Quando o assistente responde errado porque o procedimento está desatualizado, ou quando a previsão falha porque o cadastro tem duplicidade, o problema deixa de ser abstrato.

Vale usar isso deliberadamente: escolher um primeiro caso de uso que dependa dos dados que a empresa mais precisa organizar, e tratar a melhoria de dados como entregável do projeto, não como pré-requisito externo.

Um teste rápido de maturidade

Se você quer uma avaliação em cinco minutos, responda estas oito perguntas com sim ou não:

1. Consigo obter uma amostra dos dados de clientes dos últimos 24 meses em menos de dois dias, sem depender de uma pessoa específica?
2. Existe um sistema que é reconhecidamente a fonte de verdade para o cadastro de clientes e produtos?
3. Sei estimar, com número, o percentual de duplicidade nesse cadastro?
4. Existe alguma documentação — mesmo informal — do significado dos campos das tabelas principais?
5. Os dados sensíveis estão classificados e as permissões de acesso estão definidas em algum lugar consultável?
6. Consigo relacionar o mesmo cliente entre pelo menos dois sistemas diferentes com confiança?
7. Há alguém do negócio, e não da TI, formalmente responsável pela qualidade de algum domínio de dados?
8. Alguma métrica de qualidade de dados é acompanhada com regularidade?

Cinco respostas afirmativas ou mais indicam base suficiente para a maioria dos casos de uso de IA generativa, e provavelmente para os preditivos mais simples. Entre três e quatro, é possível avançar com casos de uso documentais enquanto se corrige o restante em paralelo. Abaixo de três, o próximo projeto deveria ser de organização de dados — mas ainda assim ancorado num caso de uso concreto, e não como iniciativa abstrata de governança.

O valor desse teste não está na pontuação. Está em identificar quais das oito respostas negativas bloqueiam especificamente o que você quer fazer.

Conclusão

Dados prontos para IA não é um estado binário nem um destino distante. É uma avaliação relativa a um caso de uso concreto, com lacunas classificadas por impacto real.

Empresas que exigem perfeição antes de começar nunca começam. Empresas que ignoram completamente a qualidade descobrem o problema em produção, da pior forma. O caminho intermediário — diagnóstico curto, classificação honesta das lacunas, correção do que bloqueia e tolerância explícita ao resto — é o que permite avançar com previsibilidade.

A BHELP.tech conduz esse diagnóstico ancorado em casos de uso reais, com números em vez de impressões, e trata a melhoria de dados como parte do projeto. Se você suspeita que os seus dados não estão prontos, a forma de descobrir não é adiar — é medir.