85% dos projetos de IA fracassam: a diferença entre piloto e resultado está nos dados

Por Pedro Almeida

“O fracasso de um projeto de IA raramente é culpa da máquina. É quase sempre um espelho do que a empresa ainda não arrumou em casa.”

O problema central dos projetos de inteligência artificial não está no piloto, mas na passagem para a rotina. Uma demonstração pode funcionar com dados limpos, atenção da equipe e um problema escolhido a dedo. O resultado financeiro aparece somente quando o sistema recebe informação incompleta, entra no processo real e muda uma decisão repetida. É nessa travessia que a promessa perde força. Os 85% associados ao Gartner resumem o alerta, mas os estudos mais recentes apontam uma explicação mais útil para o empreendedor: dados, processo e responsabilidade precisam ser preparados juntos.

A pergunta, portanto, não deveria ser qual ferramenta comprar. Deveria ser qual processo tem dados suficientes, dono definido e uma métrica que possa ser comparada antes e depois. Sem essa resposta, o piloto vira apresentação, não investimento.

O número de 85% alerta, mas não mede todos os projetos da mesma forma

Vale separar as métricas antes de tirar uma conclusão. Os 85% vêm de uma previsão do Gartner frequentemente citada no mercado para descrever projetos que não entregariam os resultados esperados por problemas de dados, algoritmos ou equipes. O percentual não é uma taxa única calculada sobre todos os projetos de IA existentes. A utilidade do número está em mostrar o risco de tratar uma tecnologia complexa como uma compra simples.

O dado oficial mais recente do Gartner ajuda a localizar o gargalo. Em fevereiro de 2025, a consultoria informou que 63% das organizações não tinham, ou não sabiam se tinham, práticas de gestão de dados adequadas para IA. O levantamento ouviu 1.203 líderes de gestão de dados em julho de 2024. A própria consultoria recomenda definir o que significa dado pronto para cada uso, verificar representatividade, erros e exceções e manter metadados para acompanhar a qualidade.

Essa definição muda a conversa. Uma base com milhares de registros pode continuar inadequada se mistura clientes ativos e encerrados, usa nomes diferentes para a mesma categoria ou não registra o resultado da decisão que o modelo precisa apoiar. O volume ajuda pouco quando ninguém sabe de onde veio a informação, com que frequência ela muda e quem corrige o erro.

O piloto morre quando a empresa tenta esconder o processo que o sustenta

O relatório The GenAI Divide: State of AI in Business 2025, produzido pela iniciativa NANDA do MIT, encontrou um contraste entre experimentação e resultado. Segundo os dados divulgados sobre o estudo, apenas cerca de 5% dos programas analisados conseguiram produzir aceleração rápida de receita. Para a grande maioria, o uso ficou sem impacto mensurável no resultado financeiro. A pesquisa combinou entrevistas com líderes, uma sondagem de funcionários e análise de implantações públicas, em vez de olhar somente para demonstrações de fornecedores.

O ponto não é que cinco em cada cem pilotos sejam inúteis. Um teste pode ensinar qual hipótese deve ser abandonada, qual dado falta ou qual etapa precisa ser redesenhada. O problema surge quando a empresa chama de sucesso uma prova que nunca recebeu uma meta operacional. Se ninguém definiu tempo de atendimento, margem, conversão, erro ou custo de retrabalho, qualquer resposta do sistema parece promissora.

O levantamento da S&P Global Market Intelligence reforça a diferença entre adoção e entrega. Na pesquisa Voice of the Enterprise: AI & Machine Learning, citada em reportagem do CIO Dive, a parcela de empresas que abandonaram a maioria das iniciativas de IA subiu de 17% para 42% em um ano. A mesma apuração informou que a organização média descartou 46% das provas de conceito antes da produção. São medidas diferentes: 42% descreve empresas que abandonaram a maior parte das iniciativas, enquanto 46% é a média de provas de conceito interrompidas. Não dá para somar os dois percentuais como se fossem a mesma taxa.

A fonte oficial da S&P também apontou qualidade de dados e limitações de orçamento como causas líderes do abandono, seguidas por problemas de desempenho da infraestrutura. O recado é direto para a pequena empresa: o projeto pode falhar antes do modelo ser avaliado, porque o custo de organizar a operação ficou fora do orçamento original.

