Setembro é o mês em que o medidor começa a rodar. Acaba a promoção gratuita do Joule for Developers (ABAP AI) e as capacidades passam a ser cobradas puramente por consumo, em AI Units — a moeda única que atravessa Joule e Joule Agents, funcionando como um saldo pré-pago drenado conforme o agente roda. A imprensa especializada já enquadrou o movimento pelo que ele é: FinOps de IA dentro do ERP. Em paralelo, seis assistentes de procurement (Category Management, Supplier Management, Requisition, Buying, Receiving e Services Procurement) chegam a disponibilidade geral em setembro de 2026 — mais capacidade agêntica ligada, mais consumo potencial. Traduzindo: a IA da SAP saiu do “experimente de graça” e entrou no “pague pelo que o agente trabalhar”. É um movimento natural e esperado. Mas há um recorte que a conta esconde e que este artigo destrincha: a AI Unit é função de quanto o agente precisa TRABALHAR — e o agente trabalha mais (queima mais unit) quando o dado está espalhado e a integração SAP↔não-SAP está bagunçada. Controlar a fatura, portanto, é engenharia de integração e dado — não “throttle no agente”.
O que muda em setembro: fim do grátis, ABAP AI por consumo (AI Units)
Durante a fase promocional, experimentar o ABAP AI e o Joule for Developers não pesava na fatura — era um convite para adotar. Isso muda agora: as capacidades passam a ser cobradas por consumo, e a régua é a AI Unit. Na prática, cada tarefa agêntica — gerar, explicar, refatorar, orquestrar — passa a ter um custo mensurável, drenado de um saldo.
A mudança não é um aumento de preço disfarçado; é uma mudança de modelo, de licença para consumo. E modelos de consumo têm uma característica que todo time de FinOps conhece: o custo deixa de ser previsível por assinatura e passa a variar com o uso real. Quem entende o que dirige esse uso controla a conta; quem não entende, recebe a fatura como surpresa.
Como a AI Unit funciona: moeda única de consumo, saldo pré-pago drenado conforme o agente roda
A AI Unit é desenhada como uma moeda única que atravessa as capacidades de IA da SAP — de Joule a Joule Agents. Funciona como um saldo pré-pago: você provisiona uma quantidade e ela é consumida à medida que os agentes executam trabalho. Quanto mais trabalho, mais unit; quanto mais eficiente o trabalho, menos unit para o mesmo resultado.
Esse detalhe — “menos unit para o mesmo resultado” — é o coração da questão. Duas empresas podem ligar exatamente os mesmos assistentes e ter faturas muito diferentes, porque o que determina o consumo não é só quantas vezes o agente é chamado, mas quanto esforço cada chamada exige. E o esforço é ditado, em grande parte, pela qualidade do dado e da integração por baixo.
FinOps de IA no SAP: a fatura é função de quanto o agente precisa trabalhar
Tratar isso como FinOps é o enquadramento correto. Em FinOps de nuvem, a conta não é só “quantos servidores” — é o quão eficientemente você usa cada recurso. Em FinOps de IA no ERP, a lógica é a mesma: a fatura é função de quanto o agente precisa trabalhar para entregar o resultado. E trabalho, aqui, é reprocessar contexto, buscar dado em vários lugares, reconciliar informação inconsistente e refazer o que ficou ambíguo.
É por isso que “usar menos” é uma resposta incompleta. Se o agente é obrigado a trabalhar o dobro por causa da bagunça embaixo dele, cortar chamadas apenas reduz o valor entregue sem atacar a causa do custo. A alavanca real é reduzir o esforço por tarefa — e isso é integração e dado.
O driver escondido de consumo: dado não-reconciliado e integração fora do clean core
Aqui está o driver que não aparece no slide de pricing. Quando o dado está espalhado por sistemas que não conversam, o agente precisa buscar, cruzar e reconciliar antes de agir — cada passo consome unit. Quando há custom code fora do clean core, o agente lida com complexidade acidental que poderia não existir. Quando a integração SAP↔não-SAP é frágil, o processo exige que o agente reprocesse contexto para compensar o que a arquitetura não entrega.
Some tudo isso e você tem um agente que trabalha o dobro para o mesmo resultado — e cobra o dobro em AI Units. A causa do custo alto não é “excesso de agente”; é a desordem embaixo que o obriga a trabalhar mais. É a mesma lógica de sempre em SAP: o que está fora do clean core cobra caro, e agora cobra também em consumo de IA.
Um exemplo concreto ajuda a enxergar o mecanismo. Imagine um agente que precisa validar um pedido cujo preço vive no S/4HANA, cujo estoque vive num WMS externo e cujo cadastro de cliente está num CRM não integrado. Para responder a uma única pergunta, ele consulta três fontes, reconcilia divergências e, muitas vezes, refaz a consulta porque o dado veio inconsistente. Cada um desses passos consome unit. O mesmo agente, sobre uma integração event-driven que já entrega o dado unificado e reconciliado, resolve em um passo — e cobra uma fração. A capacidade é idêntica; o que muda é o esforço que a arquitetura impõe.
O que o assistente NÃO cobre: integração SAP↔não-SAP e o fiscal BR (IBS/CBS, NF-e/SPED)
Há um pedaço que nenhum assistente cobre — e que no Brasil é incontornável: a localização fiscal. O IBS/CBS em regime dual é obrigatório em produção desde janeiro de 2026 (com alíquotas de teste, CBS em 0,9% e IBS em 0,1%), somando-se a NF-e, SPED e à camada de localização que exige integração com parceiro fiscal (Synchro, Mastersaf ou solução custom).
Esse trabalho fiscal não é feito pelo agente de IA da SAP — é engenharia de integração e reconciliação de dado, específica do país. Ou seja: mesmo com todos os assistentes ligados, o pedaço mais sensível e regulado do seu processo brasileiro continua dependendo da fundação de integração. Ignorar isso é descobrir, tarde, que o agente resolveu o genérico e deixou o fiscal — o que mais dói — de fora.
Pior: um dado fiscal inconsistente não é só um custo à parte — ele também alimenta o consumo. Quando a base tributária está desalinhada, qualquer agente que toque um processo com implicação fiscal precisa contornar a inconsistência, o que significa mais passos, mais reprocessamento e mais unit queimada. O fiscal brasileiro, portanto, entra na conta duas vezes: como escopo que o assistente não cobre e como fonte de desordem que encarece tudo o que o agente faz por perto.
Reduzir a fatura = integração enxuta + dado limpo, não throttle no agente
A conclusão prática inverte o instinto inicial. Diante de uma fatura de AI Units maior que o esperado, a reação natural é “vamos usar menos o agente”. Mas isso trata o sintoma. A causa é o esforço por tarefa, e a alavanca é integração enxuta (SAP↔não-SAP costurada com OData, iDoc, RFC e event-driven) mais dado limpo e reconciliado.
Um agente que lê dado confiável, opera sobre um clean core e conta com integração sólida faz menos passos, reprocessa menos contexto e entrega o mesmo resultado por menos unit. O medidor ligou para todo mundo — mas quem integrou bem paga menos pela mesma IA. É a diferença entre otimizar a causa e racionar o efeito.
A sequência que ancora: integrar e reconciliar antes de escalar o consumo
A ordem importa. Ligar mais assistentes sobre uma base desorganizada é escalar o consumo antes de controlar o custo — e a fatura cresce mais rápido que o valor. A sequência que ancora é a inversa: primeiro integrar e reconciliar, depois escalar. Enxugue a costura SAP↔não-SAP, reconcilie o dado (incluindo o fiscal), defina o que sai do S/4HANA para não virar consumo eterno — e só então acelere o uso dos agentes.
Essa disciplina transforma a chegada da cobrança por consumo de ameaça em oportunidade: quem arruma a fundação agora paga menos por cada AI Unit dali em diante, enquanto quem apenas liga capacidade paga a conta da própria desordem.
Há ainda um efeito composto que favorece quem age cedo. Como o consumo tende a crescer com o tempo — mais assistentes, mais casos de uso, mais volume —, cada ponto de eficiência ganhado na integração se multiplica ao longo dos meses. Reduzir o esforço por tarefa em 30% hoje não economiza 30% uma vez; economiza 30% sobre uma base de consumo que só aumenta. É o oposto do throttle, que corta valor no presente sem melhorar nada no futuro. Integração enxuta é o investimento que se paga mais de uma vez.
Como a CCX corta o consumo com integração SAP↔não-SAP e reconciliação fiscal
A CCX ataca exatamente o driver escondido da fatura. Na frente de Integrações & APIs Enterprise, com expertise em OData, iDoc e RFC e arquitetura event-driven, enxugamos a costura SAP↔não-SAP em tempo real — estoque, preço, pedido e nota fiscal sincronizados — reduzindo o quanto o agente precisa trabalhar e, com isso, o consumo de AI Units.
Na frente de Data & Business Intelligence, reconciliamos o dado (pipelines, data warehouse, ferramentas como BigQuery, Snowflake e Looker) e endereçamos o fiscal brasileiro — IBS/CBS dual, NF-e e SPED — para o agente não reprocessar contexto e queimar unit à toa. E em Consultoria em Tecnologia, definimos o clean core e a arquitetura-alvo: a decisão de o que sai do S/4HANA para não virar consumo eterno, com diagnóstico, TCO comparativo e roadmap.
A IA da SAP virou pago por consumo — e o que mais queima unit é dado não-reconciliado e integração bagunçada, não “agente demais”. Integrar SAP ao seu e-commerce → A CCX enxuga a costura OData/iDoc/RFC + event-driven, reconcilia o dado e o fiscal IBS/CBS e desenha o clean core — para você pagar menos pela mesma IA.
FAQ (People Also Ask)
O que são as AI Units da SAP? É a moeda única de consumo das capacidades de IA da SAP (Joule e Joule Agents): um saldo pré-pago drenado conforme o agente executa trabalho. Com o fim da promoção do ABAP AI/Joule for Developers em setembro de 2026, o consumo passa a ser cobrado nessa unidade.
Por que minha fatura de IA da SAP veio maior do que o esperado? Porque a AI Unit é função de quanto o agente precisa trabalhar. Dado espalhado, custom code fora do clean core e integração SAP↔não-SAP frágil fazem o agente reprocessar contexto e queimar o dobro de unit pelo mesmo resultado. A causa costuma ser integração e dado, não “agente demais”.
Os assistentes de IA da SAP cobrem o fiscal brasileiro? Não. O fiscal — IBS/CBS em regime dual (obrigatório em produção desde janeiro de 2026), NF-e e SPED — é engenharia de integração e reconciliação específica do país, feita com camada de localização e parceiro fiscal, fora do escopo dos assistentes.