Abandono de projetos de IA: 42% desistiram e o motivo não era o modelo

Em doze meses, a fatia de empresas que abandonou a maior parte das próprias iniciativas de inteligência artificial saltou de 17% para 42%. A leitura imediata é que a tecnologia decepcionou no intervalo. Os motivos documentados apontam para outro lugar: as empresas não pioraram em IA, ficaram mais rápidas em reconhecer que um projeto não ia chegar a lugar nenhum. O problema é que essa constatação continua chegando depois do dinheiro gasto.

Por que isso importa: desistir mais cedo é sinal de maturidade quando o critério de encerramento foi definido na aprovação. Quando não foi, o abandono é apenas o momento em que alguém perde a paciência, e a empresa já pagou por isso.

Os números

• De 17% para 42% foi o salto, em um ano, na fatia de organizações que abandonaram a maior parte de suas iniciativas de IA, segundo levantamento da S&P Global Market Intelligence com 1.006 respondentes na América do Norte e na Europa
• 46% das provas de conceito de IA foram descartadas, em média, antes de chegar à produção
• Custo, privacidade e riscos de segurança aparecem como os principais obstáculos citados pelas empresas
• Pelo menos 30% dos projetos de IA generativa seriam abandonados após a prova de conceito até o fim de 2025, na projeção que a Gartner publicou em julho de 2024, atribuída a qualidade de dado, controle de risco insuficiente, custo crescente e valor de negócio indefinido

Vale uma nota de data, porque o número circula sem ela. O trabalho de campo dessa pesquisa foi feito no fim de 2024. O retrato é real e é anterior à maior parte do que o mercado chama hoje de solução agêntica.

O que mudou não foi a tecnologia

Dobrar a taxa de abandono em um ano seria alarmante se a capacidade dos modelos tivesse regredido no período. Aconteceu o oposto. O que mudou foi a tolerância.

Em 2023 e 2024, projeto de IA parado sobrevivia por meses porque ninguém queria ser a pessoa que desligou a iniciativa de inovação da empresa. Em 2025, com orçamento sob escrutínio e conselho pedindo número, o mesmo projeto passou a ser encerrado em semanas.

Isso é progresso. Mas existem duas formas muito diferentes de encerrar um projeto, e de fora elas parecem iguais. Numa delas, o critério de saída estava escrito desde o começo: se o indicador não se mover até tal data, a iniciativa para. Na outra, alguém decide encerrar quando a conta chama atenção e não há resposta pronta sobre o que foi obtido.

A primeira é gestão de portfólio. A segunda é constrangimento. E é a segunda que domina os 42%.

As causas ficam todas antes da engenharia

Quando se olha o que os estudos identificam como raiz do problema, aparece um padrão incômodo para quem culpa o time técnico.

Os motivos recorrentes são: o problema nunca foi definido com clareza, o dado necessário nunca foi coletado pela organização, a decisão começou pela tecnologia em vez de começar pelo processo, não havia infraestrutura para rodar aquilo em produção, e a métrica de sucesso foi inventada depois que o orçamento já tinha sido comprometido.

Nenhuma dessas causas está ao alcance de quem entrega. Um time não reconstrói a definição de um problema que recebeu pronto, não fabrica um dado que a empresa nunca guardou, e não consegue provar resultado contra uma régua que apareceu no fim.

A análise mais citada nessa linha, da RAND, vem de entrevistas com cientistas de dados e engenheiros experientes, e sua contribuição real é justamente esse mapa de causas. Vale registrar que o percentual de fracasso frequentemente atribuído a ela é citação de literatura anterior presente no relatório, não medição feita pelo estudo. Em 14 de setembro, a StartSe abordou mais deste assunto no artigo "O 95% do MIT: o que o relatório realmente mediu".

O portão que quase ninguém desenha

Se as causas são anteriores à engenharia, a correção também é. E ela cabe em uma decisão de conselho.

A régua de sucesso precisa existir antes da escolha do fornecedor, não depois. Isso significa quatro definições escritas antes de qualquer contrato: qual resultado será medido, qual é o número dele hoje, qual é o alvo e em quanto tempo. As quatro juntas levam menos de uma reunião e resolvem ao mesmo tempo o problema da métrica inventada tarde e o do valor de negócio indefinido.

O segundo item é o critério de encerramento. Definido na aprovação, ele transforma o desligamento em cumprimento de regra, e não em derrota de alguém. Sem ele, cada projeto ruim custa a diferença entre o mês em que ficou claro que não funcionaria e o mês em que alguém teve coragem de dizer isso.

O terceiro é a ordem. Processo mapeado antes da ferramenta escolhida. Quase metade das provas de conceito que morrem antes da produção morrem porque nunca houve caminho até a produção, e isso era conhecido no primeiro dia.

Sinais e impactos

Para CEOs e conselhos. Vale exigir o critério de encerramento no mesmo documento que aprova o investimento. Aprovação sem condição de saída é cheque em aberto com prazo indeterminado.

Para C-levels e diretores. Antes da próxima prova de conceito, cabe uma pergunta só: existe caminho técnico e organizacional para isso rodar em produção? Se a resposta for incerta, o piloto já nasceu no grupo dos 46%.

Para donos de pequenas e médias. A vantagem do porte menor aqui é a distância curta entre quem decide e quem executa. A definição do problema chega ao time sem intermediário, que é justamente onde a maioria das causas se instala.

O ponto

O salto de 17% para 42% não é notícia sobre inteligência artificial. É notícia sobre como as empresas aprovam o projeto. Quem entra na próxima onda com problema definido, dado disponível, indicador medido antes e critério de encerramento escrito não elimina o risco de errar. Elimina o custo de demorar a descobrir.

Definir o problema, medir o antes, nomear o dono e escrever o critério de encerramento é o que separa portfólio de aposta. A Masterclass de IA da StartSe mostra como montar essa sequência antes de escolher qualquer ferramenta.

Garanta sua vaga na Masterclass de IA