Seu dado bagunçado não é problema de IA. É o pré-requisito dela

Toda empresa que chega até nós traz a mesma confissão, com variações na vergonha: os dados estão uma bagunça. Planilhas que contradizem o ERP. Campos livres onde deveriam existir categorias fixas. Histórico de pedidos distribuído por três sistemas, nenhum deles autoridade sobre o outro. A conclusão natural é: antes de implementar IA, precisamos resolver o dado. O problema é que essa conclusão está de cabeça para baixo. Dado bagunçado não é um pré-problema a eliminar antes da IA aparecer. É a radiografia do processo. E entender essa radiografia é exatamente o que permite construir um agente que funciona em produção.

Por que dado espalhado diz mais sobre o processo do que sobre tecnologia

Quando o campo 'fornecedor' tem 47 variações para o mesmo CNPJ, isso não é um problema de banco de dados. É a história de um processo de compras que passou por três equipes, duas aquisições e um sistema legado que nunca foi descomissionado. Quando o status de um pedido existe como texto livre num campo de observações, é porque alguém precisava registrar uma exceção que o sistema formal não suportava. Dado bagunçado é processo que vaza para onde o sistema não chegou.

Essa distinção muda tudo na abordagem. Tratar dado bagunçado como problema técnico leva a soluções técnicas: ferramentas de ETL, pipelines de limpeza, projetos de data governance que custam caro e entregam catálogos de dados que ninguém consulta. Tratar dado bagunçado como sinal de processo leva a perguntas diferentes: onde o fluxo quebra? Quem precisa de informação que o sistema formal não fornece? Qual exceção virou regra e nunca foi formalizada?

O que um agente de IA realmente precisa dos dados para operar

Um agente opera sobre contexto estruturado. Ele precisa saber o que uma entidade é, qual o seu estado atual, quais ações são possíveis sobre ela e o que aconteceu antes. Para um agente de compras, isso significa: saber que o item X pertence a uma categoria específica, que o fornecedor Y tem determinada política de prazo, que a última cotação ocorreu em determinada condição e que existe uma regra de aprovação que depende do valor total. Se qualquer uma dessas informações estiver em campo livre, duplicada com inconsistência ou simplesmente ausente, o agente para. Não degrada de forma elegante. Para.

Isso explica por que a maioria dos pilotos de IA corporativa, segundo a McKinsey e a Deloitte, não chega à produção. O piloto funciona no subconjunto de dados curado manualmente para a demonstração. Quando toca o dado real, com todas as suas exceções e o histórico de decisões não registradas, o agente erra ou trava. A equipe conclui que a IA não estava pronta. A conclusão mais precisa seria outra: o processo não estava mapeado.

Dado bagunçado não bloqueia a IA. Revela onde o processo nunca foi desenhado de forma explícita.

Dado limpo se compra? O equívoco do projeto de qualidade de dados

Existe uma categoria inteira de projetos de tecnologia que promete entregar dado limpo como produto final: iniciativas de master data management, plataformas de data quality, consultorias de data governance. A promessa é sedutora: pague por uma camada de limpeza e seu dado emergirá estruturado, pronto para qualquer consumidor downstream, incluindo agentes de IA. O problema não está na tecnologia dessas plataformas. Está no modelo mental por trás da contratação.

Dado limpo que se mantém limpo é subproduto de um processo que registra corretamente na origem. Quando o processo não define onde e como determinada informação deve ser capturada, nenhuma ferramenta de limpeza resolve o problema de forma permanente. Resolve hoje, o dado suja amanhã, porque a fonte continua sendo um campo livre preenchido por pessoas diferentes com critérios diferentes. A limpeza vira custo recorrente sem endereçar a causa.

O que observamos na prática, dentro dos projetos que a nossa equipe conduz, é que o trabalho de preparar dados para IA e o trabalho de entender o processo são o mesmo trabalho. Não têm como ser separados. Quando mapeamos como um pedido de compra percorre a operação, de qual sistema de origem parte, quem aprova, onde as exceções acontecem e como elas são registradas, esse mapeamento já produz a estrutura que o agente vai consumir. Dado limpo emerge do entendimento, não de uma ferramenta aplicada por cima.

Como identificar onde o dado quebra: o caminho das exceções

Para qualquer processo que se quer automatizar, a pergunta mais reveladora é: o que acontece quando algo foge do fluxo normal? Onde essa exceção é registrada? Por quem? Em que formato? Em processos maduros, exceções têm tratamento explícito: um campo de status específico, uma fila de revisão, um log com timestamp. Em processos que cresceram de forma orgânica, exceções vivem em e-mails, anotações em planilha e na memória de quem faz o trabalho há anos.

