Saltar para o conteúdo
SwankyForge
SwankyForge
Todos os artigos
Artigo9 min de leitura

Segundo uma contagem, 95% dos pilotos de IA não têm impacto na conta de resultados. Acorde a métrica antes de construir o modelo.

Quatro estudos de 2025 e do início de 2026 concordam que a maioria das empresas vê pouco retorno mensurável da IA, e que a falha mais comum está do lado do negócio, por isso a solução é uma métrica, uma referência e uma regra de decisão escritas antes de se construir o que quer que seja.

Em julho de 2025, o projeto NANDA do MIT publicou um relatório segundo o qual 95% das organizações estavam a obter retorno zero da IA generativa, apesar de 30–40 mil milhões de dólares de investimento empresarial. A Fortune pôs o número num título em agosto de 2025, e a partir daí ele espalhou-se.

O número é mais fraco do que a sua fama. Assenta em entrevistas a 52 organizações, num inquérito a 153 líderes seniores recolhido em quatro conferências do setor e numa análise de mais de 300 iniciativas públicas de IA. Os críticos consideraram a definição de sucesso demasiado restrita. Mas três outros estudos, com métodos diferentes, apontam na mesma direção: a maioria das empresas que usam IA ainda não a consegue encontrar nos seus resultados financeiros.

A nossa leitura é que a maioria destes pilotos ficou decidida antes de se treinar um modelo. Ninguém mediu uma referência, ninguém acordou uma métrica, ninguém no negócio era responsável pelo resultado e ninguém planeou como o resultado entraria no processo diário. São lacunas do negócio, e fechá-las custa dias de trabalho, não meses.

Quatro estudos, uma direção

Fonte Amostra O que foi medido Conclusão principal
MIT NANDA, julho de 2025 52 organizações entrevistadas, 153 líderes inquiridos, 300+ iniciativas públicas analisadas, janeiro–junho de 2025 Retorno autodeclarado da IA generativa 95% das organizações com retorno zero; 5% dos pilotos integrados a extrair milhões em valor
BCG, setembro de 2025 1.250 executivos seniores e decisores de IA Valor da IA em toda a empresa 5% geram valor substancial em escala; 60% reportam ganhos mínimos de receita e de custos
McKinsey, novembro de 2025 Inquérito global a organizações Impacto no EBIT ao nível da empresa 88% usam IA em pelo menos uma função; 39% reportam algum impacto no EBIT, e a maioria destes situa-o abaixo de 5% do EBIT
Working paper do NBER, fevereiro de 2026 Quase 6.000 executivos de empresas em quatro países Efeito no emprego e na produtividade nos últimos três anos 69% das empresas usam IA; nove em cada dez não reportam impacto no emprego nem na produtividade

As definições diferem. O MIT pergunta se uma implementação produziu retorno mensurável, o BCG distribui as empresas por grupos de maturidade, a McKinsey pergunta pelo EBIT e o inquérito do NBER pergunta pela produtividade e pelo número de trabalhadores. Nenhum deles é uma medição limpa do efeito da IA. Em conjunto, dizem que a adoção é ampla e que o retorno medido é raro.

Quanto confiar nos 95%

Menos do que os títulos sugerem, e o próprio relatório o diz. A sua secção de limitações afirma que os números são «direcionalmente corretos» e vêm de entrevistas individuais e não de relatórios oficiais das empresas, que as definições de sucesso variam entre organizações e que uma janela de observação de seis meses pode subestimar o sucesso de sistemas complexos. O sucesso foi definido como implementação para lá da fase piloto com KPIs mensuráveis, com o retorno avaliado seis meses depois do piloto. Para ferramentas específicas de uma tarefa, uma implementação bem-sucedida era aquela que os utilizadores ou executivos descreviam como tendo um efeito marcado e sustentado na produtividade ou na conta de resultados.

A crítica do Marketing AI Institute acrescenta que a definição ignora ganhos de eficiência, retenção e efeitos no pipeline comercial, e que 52 entrevistas não sustentam uma afirmação sobre todo o mercado. Os dois pontos são justos. Trate os 95% como um dado ruidoso, não como uma taxa de falha.

Duas partes do relatório resistem melhor do que o título. A primeira é o diagnóstico. Os autores escrevem que a divisão não parece ser causada pela qualidade dos modelos nem pela regulação, e que a maioria das implementações falha devido a fluxos de trabalho frágeis, à falta de aprendizagem contextual e ao desalinhamento com as operações do dia a dia. A segunda é o que fizeram os compradores bem-sucedidos: avaliaram as ferramentas por resultados operacionais e não por benchmarks de modelos, e deixaram os detentores de orçamento e os gestores do domínio escolher os problemas e liderar as implementações.

O relatório concluiu também que as parcerias externas chegaram à implementação em cerca de 67% dos casos, contra cerca de 33% nas construções internas. Somos um fornecedor, por isso temos interesse nesse número, e ele deve ser lido com a ressalva do próprio relatório: os números são autodeclarados, e as empresas que escolhem parceiros podem diferir noutros aspetos das que constroem internamente. É uma correlação.

Porque é que os pilotos estagnam