O caso da Guardian mostra o valor de medir a passagem para a escala

O MIT Center for Information Systems Research oferece um caso concreto para entender a transição. A Guardian Life Insurance Company of America registrou receita de US$ 14,5 bilhões e lucro operacional de US$ 2,4 bilhões em 2024, segundo o briefing do centro. A empresa usou uma estrutura para acompanhar iniciativas de IA desde a hipótese até o piloto e a escala, com foco em atendimento, eficiência e produtividade.

Um exemplo citado no mesmo material foi a automação do processo de solicitação de propostas e cotações. Uma tarefa que levava de cinco a sete dias passou a ser concluída em 24 horas. O número importa porque descreve uma mudança no fluxo de trabalho, e não somente uma resposta mais rápida de um modelo. A equipe precisou escolher o processo, acompanhar o tempo, envolver as áreas responsáveis e criar uma forma de decidir se o teste merecia expansão.

O briefing também descreve o WorkOnSite, solução de IA usada pela empresa Bludigit para gestão remota de obras. O caso é apresentado com três indicadores: aceleração de 40% na conclusão de projetos, redução de 80% nas inspeções e melhoria de segurança. Esses números não significam que qualquer negócio obterá o mesmo efeito. Eles mostram a forma correta de apresentar um caso: nome da solução, atividade afetada e medida observada.

Para um empreendedor, a lição está no desenho da comparação. Antes do sistema, quantas horas eram necessárias? Quantos erros apareciam? Quantas inspeções eram feitas? Depois da mudança, qual período foi observado? Sem uma linha de base, a empresa só tem uma impressão. Com uma linha de base, consegue decidir.

A pesquisa do MIT mostra que a escala exige outro tipo de empresa

O MIT CISR organizou a maturidade empresarial em quatro estágios. O primeiro reúne empresas que experimentam e se preparam. O segundo concentra a construção de pilotos e capacidades. O terceiro desenvolve formas de trabalho escaláveis com IA. O quarto trata de inovação contínua e novas receitas. O estudo de 2025 ouviu 152 empresas na pesquisa Real-Time Business Survey e acrescentou entrevistas com executivos.

Há uma mudança importante na distribuição. Em 2022, 31% das empresas estavam no estágio 3 e 7% no estágio 4. Em 2025, os percentuais passaram para 46% e 18%. Minha conta, cruzando os dois estágios de escala, é esta: a participação de empresas nos estágios 3 e 4 subiu de 38% para 64%, um avanço de 26 pontos percentuais. A conta não prova que a IA causou melhora financeira em cada empresa, mas mostra como a pesquisa define a passagem do experimento para formas de trabalho mais maduras.

O próprio estudo relaciona os estágios avançados a desempenho acima da média do setor. No estágio 1, o indicador de crescimento estava 26,5 pontos percentuais abaixo da média em 2025; no estágio 4, estava 13,9 pontos acima. No lucro, os extremos foram 15,1 pontos abaixo e 9,9 pontos acima. O resultado sugere que a diferença não está em testar ou não testar, e sim em construir capacidade para repetir o que funciona.

Essa capacidade inclui estratégia, sistemas, sincronização de pessoas e acompanhamento. A área de negócio precisa dizer qual decisão quer melhorar. A equipe técnica precisa saber de onde vem o dado e como monitorar o sistema. Quem executa a rotina precisa conseguir corrigir registros e contestar uma resposta ruim. O gestor precisa estabelecer o critério de parada, em vez de defender o projeto por causa do dinheiro já gasto.

McKinsey separa uso frequente de impacto no resultado

A pesquisa global da McKinsey ajuda a evitar outro erro de interpretação. Em 2025, 88% dos respondentes disseram que suas organizações usavam IA regularmente em pelo menos uma função. Apesar da adoção ampla, aproximadamente um terço informou que a empresa havia começado a escalar programas de IA. Apenas 39% relataram impacto no EBIT no nível da empresa.

Esses percentuais convivem sem contradição. Uma ferramenta pode ser usada todos os dias por uma equipe e ainda não alterar o lucro total, porque o ganho é pequeno, o custo de implantação é alto ou o processo seguinte continua lento. O efeito local não chega ao caixa se a organização não remove o gargalo que vem depois.

