Pesquisadores do MIT constataram que 95% dos pilotos corporativos de IA generativa não entregam impacto mensurável no resultado financeiro, e o Gartner prevê que mais de 40% dos projetos de IA agêntica serão cancelados até o fim de 2027.
A explicação confortável, segundo Vatsal Bhardwaj, fundador e CEO da Jabali AI, é que os modelos ainda não estão prontos.
Após dois anos colocando sistemas autônomos de IA em produção, ele defende que a explicação confortável também é a mais cara: o gap entre uma demo impressionante e um produto confiável é onde a maioria dos investimentos em IA morre, e modelos maiores não fecham essa lacuna.
O que aconteceu: a tese do harness ganhou respaldo de números
Bhardwaj publicou no Forbes Technology Council um artigo descrevendo o ciclo que todo executivo reconhece: um time se reúne, alguém digita um prompt, o modelo redige o contrato, tria o chamado ou escreve código funcional, e a sala decide que o futuro chegou. Surge orçamento, nasce um piloto. E então nada vai para produção.
Harness é tudo o que se constrói ao redor do modelo: o contexto que ele enxerga, as ferramentas que pode usar, os sandboxes onde atua, os fluxos de trabalho que sequenciam suas tarefas, a memória que o ancora no negócio e os loops de avaliação que dizem se a saída presta antes de o cliente descobrir. Demos não precisam disso: são uma tentativa, num exemplo favorável, avaliada por uma plateia torcendo pela mágica.
# publicidade
Demos são avaliadas pelo melhor caso. Produtos são avaliados pelo pior: dez mil tentativas por dia, sobre intenções confusas de clientes reais, julgados por quem só quer saber se a coisa funciona.
Mas por que a experiência em games sustenta essa tese? Porque jogos são um laboratório honesto para IA: objetivo e subjetivo ao mesmo tempo. Um parágrafo confiante pode estar errado sem que o leitor perceba; um jogo quebrado não engana ninguém.
O código precisa compilar, o build precisa abrir, e arte, história e mecânicas precisam concordar entre si. Depois de tudo, o produto ainda responde à pergunta mais dura do software: é divertido?
Cinco reconstruções em 24 meses: as lições da jabali AI
A Jabali AI constrói sistemas que transformam uma ideia em linguagem natural em um jogo jogável, e Bhardwaj acumula mais de 15 anos desenvolvendo games e plataformas para clientes exigentes. Essa severidade forçou a empresa a reconstruir seu harness cinco vezes em 24 meses.
A sequência evolutiva foi: um orquestrador rígido, depois um copilot com aprovação humana, em seguida pipelines de geração estruturada, depois um grafo de agentes especializados e, por fim, agentes totalmente autônomos escrevendo código real em sandboxes isolados. O tema conecta diretamente com o debate sobre IA de produção além dos prompts que o portal acompanhou no QCon AI Boston.
Lições que valem além dos games
- Estrutura vence improviso: quando você controla o esqueleto da solução, o modelo para de inventar arquiteturas e gasta capacidade no acabamento.
- Orquestração é superfície de produto: a forma como agentes passam trabalho uns aos outros influencia a qualidade tanto quanto a capacidade bruta do modelo.
- Agentes autônomos precisam de paredes: sandboxes permitem tentativas ousadas em código real sem derrubar nada crítico.
- Não se case com um modelo: o melhor modelo para a carga de trabalho mudou repetidas vezes, e cada troca ficou mais barata porque o harness absorveu a mudança.
Essa última lição ecoa diretamente a estratégia que o GitHub aplicou no Project HydraFusion, que orquestra múltiplos modelos para reduzir o custo do Copilot: quem controla a camada de orquestração troca de modelo sem reescrever a plataforma.
Info: o estudo do MIT citado por Bhardwaj aponta que os pilotos estagnam porque os sistemas não aprendem com feedback e não se encaixam nos fluxos de trabalho reais das empresas.
Evals são o que separam os 5% que dão certo
A máxima antiga de que não se melhora o que não se mede ganha um corolário severo em IA: para a maioria das tarefas de negócio valiosas, a métrica ainda não existe e precisa ser inventada.
Na Jabali AI, cada saída é avaliada em camadas: primeiro verificações objetivas (o código roda?), depois de coerência (as partes concordam entre si e com o pedido?) e só então qualidade subjetiva, pontuada por juízes de IA calibrados contra avaliações humanas.
Como isso se concretiza na prática? Bhardwaj relata um caso: os personagens dos jogos não permaneciam em seu papel. Um ferreiro mal-humorado, escrito para resmungar frases curtas sobre minério, dez minutos depois virava um assistente alegre oferecendo uma lista numerada de opções de missão. Nenhum erro aparecia e todas as métricas estavam verdes.
O problema foi detectado porque alguém do time passou uma semana lendo transcrições brutas e notou que todos os personagens convergiam lentamente para a mesma voz amigável. O fenômeno ganhou nome: persona drift. A empresa escreveu verificações para ele e acompanha esse número em cada release desde então.
Dica: o padrão geral descrito por Bhardwaj é que humanos descobrem novos modos de falha lendo transcrições brutas; uma vez que a falha tem nome, ela vira métrica. Reserve tempo semanal do seu time sênior para leitura de outputs crus antes de construir qualquer dashboard.
Esse cuidado se alinha ao que discutimos sobre por que a engenharia de contexto está substituindo o prompt engineering: qualidade em IA de produção vem de sistema, não de frase bem escrita. E o risco de confiar cegamente na avaliação automática já aparece em incidentes como o data poisoning, a ameaça silenciosa a modelos em produção.
Onde direcionar o orçamento de IA
Para quem olha para um piloto parado, Bhardwaj lista quatro prioridades de investimento, em ordem. A tabela abaixo resume as recomendações:
| Prioridade | Recomendação | Razão |
|---|---|---|
| 1. Rebalancear o orçamento | Custo de API de modelo deve ser minoria do gasto | Contexto, ferramentas, integração e avaliação tornam a inteligência confiável o bastante para cobrar por ela |
| 2. Definir critérios antes de escalar | Escreva o que é "correto" e depois o que é "bom" | Se não dá para avaliar, não dá para lançar |
| 3. Análise de erro antes de dashboards | Melhores pessoas lendo outputs brutos semanalmente | É onde modos de falha são descobertos e nomeados; as métricas nascem dos nomes |
| 4. Permanecer agnóstico de modelo | Troca de modelo deve custar uma config e um run de eval | Sua suíte responde em dias se um modelo novo merece produção, sem projeto de replataformação |
Arraste para o lado para ver toda a tabela.
Na avaliação do Mercado de TI, a tese tem um recorte relevante para o Brasil: times locais com orçamento em reais e APIs cobradas em dólar tendem a sofrer ainda mais quando o gasto concentrado no modelo não vira produto. Inverter a proporção, investindo em avaliação e integração, é uma decisão arquitetural que também protege o caixa. Quem opera agentes em nuvem já sente efeito parecido, como mostra o alerta da PwC sobre custos ocultos de infraestrutura gerados por agentes de IA.
Atenção: o artigo original é assinado pelo fundador de uma empresa que vende exatamente a tecnologia descrita, publicado no Forbes Technology Council, comunidade fechada de executivos. As lições são consistentes com dados do MIT e do Gartner, mas o interesse comercial do autor merece constar na leitura.
Vatsal Bhardwaj fecha o argumento com uma frase que resume a mudança de era: qualquer um tem acesso hoje a um modelo de ponta; a parte difícil é construir os sistemas ao redor que tornam a IA útil dia após dia. Seus clientes nunca verão seu modelo; eles só experimentarão seu harness. Para gestores brasileiros avaliando o próximo ciclo de investimento, a pergunta prática deixa de ser qual modelo contratar e passa a ser quanto do orçamento vai para a máquina que o cerca.
Fonte: Forbes Technology Council