Na nossa opinião, quatro lacunas explicam a maioria dos pilotos estagnados, e nenhuma delas é técnica.

  1. Sem referência. «O tempo de tratamento caiu 20%» não significa nada se ninguém mediu o tempo de tratamento antes do piloto, com a mesma definição, num período comparável.
  2. Sem métrica acordada. A equipa de dados reporta a exatidão do modelo, as finanças perguntam pelo custo, as operações perguntam pelo débito. Cada lado escolhe o seu número depois do facto, e o piloto acaba numa discussão em vez de numa decisão.
  3. Sem responsável no negócio. Um piloto conduzido por uma equipa central, sem ninguém do lado do negócio que controle o orçamento ou o processo, não tem quem o implemente quando funciona.
  4. Sem caminho para o processo. O modelo funciona num sandbox, mas ninguém mudou o ecrã que as pessoas usam, a ordem dos passos nem os objetivos pelos quais são avaliadas. Um resultado que chega fora do fluxo de trabalho é ignorado.

Para o responsável pelo orçamento: uma página antes de construir o que quer que seja

Antes de mover quaisquer dados ou escolher qualquer modelo, escreva uma página com seis linhas.

  • Métrica. Um número com que o negócio já se importa, com uma definição exata.
  • Referência. O seu valor atual, numa janela indicada, calculado pela consulta que o piloto vai usar.
  • Regra de decisão. Que resultado significa implementar e qual significa parar.
  • Salvaguardas. O que não pode piorar enquanto a métrica melhora.
  • Responsável. A pessoa no negócio que vai mudar o processo se o piloto funcionar.
  • Data de decisão. O dia em que a decisão é tomada, seja qual for o resultado.

Um exemplo ilustrativo para um copiloto de suporte que redige respostas a tickets de primeira linha:

Linha Entrada ilustrativa
Métrica Tempo mediano de tratamento por ticket de primeira linha
Referência Medida nas quatro semanas anteriores ao piloto, nas mesmas categorias de tickets
Regra de decisão Implementar se a mediana cair 10% ou mais; parar se cair menos de 3%
Salvaguardas Taxa de reabertura e satisfação do cliente a menos de um ponto da referência
Responsável Diretor de suporte
Data de decisão Seis semanas após o lançamento

Se acordar esta página demorar mais de uma semana, o problema não está pronto para IA. Por vezes, escrevê-la mostra que a métrica pode ser movida com uma regra ou um relatório, e então a resposta mais barata é a certa.

Para engenheiros: tornar a métrica sólida

Aleatorize na unidade onde o efeito acontece. Num copiloto de suporte, essa unidade é o agente ou a equipa, não o ticket, se de outra forma os agentes aprenderiam com o copiloto e mudariam a forma como tratam os tickets de controlo. Para processos operacionais que não podem ser divididos ao mesmo tempo, alterne períodos com um desenho switchback. Mantenha um pequeno grupo de controlo após a implementação para ver se o efeito se desvanece.

Meça a referência com o próprio pipeline do piloto. A mesma consulta, os mesmos filtros, a mesma duração de janela. Faça primeiro uma comparação A/A, dividindo o tráfego sem aplicar qualquer alteração, para ver quanto a métrica se move por si só. Métricas sazonais precisam de um grupo de controlo simultâneo; uma comparação antes-e-depois vai misturar o piloto com o calendário.

Dimensione o teste antes de começar. Para dois grupos com 80% de potência e 5% de significância, uma regra prática comum é n por grupo ≈ 16·σ²/δ², em que σ é o desvio-padrão da métrica e δ é o menor efeito que vale a pena detetar. Números ilustrativos: se o tempo de tratamento tiver um desvio-padrão de 6 minutos e o efeito que importa for 0,6 minutos, n ≈ 16 × 36 / 0,36 = 1.600 tickets por grupo. Uma equipa que trata 200 destes tickets por semana precisa de 16 semanas para recolher 3.200. É o momento de escolher um efeito maior, um piloto mais longo ou uma métrica menos ruidosa, por exemplo ajustando pelo tempo de tratamento de cada agente no período anterior. Os tempos de tratamento são assimétricos, por isso compare medianas ou valores com transformação logarítmica, ou use bootstrap para o intervalo.

Ponha a métrica no contrato. A definição, a fonte de dados, a consulta, a janela e o limiar entram no caderno de encargos como critério de aceitação do marco. Aceitar passa então a significar correr a consulta acordada, não debater se o sistema parece útil.

Escreva o critério de paragem antes do lançamento. Se o efeito na data de decisão estiver abaixo do limiar, o piloto para. Verificar o resultado todos os dias e parar quando parece bom inflaciona os falsos positivos; se espreitar mais cedo for inevitável, use um teste sequencial desenhado para isso.

Como trabalhamos com isto

Acordamos a métrica antes de treinar qualquer modelo, e ela entra no contrato como critério de aceitação. Os marcos só são faturados depois da aceitação, por isso é a métrica que decide a fatura. Um engenheiro nomeado fica no projeto do início ao fim, o que evita que a definição da métrica se desvie entre passagens de testemunho. Quando a carta de uma página mostra que uma regra ou um relatório moveria a métrica por menos, dizemo-lo e desaconselhamos a compra de ML.

Na nossa tabela de tarifas, uma fase de descoberta custa 6k–14k € em 2–3 semanas, e é nessa fase que escrevemos a carta acima juntamente com o responsável pelo orçamento. Um teardown mostra como são orçamentadas a descoberta, a prova de conceito e a produção, e a página de contacto é a forma de começar um.

Fontes

Tem um processo que custa demasiado?

Fale-nos dele. A primeira chamada é gratuita e, se a IA não for a resposta, dizemo-lo.

Falar sobre a sua tarefa