SAP API Policy: Fakten, Risiken und Handlungsempfehlungen für Ihre KI Strategie

SAP zieht die Leitplanken ein: Was die neue API Policy für KI-Strategien im Mittelstand bedeutet

SAP hat im Mai 2026 eine überarbeitete API Policy veröffentlicht, die den Zugriff auf SAP-Schnittstellen durch KI-Agenten, Automatisierungstools und Drittanbieter-Plattformen grundlegend neu regelt. Für Unternehmen, die gerade ihre KI-Strategie aufbauen, hat das weitreichende Konsequenzen. Wir analysieren die wichtigsten Punkte und zeigen, welche Handlungsempfehlungen sich daraus ergeben.

Was regelt die neue SAP API Policy?

Die API Policy ist Teil der offiziellen SAP-Dokumentation und gilt für alle SAP Cloud-Lösungen sowie das On-Premise-Portfolio — inklusive S/4HANA Private Cloud (RISE) und sämtliche Line-of-Business-Lösungen. Sie verfolgt vier zentrale Ziele:

• APIs sollen bestimmungsgemäß genutzt werden — also nur so, wie es die Dokumentation vorsieht.
• Plattformstabilität und Sicherheit sollen geschützt werden.
• Missbrauch soll verhindert werden — insbesondere durch unkontrollierte automatisierte Zugriffe.
• Skalierbare Innovation soll unterstützt werden, gerade weil KI- und Agentic-Zugriffe zunehmen.

Wichtig: SAP betont, dass die Policy keine bestehenden Lizenzrechte oder funktionalen Berechtigungen ändert. Dennoch definiert sie klar, welche APIs genutzt werden dürfen — und welche nicht.

Die drei Kategorien: Erlaubt, geduldet, verboten

SAP unterscheidet künftig deutlich zwischen drei Typen von Schnittstellen:

1. Veröffentlichte APIs (Published APIs): Alle Schnittstellen, die im SAP Business Accelerator Hub, im SAP Help Portal oder in produktspezifischen Portalen (z.B. Ariba, Concur) dokumentiert sind. Diese dürfen im Rahmen der dokumentierten Limits genutzt werden.
2. Nicht-veröffentlichte APIs (Non-published APIs): SAP-interne Schnittstellen, die nie offiziell dokumentiert wurden, aber von vielen Kunden und Partnern genutzt werden. Diese fallen in die Kategorie „Nutzung auf eigenes Risiko“ — sie können jederzeit geändert oder entfernt werden.
3. Explizit verbotene APIs: Schnittstellen, die als „Confidential and Proprietary“ gekennzeichnet sind oder durch SAP Notes als nicht erlaubt klassifiziert wurden. Prominentes Beispiel: ODP-RFC für Drittanbieter-Tools.

Besonders relevant für den Mittelstand: Community-Blogposts und Forenbeiträge machen eine API nicht zur „Published API“. Nur die offizielle SAP-Dokumentation verleiht diesen Status.

Was bedeutet das für KI-Agenten und Automatisierung?

Hier wird es spannend — und gleichzeitig kritisch für viele Unternehmen, die gerade ihre KI-Strategie aufbauen. Die Policy verlangt explizit, dass KI-gesteuerte, agentic oder automatisierte Zugriffsmuster eine SAP-Endorsement benötigen. Die Begründung aus dem offiziellen FAQ-Dokument ist aufschlussreich:

• Volumen und Unberechenbarkeit: Ein einzelner Prompt an einen KI-Agenten kann tausende API-Aufrufe auslösen — in Mustern, die transaktionale APIs nicht verarbeiten können.
• Sicherheitsrisiken: Unabhängige Forschung zeigt, dass ein signifikanter Anteil von MCP-Servern statische, langlebige Credentials verwendet. Supply-Chain-Angriffe wie „Mini Shai-Hulud“ (SAP Note 3747787 siehe auch unseren Blogbeitrag zum Thema Vibe Coding auf der BTP) haben SAP-Ökosystem-Pakete direkt kompromittiert.
• Datenintegrität: Ein Agent ohne vollständigen Geschäftskontext kann versehentlich fehlerhafte Daten in das System zurückschreiben.

SAP erkennt dabei explizit an, dass Agentic AI ein wichtiger Trend ist. Die Einschränkung richtet sich gegen unkontrollierte, undokumentierte Zugriffsmuster — nicht gegen KI grundsätzlich.

Die zwei „endorsed“ Architekturen: MCP Gateway und A2A

SAP definiert zwei offizielle Wege für den KI-Zugriff auf SAP-Systeme:

