No dia 2 do SAP TechEd, a SAP desceu um andar. Se no primeiro dia o assunto foi a porta governada — o gateway que orquestra agentes —, no segundo ela mostrou o que sustenta tudo: o dado. Chegaram o SAP-RPT-2.0 (um modelo-fundação para dado tabular/relacional, com detecção de anomalia e outlier, GA prevista para o 1º trimestre de 2027), o SAP-RPT-TS (previsão de séries temporais, no SAP IBP), a entrada da SAP Databricks na Business Data Cloud (Lakeflow, Agent Bricks, Unity, Lakebase), o lakehouse Dremio (Iceberg/Polaris, com um motor de consulta federada que lê o dado sem mover nem copiar) e a Reltio (MDM multidomínio) indo para a BDC. Rodou até na Estação Espacial Internacional, no edge, com o HPE Spaceborne-2. É um andar de dados impressionante. E ele deixa clara a lição de arquitetura que decide o seu projeto: a inteligência do agente para no dado que ele alcança — e metade desse dado mora fora da SAP.
1. O que a SAP anunciou no dia 2
O conjunto é coerente e ambicioso. O SAP-RPT-2.0 é um modelo-fundação treinado para dado tabular e relacional — o formato em que vivem os registros de um ERP —, capaz de detectar anomalias e outliers sem feature engineering manual. O SAP-RPT-TS leva a mesma ideia para previsão de séries temporais dentro do SAP IBP. A SAP Databricks entra na Business Data Cloud trazendo Lakeflow, Agent Bricks, Unity Catalog e Lakebase. O lakehouse Dremio (GA prevista para o 1º trimestre de 2027) adiciona Iceberg e Polaris e, o mais interessante, um motor de consulta federada que lê o dado onde ele está, sem precisar mover nem copiar. E a Reltio, de MDM multidomínio, entra para reconciliar dado mestre dentro desse ecossistema.
Traduzindo: a SAP não anunciou "IA em ação" no dia 2 — anunciou o andar de baixo que torna a IA possível. Modelo que entende o formato do dado corporativo, lakehouse que federa fontes e MDM que reconcilia identidade. É a fundação de dados do agente.
2. Por que isso importa pro agente: a inteligência para no dado que ele alcança
Um agente de IA não é mais inteligente que o dado que ele consegue ler. Pode ter o melhor modelo de raciocínio do mercado; se a informação que chega até ele está incompleta, desatualizada ou contraditória, a resposta será incompleta, desatualizada ou contraditória — com confiança de máquina. É por isso que a corrida de 2026 deixou de ser por modelo e passou a ser por fundação de dados: quem dá ao agente um dado bom, reconciliado e acessível, ganha; quem não dá, colhe alucinação operacional.
A SAP entendeu isso e está construindo um andar de dados forte para o que vive dentro do seu mundo. O ponto cego — e a oportunidade do projeto — é o que vive fora dele.
3. O limite: modelo tabular e federação resolvem o dado SAP, não o não-SAP que decide a resposta
Um modelo-fundação tabular treinado sobre o dado SAP entende muito bem o dado SAP. Um lakehouse que federa fontes resolve lindamente as fontes que já estão no padrão — catalogadas, com esquema conhecido, acessíveis por Iceberg. Esses são avanços reais. Mas eles compartilham um pressuposto: o dado está, em larga medida, dentro de casa ou já padronizado. Para uma operação brasileira típica, esse pressuposto não se sustenta — porque a metade do dado que decide a resposta ao cliente não está na SAP.
Consulta federada é ótima para ler sem mover. Mas ela pressupõe que você consiga apontar para a fonte e confiar que o mesmo cliente, o mesmo produto, o mesmo pedido estão representados de forma reconciliável entre as fontes. Quando os identificadores não batem — e, entre SAP e o mundo não-SAP, raramente batem —, federar te dá acesso a duas verdades diferentes sobre a mesma entidade. O problema deixa de ser de conectividade e passa a ser de reconciliação.
4. Onde mora o dado que decide (e por que os IDs não batem)
Pense no que o agente precisa para responder a uma pergunta de negócio real. O catálogo e o pedido vivem no e-commerce. A posição e a reserva vivem no OMS. A nota, o tributo e o CFOP vivem no fiscal/NF-e. O histórico e o contato vivem no CRM. Contratos, condições especiais e casos de borda vivem no legado. Nenhum desses sistemas nasceu falando o idioma de chaves da SAP.
O resultado é o problema clássico de dado mestre: o produto tem um SKU no e-commerce e um código de material no ERP; o cliente tem um id no CRM e um número de parceiro de negócio no SAP; o pedido tem um número na plataforma de venda e outro no ERP. Enquanto um humano concilia isso "no olho", o agente precisa de uma correspondência explícita e confiável — senão ele soma maçãs com laranjas e responde com segurança sobre uma entidade que não existe. É aqui que a federação, sozinha, não chega.
O caso brasileiro agrava o problema por um motivo específico: a camada fiscal. A NF-e, o CFOP, a tributação por estado e por tipo de operação formam um domínio de dado que raramente mora no SAP de forma completa e que precisa casar exatamente com o pedido, o cliente e o produto para a nota sair certa. Um agente que responde sobre prazo, cobrança ou devolução precisa que o pedido no e-commerce, a posição no OMS e o documento fiscal estejam amarrados ao mesmo registro — e essa amarração cruza justamente a fronteira SAP ↔ não-SAP que a federação por si só não reconcilia. É um dado que decide a resposta e que, por natureza, é distribuído.
5. Federar não basta: reconciliar dado mestre SAP ↔ não-SAP
Federar é dar acesso; reconciliar é garantir que o que você acessa é a mesma coisa. A reconciliação de dado mestre — produto, cliente, pedido, fiscal — entre o SAP e o mundo não-SAP é o trabalho que transforma "consigo consultar as duas fontes" em "sei que é o mesmo cliente nas duas". É mapear chaves, resolver duplicatas, definir qual atributo é autoritativo em cada fonte, manter a correspondência viva à medida que os sistemas mudam. A SAP oferece a peça interna (Reltio na BDC); a ponte até o não-SAP brasileiro — e-commerce, OMS, fiscal/NF-e, CRM, legado — continua sendo engenharia de integração e de dado.
E "manter viva" é a parte que separa um projeto de reconciliação de um de-para de planilha. Sistemas mudam: o e-commerce migra de plataforma, o CRM ganha um novo campo, o ERP reorganiza o cadastro de materiais. Uma reconciliação feita uma vez e esquecida apodrece — os IDs que batiam param de bater, e o agente volta a responder sobre entidades que divergiram no silêncio. Por isso a ponte não é um projeto de carga única: é uma camada de integração que recebe as mudanças na origem por evento, atualiza a correspondência e expõe o dado mestre reconciliado de forma contínua, com qualidade e linhagem — para que a federação da SAP tenha, do lado não-SAP, entidades em que ela possa confiar.
6. Como a CCX constrói essa ponte de dado
É esse o projeto que a CCX entrega. A frente de Integrações & APIs Enterprise, somada à expertise em MuleSoft (Anypoint Platform, API-led connectivity), constrói a ponte de dado entre a Business Data Cloud/SAP e o não-SAP: federar o que dá para federar (Iceberg/Dremio) e, acima disso, reconciliar identidade e dado mestre — produto, cliente, pedido, fiscal — com os IDs batendo entre SAP e e-commerce, OMS, CRM e legado, com a expertise de integração SAP em OData, iDocs e RFC.
Sobre essa base, a frente de Data & BI modela e reconcilia o dado multidomínio que alimenta os agentes — MDM SAP ↔ não-SAP, qualidade e linhagem — e a Observabilidade 360° rastreia de qual fonte o agente leu cada campo. A SAP deu o andar de baixo (modelo tabular + Databricks + Dremio); construir a ponte desse andar até o seu não-SAP é o que faz o agente, enfim, responder certo.
A inteligência do agente para no dado que ele alcança. A SAP ergueu o andar de dados; a ponte até o seu não-SAP — federar e reconciliar produto, cliente, pedido e fiscal com os IDs batendo — é o projeto. A CCX constrói essa ponte: Integrações & APIs Enterprise + MuleSoft + Data & BI. Integrar SAP ao seu e-commerce →
7. Perguntas frequentes
O que é o SAP-RPT-2.0? É um modelo-fundação da SAP treinado para dado tabular/relacional — o formato dos registros de ERP — capaz de tarefas como detecção de anomalia e outlier sem feature engineering manual, com GA prevista para o 1º trimestre de 2027. O SAP-RPT-TS é a variante para previsão de séries temporais.
O Dremio federa dado não-SAP? O Dremio consegue consultar fontes externas via Iceberg/Polaris sem mover o dado. Mas federar o acesso não reconcilia as entidades: se o mesmo cliente ou produto tem identificadores diferentes entre SAP e os sistemas não-SAP, a consulta federada devolve versões que precisam ser reconciliadas por MDM.
Como reconciliar dado mestre entre SAP e e-commerce? Mapeando as chaves (material ↔ SKU, parceiro de negócio ↔ id de cliente, pedido ERP ↔ pedido da plataforma), definindo a fonte autoritativa por atributo e mantendo a correspondência viva por uma camada de integração — com OData, iDocs e RFC do lado SAP e APIs do lado não-SAP.
Por que o agente precisa de dado reconciliado, e não só federado? Porque federar dá acesso a várias fontes, mas se a mesma entidade aparece diferente em cada uma, o agente combina dados que não correspondem e responde com confiança sobre algo inconsistente. Reconciliar garante que "o mesmo cliente" seja, de fato, o mesmo.