Política de API da SAP: a porta fechou para os agentes de IA?
Se a sua empresa acompanha o universo SAP, provavelmente já cruzou com essa discussão. Em abril de 2026, a SAP publicou uma nova Política de API. Em poucos dias, o assunto tomou as redes e a imprensa especializada. A leitura mais repetida foi a de que a SAP havia fechado a porta para agentes de inteligência artificial.
A reação é compreensível. Afinal, APIs são o caminho por onde os sistemas conversam. Qualquer regra nova nesse território mexe com projetos, orçamentos e planos de IA que já estavam em andamento.
Mas entre a notícia e o documento existe uma distância. E é justamente nessa distância que está a decisão certa para o seu ambiente.
O que a política realmente diz
A discussão se concentra na seção 2.2.2. Em resumo, o trecho proíbe que agentes autônomos de IA disparem sequências de chamadas contra APIs da SAP, além de vedar a extração de dados em larga escala.
Essa proibição, porém, vem acompanhada de uma ressalva importante. As restrições se aplicam apenas fora das arquiteturas endossadas pela SAP. Dentro dos caminhos previstos pela empresa, a integração com IA continua permitida, inclusive com plataformas de outros fornecedores.
Para entender a regra, é útil separar dois tipos de API. De um lado, As Published APIs são aquelas documentadas no SAP Business Accelerator Hub e na documentação oficial de produto, com uso previsto, suporte e maior estabilidade. Já as Non-Published APIs são interfaces internas em namespaces SAP, sem documentação pública. Nesse caso, o uso ocorre por conta e risco, sem garantia de continuidade.
Além disso, a política combina dois níveis de controle. O primeiro envolve limites específicos, definidos na documentação e no SAP Business Accelerator Hub, como quotas técnicas de requisição, ingestão e saída de dados. O segundo trata de usos que podem comprometer performance, estabilidade ou segurança, como scraping, extração em larga escala e integração com agentes autônomos fora das arquiteturas endossadas.
A SAP também declara monitorar o uso de APIs para apoiar compliance e estabilidade da plataforma. Ou seja, o acompanhamento faz parte da operação.
A imagem que melhor traduz a mudança não é a de uma porta fechada. É a de uma portaria nova. O acesso continua existindo, mas agora há um caminho definido para entrar.
Como a SAP pretende aplicar a política
A empresa descreve três frentes para colocar as regras em prática.
A primeira é a priorização do diálogo, com foco em uso seguro e acesso equilibrado. A segunda envolve verificações automatizadas, com a extensão do Cloudification Repository para classificar interfaces não liberadas ou explicitamente proibidas, além de checks de ATC para sinalizar consumo fora do padrão. A terceira é a oferta de soluções desenhadas para a nova realidade da IA, com arquiteturas de referência e orientações para dados e inteligência artificial.
Em resumo, os benefícios declarados para o cliente são estabilidade, melhoria proativa de performance e uma base mais segura para construir soluções de IA confiáveis.
E quem usa IA de outros fornecedores?
Essa era uma das maiores dúvidas do mercado. O FAQ oficial responde de forma direta: a política não obriga o cliente a adotar a IA da própria SAP.
Qualquer plataforma de IA pode se conectar ao ambiente SAP pelos caminhos endossados. Esses caminhos usam protocolos abertos e não tecnologias proprietárias. O Joule, assistente de IA da SAP, também não é obrigatório.
Em outras palavras, a escolha da plataforma de IA, da ferramenta de dados e da camada de integração continua sendo do cliente. O que muda é a necessidade de conectar esses recursos por arquiteturas reconhecidas pela SAP.
Minhas integrações vão continuar funcionando?
Para integrações baseadas em APIs publicadas, dentro do uso descrito na documentação, a SAP não espera impacto.
Por outro lado, o ponto de atenção está nas integrações construídas sobre interfaces não documentadas. Nesses casos, o documento declara que nada foi invalidado de forma retroativa. Essas integrações podem continuar funcionando, mas permanecem na mesma condição de antes: sem garantia de estabilidade, suporte ou continuidade.
A forma de aplicação também traz alguma tranquilidade. Para integrações existentes, a intenção descrita é contatar o cliente e entender o caso antes de qualquer medida restritiva. Bloqueios técnicos estão previstos, mas aparecem como último recurso diante de descumprimento.
O ponto que merece atenção de verdade: ODP-RFC
Aqui a mudança é mais concreta. A SAP classificou uma interface antiga de extração de dados, chamada ODP-RFC, como não permitida para uso por clientes e parceiros.
Isso afeta empresas que replicam dados do SAP para plataformas externas de análise, especialmente quando a ferramenta utilizada depende dessa interface. Se esse é o seu caso, não há motivo para pânico imediato, mas há necessidade de plano.
As alternativas suportadas estão documentadas pela SAP. Existem caminhos para replicação contínua, consumo analítico e compartilhamento de dados em larga escala. Desse modo, a escolha certa depende do volume, da frequência e do destino dos dados.
Como ficam os agentes de IA
A SAP publicou um guia oficial para mostrar como plataformas de IA de outros fornecedores devem se conectar ao seu ambiente. A lógica é simples: existem interfaces desenhadas para agentes externos e lakehouses de dados, sem exigir que o cliente use apenas soluções da própria SAP.
No caso dos agentes, o AI Golden Path orienta o desenvolvimento, a implantação e a gestão dentro do ecossistema SAP. A arquitetura combina componentes como Joule, Joule Orchestrator, Agent Gateway, Joule Studio, SAP BTP e SAP Cloud SDK for AI.
Existem dois modos principais de criar agentes. Um é mais visual, voltado a low-code. O outro é técnico, voltado a times de desenvolvimento. Em ambos, a comunicação pode ocorrer por padrões como A2A e MCP, com autenticação controlada.
Na borda dessa arquitetura, o Agent Gateway conecta agentes externos por meio do protocolo A2A. O MCP Gateway, hospedado na SAP Integration Suite, faz a ponte com ferramentas externas. Assim, agentes e clientes de IA de Google Cloud, Microsoft Azure, AWS, IBM Cloud e outros provedores podem se comunicar com soluções como S/4HANA, SuccessFactors, Business Data Cloud, Concur, Customer Experience e Business Networks.
O ponto central é este: fornecedores externos continuam podendo se integrar ao ambiente SAP, desde que usem interfaces desenhadas para esse fim, e não caminhos paralelos.
Como os dados de terceiros se conectam ao SAP
Para dados, a lógica é parecida. As aplicações SAP alimentam um núcleo governado, a partir do qual as informações podem ser consumidas por plataformas externas conforme o tipo de uso, o volume e o destino.
O Business Data Cloud aparece como base para centralizar e governar dados. O SAP Datasphere permite federação e replicação controlada. Já BDC Connect e Delta Sharing apoiam a integração com ambientes como Amazon Redshift, Amazon Athena, Microsoft Fabric, Google BigQuery, Databricks, Snowflake, Azure Data Lake, Amazon S3 e Google Cloud Storage.
Também há arquiteturas específicas para integração com Databricks, Snowflake, Google Cloud Platform, Azure e AWS.
A conclusão é direta: a escolha da plataforma de IA e da plataforma de dados continua sendo do cliente. O que passa a pesar mais é a governança sobre o modo como esses ambientes acessam o ecossistema SAP.
Onde as críticas têm razão
Nem toda crítica nasceu de uma leitura apressada. Grupos de usuários e consultores apontam lacunas reais.
O catálogo de APIs publicadas ainda não cobre todos os cenários de negócio. Como resultado, isso pode empurrar projetos legítimos para interfaces não documentadas. Também faltam definições contratuais mais claras e mais detalhes sobre o modelo de uso justo prometido.
São pontos válidos e merecem acompanhamento. Ao mesmo tempo, a SAP mantém canais para registrar a necessidade de novas APIs e afirma que dará aviso prévio antes de restringir qualquer interface de risco.
Por que isso está acontecendo agora
A explicação declarada pela SAP é operacional. Um único comando dado a um agente de IA pode gerar milhares de chamadas contra o sistema. As APIs transacionais não nasceram para esse padrão de uso.
Regras de limite e quota já são comuns no software corporativo. Soluções como SuccessFactors e Ariba documentam limites de requisição há anos. A novidade está menos no controle em si e mais na unificação das regras em um documento pensado para a era dos agentes.
Outro ponto importante: ferramentas de RPA baseadas em regras, sem decisão autônoma por IA, ficam fora do escopo da restrição da seção 2.2.2. Ainda assim, continuam sujeitas às demais regras da política.
O que fazer com essa informação
A pergunta útil não é se a política afeta o mercado. É se ela afeta o seu ambiente.
Três verificações ajudam a responder:
- Quais interfaces cada integração utiliza e quantas delas são APIs publicadas.
- Se alguma ferramenta de dados depende de ODP-RFC.
- Se algum piloto de IA acessa o SAP fora de um caminho governado.
Dessa forma, esse levantamento evita duas armadilhas. A primeira é paralisar projetos de IA por medo de uma proibição que não existe. A segunda é seguir adiante sem perceber uma dependência que precisa de migração.
A Megawork realiza esse trabalho em ambientes SAP, do inventário de interfaces ao desenho da arquitetura de ntegração e dados.
A pergunta, portanto, é simples: quais das suas integrações dependem hoje de interfaces não publicadas?
Além das APIs: agentes prontos no ambiente SAP
Enquanto isso, o debate se concentrou nas regras de acesso. Contudo, um fato passou despercebido. De fato, a SAP já oferece uma camada de agentes de IA prontos. Eles vêm incorporados às próprias soluções, com casos de uso definidos por área de negócio.
Para muitas empresas, o primeiro passo com agentes não é construir. Antes, é descobrir o que já existe. Na prática, o Agentes SAP Discovery reúne esses agentes e ajuda a identificar quais se aplicam à sua operação.
FAQ
Não. Qualquer plataforma de IA pode se conectar por arquiteturas endossadas, baseadas em protocolos como A2A e MCP. A restrição da seção 2.2.2 vale para acessos fora desses caminhos..
A SAP não espera impacto para integrações que usam APIs publicadas conforme a documentação. Para integrações existentes fora do padrão, a intenção declarada é conversar com o cliente antes de qualquer medida restritiva.
ODP-RFC é uma interface legada de extração de dados. A SAP a classificou como não permitida para uso por clientes e parceiros. As alternativas suportadas incluem replicação via SLT, ODP-OData, CDS Views analíticas e Business Data Cloud com Delta Sharing.
Não. As arquiteturas endossadas definem o lado SAP da integração. A plataforma de IA, a plataforma de dados e a ferramenta de integração seguem sendo escolha do cliente.
Ferramentas de RPA baseadas em regras, sem planejamento autônomo por IA, ficam fora do escopo da seção 2.2.2. As demais regras da política continuam valendo.
A SAP prioriza monitoramento e diálogo. Medidas técnicas, como throttling e suspensão, estão previstas como último recurso em casos de descumprimento.