Enquanto a Dreamforce 2026 fecha discutindo por que o ROI dos agentes não apareceu, uma pesquisa fecha a conta com número. A Deloitte ouviu 3.235 líderes e 60% apontaram a integração de sistemas legados — e não a capacidade do modelo — como a barreira primária para colocar agentes em produção. E não para aí: avaliação/observabilidade é o maior bloqueador isolado, citado por 64%, e apenas cerca de 1 em 5 relata governança madura de agente autônomo.
Este texto é agnóstico e no nível da engenharia: o ponto não é “compre a ferramenta X”, e sim que o modelo já não é o gargalo — integrar o seu legado e instrumentar a cadeia é. O ROI de um agente, na prática, deixou de ser um problema de modelo e virou um projeto de integração + observabilidade. Vamos ao que os dados mostram e ao que fazer com eles.
Onde o ROI de agente realmente trava: 60% integração de legado, 64% observabilidade
Os dois números da Deloitte contam a história inteira. O primeiro localiza a barreira de entrada: 60% dos líderes dizem que o obstáculo nº1 é conectar o agente aos sistemas legados — o ERP, o mainframe, o banco on-premise, o dado que não mora no fornecedor. Não é “o modelo alucina” nem “falta capacidade de raciocínio”. É que o agente, por mais inteligente que seja, não alcança os sistemas onde a ação precisa acontecer.
O segundo número — 64% travando em avaliação/observabilidade — explica por que muita gente acha que chegou à produção e não consegue provar. Sem instrumentação, o agente vira uma caixa-preta: ninguém sabe quantas ações ele executou, quanto custou cada uma, onde errou e por quê. E o que não se mede não se defende numa reunião de ROI. Juntos, integração (para o agente agir) e observabilidade (para provar que a ação valeu) formam o par que decide se o piloto vira resultado.
Um exemplo concreto: o agente que promete “reprogramar uma entrega”
Pegue um caso de uso banal e veja onde ele quebra. Um agente de atendimento precisa “reprogramar a entrega” de um cliente que ligou. Na demo, ele entende o pedido, escolhe a nova data e responde com simpatia — parece resolvido. Em produção, reprogramar uma entrega significa: consultar o status real no TMS, checar disponibilidade de rota no ERP, gravar a nova janela no sistema de pedidos, disparar a notificação no canal certo e registrar tudo para auditoria. Cinco sistemas, cinco contratos de API, cinco permissões.
Se qualquer uma dessas pontes não existe — ou existe como uma integração ponto-a-ponto frágil que alguém costurou às pressas — o agente ou não consegue agir ou age errado, e um erro silencioso em produção custa muito mais caro que uma demo que não roda. É por isso que “o modelo entende o pedido” e “o agente reprograma a entrega de verdade” são dois mundos separados por engenharia de integração. O cérebro estava pronto desde o começo; o que faltava eram os braços confiáveis para tocar cada sistema e os sensores para provar que a ação aconteceu como deveria.
As 5 lacunas que concentram 89% das falhas de escala
As análises que consolidam mais de 120 data points do ano convergem num diagnóstico incomodamente consistente: cinco lacunas concentram 89% das falhas de escala. São elas: (1) integração com o legado; (2) qualidade inconsistente da saída em volume (o que funciona em dez casos degrada em dez mil); (3) ausência de monitoramento/observabilidade; (4) dono organizacional indefinido (ninguém responde pelo que o agente faz); e (5) dado de treino de domínio insuficiente.
Repare no que não está na lista: “o modelo é fraco”. O modelo está ótimo. Quatro das cinco lacunas são de engenharia e governança do ambiente do cliente — conectar, medir, atribuir dono, alimentar com dado bom — e a quinta é sobre dado, não sobre capacidade de raciocínio. É por isso que trocar de modelo raramente resolve o problema de quem está empacado: o gargalo nunca esteve no modelo. Estava no encanamento e nos instrumentos.
Vale destacar a segunda lacuna, porque ela é a mais traíçoeira: qualidade inconsistente da saída em volume. Um agente que acerta 95% dos casos numa demo com cem interações parece pronto; o mesmo agente, sob cem mil interações reais, transforma aqueles 5% de erro em milhares de ações erradas por dia — pedidos aprovados indevidamente, respostas fora de política, escalações que não deveriam existir. Sem observabilidade que capture esse desvio em tempo real e sem uma malha de integração que imponha limites e validações, a degradação só aparece quando o cliente reclama. Escala não é rodar mais rápido; é manter a qualidade sob volume — e isso é problema de arquitetura, não de modelo.
O agente não emperra no cérebro, emperra no encanamento
A metáfora ajuda a não gastar dinheiro no lugar errado. Um agente tem um cérebro (o modelo) e precisa de braços (as integrações que o deixam agir) e de sensores (a observabilidade que mostra o que ele fez). A indústria passou dois anos investindo no cérebro, e o cérebro ficou excelente. Mas um cérebro genial sem braços não move nada, e sem sensores ninguém sabe se ele moveu.
Na prática, isso significa conectar o agente ao seu estado: o ERP com customizações, o legado sem API moderna, o dado que mora fora de qualquer nuvem de fornecedor. Essa costura é específica da sua empresa — não vem pronta em nenhum keynote — e é exatamente ela que separa o agente que “responde bem” do agente que executa uma ação com consequência no mundo real. Comprar o agente é a parte fácil; traduzi-lo para o seu ambiente é o trabalho.
Sem observabilidade não há ROI: trace, custo por execução, taxa de erro, dono
Se integração é o que faz o agente agir, observabilidade é o que transforma essa ação em ROI defensável. Um agente em produção precisa de trace da cadeia prompt → ferramenta → ação: cada passo registrado, com entrada, saída e a chamada de sistema que ele disparou. Precisa de custo por execução, porque um agente que resolve um caso a US$ 4 de tokens pode ser ótimo ou péssimo dependendo do que aquele caso vale. Precisa de taxa de erro por tipo de ação, para saber onde ele quebra antes que o cliente descubra. E precisa de dono organizacional: uma pessoa que responde pelo que cada agente pode alcançar e fazer.
Sem isso, o “ROI” do agente vira uma história contada de memória. Com isso, vira uma planilha. Não é coincidência que 64% apontem observabilidade como bloqueador: a maioria instrumentou a aplicação tradicional, mas ainda não instrumentou a cadeia de decisão do agente — que é onde o custo e o risco realmente moram.
Há ainda um ângulo financeiro que quase ninguém instrumenta: o custo unitário do agente em produção. Diferente de um software tradicional, cujo custo marginal por transação é quase zero, um agente consome tokens, chamadas de ferramenta e, muitas vezes, múltiplas idas e voltas de raciocínio a cada tarefa. Sem medir o custo por execução, uma automação que parecia barata pode consumir a margem que deveria gerar — e o time só descobre na fatura. Observabilidade de agente, portanto, não é só confiabilidade: é também FinOps. Saber quanto custa cada ação, comparar com o valor que ela gera e cortar os fluxos que não se pagam é parte do mesmo trabalho que prova o ROI. Quem não instrumenta o custo opera no escuro em dois eixos ao mesmo tempo: não sabe se o agente acerta, nem se ele se paga.
Como a CCX tira o agente do PoC: integração API-led + observabilidade 360°
Na CCX, atacar a barreira real é um projeto de engenharia com dois pilares. O primeiro é a integração: pela frente de Integrações & APIs Enterprise, conectamos o agente ao seu legado e ao seu ERP com REST, GraphQL e gRPC e arquitetura event-driven (Kafka/RabbitMQ), com idempotência e contratos explícitos; quando faz sentido, com MuleSoft / API-led connectivity (Anypoint Platform), para uma malha governada de ponta a ponta — e um gateway onde política, limite e roteamento das chamadas ficam num ponto só, em vez de uma dúzia de integrações frágeis.
O segundo pilar é a observabilidade: pela frente de Observabilidade 360° (Datadog, Grafana, Prometheus, Sentry e tracing distribuído com OpenTelemetry), instrumentamos o rastro prompt → ferramenta → ação, o custo por execução e a taxa de erro, com dashboards e alertas por cliente. Sobre os dois, a Consultoria em Tecnologia desenha a arquitetura-alvo e define o dono organizacional do que cada agente alcança. Foi esse o eixo dos posts anteriores da frente — a diferença entre conectar as nuvens do fornecedor e integrar o seu estado e a identidade e autorização do padrão MCP.
Quer tirar o agente do PoC atacando a barreira real? Veja as soluções de integração da CCX; para a conexão API-led do seu legado/ERP, Consultoria MuleSoft; para a observabilidade da cadeia prompt→ferramenta→ação, Data & BI. O modelo já está pronto; o seu ambiente é engenharia.
Perguntas frequentes (FAQ)
Por que agentes de IA não chegam à produção?
Porque o gargalo não é o modelo, e sim conectar o agente aos sistemas reais e conseguir medir o que ele faz. A Deloitte (3.235 líderes) aponta integração de legado como a barreira nº1 (60%) e observabilidade como o maior bloqueador isolado (64%); some a isso 88% dos pilotos que não escalam, e o padrão fica claro: falta encanamento e instrumentação, não inteligência.
Qual a maior barreira para escalar IA?
Integração de sistemas legados, seguida de avaliação/observabilidade. Cinco lacunas concentram 89% das falhas de escala: integração de legado, qualidade inconsistente da saída em volume, ausência de monitoramento, dono organizacional indefinido e dado de domínio insuficiente. “Modelo fraco” não está na lista.
O que é observabilidade de agente de IA?
É instrumentar a cadeia de decisão do agente — trace de prompt → ferramenta → ação, custo por execução, taxa de erro por tipo de ação — para saber o que ele fez, quanto custou e onde quebrou. Sem isso, não dá para provar ROI nem operar o agente com segurança. Ferramentas típicas: OpenTelemetry, Datadog, Grafana, Prometheus, Sentry.
Como integrar um agente de IA com sistemas legados?
Com conectividade API-led: expor as capacidades do legado e do ERP como APIs governadas (REST/GraphQL/gRPC), usar arquitetura event-driven (Kafka/RabbitMQ) onde faz sentido, centralizar política e roteamento num gateway e, quando o cenário pede malha enterprise, MuleSoft/Anypoint. O objetivo é dar ao agente braços confiáveis para agir no seu estado, com identidade e contrato explícitos.
A Dreamforce saiu perguntando o ROI do agente. A pesquisa responde onde ele trava — e não é o modelo. Enquanto o gargalo for tratado como problema de inteligência, o piloto vai continuar morrendo entre a demo e a produção. Ver soluções de integração da CCX →