Por que projetos de IA falham, e a correção prática para cada causa

Por que projetos de IA falham: o que dizem as pesquisas?

As pesquisas concordam que a maioria dos projetos trava entre o piloto e a produção, e que o modelo raramente é o motivo. O MIT NANDA informou em julho de 2025 que 95% das organizações não viram retorno mensurável no resultado financeiro com IA generativa, e apontou fluxos de trabalho frágeis, ferramentas que não aprendem com o contexto e pouca aderência ao trabalho do dia a dia.

O relatório da BCG de outubro de 2025 sobre a crescente lacuna de valor da IA constatou que só uma pequena minoria das empresas obtém valor com IA em escala. Segundo uma pesquisa da S&P Global Market Intelligence, uma parcela crescente das empresas abandonou a maioria das suas iniciativas de IA em 2025, citando custo, privacidade de dados e segurança. O Gartner previu em junho de 2025 que mais de 40% dos projetos de IA agêntica serão cancelados até o fim de 2027 por causa de custo, valor pouco claro ou controles de risco fracos, e alertou para o agent washing.

Lidas em conjunto, essas conclusões apontam sete causas. As seções abaixo tratam de uma por vez, cada uma com a correção que aplicamos.

Causa 1: ninguém mediu o ponto de partida

Um projeto não consegue mostrar valor se ninguém registrou como o trabalho funcionava antes dele. O valor pouco claro citado pelo Gartner muitas vezes é exatamente isso: o sistema funciona, mas não há um número anterior para comparar, então a revisão do orçamento não tem a que recorrer.

A correção é medir antes de construir. Para o fluxo escolhido, registre minutos por tarefa, tarefas por mês, a taxa de erros ou retrabalho e quem faz o trabalho. Combine a meta nas mesmas unidades (por exemplo, tempo de lançamento de notas fiscais e a porcentagem de notas que precisam de correção) e coloque a comparação em um relatório mensal a partir do lançamento.

Se ainda não for possível medir a linha de base, passe duas semanas registrando-a manualmente antes de financiar a construção. É barato e muitas vezes mostra que o gargalo real está em outro lugar, não onde todos supunham.

Causa 2: o fluxo de trabalho quebra com entradas reais

Fluxos de trabalho frágeis, a primeira causa citada pelo MIT NANDA, normalmente vêm de testes com amostras arrumadas. As entradas reais incluem PDFs digitalizados, cadeias de e-mails encaminhados, pessoas que mudam de assunto no meio da ligação e registros que já existem no CRM com um nome ligeiramente diferente.

A correção é um conjunto de avaliação montado com exemplos reais e bagunçados, com respostas corretas conhecidas, rodado de novo após cada mudança em prompts, recuperação ou modelo. Acrescente validação por campo (totais que precisam bater, datas que precisam estar no intervalo, IDs que precisam existir no NetSuite ou no QuickBooks) e um limite de confiança que envie os itens duvidosos para uma fila de revisão humana em vez de chutar.

• Conjunto de avaliação tirado dos últimos meses de entradas reais, incluindo as falhas.
• Regras de validação em cada campo gravado em um sistema de registro.
• Fila de revisão humana para tudo o que ficar abaixo do limite de confiança.

Causa 3: a ferramenta fica fora do trabalho diário

A pouca aderência ao trabalho do dia a dia, terceira causa do MIT NANDA, aparece como uma janela de chat ou um dashboard separado que as pessoas precisam lembrar de abrir. Em semanas elas param de abrir, e o uso cai silenciosamente a zero.

A correção é entregar o resultado onde o trabalho já acontece: um rascunho de resposta dentro do chamado do Zendesk, um registro preenchido no HubSpot ou no Salesforce, uma conta de fornecedor aguardando aprovação no ERP, um resumo publicado no canal que a equipe já usa. Um dos nossos estudos de caso mostra o mesmo princípio sem chatbot nenhum: um prestador de serviços de terapia levou os terapeutas para um portal guiado no AppSheet com validação e sincronização com o faturamento, a digitação de dados caiu de 10-15 minutos por dia para menos de 3 e os erros foram barrados na origem.

Causa 4: o sistema não aprende com o contexto

