A consolidação de modelo que o Claudeforce (26 de agosto) recolocou nas manchetes tem um capítulo anterior que vale reler esta semana: o ERP já fez isso. A SAP nomeou a Anthropic como parceira estratégica cornerstone e selecionou o Claude como o modelo primário de raciocínio e agência embutido no Joule e nos Joule agents — com Mistral AI e Cohere como opções de modelo soberanas na sua infraestrutura de nuvem, e o Joule Studio (o ambiente de construção de agentes) model-agnostic por design.
Junte isso ao movimento da Salesforce e o padrão de 2026 fica nítido: o “cérebro” do seu ERP virou um modelo de fronteira alugado — e, por construção, trocável. O movimento é racional; a SAP não quer casar com um único fornecedor de modelo. Mas ele tem uma consequência estratégica que não cabe no keynote: se o modelo embaixo do seu agente SAP é intercambiável, apostar nele é apostar em algo desenhado para mudar. A camada durável — a única que a SAP não padroniza por você — é a que sempre foi o trabalho de verdade: a integração, o dado e o fiscal.
O que a SAP fez: Claude primário no Joule, Mistral/Cohere soberanos, Joule Studio model-agnostic
Vamos ao fato, com a precisão devida. A parceria SAP↔Anthropic foi firmada no Sapphire (maio de 2026); aqui ela é lida como o capítulo-ERP da consolidação de modelo que o Claudeforce recolocou em pauta. A SAP posicionou o Claude como o motor de raciocínio primário do Joule, seu copiloto e camada de agentes. Ao mesmo tempo, ofereceu Mistral e Cohere como alternativas soberanas — relevante para quem tem exigências de residência de dado e soberania — e desenhou o Joule Studio para ser agnóstico de modelo.
A leitura correta desse conjunto não é “a SAP escolheu o melhor modelo”. É “a SAP desenhou o Joule para trocar de modelo”. Model-agnostic por design significa, em bom português, que o modelo é uma peça removível. E peças removíveis não são onde você constrói vantagem duradoura.
Na semana do Claudeforce: o padrão de 2026 é o modelo virar ingrediente plugável
O que a SAP fez no ERP e a Salesforce fez no CRM contam a mesma história. Em ambos, o modelo de fronteira deixou de ser um destino e virou um ingrediente que você liga, aluga e troca. É a mesma comoditização que transformou banco de dados e fila em serviços gerenciados na década passada: o componente vira commodity e o valor migra para o que você faz com ele.
Para o cliente, a implicação é libertadora e desconfortável ao mesmo tempo. Libertadora porque tira a ansiedade da “escolha certa de modelo” — ela deixou de ser decisiva. Desconfortável porque desloca a responsabilidade para a camada que ninguém padroniza por você: o harness de integração, o dado governado e, no Brasil, o fiscal.
Vale sublinhar que isso é uma tendência de mercado, não uma jogada isolada de um fornecedor. O desenho model-agnostic do Joule — com opções soberanas plugáveis — é a versão SAP do mesmo princípio que aparece no CRM e nos modelos de fronteira que chegam gated e trocáveis. Não se trata de eleger um modelo; trata-se de reconhecer que o modelo, qualquer que seja, é a peça que menos diferencia o resultado no seu processo real.
Por que apostar no modelo é apostar no que vai mudar
Se o modelo é trocável por design, investir energia nele é investir no que foi feito para ser substituído. O modelo vai melhorar, baratear e ser trocado por outro — soberano ou não — e nada disso, sozinho, faz o seu processo rodar. Um agente SAP não erra menos porque o modelo ficou mais esperto se ele continua lendo um dado espalhado e escrevendo em sistemas que não se falam.
A pergunta estratégica, então, inverte-se: em vez de “qual modelo colocar no meu Joule?”, o que importa é “o que continua sendo meu independentemente do modelo?”. E a resposta é sempre a mesma tríade — integração, dado e fiscal.
Há um teste simples para separar o que é aposta segura do que é aposta no efêmero: pergunte, para cada investimento de IA no seu SAP, se ele sobrevive à próxima troca de modelo. Um conector OData bem desenhado sobrevive. Um pipeline de reconciliação de dado sobrevive. Uma camada de localização fiscal sobrevive. Já um prompt afinado para as idiossincrasias de um modelo específico, ou uma automação amarrada ao comportamento de uma versão, evapora no dia em que o Joule troca o motor. Investir na camada que sobrevive é o que transforma a comoditização do modelo de ameaça em vantagem.
A camada durável: integração SAP↔não-SAP (OData/iDoc/RFC/event-driven)
A primeira camada durável é a integração entre o SAP e o resto do seu mundo. Nenhum agente, com nenhum modelo, cria sozinho a costura que conecta o ERP ao e-commerce, ao WMS, ao CRM, aos canais e aos gateways. Essa conexão vive em OData, iDoc, RFC e em arquitetura event-driven — e é ela que decide se o agente consegue, de fato, ler estoque e escrever pedido no sistema de registro sem duplicar nem perder evento.
Essa camada é durável justamente porque é específica do seu ambiente. Ela não vem no Joule, não vem no modelo e não é padronizada pela plataforma. Trocar o modelo é fácil e a SAP até facilita; refazer a sua integração SAP↔não-SAP, não — e é ela que carrega o peso de qualquer agente que pretenda agir.
O dado reconciliado que qualquer modelo precisa ler para não errar
A segunda camada é o dado. Um agente é tão bom quanto a verdade que ele lê. Se o preço vem de um lugar, o estoque de outro e o cadastro de um terceiro, e os três discordam, o agente vai agir com convicção sobre uma realidade que não existe — e a autonomia só torna esse erro mais rápido e mais caro.
Reconciliar o dado — definir a fonte de verdade, resolver divergências, manter a consistência entre SAP e não-SAP — é pré-requisito para qualquer agente, com qualquer modelo. É uma disciplina de engenharia de dados, não um efeito colateral de um LLM mais capaz. Troque o modelo dez vezes: se o dado continuar espalhado, o agente continuará errando com mais eloquência.
O que modelo nenhum toca: o fiscal brasileiro (IBS/CBS, NF-e/SPED)
A terceira camada é a mais brasileira e a mais ignorada nos keynotes globais: o fiscal. A reforma tributária colocou IBS e CBS em regime dual — obrigatório em produção desde janeiro de 2026 — sobre uma máquina que já tinha NF-e, SPED e uma camada de localização inteira. Nenhum modelo de fronteira, por mais alinhado que seja, calcula o seu tributo, emite a sua nota ou concilia o seu SPED.
Essa camada não só é sua como é intransferível: ela depende de regras nacionais que mudam, de obrigações acessórias específicas e de uma localização que precisa acompanhar a legislação em tempo real. É o pedaço do problema em que “o modelo mais inteligente do mundo” tem exatamente zero a oferecer — e onde um erro não é um mau texto, é uma autuação.
Clean core: o que fica na plataforma e o que precisa ser seu por design
Tudo isso desemboca numa decisão de arquitetura que a SAP mesma prega: o clean core. A ideia é manter o núcleo do ERP padronizado e atualizável, empurrando customização e integração para camadas de extensão bem desenhadas. Traduzindo para o tema de hoje: o modelo e o núcleo ficam na plataforma (padronizados, trocáveis); a integração SAP↔não-SAP, o dado reconciliado e o fiscal ficam nas suas camadas de extensão — e precisam ser desenhados para durar, independentemente de qual modelo estiver embaixo do Joule amanhã.
Decidir com clareza o que é da plataforma e o que é seu por design é o que evita dois erros simétricos: customizar o núcleo (e travar as atualizações) ou terceirizar a camada durável para um modelo que foi feito para mudar.
Como a CCX prepara o harness que faz o agente render com qualquer modelo
É exatamente aqui que entra a CCX. A SAP tornou o Joule model-agnostic — o cérebro do seu ERP é alugado e trocável. O que não troca é a camada que faz o agente render, e é nela que trabalhamos. Na frente de Integrações & APIs Enterprise (SAP↔não-SAP), enxugamos a costura em OData, iDoc e RFC sobre arquitetura event-driven (Kafka/RabbitMQ), conectando o SAP ao e-commerce, ao Protheus, aos canais e aos gateways — com sincronização em tempo real de estoque, preço, pedido e NF.
Por baixo, preparamos o que qualquer modelo precisa ler. Em Data & Business Intelligence, reconciliamos o dado (incluindo o fiscal) para o agente agir sobre uma verdade única. E em Consultoria em Tecnologia, desenhamos a arquitetura-alvo e o clean core — o que fica no modelo/plataforma e o que precisa ser seu por design. Assim, quando o Joule trocar de modelo (e ele vai), o seu agente continua rendendo, porque a camada que decide já é sua.
O ingrediente troca; o prato é você que faz. Faça um diagnóstico de integração e dado do seu SAP com a CCX — Integrar SAP ao seu e-commerce →. Reconcilie o dado e o fiscal IBS/CBS para o agente render com qualquer modelo em /br/data-e-bi, trate clean core e arquitetura-alvo em /br/consultoria-em-tecnologia e veja a frente SAP completa em /br/sap. Para aprofundar, leia sobre o agente que executa sobre dado ruim e sobre por que a fatura de IA depende da integração.
FAQ (People Also Ask)
O que significa o Joule ser model-agnostic? Significa que o Joule foi desenhado para trocar de modelo. A SAP pôs o Claude como modelo primário de raciocínio, com Mistral e Cohere como opções soberanas, e fez o Joule Studio agnóstico de modelo por design — ou seja, o modelo é uma peça intercambiável.
Se a SAP escolheu o Claude, por que não apostar no modelo? Porque o modelo é trocável por construção. Apostar nele é investir no que foi feito para mudar. O que dura — e a SAP não padroniza por você — é a integração SAP↔não-SAP, o dado reconciliado e o fiscal.
O que o modelo do Joule não resolve? A integração entre SAP e sistemas não-SAP (OData/iDoc/RFC/event-driven), a reconciliação do dado que o agente lê e o fiscal brasileiro (IBS/CBS em regime dual, NF-e, SPED). Nenhum modelo calcula seu tributo ou emite sua nota.
O que é clean core e por que importa aqui? É manter o núcleo do ERP padronizado e atualizável, empurrando integração e customização para camadas de extensão. Importa porque define o que fica na plataforma (trocável) e o que precisa ser seu por design (durável).
Como fazer o agente SAP render independentemente do modelo? Preparando o harness que a plataforma não faz: integração SAP↔não-SAP com contrato e event-driven, dado reconciliado (incluindo fiscal) e uma arquitetura clean core. Assim, trocar o modelo não quebra o agente.