1. MCP Gateway auf SAP Integration Suite: Ein vom Kunden verwalteter Einstiegspunkt mit Authentifizierung, Autorisierung, Rate Limiting und Audit Logging. Externe KI-Plattformen können über diesen Weg auf SAP zugreifen.
2. Agent2Agent (A2A) Protokoll: Für Multi-Agenten-Szenarien, in denen ein externer KI-Orchestrator Aufgaben an SAP-verwaltete Agenten delegieren muss. A2A ist ein offener Standard unter der Linux Foundation.

SAP positioniert sich hier als Standards-Entwickler, nicht als Standards-Konsument: Das Unternehmen ist Gold-Mitglied der Agentic AI Foundation (AAIF) und leitet den Workstream zu Agent Identity und Security.

Was heißt das konkret?

Unternehmen, die heute KI-Agenten direkt auf SAP-APIs loslassen — etwa über selbstgebaute MCP-Server oder direkte API-Aufrufe aus LLM-Orchestrierungstools — bewegen sich in einer Grauzone, die SAP zunehmend einschränken wird. Die bevorzugten Wege führen über SAP-kontrollierte Gateways.

Stimmen aus der Branche: „Nicht Restriktion, sondern Reifeschritt“

Die Reaktionen in der SAP-Community sind differenziert. Valentino Koester, Global SAP & AI Leader bei KPMG, bringt es in einer viel beachteten LinkedIn-Analyse auf den Punkt:

„SAP didn’t close its APIs. It redefined how AI is allowed to interact with SAP systems.“

Koester argumentiert, dass die Policy einen architektonischen Paradigmenwechsel markiert: weg von der Idee eines zentralen KI-Layers, der alle Workflows über SAP- und Non-SAP-Plattformen orchestriert, hin zu verteilter Intelligenz mit plattform-eigenen Ausführungsgrenzen:

• Distributed Intelligence statt zentraler Orchestrierung
• Federated Agents — KI-Systeme tauschen Absichten aus, statt gegenseitig Prozesse zu übernehmen
• Platform-owned Execution Boundaries — jede Plattform kontrolliert ihre eigene Ausführungsumgebung

Jennifer Maier (KPMG) ergänzt in den Kommentaren eine entscheidende Frage: Wer trägt die Verantwortung, wenn KI-Agenten autonom Entscheidungen priorisieren, Prozessflüsse ändern oder Aktionen über mehrere Systeme hinweg auslösen? Governance-Modelle und Kontrollmechanismen müssten sich parallel zur Technologie entwickeln — nicht Jahre später.

Diese Perspektive deckt sich mit einer zentralen Erkenntnis: Die API Policy ist weniger eine technische Einschränkung als vielmehr die Formalisierung dessen, was Enterprise-Architekten ohnehin wissen — unkontrollierte KI-Autonomie in transaktionalen Systemen ist kein tragfähiges Modell.

Vendor Lock-in oder legitime Governance?

SAP adressiert die Vendor-Lock-in-Frage direkt im FAQ. Die zentrale Aussage: Die Policy schränkt nicht die Nutzung von Drittanbieter-Integrationstools, KI-Plattformen oder Datenplattformen ein — vorausgesetzt, der Zugriff erfolgt über veröffentlichte SAP-APIs und „endorsed architectures“.

Dennoch ergibt sich ein differenziertes Bild:

• Drittanbieter-Integrationsplattformen dürfen weiterhin genutzt werden — aber nur über Published APIs und unter Einhaltung der Rate Limits.
• Drittanbieter-KI-Plattformen müssen über endorsed Architekturen (A2A via Joule/Agent Gateway) zugreifen.
• Drittanbieter-Datenplattformen erhalten SAP-Daten über BDC Connect und Delta Sharing — legacy-Pfade wie ODP-RFC werden explizit nicht mehr unterstützt.

Für Kunden bedeutet das: Die Wahlfreiheit auf der Nicht-SAP-Seite bleibt erhalten. Aber der Zugang auf der SAP-Seite wird zunehmend kanalisiert. Wer heute auf unkontrollierte API-Zugriffe setzt, muss umdenken.

Auswirkungen auf RISE-Kunden und bestehende Integrationen

Für Unternehmen im RISE-Transformationsprozess gibt es eine gute und eine weniger gute Nachricht:

Gut: Kundeneigene APIs im Z- oder Y-Namespace sind nicht betroffen. Custom RFCs, BAPIs und Function Modules bleiben erlaubt — solange sie keine SAP-internen APIs umgehen oder unkontrollierte Last erzeugen.

Weniger gut: Die Remediation bestehender Integrationen, die auf nicht-veröffentlichte SAP-APIs angewiesen sind, ist nicht automatisch im RISE-Scope enthalten. SAP empfiehlt, dies explizit während der Vertragsverhandlung zu klären.