Um sistema que responde a partir de um prompt congelado continua cometendo os mesmos erros, e é por isso que ferramentas que não aprendem com o contexto entraram na lista do MIT NANDA. As políticas mudam, as tabelas de preço são atualizadas e a equipe corrige o mesmo erro toda semana sem nenhum efeito.

A correção tem duas partes. Primeiro, ancorar as respostas nos documentos atuais da empresa por meio de recuperação com citações, para que atualizar um arquivo no SharePoint ou no Google Drive atualize a resposta e um revisor possa ver a fonte. Segundo, fechar o ciclo: cada correção feita na fila de revisão é registrada, adicionada ao conjunto de avaliação e usada para ajustar prompts ou regras em uma rotina regular.

Para agentes de voz, a mesma ideia vale para as transcrições: as ligações em que o agente transferiu, entendeu errado ou perdeu a pessoa são o melhor material de treinamento para a próxima rodada de mudanças em prompts e encaminhamento.

Causa 5: os custos crescem mais rápido que o valor

O custo é o motivo que aparece tanto nas conclusões da S&P Global quanto nas do Gartner. As contas baseadas em uso, de tokens de modelo e minutos de voz, sobem com o volume, e um agente preso em um loop pode gastar em uma tarde mais do que a sua tarefa valia.

A correção é embutir o orçamento no sistema. Defina um teto de custo por tarefa que interrompa a execução e alerte alguém, registre tokens e minutos por tarefa desde o primeiro teste, direcione classificações simples a um modelo menor e reserve o maior para o raciocínio de verdade, e revise todo mês o custo por tarefa em relação ao valor por tarefa. Nosso guia de custos de implementação de IA lista os componentes de custo de operação a acompanhar.

Causa 6: preocupações com privacidade e segurança param a implantação

Privacidade de dados e segurança são os outros motivos citados pela pesquisa da S&P Global, e costumam aparecer tarde, quando o jurídico ou a TI veem o desenho pela primeira vez. Um piloto construído em uma conta de chat de consumo não pode ir para produção com dados de clientes ou pacientes.

A correção é resolver o tratamento de dados nas primeiras semanas. Use planos de API ou corporativos cujos termos se encaixem nos seus dados, obtenha um Business Associate Agreement assinado de cada fornecedor que toque informações de saúde protegidas, dê ao sistema só o acesso mais restrito de que ele precisa e registre cada prompt e resultado. Os clientes são donos das contas, então os dados ficam sob contratos que eles controlam.

Traga a TI e o jurídico para a análise antes da construção, não depois. Um fluxo de dados de uma página mostrando quais sistemas são lidos, quais são gravados, quais fornecedores veem os dados e onde os logs ficam responde à maioria das perguntas deles desde cedo.

Causa 7: agentes agem sem controle suficiente

Controles de risco fracos são o terceiro motivo na previsão de cancelamentos do Gartner, e os agentes elevam o risco porque executam ações, e não apenas escrevem texto. O agent washing agrava o problema: produtos vendidos como agentes autônomos que na verdade são scripts simples, ou que agem com muito mais liberdade do que o comprador percebeu.

A correção é delimitar o que um agente pode fazer. Liste as ferramentas dele explicitamente, dê a cada ferramenta a permissão mínima, exija aprovação humana para tudo o que movimenta dinheiro, contata um cliente ou altera registros regulados, e mantenha um caminho de rollback que possa desligar o agente e devolver o trabalho às pessoas. Ao avaliar um fornecedor, peça para ver as chamadas de ferramentas e os logs de uma execução real, e não só a resposta final.

Construir internamente ou com um parceiro especializado?

O MIT NANDA informou que projetos comprados de parceiros especializados ou construídos com eles tiveram sucesso com mais frequência do que os internos. A mesma pesquisa constatou que os maiores retornos vieram da automação de retaguarda, embora os orçamentos pendessem para vendas e marketing.

Seja qual for o caminho, o que importa são as correções acima. Definimos o escopo de cada projeto em uma análise gratuita, cobramos um preço fechado pela construção e entregamos o código, os prompts e as contas para que a sua equipe possa operar. Nosso guia de roadmap de implementação apresenta as fases em ordem.