Essa distinção tem consequência direta para a construção do agente. Um agente precisa de regras explícitas para operar. Se a regra existe apenas na cabeça de um analista, o agente não tem como segui-la. A primeira etapa de qualquer projeto nosso é mapear os caminhos de exceção e transformá-los em regras formais. Esse processo frequentemente revela que o que parecia exceção acontece numa parcela relevante dos casos. A exceção virou o processo real, mas nunca foi documentada como tal.

O que acontece quando dado e processo são tratados como uma coisa só

Em um projeto de automação de compras que a nossa equipe conduziu para uma empresa de mineração, o ponto de partida era exatamente esse cenário: dados distribuídos entre o Protheus e planilhas de controle, com campos de fornecedor e item inconsistentes, sem histórico de cotação estruturado. A tentação óbvia seria iniciar um projeto de limpeza antes de construir qualquer agente.

O caminho que escolhemos foi diferente. Mapeamos o processo de compras do início ao fim, entrevistando as pessoas que o executavam, identificando onde cada decisão era tomada e onde cada informação era registrada. Esse mapeamento revelou que a grande maioria dos pedidos seguia um fluxo previsível com dados suficientemente estruturados. O restante representava exceções com padrões identificáveis, para as quais desenhamos tratamento específico no agente. O dado não precisou estar perfeito para o agente operar: precisou estar compreendido. O resultado foi redução de 30 para 5 minutos por pedido processado, com zero erros de entrada no ERP.

O agente não precisa de dado perfeito. Precisa de dado cujo comportamento, incluindo os defeitos, seja conhecido e tratado de forma explícita.

Por que a preparação de dados para IA começa no desenho do agente

Existe uma sequência que parece lógica e que quase sempre falha: primeiro limpar os dados, depois construir a IA. O problema é que não se sabe quais dados limpar até saber o que o agente precisa fazer. E não se sabe o que o agente precisa até mapear o processo. A limpeza prematura invariavelmente limpa as coisas erradas, com critérios que não refletem o que o sistema vai consumir.

A sequência que funciona começa pelo processo: entender o que precisa acontecer, quem decide o quê, em qual ordem, com base em quais informações. Esse entendimento determina quais dados são necessários, em qual granularidade e com qual nível de completude. A partir daí, a limpeza tem critério real. O objetivo deixa de ser deixar o dado bonito e passa a ser deixar o dado apto a suportar a decisão que o agente vai tomar.

O que separa a IA que vai para produção da que fica no piloto

Segundo dados amplamente reportados pela McKinsey e pela Deloitte, a maioria dos projetos de IA corporativa não chega à produção. A explicação mais frequente, dentro das próprias organizações, é que faltou dado. A explicação mais precisa é que faltou entendimento do processo que gera o dado. Um piloto funciona com dado curado. Produção funciona com dado real, dinâmico, com exceções que ninguém previu na demonstração.

Os projetos que chegam à produção têm uma característica em comum: o agente foi construído com conhecimento explícito de onde o dado é confiável, onde ele é incompleto e o que fazer em cada caso. Isso não é resiliência adicionada depois como patch. É o resultado de ter mapeado o processo antes de escrever a primeira linha de lógica do agente. A nossa fábrica de agentes é desenhada para capturar esse mapeamento e transformá-lo em comportamento do sistema, não em documentação que fica numa gaveta.

Dado para IA não é um estado que se atinge antes de começar. É uma propriedade que emerge de construir o agente certo sobre o processo certo.

O ponto de entrada que funciona na prática

Para qualquer operação que considera IA como próxima etapa, a pergunta certa não é 'nosso dado está pronto?'. A pergunta certa é 'nosso processo está mapeado?'. Se a resposta for não, esse é o trabalho, e não como projeto separado de data governance, mas como parte inseparável do desenho do agente.

Na prática, isso significa escolher um processo com volume suficiente para justificar automação, com variação limitada o bastante para ser mapeável, e com dados distribuídos por no máximo dois ou três sistemas. Mapear esse processo do início ao fim, incluindo as exceções. Identificar quais dados o agente precisa e em qual estado eles estão hoje. Esse diagnóstico normalmente leva algumas semanas e já produz clareza suficiente para decidir se e como construir. Mais do que preparar dado, é entender se a operação está pronta para ser operada por sistema.

Quer ler a sua operação a fundo?