A McKinsey encontrou também uma associação entre alto desempenho e redesenho de fluxos de trabalho. As empresas que extraem mais valor usam IA para crescimento e inovação, além de eficiência, e muitas estão reorganizando a maneira como o trabalho acontece. Em outra análise da consultoria, empresas de alto desempenho, definidas pelo peso da IA no EBIT, eram três vezes mais propensas a promover uma mudança ampla no modelo operacional e duas vezes mais propensas a redesenhar o fluxo antes de escolher a ferramenta.

Isso explica por que copiar o chatbot de uma concorrente raramente reproduz o resultado. A tecnologia pode ser parecida, mas o caminho do pedido, a qualidade do cadastro, o poder de decisão da equipe e a forma de medir o atendimento são diferentes.

O orçamento precisa incluir dados, treinamento e manutenção

O custo de um projeto de IA não termina na assinatura da ferramenta. Há trabalho para limpar e classificar dados, integrar sistemas, criar permissões, revisar respostas e treinar quem vai usar o resultado. Também existe o custo de acompanhar a qualidade depois que o sistema entra em produção. Uma base muda, o comportamento do cliente muda e uma regra que funcionava em janeiro pode gerar erro em julho.

Uma pesquisa da Deloitte com 1.854 executivos da Europa e do Oriente Médio, apoiada por 24 entrevistas, encontrou uma diferença entre investimento e retorno. A maioria das organizações aumentou o investimento em IA, mas os retornos de um caso de uso típico demoravam de dois a quatro anos para aparecer. Apenas 6% dos entrevistados disseram obter retorno em menos de um ano. O dado não deve ser usado para prometer prazo ao pequeno negócio. Ele serve para colocar expectativa e payback na mesma conversa.

O empreendedor pode reduzir o risco escolhendo uma tarefa com começo e fim claros. Resumir pedidos recebidos em um canal, classificar chamados por motivo ou localizar informações em documentos internos são exemplos de escopo controlável. A primeira versão deve ter uma pessoa responsável por revisar o resultado e uma regra objetiva para interromper o teste se o erro ou o custo ultrapassar o limite.

O que o dono de negócio faz na segunda-feira

Na segunda-feira, escolha uma rotina que consuma tempo toda semana e escreva o processo em uma página. Registre quem inicia a tarefa, quais dados entram, qual decisão sai, quanto tempo ela leva e onde ocorrem os erros. Não comece pela ferramenta. Comece pelo mapa do trabalho.

Depois, faça uma amostra manual com 30 casos reais do último período disponível. Conte quantos registros estão completos, quantos precisam de correção e qual resultado seria considerado bom. Se os dados não permitirem identificar o problema, o primeiro projeto deve ser organizar a base, não treinar um modelo.

Em seguida, defina três números: a linha de base, a meta e o limite de perda aceitável. Para atendimento, pode ser tempo médio, taxa de encaminhamento e quantidade de retrabalho. Para vendas, pode ser tempo até a proposta, conversão e margem. Para estoque, pode ser ruptura, excesso e tempo de reposição. A métrica precisa existir antes do piloto.

Faça um teste curto com um único fluxo, mantenha revisão humana e registre cada erro. Ao fim do período, compare os números com a linha de base. Se houver ganho, calcule o custo de manter a solução por mês e identifique quais dados e pessoas serão necessários para ampliar. Se não houver ganho, encerre o teste, documente o motivo e use o aprendizado para escolher o próximo problema.

O projeto que escapa da estatística dos fracassos não é o que parece mais futurista. É o que consegue provar uma melhora em uma rotina real, com dados que a equipe entende e uma pessoa que responde pelo resultado. A inteligência artificial entra depois dessa decisão. O trabalho de preparação é o que transforma um piloto em operação.

Fontes consultadas

• Gartner, Lack of AI-Ready Data Puts AI Projects at Risk
• MIT CISR, Grow Enterprise AI Maturity for Bottom-Line Impact
• S&P Global Market Intelligence, Generative AI Outlook: From Hype to Value
• McKinsey, The State of AI: Global Survey 2025
• Deloitte, AI ROI: The paradox of rising investment and elusive returns
• CIO Dive, AI project failure rates are on the rise: report