Uma investigação do MIT de 2026 concluiu que cerca de 95 por cento dos projetos-piloto de GenAI nas empresas não produzem qualquer retorno mensurável na demonstração de resultados, e que cerca de 88 por cento nunca chegam a produção. A causa quase nunca é a qualidade do modelo. Cerca de 80 por cento do trabalho entre um piloto bem-sucedido e um sistema a funcionar é engenharia de dados, governação, integração no processo e medição — precisamente as partes que um piloto típico salta. As organizações que conseguem passar reportam cerca de 3,70 dólares por cada dólar gasto, começando perto dos 41 por cento no primeiro ano e chegando a cerca de 124 por cento ao terceiro.
Porque é que quase nenhum piloto chega à demonstração de resultados
O número de 95 por cento induz em erro se for lido como «os modelos não funcionaram». Na maioria dos casos o modelo funcionou bem. O que falhou foi que o piloto provou uma coisa enquanto a organização precisava de decidir outra.
Um piloto típico testa se o modelo consegue executar uma tarefa. A decisão que está por trás é se o processo de negócio vai mudar, quem vai deixar de fazer o quê, como se mede isso todos os meses e quem responde quando o sistema erra. São duas perguntas completamente diferentes, e é a segunda que aparece nas contas.
É também daqui que vem a conhecida divisão 80/20. A parte que parece o projeto — escolher um modelo, escrever prompts, fazer uma demonstração — é cerca de um quinto do trabalho. Os restantes quatro quintos são limpar e expor os dados, permissões e classificação da informação, ligar às ferramentas em que a equipa já trabalha, e construir a medição. Um piloto que não tocou em nenhuma destas quatro frentes não reduziu risco. Apenas o empurrou para a frente.
Um teste para fazer antes de começar. Escreva numa frase a decisão que será tomada no fim do piloto, e o número que a vai resolver. Se não conseguir escrever essa frase, o que está a preparar é uma demonstração, não um piloto. Demonstrações são legítimas — apenas não as orce como pilotos nem espere retorno delas.
O que os pilotos medem e o que deviam medir
Esta lacuna repete-se em quase todas as organizações, e é normalmente a razão pela qual o piloto teve sucesso e o projeto morreu.
| O que é realmente medido | Porque não chega | O que medir em vez disso |
|---|---|---|
| Precisão do modelo num conjunto de teste | O conjunto de teste foi construído a partir dos casos em que pensou, não do tráfego real | Taxa de sucesso numa amostra aleatória do último mês de tráfego real, incluindo os casos estranhos |
| Tempo poupado, tal como os utilizadores o estimam | As estimativas declaradas são sistematicamente inflacionadas e não aparecem em nenhuma rubrica orçamental | Tempo de ciclo ponta a ponta medido, antes e depois, na mesma classe de tarefa |
| Satisfação num inquérito | Mede o entusiasmo com a novidade, que decai ao fim de cerca de seis semanas | Taxa de regresso à sexta semana entre os utilizadores ativos na primeira |
| Custo de tokens durante o piloto | Reflete volume pequeno e casos convenientes | Custo por unidade de trabalho a volume pleno, incluindo repetições, recuperação e escalada humana |
| «A equipa adora» | Não distingue uma conveniência de algo sem o qual já não se consegue trabalhar | O que acontece se o desligar durante uma semana. É o único teste que não se pode falsear |
A última linha parece leviana mas é a mais forte da lista. Uma ferramenta que pode desligar durante uma semana sem uma única queixa não vai sobreviver ao orçamento anual, e não faz sentido investir-lhe mais um trimestre.
Quatro camadas de ROI, e só uma conta
Quando um diretor-geral pergunta qual é o retorno, há quatro respostas possíveis e não são equivalentes. Distingui-las é o que separa um piloto que volta a ser financiado de um que é encerrado.
| Camada | Exemplo | Aparece nas contas | Quando é legítimo |
|---|---|---|---|
| Horas poupadas | Cada operador poupa 40 minutos por dia | Não. As horas não desapareceram, mudaram para outra tarefa | Só quando consegue mostrar para onde foram as horas e o que saiu delas |
| Capacidade libertada | A mesma equipa trata mais 30 por cento de volume | Indiretamente, como crescimento que não exigiu contratações | Quando existe procura real para essa capacidade |
| Custo direto eliminado | Menos horas de prestadores, menos uma ferramenta externa, menos horas extraordinárias | Sim, de imediato | Sempre. É a camada mais fácil de defender |
| Receita acrescentada | Mais leads qualificados, ciclo de venda mais curto, menos abandono | Sim, com um desfasamento de um a dois trimestres | Quando há um grupo de controlo, ou pelo menos uma base histórica limpa |
A maioria dos pilotos reporta a primeira camada na esperança de que seja lida como a terceira. Faça o contrário: construa o piloto à volta da terceira ou da quarta camada, mesmo que o âmbito seja bem menor. Uma poupança anual provada de 40.000 dólares vale mais do que um milhão teórico.
Um piloto de seis semanas sobre o qual se consegue mesmo decidir
A estrutura que funciona é mais curta do que a maioria das organizações planeia e exige mais trabalho à cabeça.
Semana 1 — definir a decisão e a linha de base. A frase de decisão, o número que a resolve, e uma medição do estado atual exatamente nessa métrica. Sem uma linha de base medida não há nada com que comparar no fim, e este é, surpreendentemente, o passo mais vezes saltado.
Semanas 2 e 3 — a versão mais barata que responde à pergunta. Comprar antes de construir. Os dados de mercado mostram que começar a fase de prova com um componente pronto produz um ROI 3,2 vezes superior, e que construir antes de validar desperdiça em média cerca de 14 meses. Tratámos disto em construir ou comprar capacidade de IA.
Semanas 4 e 5 — tráfego real, utilizadores reais. Não um laboratório. Um grupo definido a trabalhar com a ferramenta no seu dia a dia, incluindo os casos feios e incluindo as escaladas.
Semana 6 — decidir. Alargar, estreitar ou encerrar. Os três desfechos têm de ser igualmente legítimos desde o primeiro dia, caso contrário o resultado é conhecido de antemão.
O orçamento de medição não é opcional. Aloque pelo menos 15 por cento do orçamento do piloto à medição em si: recolha da linha de base, amostragem manual semanal da qualidade, e acompanhamento do custo por unidade de trabalho. Um piloto sem orçamento de medição acaba numa discussão sobre impressões, e uma discussão sobre impressões resolve-se sempre a favor do statu quo.
Quando encerrar um piloto, e porque é que isso poupa dinheiro
Encerrar cedo não é um fracasso, é um mecanismo de retorno por direito próprio. Quatro sinais justificam parar antes da sexta semana.
- A taxa de sucesso em tráfego real está materialmente abaixo do conjunto de teste interno, e a diferença não fecha ao fim de duas rondas de correções. É quase sempre sinal de que os dados não estão num estado que suporte a tarefa.
- O custo por unidade de trabalho a volume pleno excede a alternativa humana. Preço, cache e encaminhamento podem alterar isso, mas se a diferença for um múltiplo em vez de dezenas de por cento, o problema é a arquitetura e não o preço.
- Os utilizadores voltam sozinhos ao processo antigo, sem que ninguém lhes peça. É o sinal mais precoce e mais honesto disponível.
- Ninguém vai assumir a responsabilidade do processo depois do piloto. Sem dono, nada chega a produção, por muito bons que sejam os números.
Uma organização que encerra dois pilotos por trimestre ao fim de seis semanas, em vez de os arrastar um ano, liberta orçamento para a terceira tentativa — e é exatamente esse o mecanismo que separa as organizações que reportam 3,70 dólares por dólar de todas as outras.
De onde vem a diferença entre 41 por cento e 124 por cento
Estes dois números descrevem as mesmas organizações em momentos diferentes, e a diferença entre eles não é um modelo melhor. São três coisas aborrecidas.
A primeira é o custo. A capacidade idêntica torna-se materialmente mais barata com cache, processamento em lote e encaminhamento entre modelos — empilhar os três corta uma fatura de inferência em 60 a 80 por cento sem mudar nada na experiência do utilizador. No primeiro ano paga preço cheio porque está a medir em vez de otimizar.
A segunda é o âmbito. O primeiro caso de uso resolve um problema. Ao terceiro ano a mesma infraestrutura, a mesma governação e a mesma classificação da informação servem cinco casos de uso, e o custo fixo divide-se. É por isso que o investimento na camada de dados parece caro demais no primeiro ano e parece óbvio ao terceiro.
A terceira é o próprio processo. No primeiro ano a ferramenta é acrescentada a um processo existente, por isso acrescenta custo antes de retirar algum. Só quando o processo é reescrito à volta dela — passos que desaparecem, aprovações que se fundem, papéis que mudam — é que aparece o grande retorno. As organizações que nunca chegam a essa fase ficam perto dos 41 por cento e concluem que a IA não compensou.
As três assentam na mesma base: um modelo de custo completo da funcionalidade, que expusemos em quanto custa mesmo uma funcionalidade de IA, e um preço ligado a essa estrutura de custos, de que falámos em preço de um produto assente num modelo. Se está a definir um piloto neste momento, fixe os critérios de aceitação na mesma reunião em que define a decisão.
Construir o dispositivo de medição e de decisão à volta de um piloto faz parte do trabalho de planeamento financeiro e de crescimento que fazemos com clientes.
Perguntas frequentes
Porque é que 95 por cento dos pilotos de IA falham?
Uma investigação do MIT de 2026 concluiu que cerca de 95 por cento dos pilotos de GenAI nas empresas não produzem qualquer retorno mensurável na demonstração de resultados e que cerca de 88 por cento nunca chegam a produção. A causa principal não é a qualidade do modelo mas o facto de o piloto ter testado uma capacidade técnica em vez de testar uma alteração ao processo de negócio. Cerca de 80 por cento do trabalho entre piloto e produção é engenharia de dados, governação, integração nas ferramentas existentes e medição — as partes que a maioria dos pilotos salta por completo.
Quanto tempo deve durar um piloto de IA?
Seis semanas chegam para decidir e são normalmente melhores do que seis meses. Uma semana para definir a decisão e medir a linha de base, duas semanas para a versão mais barata que responde à pergunta, duas semanas em tráfego real com utilizadores reais, e uma semana para decidir. Um piloto mais longo não produz mais certeza. Só torna o encerramento mais caro e politicamente mais difícil.
Como se mede o ROI de um projeto de IA?
Separe quatro camadas: horas poupadas, capacidade libertada, custo direto eliminado e receita acrescentada. Só as duas últimas aparecem na demonstração de resultados. Meça o estado atual exatamente na mesma métrica antes de começar, compare o custo por unidade de trabalho a volume pleno incluindo repetições e escalada humana, e aloque pelo menos 15 por cento do orçamento do piloto à medição em si.
Quando se deve encerrar um piloto mais cedo?
Quando surge qualquer um de quatro sinais: a taxa de sucesso em tráfego real está materialmente abaixo do conjunto de teste interno e não fecha ao fim de duas rondas de correções, o custo por unidade de trabalho é um múltiplo da alternativa humana, os utilizadores regressam por iniciativa própria ao processo antigo, ou ninguém vai assumir o processo depois de o piloto acabar. Encerrar depressa liberta orçamento para a tentativa seguinte, que é o verdadeiro mecanismo de retorno.
Porque é que o retorno sobe de 41 por cento no primeiro ano para 124 por cento ao terceiro?
Três razões, nenhuma delas sobre o modelo. O custo de inferência cai 60 a 80 por cento depois de empilhados cache, processamento em lote e encaminhamento entre modelos. O custo fixo de infraestrutura divide-se por mais casos de uso a correr sobre a mesma governação e os mesmos dados. E sobretudo, o processo de negócio é reescrito à volta da ferramenta em vez de a ferramenta ser enxertada num processo existente — enquanto isso não acontecer, a ferramenta acrescenta custo antes de retirar algum.
Para ler a seguir
Reduzir o custo de inferência em 60 a 80 por cento — é a alavanca que leva o retorno de 41 para 124 por cento: cache, processamento em lote e encaminhamento entre modelos.