On 27 April 2026, SAP updated its API policy with surprisingly little fanfare. No press release. No customer advisory. The document simply appeared. Within days, the enterprise technology community had read it carefully enough to react with alarm.

The clause that changed everything is Section 2.2.2 of API Policy v4/2026, published at API Policy. It reads, in part: SAP prohibits API use for interaction or integration with semi-autonomous or generative AI systems that plan, select, or execute sequences of API calls, except through SAP-endorsed architectures.

That is not a technical footnote. It is a strategic declaration. And SAP is not alone.

‍The question is no longer whether AI can access enterprise data. The question is who decides the terms on which it does.

What SAP Just Did

In plain language: Microsoft Copilot is out. Salesforce Einstein is out. The hundreds of agentic tools built on Claude or GPT-4 that connect to SAP data via API are now formally in violation. The only permitted path for AI agents runs through SAP's own endorsed stack: Joule (the AI assistant), Business Data Cloud (the data layer), and Agent Gateway (the integration controller).

SAP's own AI sits on the permitted side of the line it just drew. Everyone else's does not.

To understand the scale of the problem this creates: DSAG's 2026 investment survey found that only 3% of SAP customers use Joule in production. Meanwhile, 77% of AI-active SAP enterprises are already running Microsoft Copilot. SAP has effectively blocked the AI tool that 97% of its own customers are actually using.

CEO Christian Klein told investors on the Q1 call that customers will not be charged to access their own data and that SAP wants an open platform. He positioned the policy as protecting system stability, not blocking AI. He is not entirely wrong. An agentic loop gone wrong can destabilize a mission-critical ERP. That is a legitimate concern.

But stability protection and competitive moat are not mutually exclusive. Both things are true simultaneously. SAP invested heavily in Joule, then drafted a policy that routes all autonomous AI traffic through Joule's architecture. That asymmetry is commercially convenient. Enterprises should name it clearly. ‍

SAP Is Not the Only One

The SAP move is explicit. The broader industry is doing the same thing more quietly.

The pattern is the same everywhere: build your own AI capability, then control the on-ramp. Not by blocking AI outright. By making it significantly harder for anyone else's AI to compete inside your data estate. ‍

Who Owns the Data?

Three things are in dispute simultaneously, and they are legally distinct. ‍

Raw Data: Yours

The EU Data Act, effective September 2025, anchors customer rights to data generated in connected systems. SAP acknowledged this. Your transactions, payroll records, and procurement history belong to you. SAP cannot claim ownership of the content. ‍

Data Structure and Schema: Theirs

The underlying data model, the table structures, the business logic encoded into SAP's schema, the semantic layer that makes raw data meaningful: SAP built that. It is their intellectual property. Accessing your data through SAP's proprietary architecture is not the same as simply reading your own records. You are using SAP's structure to do it.

This matters enormously for AI. A language model does not just read data. It learns from schema patterns and relationship structures. The data is yours. The architecture that gives it meaning may not be. ‍

Practical Access: Contested

A legal right without an integration layer is not operational. SAP acknowledges data ownership. But if the only approved path for an AI system to access that data runs through SAP-endorsed architectures, your legal entitlement is real and your practical leverage is constrained. Rights and access architecture are entirely different problems.

‍You can own your data completely and still find yourself unable to use it on your own terms. That is not a contradiction. It is the design. ‍

Is It Legal?

Almost certainly yes. Vendors set API terms. Courts have consistently upheld that right, from Twitter's third-party restrictions to LinkedIn's action against scrapers. SAP is on solid legal ground.

The sharper question is competition law. The EU Digital Markets Act imposes interoperability obligations on designated gatekeepers. SAP is not yet formally designated. If it were, this policy would face a serious challenge. That designation conversation should start now.

The DSAG, representing tens of thousands of SAP customers, has called the policy unacceptable. Not because SAP lacks the right to set terms, but because they were changed unilaterally, the scope is vague, and existing integrations are left in legal limbo. That grievance is entirely legitimate. ‍

The Strategic Picture

SAP's value proposition always rested on three things: feature depth, process breadth, and data lock-in. AI erodes all three. An agent that reasons across your data in real time is a credible substitute for significant ERP functionality. If that agent is third-party, SAP loses the relationship entirely.

Restricting the API is the defensive move. Acquiring German AI startup Prior Labs for one billion euros is the offensive one. Control the access layer, embed the AI, keep the customer. Coherent strategy. Uncomfortable reality for everyone paying the licence fees.

‍Vendor valuations are down sharply. AI-native alternatives are eroding the case for expensive legacy platforms. This policy is not just competitive strategy. It is a survival move by incumbents who can see the cliff edge clearly.

‍What Boards, CIOs and User Communities Must Do

Three actions for enterprises. One demand for user communities.

• Audit your AI integrations immediately. Every third-party agent pulling from SAP, Salesforce, ServiceNow, or Workday via API is potentially non-compliant today. Know your exposure before your vendor does.
• Build an independent data layer. Extract your data into your own warehouse. Let AI agents consume freely from there. This severs the dependency on vendor-controlled access architecture. It is the same move enterprises made with mainframes. The logic is identical.
• Negotiate AI access rights at every renewal. API access, data portability, and the right to use third-party AI on your own data must be explicit contractual terms, not assumptions. Every renewal is now an AI negotiation.
• User communities: make noise, collectively and loudly. DSAG has already called this unacceptable. UKISUG, ASUG, SUGEN and every regional SAP user group should follow with a coordinated, public, and unambiguous demand: revert the unilateral change, clarify the scope in writing, grandfather existing integrations, and submit to independent review under the EU Data Act. Vendors respond to organised customer pressure. Silence is interpreted as consent. ‍

The Bottom Line

Software vendors cannot stop AI. But they can control the on-ramp, and that is exactly what Section 2.2.2 does. This is the opening move in a long fight over who controls AI access to enterprise data. Other vendors are watching. Regulators are watching. The enterprises that act now, contractually, architecturally, and collectively through their user communities, will have options. Those that wait will find the terms set for them. ‍

The next policy update will also arrive without a press release.