Todo board quer IA rodando no SAP porque viu o Joule no palco. A resposta curta para "quando ligar a IA no SAP" ganhou, esta semana, um argumento que desmonta a pressa: nem a própria SAP botou a IA para rodar solta. O CEO Christian Klein prometeu mais de 400 agentes e 50 assistentes para o segundo semestre de 2026 e uma nova plataforma de IA de negócios — mas adiou a disponibilidade geral de propósito, explicando que segurou o lançamento "até a SAP controlar totalmente o ciclo de vida do agente" (governança, acurácia, permissão), e cravou o número que expõe a base: 60% dos sistemas SAP instalados ainda não estão na nuvem, o que ele mesmo aponta como gargalo para o deploy amplo. Tração real hoje: 150 clientes de Joule Work. A leitura é dura para qualquer mesa de TI: se o dono da plataforma respeita a fila — primeiro a nuvem, primeiro a governança do agente — colocar agente por cima de uma migração inacabada e sem governança não é ousadia, é furar a fila que o próprio fornecedor não furou.
IA no SAP: a resposta curta (nem a SAP botou pra rodar solto)
O gargalo para IA no SAP não é o modelo (o Joule). É migração concluída + integração que faz o dado circular + governança do agente — nessa ordem. E quem está dizendo isso, na prática, é a própria SAP: ela poderia ter lançado a plataforma de agentes no início de 2026 e escolheu segurar até controlar o ciclo de vida; e reconheceu que a maioria da base nem tem a nuvem, pré-requisito para acessar as capacidades de IA. Se você tem um board pressionando "por que a gente não tem o Joule rodando?", a resposta ganhou um argumento novo e forte: porque nem a SAP botou pra rodar solto — ela adiou o GA de propósito e admitiu o gargalo da nuvem. Primeiro a fundação; depois o agente rende. O resto do texto abre as três verdades que essa fala expõe.
O que a SAP comprometeu e o que segurou
Os números do comprometimento contam a história sozinha. Mais de 400 agentes e 50 assistentes prometidos para o segundo semestre de 2026 — a ambição. Disponibilidade geral adiada de propósito, com o CEO dizendo que segurou "até a SAP controlar totalmente o ciclo de vida" do agente — o freio. 60% da base instalada fora da nuvem, apontado por ele como gargalo para o deploy amplo — a realidade da fundação. E 150 clientes de Joule Work — a tração real hoje, muito distante dos 400+ agentes anunciados. Junte as peças: uma promessa grande, uma tração pequena e um gargalo declarado de fundação. O dono da plataforma, que teria o caminho mais fácil para embarcar a IA, escolheu frear por governança e por migração.
Por que o dono da plataforma freou de propósito
O ponto que merece atenção é o porquê do freio. A SAP não adiou por falta de modelo — adiou para controlar versão, acurácia e permissão do agente antes de escalar. Em outras palavras: o fornecedor que mais conhece o próprio produto decidiu que soltar agentes sem AgentOps (governança do ciclo de vida) era risco, não vanguarda. E foi explícito sobre a fundação: sem a migração S/4HANA/nuvem, o cliente não acessa as capacidades de IA. Quando o dono da plataforma respeita essa sequência publicamente, ela deixa de ser opinião de consultoria e vira referência do próprio fornecedor. É contra esse pano de fundo que o seu piloto precisa ser lido.
Verdade 1 — Se a SAP freia por governança, seu piloto sem governança é risco, não vanguarda
A SAP adiou o GA para ter a governança do agente — versão, permissão, acurácia — exatamente o AgentOps que a maioria dos pilotos não tem. Se o fornecedor que controla a plataforma inteira achou que soltar sem isso era arriscado demais, o seu piloto solto, sem versionamento, sem escopo por agente e sem medição de acurácia, não é ousadia competitiva — é a mesma exposição que a SAP recusou correr, só que sem a estrutura da SAP por trás. Colocar agente em produção sobre dado sensível de ERP sem governar o ciclo de vida do agente é o tipo de decisão que parece rápida na demo e cara no incidente.
Verdade 2 — 60% fora da nuvem: migração é pré-requisito, não paralelo
O número mais desconfortável é o 60%. Se a maioria da base instalada ainda não está na nuvem, para a maioria dos clientes a fundação não está pronta — e sem a migração S/4HANA/nuvem não há acesso às capacidades de IA. A SAP está dizendo, com todas as letras, que migração é pré-requisito, não paralelo: não dá para "ligar o Joule enquanto migra". Isso reposiciona a conversa dentro da empresa: antes de discutir agentes, a pergunta é se a migração terminou. Tratar migração e IA como trilhas paralelas é ignorar o gargalo que o próprio fornecedor declarou — e é a receita do piloto que nunca escala porque a base embaixo dele não sustenta.
Verdade 3 — A integração é o que faz (ou não) o dado circular
Mesmo com a nuvem pronta e a governança montada, sobra a peça que decide se o agente rende: a integração que faz o dado circular entre S/4HANA, e-commerce, WMS, fiscal e BI. Um agente governado sobre dado que não circula é agente de silo — bonito na demo, parado na escala, respondendo com informação incompleta porque o dado dele mora em outro sistema. A IA no SAP só entrega valor quando o dado do pedido, do estoque, do fiscal e do cliente chega ao agente em tempo real, integrado. Sem essa camada, você tem um agente que sabe muito sobre um pedaço e nada sobre o resto — e decisões parciais em produção são piores que nenhuma automação.
A sequência que o fornecedor respeitou (agnóstica de ERP)
Junte as três verdades e você tem a sequência que a própria SAP respeitou: nuvem/migração → integração → governança do agente → agente. Primeiro a fundação (migração concluída), depois o encanamento (dado circulando entre os sistemas), depois a governança (versão, permissão, acurácia por agente), e só então o agente em escala. E a tese é agnóstica de ERP: vale para SAP, mas a lógica — migração + integração + governança antes do agente — vale para Protheus, Oracle, qualquer ERP. O erro que se repete é inverter a ordem: começar pelo agente (o que impressiona o board) e descobrir, na escala, que a fundação, o dado e a governança não estavam prontos. A SAP acabou de mostrar a ordem certa ao respeitá-la no próprio produto.
Como a CCX monta essa sequência
Quer montar a fila que a própria SAP respeitou — em vez de furá-la e chamar de piloto? É isso que a CCX monta, na ordem certa. As Migrações de Plataforma concluem ou destravam a migração S/4HANA/nuvem que a SAP diz ser pré-requisito — a fundação que 60% da base ainda não tem, e sem a qual não há acesso à IA. As Integrações SAP ↔ e-commerce (e WMS, fiscal, BI) fazem o dado circular em tempo real, com arquitetura orientada a eventos, para o agente não ficar em silo. A Security Engineering monta a governança do agente que a própria SAP adiou o GA para ter: versão, permissão, escopo e acurácia por agente. E o Data & BI garante o master data limpo para o dado circular e o agente render. Por cima, a Consultoria em Tecnologia mapeia a sequência — nuvem/migração, integração, governança, agente — para você não furar a fila. Primeiro a fundação; depois o agente rende. Integrar SAP ao seu e-commerce →
Perguntas frequentes (FAQ)
Por que a SAP adiou o Joule?
Segundo o CEO Christian Klein, a SAP poderia ter lançado a plataforma de agentes no início de 2026 e segurou de propósito "até controlar totalmente o ciclo de vida do agente" — governança, acurácia e permissão — antes de escalar. Ele também apontou que 60% da base instalada não está na nuvem como gargalo para o deploy amplo. Ou seja: o freio foi por governança e por migração, não por falta de modelo.
Preciso migrar pra nuvem antes de usar IA no SAP?
Para a maioria dos cenários, sim. A própria SAP indica que, sem a migração S/4HANA/nuvem, o cliente não acessa as capacidades de IA — por isso o CEO tratou os 60% fora da nuvem como gargalo. A migração é pré-requisito, não uma trilha paralela que você roda "enquanto liga o Joule".
O que é governança de agente de IA?
É o controle do ciclo de vida do agente: qual versão está em produção, quem tem permissão para quê, com que escopo, e como se mede e mantém a acurácia — além de como aposentar um agente sem quebrar processos. É o "AgentOps" que a SAP adiou o GA justamente para ter, e a ausência dele é o que transforma um piloto em risco em produção.
Por que meu piloto de IA no SAP não escala?
Quase sempre porque a fundação embaixo dele não está pronta: migração incompleta, dado que não circula entre S/4HANA, e-commerce, WMS, fiscal e BI, e nenhuma governança do agente. Inverter a ordem — começar pelo agente antes da migração, da integração e da governança — é a causa mais comum do piloto que impressiona na demo e para na escala. A sequência que a SAP respeitou é: fundação, integração, governança e, então, agente.
Se nem o dono da plataforma botou a IA pra rodar solta, furar a fila não é vanguarda — é piloto parado. A pergunta não é "quando a gente liga o Joule?"; é "minha migração terminou, meu dado circula e eu tenho a governança do agente que a própria SAP disse que ia montar antes de escalar?". Montar a sequência que a SAP respeitou — migração, integração e governança — com a CCX →