SAP stellt Tools wie den ABAP Test Cockpit (ATC) mit Cloud Readiness Check bereit, um Abhängigkeiten von nicht-veröffentlichten Schnittstellen im eigenen Code zu identifizieren.

Fünf Handlungsempfehlungen für den Mittelstand

Basierend auf der Analyse der SAP API Policy und den Implikationen für mittelständische Unternehmen empfehlen wir folgende Schritte:

1. API-Inventur durchführen: Prüfen Sie, welche SAP-APIs Ihre Integrationen heute nutzen. Sind es Published APIs? Nutzen Sie den ATC Cloud Readiness Check, um Risiken zu identifizieren.
2. KI-Strategie auf Governance ausrichten: Wenn Sie KI-Agenten einsetzen, die auf SAP-Daten zugreifen, evaluieren Sie die endorsed Architekturen (MCP Gateway, A2A). Planen Sie keine Produktiv-Szenarien auf Basis unkontrollierter API-Zugriffe.
3. Plattformunabhängigkeit sichern: Setzen Sie auf Integrationsplattformen, die sowohl SAP-endorsed Wege als auch Non-SAP-Systeme anbinden können — ohne sich in eine einzige Vendor-Architektur zu begeben.
4. RISE-Verträge prüfen: Klären Sie vor Vertragsabschluss oder -verlängerung, ob die Remediation bestehender Integrationen im Scope enthalten ist.
5. Orchestrierungsschicht aufbauen: Statt KI-Agenten direkt auf einzelne System-APIs loszulassen, brauchen Sie eine Governance-Schicht, die Authentifizierung, Autorisierung, Rate Limiting und Audit Logging zentral steuert.

Die Simplifier-Perspektive: Souveräne KI-Orchestrierung als Antwort

Die SAP API Policy macht eines deutlich: Der direkte, unkontrollierte Zugriff von KI-Agenten auf Enterprise-Systeme ist keine tragfähige Architektur — unabhängig vom Vendor. Was Unternehmen brauchen, ist eine souveräne Orchestrierungsschicht, die zwischen KI-Agenten und Backend-Systemen vermittelt.

Genau das ist der Kern der Simplifier-Plattform: Als Agentic AI Platform für SAP-Unternehmen bietet Simplifier eine Architektur, die KI-Agenten governance-konform in bestehende Prozesslandschaften einbettet — mit vollständiger Kontrolle über Authentifizierung, Datenflüsse und Systemzugriffe.

Die entscheidenden Vorteile:

• Kein Vendor Lock-in: Simplifier setzt auf offene Standards (API-first, MCP-kompatibel) und gibt Kunden die volle Code-Ownership.
• SAP-native Integration: Tiefe SAP-Anbindung über veröffentlichte APIs — konform mit der neuen API Policy.
• Governance by Design: KI-Agenten werden über eine zentrale Runtime orchestriert, die Rollen, Berechtigungen und Audit Trails durchsetzt.
• Betrieb nach Kundenwahl: On-Premise, Hybrid oder souveräne Cloud — keine erzwungene Hyperscaler-Abhängigkeit.

Die SAP API Policy bestätigt eine Entwicklung, die wir seit langem vertreten: KI in Enterprise-Systemen braucht eine gesteuerte Ausführungsschicht. Nicht mehr „KI kann alles direkt“, sondern „KI wird orchestriert, governed und kontrolliert eingesetzt“.

Fazit: Die API Policy als Katalysator für bessere KI-Architekturen

SAPs neue API Policy ist kein Rückschritt, sondern ein notwendiger Reifeschritt. Sie erzwingt, was in der Enterprise-KI ohnehin überfällig war: Governance, kontrollierte Zugangswege und klare Architekturentscheidungen. Für mittelständische Unternehmen bedeutet das kurzfristigen Handlungsbedarf — aber langfristig stabilere und sicherere KI-Integrationen.

Die zentrale Frage für Entscheider lautet nicht mehr „Ob KI“, sondern „Wie orchestriere ich KI so, dass sie in meiner Enterprise-Landschaft sicher und governance-konform arbeitet?“

Wenn Sie diese Frage für Ihr Unternehmen beantworten möchten, sprechen Sie mit uns. Wir zeigen Ihnen, wie Sie KI-Agenten in Ihrer SAP-Landschaft produktiv einsetzen — ohne Governance-Risiken, ohne Lock-in und ohne Architekturkompromisse.

---

Quellen: SAP API Policy FAQ (Mai 2026, Version 1.1) | Valentino Koester (KPMG) — LinkedIn-Analyse