A demonstração funcionou. O fornecedor trouxe três exemplos, o agente respondeu tudo certo e a sala inteira saiu animada da reunião. Seis meses depois, aquele piloto continua sendo piloto. A conclusão fácil é que a ferramenta era ruim, então a empresa troca de fornecedor e repete o ciclo. A conclusão correta costuma ser outra: faltou preparar dados para IA antes de tentar colocar qualquer coisa em produção.
Esse diagnóstico incomoda porque contraria a promessa que o mercado vendeu. Ainda assim, ele explica a maior parte dos projetos travados nas empresas brasileiras.
O piloto encanta porque o cenário é escolhido a dedo
Toda demonstração usa dado limpo, porque o fornecedor seleciona três contratos bem preenchidos, dois chamados representativos e um relatório organizado. Nesse ambiente, então, o modelo brilha.
A operação real é outra coisa. Ali, o mesmo campo aparece preenchido de quatro jeitos diferentes e o cadastro do cliente está duplicado em dois sistemas. Metade dos anexos é foto de documento tirada no celular. Além disso, a regra que decide o desconto vive na cabeça de alguém que trabalha na empresa há doze anos.
Quando o piloto encontra esse cenário, ele não erra de forma escandalosa. Erra pouco, de maneira difusa e difícil de auditar, o que é bem pior. A equipe perde confiança, o uso cai e o projeto morre por abandono, sem que ninguém formalize o enterro.
Onde o dinheiro de IA está sendo mal alocado
Um levantamento sobre maturidade digital divulgado em julho de 2026 escancarou o desequilíbrio. Enquanto 92% das empresas pretendem ampliar o investimento em IA para marketing em 2026, metade não vai destinar recurso nenhum ao saneamento de dados nessa mesma área. Em vendas, 81% planejam ampliar o investimento e 40% seguem sem verba para saneamento.
O mesmo estudo mediu o gargalo estrutural. Falta integração entre ERP e CRM em 39% das empresas na área de marketing, número que sobe para 50% em vendas. Ou seja, a informação de venda mora em um sistema e a de faturamento mora em outro. Na prática, ninguém consegue responder uma pergunta simples sem exportar planilha.
O efeito aparece nos projetos. Um estudo da Fivetran, por exemplo, apontou que 42% das empresas enfrentaram atraso, baixo desempenho ou fracasso em mais da metade das suas iniciativas de IA por problemas de prontidão de dados. O Gartner, por sua vez, projeta que mais de 40% dos projetos de IA agêntica sejam cancelados até o fim de 2027. Custo crescente e dificuldade de demonstrar valor lideram as causas.
Há um contraponto útil no mesmo mercado. Segundo o Gartner, organizações com iniciativas de IA bem-sucedidas investem até quatro vezes mais, proporcionalmente à receita, em fundamentos como qualidade de dados, governança e gestão da mudança. O dinheiro não vai para o modelo. Vai para baixo dele.
Preparar dados para IA não significa arrumar tudo antes
Aqui mora o erro de rota mais caro. Assim que descobre que o problema é o dado, muita empresa parte para o projeto corporativo de governança, com comitê, inventário completo e cronograma de dezoito meses. Esse caminho quase sempre termina em nada, porque o negócio perde a paciência antes da primeira entrega.
A alternativa, portanto, é começar pelo domínio de dado que destrava o caso de uso de maior impacto. Um domínio é um recorte com dono claro: cadastro de cliente, histórico de atendimento, catálogo de produto, contratos vigentes. Escolhe-se um, arruma-se ele de verdade, valida-se o modelo de governança nesse escopo pequeno e só depois o trabalho se expande.
Vale lembrar de um detalhe que costuma passar despercebido. Mais de 80% da informação corporativa é dado não estruturado, ou seja, contrato em PDF, e-mail, transcrição de reunião, foto de nota fiscal. Esse acervo é justamente o que a IA lê melhor que qualquer sistema anterior, contanto que alguém o organize e o torne pesquisável.
A AI Infinity ajuda sua empresa a identificar o que precisa ser organizado, integrado e documentado para transformar demonstrações que funcionam em operações que se sustentam.
Preparar dados para IA: as quatro peças que faltam
Nenhuma delas é exótica, e todas custam menos no começo do projeto do que no meio dele.
Dono do domínio. Uma pessoa da área de negócio responde pela qualidade daquele conjunto de dados. Sem dono, aliás, o dado se degrada de novo em poucos meses, mesmo depois de limpo.
Regra de qualidade escrita. Qual formato o campo aceita, o que fazer com registro duplicado, quando o cadastro é considerado completo. São decisões de negócio, não de tecnologia.
Integração real. Sistemas conversando por API, isto é, com um identificador único que permite ligar o cliente do CRM ao pedido do ERP. Exportação manual de planilha não conta como integração.
Métrica definida antes de desenvolver. O que exatamente vai melhorar, medido como e comparado com qual linha de base. Sem métrica anterior ao desenvolvimento, qualquer avaliação depois vira opinião, e a empresa perde a capacidade de justificar o investimento.
Quem paga a conta de preparar dados para IA
Esse trabalho tem um problema político: ninguém quer patrociná-lo. Preparar dados para IA não rende slide bonito, não tem demonstração encantadora e não cabe em uma reunião de trinta minutos. Por isso a tarefa fica sempre para depois, enquanto o orçamento vai para a próxima ferramenta.
A AI Infinity trata essa etapa como parte do trabalho, e não como pré-requisito que atrasa a entrega. As três primeiras fases do Ciclo Infinity fazem exatamente isso. Examinar avalia o estado atual e mede a maturidade digital. Visualizar mapeia o processo como ele acontece de fato, com seus atores, decisões e desperdícios. Ordenar prioriza as oportunidades por impacto contra esforço, colocando as vitórias rápidas na frente.
A diferença prática está em quem faz. Um time que opera dentro da empresa lida com o dado real, ou seja, com a exceção que só o gerente conhece e com o campo que a equipe preenche errado desde 2019. Consultoria que trabalha de fora recebe o dado que a empresa consegue exportar, que raramente é o mesmo.
FAQ: Preparar dados para IA
1. Como distinguir um problema de dado de um problema de modelo quando o piloto erra?
Um teste simples separa os dois. Pegue vinte casos em que o sistema errou e verifique se um funcionário experiente, olhando exatamente a mesma informação que o modelo recebeu, acertaria. Se a pessoa também erraria, porque faltava contexto, o campo estava vazio ou a regra não estava registrada em lugar nenhum, o problema é de dado. Se a pessoa acertaria com folga, aí sim vale investigar o modelo, a instrução ou a forma de recuperação da informação. Uma coisa, no entanto, precede a outra. Na prática, boa parte dos erros classificados como alucinação são casos em que o sistema simplesmente não tinha acesso ao dado necessário para responder.
2. O conhecimento que só existe na cabeça das pessoas dá para transformar em dado?
Dá, e essa costuma ser a etapa de maior retorno, embora seja a mais ignorada. O caminho não é pedir para alguém escrever um manual, porque manual escrito do zero fica genérico e desatualiza rápido. Funciona melhor a extração a partir de casos reais: pegue decisões já tomadas, entreviste quem decidiu sobre o porquê de cada uma e registre o critério em formato consultável. Duas coisas mudam com isso. Primeiro, a regra passa a existir fora da pessoa, o que reduz o risco de saída dela. Segundo, ela vira contexto que o sistema consegue usar, e é essa diferença que separa um agente que responde bem de um que responde por eliminação.
3. Qual a diferença entre limpar dados para relatório e preparar dados para IA de fato?
Relatório tolera imperfeição que a IA não tolera, uma vez que o ser humano corrige mentalmente o que vê. Um dashboard com 3% de registro duplicado ainda aponta a tendência certa, e o gestor ignora o ruído. Um agente que decide caso a caso trata cada registro como verdade e propaga o erro individual. Há também um requisito adicional que relatório nunca exigiu: a informação precisa ser pesquisável por significado, com metadado que diga o que aquele documento é, de quando ele é e a que cliente pertence. Por isso empresa com dashboard maduro ainda pode ter base despreparada para IA.
4. Se a base está ruim, faz sentido começar por processo interno em vez de atendimento ao cliente?
Faz, e por dois motivos que se reforçam. O primeiro é tolerância a erro: um agente que ajuda o time interno a achar informação em contrato erra sem gerar dano externo, então a organização aprende sem expor a marca. O segundo é que processo interno produz, como subproduto, exatamente a documentação e a estrutura de dado que o caso externo vai exigir depois. Existe um contraponto honesto, porém. Projeto interno gera menos visibilidade e por isso perde patrocínio mais rápido, então ele precisa de métrica clara desde o início para sobreviver à primeira revisão de orçamento.
5. Como avaliar se um fornecedor está vendendo solução sobre uma base que não existe?
Três perguntas costumam revelar isso na primeira reunião. Pergunte quais fontes de dado a solução precisa acessar e em qual formato, porque resposta vaga aqui indica que ninguém olhou os sistemas ainda. Pergunte o que acontece quando o dado necessário está ausente ou contraditório, já que a resposta correta envolve o sistema recusar e escalar, e não improvisar. Por fim, peça a métrica de sucesso definida antes do desenvolvimento, com a linha de base atual medida. Fornecedor que promete resultado sem ter medido o ponto de partida está vendendo expectativa.
