SAP's API Policy v4/2026: who owns your ERP data when agents read it?

What Section 2.2.2 actually says

The clause is short and intentionally broad. SAP customers can continue to use SAP APIs for the integration scenarios they always have. What is now explicitly excluded is the new pattern that exploded in 2025: autonomous or generative AI systems planning, selecting, and executing sequences of API calls against SAP. The wording is wide enough to cover most agentic frameworks that have been built on top of SAP in the last twelve months.

What that means in practice:

• Microsoft Copilot Studio agents calling S/4HANA APIs — out of scope of the licence.
• n8n, LangChain, LangGraph, CrewAI, AutoGen workflows that orchestrate SAP-API calls — out of scope.
• Salesforce Einstein / Agentforce agents reaching into SAP via the BAPI/OData layer — out of scope.
• In-house Python or Node services that wrap an LLM around the SAP API surface — out of scope.

What stays in scope: SAP's own AI surface — Joule, the Joule Agent Gateway, and the Business AI Platform — running against SAP APIs natively. That is the pattern the policy is designed to leave standing.

Why the policy is bigger than a licensing detail

The most common framing in coverage so far is vendor protectionism: SAP locking out competitors. That framing is correct as far as it goes, but it misses the structural question the policy raises.

An ERP runs on the customer's business data. The customer entered it, owns it, and is the data controller under DSGVO. When an autonomous agent reads from SAP, the agent acts on the customer's behalf. If SAP can decide which agents are allowed to read that data and which are not, SAP is exercising a control right over the customer's own data. That is not a licensing question. That is a data-ownership question.

The policy makes the answer explicit: when an agent reads SAP data via SAP APIs, SAP claims a say in which agent is allowed. Customers who hadn't realised the question was open now have an answer.

The architectural escape hatch

There is one architectural pattern the policy doesn't touch: replicate the data the agents need into a customer-owned data plane, and let the agents reason against the customer's copy. The SAP API contract terminates at the replication boundary. The agent reasons against data the customer controls. SAP's API policy has no jurisdiction over the customer's own data store.

In practice this is a familiar architecture, not a new invention. It is the same separation that B2B integration has used for decades — extract a working copy of the relevant business objects, transform them into the schema your downstream consumer needs, load them into the target. Agents are just the latest kind of downstream consumer. The integration plane needs to be customer-owned (not hosted inside SAP-managed products), with provenance, lineage, and replay that are not metered by the source system.

We've written more about this architecture in our companion paper on the PI/PO to Cloud Integration transparency gap, which lays out the meta-layer pattern in detail. The agentic-AI angle is the same architecture viewed from a different downstream consumer.

What it means for SAP-anchored Mittelstand

Most German Mittelstand IT teams are mid-evaluation on AI workloads against SAP. The new policy gives them three honest options:

1. Wait for Joule. Accept the gating (RISE/GROW, on-prem locked out, opaque pricing) and use only SAP's own AI surface. The roadmap dictates the timeline.
2. Pause non-SAP agent work. Halt Copilot / n8n / LangChain projects that reach into SAP. Wait for either a policy revision or a viable Joule alternative. Lose 12–24 months of compounding capability.
3. Build a customer-owned data plane. Replicate the business objects the agents actually need (Sales Order, Material, Customer, Open Items, Aging) into a sovereign integration plane. Let agents reason against that copy. The SAP API contract stays narrow and intact.

Each option has trade-offs. The third is the only one that preserves both the SAP investment and the agentic AI runway.

Sources we trust on this

• Kai Waehner — Data ownership in the age of agentic AI (May 2026) — the strongest architectural read of the policy
• CIO.com / DSAG — DSAG criticises SAP's new API policy — the customer-side response in writing
• The Register — New SAP API policy provokes (April 2026) — mainstream coverage of the dispute
• SAP Community — Impacts on existing customer integrations — the SAP-internal Q&A thread, useful for the practitioner counter-position