A demo saiu redonda. O modelo leu o email, percebeu o pedido, redigiu uma resposta impecável, e a sala aplaudiu. Três meses depois, esse piloto continua a ser exatamente isso: uma demo que alguém liga quando aparece um diretor. Nunca passou a produção. Não é falta de sorte nem falta de orçamento para «mais IA»: é o padrão mais comum do setor. A demo impressiona porque mostra a parte fácil. Produção é tudo o que a demo, por desenho, saltou.
Porque fracassam os pilotos de IA (e quase nunca é o modelo)
Os números do último ano são incómodos. O inquérito Voice of the Enterprise da S&P Global Market Intelligence (2025) encontrou que 42% das empresas abandonaram a maioria das suas iniciativas de IA em 2025 — contra 17% um ano antes —, descartando quase metade das suas provas de conceito antes de chegarem a produção. A IDC, por seu lado, calculou que 88% dos pilotos de IA não superam o salto para o desdobramento amplo: só 4 provas de conceito em cada 33 chegaram a produção. Não é que o modelo não fosse capaz na demo. É que «capaz na demo» e «em produção» são duas coisas distintas — e a segunda não foi comprada.
Convém separar duas perguntas que a demo mistura de propósito. A primeira — «o modelo consegue fazer isto?» — recebe quase sempre um sim. A segunda — «a tua empresa consegue operar isto todos os dias, com os teus dados, os teus sistemas, as tuas permissões e as tuas exceções?» — é a que decide se há projeto. A demo responde à primeira e esconde a segunda. Por isso uma demo brilhante é um sinal tão mau como bom: prova o que quase nunca falha e cala o que falha sempre.
Os 70% que a demo salta
A BCG resume-o num princípio que envelhece muito bem: o sucesso de um projeto de IA é 10% algoritmos, 20% dados e tecnologia, e 70% pessoas, processos e mudança cultural. A demo vive inteira nesses primeiros 10%. O fosso entre o piloto e a produção são esses 70% — mais os 20% de canalização de dados — que nenhuma apresentação de vendas mostra, porque não dá um vídeo bonito.
Esses 70–90% invisíveis são, em concreto, isto:
- Dados a sério, não de laboratório. A demo corre sobre três exemplos limpos. Produção recebe PDFs tortos, campos vazios, duplicados e o email que não segue nenhum modelo. Sem dados fiáveis e acessíveis, o mesmo modelo que brilhou na demo começa a inventar.
- Integrações. O resultado tem de entrar e sair dos teus sistemas — CRM, ERP, email, base de dados — com autenticação, permissões e rastreabilidade. Essa cablagem é 80% do trabalho real e 0% da demo.
- Casos raros e tratamento de erros. A demo não tem casos raros; a terça-feira tem. O que acontece quando o modelo não tem a certeza, quando a API cai, quando o dado chega a meio? Um sistema em produção tem resposta para isso. Uma demo, não.
- Observabilidade e custo. Em produção precisas de ver o que o sistema faz, quando se engana e quanto custa cada execução à escala. Um piloto sem instrumentação não se governa: desliga-se ao primeiro susto.
- Propriedade e adoção. Alguém tem de ser dono do sistema, mantê-lo e conseguir que a equipa o use a sério em vez de voltar à folha de cálculo de sempre. Sem dono e sem adoção, até o melhor sistema morre sozinho.
Demo vs produção: não é o mesmo projeto
| Dimensão | Na demo | Em produção |
|---|---|---|
| Dados | Três exemplos limpos e escolhidos | Tudo o que entra, sujo e a qualquer hora |
| Erros | Não aparecem | São metade do desenho |
| Integração | Copiar e colar o resultado | Entra e sai dos teus sistemas com permissões |
| Custo | Irrelevante (uma execução) | Medido por execução, à escala |
| Dono | Quem fez a demo | Alguém que o mantém todos os dias |
| Sucesso | Impressionar a sala | Funcionar sem ninguém a olhar |
Há uma versão deste fracasso que é de operação — os 70% acima — e outra que é de desenho: prometer um sistema que se governa sozinho e largá-lo sem a pessoa que o governa. Essa segunda desenvolvemo-la à parte em o mito do agente 100% autónomo. E às vezes a conclusão honesta é que esse processo não devia ter sido automatizado por inteiro: tratamos isso em quando NÃO automatizar um processo com IA. Aqui o foco é outro: mesmo que o processo seja bom candidato e o humano esteja bem colocado, o piloto morre à mesma se ninguém construir os 70% aborrecidos.
Como se atravessa o fosso
A ordem que funciona inverte a da demo. A demo começa pelo modelo e espera que o resto encaixe sozinho. Um sistema começa pelo processo e trata o modelo como mais uma peça:
- Começa pelo processo, não pelo modelo. Mapeia como o trabalho se faz hoje — onde encrava, que exceções aparecem, quem decide o quê. É o que separa automatizar processos com IA de comprar uma ferramenta e rezar.
- Orça os 70% desde o primeiro dia. Dados, integrações, tratamento de erros e adoção não são «fase dois»: são o projeto. Se o plano só cobre a demo, já sabes como acaba.
- Instrumenta antes de escalar. Mede o acerto, o custo por execução e o que é escalado para um humano. Um sistema que não podes medir é um sistema que não podes governar.
- Põe um dono e um humano no ciclo. Alguém mantém o sistema, e uma pessoa revê precisamente onde o critério pesa mais do que a velocidade. É a lógica de montar processos internos com agentes: a IA faz o trabalho pesado, o humano decide o que importa.
Nada disto aparece num vídeo de noventa segundos, e é precisamente por isso que o setor prefere vender-te a demo. Nós fazemos o contrário: construímos os 70% aborrecidos, ligamo-los aos teus sistemas, instrumentamo-los e deixamo-los a correr numa terça-feira qualquer sem ninguém a olhar. Chama-se automação de operações, e cobra-se pelo que funciona em produção, não pelo que impressiona a sala.