Os dados da SAP finalmente podem sair da SAP. O que os agentes precisam é que o significado viaje junto
Em uma semana, SAP, Databricks e Google abriram caminhos para dados e semântica da SAP chegarem a agentes de IA. São quatro problemas diferentes, e só parte disso está em disponibilidade geral (GA).
Ouça este artigo · 4 min
Narração completa do artigo, gerada por IA.
Por vinte anos, tirar dados da SAP significou extração: um pipeline que copiava tabelas para um data warehouse, arrancava delas o contexto de negócio que lhes dava sentido e deixava a governança para trás na fronteira. Um campo chamado NETWR chegava ao warehouse; o conhecimento de que ele é um valor líquido de pedido na moeda do documento, e a quais documentos se aplica, ficava na SAP.
Isso era tolerável para dashboards feitos por gente que conhecia a SAP. Não funciona para agentes, que leem campos ao pé da letra e em escala. Na última semana de outubro, três fornecedores anunciaram respostas diferentes para esse problema, e vale a pena separá-las.
O que foi anunciado
A SAP, no TechEd Berlin, em 29 de outubro, detalhou novas capacidades do SAP Business Data Cloud. Concluiu a aquisição da Dremio e agora oferece SQL federado entre lakehouses e bancos como SQL Server, Oracle, MongoDB e Postgres sem mover dados, além de Apache Iceberg nativo e um catálogo universal com Apache Polaris. Concluiu também a aquisição da Reltio, e o SAP Reltio está em disponibilidade geral (GA) no BDC para master data multi-domínio com resolução de entidades baseada em IA. E apresentou o Ontology Manager, uma forma assistida por IA de montar visões por domínio do SAP Knowledge Graph, que conecta entidades de negócio, relacionamentos e regras. O exemplo da própria SAP é uma visão de agente de cobrança cobrindo clientes, faturas, condições de pagamento e risco de crédito.
A Databricks, em 30 de outubro, descreveu a próxima fase do SAP Databricks dentro do BDC. SAP Databricks e BDC Connect estão disponíveis hoje. Genie, Lakeflow, Unity Gateway e Lakebase dentro do SAP Databricks estão planejados, assim como uma integração de mão dupla entre o Genie, da Databricks, e o Joule, da SAP.
O Google, em 29 de outubro, colocou em disponibilidade geral o suporte ampliado a modelos semânticos do Knowledge Catalog. Ele ingere definições de negócio do Looker, do BigQuery, do dbt MetricFlow, do Snowflake, do Databricks e, via BDC, da Core Schema Notation da SAP. Quando duas ferramentas definem a mesma métrica de formas diferentes, as duas aparecem com sua procedência, para que os data stewards possam reconciliá-las. O Google cita benchmarks internos de quase quatro vezes mais acurácia dos agentes e até 75 por cento menos tokens; são números do Google, com metodologia não divulgada.
Quatro problemas, não um
É tentador arquivar tudo isso sob “camada semântica”. Os anúncios tratam de quatro formas diferentes de um agente falhar com dados enterprise.
| Falha do agente que ele resolve | Status | |
|---|---|---|
| Federação e zero-copy (Dremio, Iceberg, BDC Connect) | Não alcança o dado ou lê uma cópia desatualizada | Entregue pela SAP; adições da Databricks planejadas |
| Resolução de entidades (SAP Reltio) | Trata dois registros de um mesmo cliente como dois clientes | Em disponibilidade geral |
| Significado de negócio (CSN no Knowledge Catalog, Ontology Manager) | Usa a definição errada de uma métrica ou de um relacionamento | Suporte do catálogo em GA; Ontology Manager recém-apresentado |
| Agir na aplicação (Genie e Joule) | Consegue responder, mas não agir onde o processo acontece | Planejado |
Um agente pode ter o acesso perfeito e ainda assim contar o mesmo cliente duas vezes. Pode resolver os clientes corretamente e ainda calcular margem com uma definição que o financeiro abandonou no ano passado. Cada linha precisa do seu próprio dono e do seu próprio teste, e é por isso que defendemos que o contexto de um agente precisa de uma especificação com significado, evidência e atualidade como propriedades separadas.
A pergunta que vem a seguir
Quando escrevemos sobre agentes que leem definições de negócio onde elas vivem em outubro, a pergunta em aberto era qual definição vence. A resposta do Google, mostrar as duas com procedência, é honesta e incompleta: expõe o conflito e deixa a decisão para um steward.
A posição da SAP é diferente e, para clientes SAP, persuasiva. O ERP é onde as transações são registradas, então deveria ser onde o significado dessas transações é definido, e os agentes deveriam ler esse significado em vez de reconstruí-lo. É coerente com a aposta da SAP de que os agentes mais valiosos ficam dentro do sistema de transação.
Para os times de arquitetura, a sequência prática sai da tabela. Decida quem é dono de cada definição crítica antes de comprar um catálogo. Trate a resolução de entidades como um programa de qualidade de dados, não como um recurso de IA. E planeje em torno do que está em disponibilidade geral hoje; o Genie dentro da SAP e a integração entre Genie e Joule ainda são roadmap.