40% dos Projetos de Agentes de IA Vao Ser Cancelados

Fonte: Unsplash

A previsão de que boa parte dos projetos de agentes de IA vai ser cancelada antes de chegar em produção não vem de quem odeia tecnologia. Vem de quem já viu o mesmo filme antes: em automação de processos, em projetos de big data, em migrações para nuvem. A tecnologia nunca foi o gargalo. O gargalo é quando o projeto nasce sem dono claro, sem limite de escopo e sem acordo sobre o que significa "deu certo".

Se você está colocando um agente para rodar — ou defendendo o orçamento de um — vale entender as causas de fracasso antes de escrever a primeira linha de fluxo. Elas raramente são técnicas, e quase sempre aparecem nas mesmas quatro frentes.

Expectativa de motorista autônomo, escopo de piloto assistido

É o cenário mais comum: a apresentação promete um colega virtual que "resolve o setor", e o projeto começa com um caso de uso do tamanho de um andar. Na primeira semana, o agente erra um cálculo, responde algo estranho fora do contexto ou trava numa exceção que ninguém tinha previsto. A confiança cai, o patrocínio esfria e o projeto vira "projeto em estudo" — que é o nome bonito para cancelado.

O problema é de amarração entre três coisas que quase nunca são alinhadas na kickoff:

O que a diretoria espera: redução de custo, velocidade, atendimento 24 horas.
O que a ferramenta entrega hoje: execução confiável dentro de um escopo treinado e documentado.
O que o time consegue operar: manutenção, monitoramento e revisão com a equipe que já existe.

Quando essas três listas não são escritas lado a lado, cada parte imagina um projeto diferente. E projetos diferentes não convergem sozinhos.

Escopo aberto demais: "quanto mais abrangente, melhor"

Escopo aberto é a forma elegante de adiar a decisão de priorizar. Em vez de escolher um fluxo, escolhe-se "todo o atendimento" ou "a área financeira inteira". O resultado previsível: o agente precisa entender dezenas de exceções de uma vez, e o time gasta mais tempo lidando com falhas do que medindo ganho.

O corte certo costuma doer um pouco. Um bom escopo inicial tem quatro características:

Volume alto e repetitivo — o tipo de tarefa que já acontece dezenas de vezes por dia.
Dados acessíveis e limpos — se a base está em cinco planilhas pessoais, o projeto nasce quebrado.
Baixo custo de erro — errar uma classificação interna é diferente de errar um valor pago.
Resultado mensurável sem rodeio — tempo por atendimento, taxa de retrabalho, quantidade de exceções.

Escopo que fecha esses quatro critérios dá resultado em semanas. Escopo que não fecha vira semestre de discussão.

Ninguém é dono do agente depois do launch

Pergunte em qualquer projeto travado quem é o responsável por revisar as saídas erradas na segunda-feira de manhã. O silêncio que vem depois costuma ser a resposta. Projetos de agente morrem no pós-lançamento porque foram tratados como entrega de software e não como operação contínua.

Agente não é produto que se encerra no deploy. Ele precisa de:

Um dono nomeado, com tempo alocado — não "o time" genérico.
Uma rotina de revisão de amostras das saídas, mesmo depois de tudo parecer estável.
Um canal de exceções: quando o agente não sabe, o que acontece? Cai para humano? Para fila? Para erro silencioso?
Um critério de desligamento definido antes de ligar — em que situação o fluxo é pausado.

Sem isso, a primeira onda de reclamação interna bate e o projeto perde proteção política. E projeto sem defensor some da pauta em duas reuniões.

Dados e integrações: a parte que ninguém estima

Metade do cronograma costuma sumir em tarefas que não parecem "IA": obter acesso, padronizar campo, tratar histórico inconsistente, convencer o dono do sistema a liberar integração. Um agente só é tão bom quanto a memória que ele consulta. Se a base de conhecimento tem resposta de 2022 e três versões do mesmo procedimento, a saída vai refletir essa confusão.

Um teste rápido antes de aprovar cronograma: escolha cinco perguntas reais que o agente precisará responder e procure a resposta manualmente nas fontes. Se você leva mais de dois minutos por pergunta, ou se encontra duas respostas conflitantes, o problema é documentação, não modelo. Resolver isso antes encurta o projeto; descobrir depois atrasa tudo.

Custo que ninguém acompanhou até a fatura

Existe também o fracasso por valor: o projeto funciona, mas custa mais do que o problema que resolve. Chamadas de modelo, retrabalho humano corrigindo saída, horas de engenharia mantendo integração frágil — tudo isso se acumula sem aparecer no dashboard inicial.

Manter um registro simples já evita a surpresa:

data | tarefas | custo estimado | correções humanas | exceções
05/08 | 412    | ...            | 31                | 9
06/08 | 398    | ...            | 27                | 6

Se as correções humanas não caem ao longo das semanas, você não tem um agente maduro — tem um processo caro disfarçado de automação. E é exatamente esse o tipo de dado que faz comitê cancelar projeto antes do fim do trimestre.

Governança que trava antes mesmo de começar

Às vezes o projeto não morre por fracasso técnico, e sim por nunca conseguir nascer: legal pede avaliação de risco, segurança pede revisão de acesso, área de dados pede comitê — e o agente vira bola de neve institucional. O erro não é ter governança; é construir a governança junto do projeto, e não depois.

Na prática, isso significa levar segurança e compliance para a primeira conversa, mostrar um prototipo limitado (leitura apenas, sem escrita em sistema de produção) e negociar critérios de aprovação em etapas. Projeto que chega no comitê com prototipo funcionando e escopo fechado aprova muito mais rápido do que projeto que chega só com slides.

As três perguntas que salvam o projeto

Antes de qualquer kickoff, escreva as respostas destas três frases em uma página só:

"Se der tudo certo, em 60 dias o que mudou na rotina de quem?" — resposta operacional, não numérica abstrata.
"Se o agente errar às 22h de um sábado, quem vê primeiro e o que faz?" — se não houver resposta, não lance.
"Qual é o sinal claro de que vale cancelar?" — definido antes evita arrastar um projeto morto por mais dois trimestres.

Projetos que respondem essas três frases com clareza têm muito mais chance de atravessar o primeiro contratempo — porque contratempo é garantido. A diferença entre quem passa e quem cai é ter decidido de antemano o que fazer quando a primeira coisa der errado.

E aí, fez sentido?

Conte nos comentários sua experiência com projetos de agentes de IA — e se o artigo te ajudou, compartilhe com alguém que precisa ler. 👇