Gastamos US$ 35 bilhões em IA e não tivemos quase nada em troca
A ligação veio numa terça-feira à noite. Uma empresa de saúde de médio porte — que vínhamos assessorando — acabara de matar seu principal projeto de IA. Nove meses de trabalho. Um gasto de seis dígitos. O CTO parecia exausto, não irritado. "Funcionava perfeitamente na demo", ele me disse. "Todas as vezes, sem exceção. Aí conectamos a dados reais de pacientes e ele começou a alucinar códigos de seguro."
Eu não soube o que dizer, porque tinha ouvido alguma versão dessa história uma dúzia de vezes só naquele trimestre. IA que deslumbra numa sala de reunião e se desintegra em produção. Pilotos que geram entusiasmo no primeiro mês e revisões de orçamento no sexto. A lacuna entre o que a IA generativa promete e o que ela entrega dentro de uma empresa real é a tensão definidora deste momento na tecnologia.
E agora temos os números para provar. A iniciativa NANDA do MIT publicou, em meados de 2025, um estudo que caiu como uma granada: dos estimados US$ 30 bilhões a US$ 40 bilhões que as empresas despejaram em IA generativa, cerca de 95% dos pilotos não entregaram impacto mensurável na demonstração de resultados. A própria pesquisa de 2025 da McKinsey reforça isso — 88% das organizações dizem usar IA em algum lugar, mas apenas 39% conseguem apontar qualquer impacto no EBIT.
Eu dirijo a Veriprajna, onde construímos sistemas de IA profunda para empresas. Não sou um observador neutro aqui. Mas estive perto o bastante dos destroços — e dos raros sucessos — para ter um retrato claro do que está realmente dando errado. E não é o que a maioria das pessoas pensa.
A demo parecia ótima. Aí a realidade apareceu.
A experiência daquele CTO da área de saúde não era incomum. Era praticamente o resultado mediano.
Os dados do MIT mapeiam um funil brutal: 80% das organizações exploram ferramentas de IA generativa. Apenas 20% chegam a um piloto. E só 5% alcançam a produção com resultados de negócio mensuráveis. Os pesquisadores chamam isso de "lacuna de aprendizado", que é um jeito educado de dizer que a maioria das empresas não entende o que comprou.
Lembro de estar sentado no nosso escritório depois de ler o relatório completo do MIT, discutindo com meu cofundador se o número de 95% não era dramático demais. Não era. Se é que havia algo, ele subestimava o problema, porque muitos dos 5% "bem-sucedidos" tinham redefinido o sucesso para baixo — mediram taxas de adoção ou satisfação do usuário em vez de impacto real na receita.
O padrão que continuo vendo é este: uma equipe constrói uma prova de conceito usando um dos principais LLMs. Ele lida lindamente com as dez consultas de exemplo. A liderança se empolga. O orçamento é aprovado. Aí o sistema encontra o mundo real — dados bagunçados, casos extremos, entradas ambíguas, exigências regulatórias em que "quase certo" é um processo judicial — e desmorona.
A lacuna entre uma IA pronta para demo e uma IA pronta para produção não é uma lacuna. É um cânion, e a maioria das empresas só percebe que está do lado errado depois de já ter pulado.
60% dos usuários no estudo do MIT relataram que os modelos não conseguiam aprender com o feedback ao longo do tempo. 55% disseram gastar esforço excessivo fornecendo contexto para cada prompt. 40% disseram que os modelos simplesmente "quebravam" ao encontrar entradas fora do padrão. Esses não são modos de falha exóticos. Isso é uma terça-feira qualquer.
Por que as empresas estão construindo sobre areia movediça?
A maior parte do que o mercado corporativo chama hoje de "produtos de IA" são wrappers — interfaces de usuário finas assentadas sobre uma chamada de API para o GPT-4, o Claude ou o Gemini. Você digita algo, aquilo vai para o modelo, o modelo responde e o wrapper formata tudo bonitinho.
Tenho uma lembrança visceral de uma reunião de pitch em que um cliente em potencial me mostrou seu "motor de compliance movido a IA". Perguntei o que acontecia quando o comportamento do modelo subjacente mudava após uma atualização do provedor. A sala silenciou. Eles não tinham considerado isso. O produto inteiro era um template de prompt e um dashboard bonito. A "inteligência" que vendiam era inteiramente alugada.
Essa é a falácia do wrapper, e ela está em toda parte. A abordagem costuma se apoiar no que o pessoal do setor chama de "megaprompt" — você enfia regras, dados, contexto e instruções em uma única interação gigante e torce para que o modelo dê conta. Escrevi sobre esse problema arquitetural com mais profundidade em nossa pesquisa na versão interativa, mas a versão curta é que os megaprompts criam três problemas fatais:
Não dá para auditá-los. Não há como verificar se o modelo seguiu as instruções na ordem correta. Para setores com forte carga de compliance, isso está fora de cogitação.
São economicamente frágeis. Janelas de contexto longas e novas tentativas queimam tokens. E aqui vai um número que me chocou quando o vi pela primeira vez: a diferença entre um tokenizador eficiente e um ineficiente pode significar uma variação de custo de 450% para a mesma carga de trabalho. Uma empresa que processa 100.000 consultas de clientes por dia poderia ver o custo anual saltar de US$ 36.500 para mais de US$ 164.000 apenas por escolher o modelo errado para um caso de uso multilíngue.
São quebradiços. Mude três palavras em um prompt e você obtém uma saída completamente diferente. Tente construir um SLA em cima disso.
A armadilha econômica é ainda pior que a técnica. Quando a OpenAI ou a Anthropic derruba os preços de API — e eles vão continuar caindo —, as empresas de wrapper veem suas margens evaporar. Elas não são donas dos dados. Não são donas do fluxo de trabalho. Estão revendendo a inteligência alheia com uma margem, e no momento em que o locador reduz o aluguel para todo mundo, o sublocador fica sem negócio.
O que "IA profunda" realmente significa?
Vou contar o momento em que o conceito fez sentido para mim.
Estávamos trabalhando em um sistema de processamento de documentos para um cliente de logística. A abordagem inicial era direta: enviar o documento de embarque para um LLM, pedir que extraísse os campos relevantes e devolver os resultados. Funcionava com formulários padrão. Aí esbarramos em um manifesto de contêiner de um porto do Sudeste Asiático com anotações em idiomas misturados, correções à mão e um formato que não correspondia a nada nos dados de treinamento. O modelo devolveu lixo com toda a confiança do mundo.
Meu engenheiro-líder, frustrado após uma semana de engenharia de prompt que só produzia novos modos de falha, finalmente disse: "Estamos pedindo a um cérebro que faça sete trabalhos. E se déssemos cada trabalho a um especialista?"
Isso é IA profunda em uma frase. Em vez de tratar o LLM como um oráculo que dá conta de tudo, você o trata como um componente dentro de um sistema maior. Você decompõe o problema. Um agente cuida da compreensão da consulta. Outro recupera dados de um banco de dados estruturado. Um terceiro valida a saída contra regras conhecidas. Um quarto formata a resposta. Cada agente tem uma responsabilidade definida, e o fluxo de trabalho entre eles é determinístico — ou seja, você controla a sequência, a lógica e os pontos de verificação.
A IA profunda trata o modelo de linguagem como um estagiário talentoso, não como um CEO. Você lhe dá tarefas específicas dentro de uma estrutura governada, não as chaves do prédio.
Os padrões de design agêntico que fazem isso funcionar não são teóricos. Estão sendo implantados agora:
Um padrão de reflexão em que o agente critica a própria saída antes de enviá-la ao usuário. Um padrão de uso de ferramentas em que o agente chama calculadoras, APIs ou bancos de dados externos em vez de tentar computar respostas de memória. Um padrão de planejamento que divide objetivos complexos em etapas sequenciais. E um padrão de orquestração em que um agente supervisor gerencia todo o fluxo de trabalho, roteando tarefas para o especialista certo.
Quando reconstruímos aquele sistema de logística usando orquestração multiagente, a acurácia de extração em documentos fora do padrão passou de cerca de 60% para mais de 95%. Mais importante: quando ele de fato falhava, conseguíamos ver exatamente onde e por quê — porque o sistema não era mais uma caixa-preta. Era um pipeline com etapas observáveis e auditáveis.
Por que o custo de tokens mata o ROI da IA corporativa?
Esta é a parte que não recebe atenção suficiente.
Todo mundo fala de acurácia do modelo. Quase ninguém fala da economia unitária de rodar esses sistemas em escala. Mas eu vi custos de token assassinarem em silêncio o business case de projetos de IA que, no resto, funcionavam perfeitamente.
A conta é simples, mas brutal. Modelos diferentes tokenizam o texto de formas diferentes — especialmente textos que não estão em inglês e escritas complexas. Uma consulta que custa 800 tokens em um modelo pode custar 4.500 em outro. Multiplique isso por centenas de milhares de interações diárias e você tem uma diferença de custo que apaga qualquer ganho de eficiência que a IA deveria entregar.
Tive um momento de alarme genuíno quando rodamos a análise de tokenização para um cliente que operava em tâmil e inglês. A diferença de custo entre o modelo que usavam e uma alternativa mais eficiente era de 4,5x. Estavam sangrando dinheiro em cada interação e atribuindo isso a "custos de infraestrutura" no orçamento. Ninguém tinha pensado em olhar o tokenizador.
Sistemas de IA profunda resolvem isso sendo cirúrgicos sobre quando usar tokens caros de LLM. Tarefas de alto volume e baixa complexidade ficam com modelos menores ou com lógica determinística. A capacidade cara de raciocínio fica reservada para as etapas em que ela realmente importa. É a diferença entre contratar um consultor sênior para atender cada telefonema e deixá-lo focado nas decisões que exigem julgamento.
A regra 10-20-70 que ninguém segue
Quando converso com executivos sobre por que seus projetos de IA travaram, eles quase sempre apontam para a tecnologia. O modelo não era bom o bastante. Os dados não estavam limpos. A integração era complexa demais.
Eles não estão errados em nada disso. Mas estão deixando passar a proporção real. As empresas que de fato estão vendo impacto no EBIT — e a McKinsey diz que apenas 6% veem mais de 5% do EBIT total vindo de IA — seguem uma alocação de recursos que surpreenderia a maioria dos profissionais de tecnologia:
10% do esforço vai para a escolha e o ajuste dos algoritmos. 20% vão para a construção da infraestrutura de dados e tecnologia. 70% vão para a gestão de pessoas, processos e transformação cultural.
Setenta por cento. Não em tecnologia. Em fazer seres humanos mudarem o jeito de trabalhar.
Resisti a essa ideia por mais tempo do que deveria. Sou engenheiro por instinto. Queria acreditar que, se construíssemos um sistema melhor, a adoção viria atrás. Foi preciso um projeto doloroso — em que entregamos uma solução tecnicamente excelente que ficou três meses sem uso porque ninguém tinha redesenhado o fluxo de trabalho ao redor dela — para eu internalizar que a tecnologia é a parte fácil.
Empresas de médio porte que seguem o princípio 10-20-70 melhoram seu EBITDA em 160 a 280 pontos-base em até 24 meses. As que gastam 70% em tecnologia e 10% em gestão de mudança acabam com software caro encostado na prateleira.
As vitórias não são glamourosas. Gestão do ciclo de receita. Automação de baixa de recebíveis. Otimização de custos de nuvem. Ninguém escreve posts empolgados no LinkedIn sobre reduzir a fila de contas de pacientes com alta, mas ainda não faturadas. Mas o Inova Health System cortou essa fila em 50% e economizou US$ 1,3 milhão por ano. Os assistentes virtuais de IA da OSF HealthCare economizaram US$ 1,2 milhão enquanto aumentavam a receita em mais US$ 1,2 milhão. A UPS economiza US$ 400 milhões por ano com roteirização baseada em IA.
Esses não são resultados de piloto. São sistemas em produção rodando em escala, construídos com o tipo de integração profunda que wrappers não conseguem alcançar.
O que acontece quando agentes de IA começam a agir por conta própria?
A mudança de uma IA que responde perguntas para uma IA que toma ações muda completamente o cálculo de segurança.
Tenho pensado muito nisso, em parte por causa de um quase acidente que tivemos durante os testes. Estávamos construindo um sistema agêntico que precisava acessar o ERP de um cliente para puxar dados de estoque. Durante uma execução de teste, o agente — seguindo uma cadeia de raciocínio tecnicamente lógica, mas contextualmente errada — tentou modificar um pedido de compra em vez de apenas lê-lo. Tínhamos salvaguardas em vigor. A ação não passou. Mas fiquei sentado à minha mesa depois pensando no que teria acontecido se tivéssemos sido menos cuidadosos.
É por isso que padrões como o Model Context Protocol (MCP) e o framework NANDA importam tanto. O MCP — desenvolvido pela Anthropic — funciona como uma camada de integração padronizada entre agentes de IA e fontes de dados corporativas. As pessoas o chamam de "USB-C da IA", o que é apropriado: significa que você não precisa de integrações customizadas e frágeis para cada conexão. O NANDA fornece a camada de governança — atestação de capacidade verificável criptograficamente (ou seja, você pode provar o que um agente tem e não tem permissão para fazer), controles de acesso zero-trust estendidos a agentes autônomos e trilhas de auditoria centralizadas.
Para o detalhamento técnico completo desses padrões arquiteturais e de como eles se encaixam, veja nosso artigo de pesquisa.
A questão não é que a IA agêntica seja perigosa e que devamos desacelerar. A questão é que a abordagem de wrapper — em que você tem visibilidade mínima do que o modelo está fazendo e por quê — se torna genuinamente imprudente quando o modelo pode executar ações no mundo real. Sistemas de IA profunda com fluxos de trabalho observáveis e governados não são apenas engenharia melhor. São a única forma responsável de implantar agentes autônomos em uma empresa.
"É só usar o GPT" e outros conselhos caros
As pessoas me perguntam o tempo todo se não deveriam simplesmente esperar os modelos melhorarem. "O GPT-5 vai resolver isso", ouvi um investidor dizer num jantar. "Por que construir toda essa infraestrutura se a próxima versão do modelo vai lidar com isso nativamente?"
Entendo o apelo desse argumento. É limpo. Não exige trabalho duro. E está errado.
Modelos melhores não consertam o problema do wrapper. Eles o pioram. Um modelo mais poderoso numa arquitetura de megaprompt é como colocar um motor de Fórmula 1 num carro sem volante. Você vai mais rápido na direção errada. Os problemas que matam a IA corporativa — falta de auditabilidade, prompts quebradiços, ausência de ciclos de feedback, contexto de negócio faltando, custos descontrolados — são problemas arquiteturais, não problemas de capacidade.
A economia da shadow AI prova isso. Mais de 90% dos funcionários já usam secretamente contas pessoais do ChatGPT ou do Claude para trabalhar porque as ferramentas oficiais de IA da empresa são rígidas demais. Os modelos são capazes o bastante. Os sistemas ao redor deles é que não são.
Modelos melhores não salvam uma arquitetura ruim. Eles apenas alucinam mais rápido e com mais confiança.
A outra pergunta que recebo é sobre prazo. "Quanto tempo isso leva de verdade?" A resposta honesta é de 12 a 18 meses para sair de experimentos dispersos e chegar a uma IA que move a demonstração de resultados. Os primeiros três meses são de descoberta — identificar onde a IA pode criar valor sem criar exposição regulatória. Do terceiro ao sexto mês vem a preparação dos dados, que é onde 58% dos CXOs dizem que empacam. Do sexto ao décimo segundo mês é construir e iterar protótipos multiagente — e falo de mais de 30 ciclos de iteração contra dados do mundo real, não três demos polidas. A fase final é a implantação em produção com suporte operacional completo: detecção de drift, monitoramento de viés, governança de custos.
Não é rápido. Não é fácil. Mas as empresas que fazem isso são as que aparecem nos 6% da McKinsey com impacto real no EBIT.
A divisão é uma escolha
A "Divisão da GenAI" que o MIT identificou não é uma lacuna de tecnologia. É uma lacuna de decisão.
De um lado: empresas que trataram a IA generativa como um produto a comprar, um wrapper a implantar, uma demo para mostrar ao conselho. São os 95%. Gastaram dinheiro de verdade e receberam press releases.
Do outro lado: empresas que trataram a IA como um desafio arquitetural — um que exige decompor problemas, governar fluxos de trabalho, redesenhar processos e fazer o trabalho nada glamouroso de conectar modelos à realidade bagunçada dos dados corporativos. São os 5%. Gastaram um dinheiro parecido e obtiveram impacto no EBIT.
Às vezes penso naquele CTO da área de saúde. O que me ligou numa terça-feira, exausto, tendo acabado de matar seu projeto de IA. Ele ligou de novo quatro meses depois. Sua equipe havia reconstruído o sistema com uma abordagem multiagente — agentes separados para extração de dados, validação de códigos e verificação de compliance, com repasses determinísticos entre eles. Não era tão elegante quanto a demo original. Foi mais lento de construir. Exigiu mais reflexão antecipada sobre desenho de fluxo de trabalho e modos de falha.
Funcionou. Não perfeitamente — nada é perfeito —, mas com confiabilidade suficiente para implantar, auditar e melhorar. Confiável o bastante para aparecer numa demonstração de resultados.
A era de tratar a IA como um truque de mágica acabou. O que vem a seguir é mais difícil, mais lento e menos fotogênico. Também é a única coisa que de fato funciona.
