Tem um dado novo que deveria incomodar quem colocou um agente de IA na frente do cliente: 44% dos consumidores já viram a IA de uma empresa contradizer um atendente humano ou a própria política da empresa. O número vem do Agentic Consumer Report da Capacity (survey com 1.000 consumidores nos EUA), que mostra também que 35% já usaram um agente de IA em um pedido de atendimento. A leitura preguiçosa é "o modelo alucinou". A leitura correta — e a que decide o seu projeto — é outra: o agente não contradiz por burrice do modelo. Ele contradiz porque o dado que ele alcança no CRM, no ERP, no OMS e no catálogo não bate entre os sistemas, e ninguém reconcilia qual versão é a verdade. Essa é a face da confiabilidade de um problema que é, na origem, de integração.
1. O dado que incomoda: 44% já viram a IA contradizer a empresa
O relatório da Capacity não é sobre tecnologia de modelo — é sobre percepção de quem está do outro lado. Um terço dos consumidores já interagiu com um agente de IA num atendimento, e quase metade saiu dessa interação com uma inconsistência na mão: a IA disse um preço, um prazo, um status de pedido ou uma regra que não batia com o que o atendente humano, o site ou o contrato diziam. Para o cliente, o efeito é imediato e corrosivo: se a IA da empresa se contradiz, por que confiar nela da próxima vez?
É tentador tratar isso como ruído de uma tecnologia nova que vai amadurecer sozinha. Não vai. A contradição que o cliente percebe não é um bug de linguagem que o próximo modelo resolve — é o sintoma visível de uma arquitetura de dados que nunca foi feita para responder a uma pergunta única e autoritativa. O modelo só está fazendo o que todo sistema faz diante de fontes divergentes: escolhe uma. E, na frente do cliente, costuma escolher a errada.
2. Por que acontece: o agente lê de sistemas que não batem — e escolhe a versão errada
Imagine a pergunta banal: "qual o preço desse produto e quando chega no meu CEP?". Para respondê-la, o agente pode tocar o preço no CRM (que tem uma tabela promocional), o preço no e-commerce (que tem outra), o estoque no OMS, a posição no WMS, a regra de frete acoplada à plataforma e a política de troca no catálogo ou numa base de conhecimento. Cada um desses sistemas foi construído em um momento diferente, por um time diferente, com a sua própria noção de verdade. Enquanto um humano no atendimento aprende, com o tempo, "onde olhar" e "em quem confiar", o agente não tem esse julgamento tácito: ele consulta o que foi conectado e devolve o que encontrou primeiro, com confiança de máquina.
O resultado é a contradição. O preço no CRM diverge do preço no catálogo; o estoque que o OMS reporta não considera a reserva que o carrinho já fez; a regra de elegibilidade de desconto no ERP não é a mesma que está escrita na FAQ. Nenhuma dessas divergências é culpa do modelo — todas existiam antes dele, caladas, porque nenhum humano consultava os quatro sistemas ao mesmo tempo e em voz alta. O agente só tornou o problema audível: ele fala, em tempo real, a partir de um dado que a sua operação nunca reconciliou.
Um exemplo concreto deixa isso palpável. O cliente pergunta ao agente se ainda dá tempo de comprar um produto com desconto e receber até sexta. O agente lê o preço promocional no CRM (onde a campanha foi cadastrada), confirma disponibilidade no e-commerce (que mostra o item como "em estoque") e estima o prazo pela regra de frete da plataforma. Responde: "sim, R$ 199, chega quinta". Só que a promoção no CRM já expirou no ERP, o "em estoque" do e-commerce não desconta as reservas que o OMS já fez, e a regra de frete não considera que o CD que atende aquele CEP está sem o item. Três sistemas, três verdades, uma resposta confiante e errada. O cliente não vê uma falha de IA — vê uma empresa que não sabe o próprio preço, estoque e prazo.
Por isso trocar de modelo não resolve. Um modelo melhor raciocina melhor sobre o dado que recebe — mas se o dado que chega já é contraditório, o raciocínio apenas escolhe com mais eloquência entre duas versões erradas. A contradição nasce na camada de dado e integração, e é lá que ela se cura.
3. Não é "modelo melhor", é grounding: contrato de dado, reconciliação e fonte de verdade única
"Grounding" virou palavra da moda, mas no contexto operacional ela tem um significado preciso e pouco glamouroso: ancorar o agente numa fonte de verdade reconciliada entre os sistemas antes de ele responder. Três peças sustentam isso.
A primeira é um contrato de dado: uma definição explícita de qual sistema é a autoridade para cada campo. O preço vigente é o do ERP ou o do e-commerce? O status do pedido é o do OMS ou o do sistema de logística? Quando isso está escrito e implementado, o agente para de "escolher" — ele sempre lê a fonte canônica de cada campo. A segunda é a reconciliação em tempo real: uma camada que cruza CRM, ERP, OMS, catálogo e fiscal e resolve a divergência (preço efetivo, estoque disponível líquido de reservas, elegibilidade de desconto) antes de o agente ser consultado — não um feed de madrugada que já nasce velho, mas uma sincronização orientada a evento, com idempotência, em que a mudança na origem se propaga na hora. A terceira é a fonte de verdade única: um ponto de acesso que o agente consulta e que devolve "a" resposta, não "uma" resposta.
Repare que nada disso é sobre IA. É engenharia de integração e de dado: APIs limpas sobre os sistemas de registro, uma arquitetura orientada a evento que mantém as superfícies em dia, e um modelo de dado que diz o que cada campo significa e de onde ele vem. O agente é só o primeiro consumidor que exige essa disciplina em voz alta.
4. A outra metade: conter o agente e observar a divergência antes do cliente
No mesmo dia em que o relatório da Capacity circulou, a indústria de infraestrutura reagiu pela outra ponta do problema. A Akamai lançou o Agent Sandbox (um runtime isolado para rodar código gerado por agente, com bloqueio de saída de rede — egress — por padrão) e o GitHub endureceu os Agentic Workflows com tratamento mais seguro de credencial e rede. Essa é a metade da contenção: limitar onde o agente roda e o que ele consegue alcançar. É necessária — mas não cura a contradição, porque o problema do dia não é o agente alcançar demais, é ele alcançar um dado inconsistente.
A peça que fecha o ciclo é a observabilidade. Grounding reconcilia o dado; observabilidade detecta quando, ainda assim, a resposta do agente divergiu do sistema-fonte — idealmente antes do cliente perceber. Rastrear de qual fonte o agente leu cada campo, alertar quando ele respondeu "R$ 199" enquanto o ERP dizia "R$ 219", medir a taxa de contradição como um indicador de produto: isso transforma a contradição de um incidente que o cliente reporta num sinal que a sua operação captura. Conter, ancorar e observar são as três camadas — e nenhuma delas é um modelo melhor.
Vale sublinhar por que a observabilidade de agente é diferente da observabilidade de sistema tradicional. Monitorar latência, erro e throughput continua necessário, mas não captura o tipo de falha que gera a contradição: a resposta pode voltar rápida, sem erro HTTP e dentro do SLA — e ainda assim estar errada, porque leu a fonte errada. O que precisa ser instrumentado é a procedência de cada campo da resposta (de qual sistema veio o preço, o estoque, o status) e a divergência contra a fonte canônica. Sem isso, a empresa só descobre a contradição quando o cliente reclama — e aí o dano de confiança já aconteceu. Com isso, a contradição vira uma métrica que cai semana após semana, igual a qualquer outro indicador de qualidade.
5. Como a CCX constrói essa camada
É exatamente aqui que a CCX atua. A frente de Integrações & APIs Enterprise constrói o grounding operacional: o contrato de dado que define qual sistema é a verdade por campo e a reconciliação em tempo real entre CRM, ERP, OMS, catálogo e fiscal, com APIs limpas (REST, GraphQL, gRPC) sobre arquitetura event-driven (Kafka, RabbitMQ) e idempotência — incluindo as integrações SAP ↔ e-commerce e Protheus ↔ e-commerce que já rodam em produção.
Sobre essa base, a frente de Data & BI harmoniza e modela o dado que o agente lê — uma fonte única e confiável, com qualidade e linhagem, para que "preço vigente" ou "estoque disponível" signifiquem a mesma coisa em todos os sistemas. E a Observabilidade 360° (com Datadog, Grafana, Prometheus e tracing distribuído via OpenTelemetry) rastreia de onde veio cada campo e alerta quando a resposta do agente diverge da origem — pegando a contradição antes do cliente. Com mais de 200 projetos entregues, o princípio é direto: agente confiável é dado reconciliado, não prompt melhor.
A IA não contradiz por burrice do modelo — contradiz porque o dado entre os seus sistemas não bate. A cura é grounding: uma fonte de verdade reconciliada entre CRM, ERP, OMS e catálogo, com observabilidade que pega a divergência antes do cliente. A CCX constrói essa camada — Integrações & APIs Enterprise + Data & BI + Observabilidade. Conheça as soluções da CCX →
6. Perguntas frequentes
Por que a IA dá respostas diferentes para a mesma pergunta? Porque ela consulta sistemas que guardam versões diferentes do mesmo fato — preço no CRM, no e-commerce e no ERP, por exemplo. Sem uma fonte de verdade reconciliada por campo, o agente escolhe uma das versões, e nem sempre a correta.
O que é grounding de um agente de IA? É ancorar o agente em dados reais, consistentes e atualizados antes de ele responder — definindo qual sistema é a autoridade para cada campo e reconciliando as fontes em tempo real, em vez de deixar o modelo "adivinhar" a partir de dados divergentes.
Como garantir que o agente leia o dado certo? Com um contrato de dado (qual sistema manda em cada campo), uma camada de integração event-driven que mantém as fontes sincronizadas e uma fonte de verdade única que o agente consulta — somados a observabilidade que detecta quando a resposta diverge da origem.
Trocar de modelo de IA resolve a contradição? Não. Um modelo melhor raciocina melhor, mas se o dado de entrada é inconsistente, ele apenas escolhe com mais confiança entre versões erradas. A contradição se resolve na camada de dado e integração.