SAP API Policy 2026: Auswirkungen auf Clean Core, RISE und KI-Architekturen
Warum die neue SAP API Governance Unternehmen, Integrationen und AI-Projekte nachhaltig verändert
Die neue SAP API Policy gehört zu den wichtigsten Governance-Änderungen im SAP-Ökosystem seit Einführung von Clean Core und SAP BTP. Sie definiert erstmals produktübergreifend, welche SAP APIs offiziell genutzt werden dürfen, wie KI-Agenten auf SAP-Systeme zugreifen sollen und welche Integrationsmuster als compliant gelten. Besonders relevant ist die Policy für Clean-Core-Strategien, RISE-Projekte und AI-basierte Automatisierungsszenarien.
Das Dokument ist technisch präzise, juristisch defensiv formuliert und bewirkt in der Praxis mehr als der sachliche Ton vermuten lässt. Die DSAG reagierte unmittelbar mit einer deutlichen Stellungnahme.
Was bedeutet das für Kunden, Partner und laufende RISE-Projekte? Dieser Beitrag gibt eine fundierte Einordnung.
Was die API Policy konkret regelt
Die neue Policy verfolgt nach eigenen Angaben vier Ziele: Sie soll sicherstellen, dass APIs bestimmungsgemäß genutzt werden, die Plattformstabilität schützen, Missbrauch verhindern und skalierbare Innovation unterstützen – gerade angesichts des stark wachsenden KI- und Automatisierungsbedarfs.
Kern der Policy ist die Definition von „Published APIs“: Als veröffentlichte und damit offiziell nutzbare Schnittstellen gelten ausschließlich solche, die im SAP Business Accelerator Hub oder in der jeweiligen Produktdokumentation ausgewiesen sind. Schnittstellen, die nur über Debugging, Reverse Engineering oder Community-Beiträge bekannt wurden, gelten ausdrücklich als nicht erlaubt.
Darüber hinaus legt die Policy fest, dass SAP APIs Rate Limits, Throttling und andere technische Kontrollen unterliegen können. Und: Autonome, ungesteuerte KI-Agenten, die SAP-APIs im Hintergrund aufrufen, ohne durch eine SAP-endorsed Architektur (MCP Gateway auf der SAP Integration Suite oder A2A-Protokoll) zu laufen, sind aus dem Rahmen der erlaubten Nutzung herausgefallen.
Wichtig zu verstehen
Die Policy ändert laut SAP keine bestehenden Vertragsverhältnisse und keine lizenzierten Funktionsberechtigungen. Es handelt sich um einen technischen Ordnungsrahmen – der jedoch Auswirkungen auf die erlaubten Nutzungsmuster hat.
Was die DSAG kritisiert – und warum das berechtigt ist
Die DSAG hat sich am 29. April 2026 klar positioniert. Drei Kritikpunkte stechen hervor:
Fehlende Vertragssicherheit: Der SAP Business Accelerator Hub und die Produktdokumentationen sind nach Auffassung der DSAG bislang nicht eindeutig als Vertragsbestandteile ausgestaltet. Damit fehlt die rechtliche Verbindlichkeit: Änderungen an den dort dokumentierten APIs könnten formal ohne vertragliche Konsequenz durchgeführt werden. Das ist aus Unternehmenssicht keine tragbare Basis für architektonische Entscheidungen.
„Die DSAG fordert schon länger absolut belastbare Vertragsdokumente. SAP nimmt jedoch bei der API Policy eine gegenläufige Position ein.“
Michael Bloch, DSAG-Fachvorstand Lizenzen, Vertragswesen & Support
Unklares Fair-Use-Modell: SAP hat laut DSAG angekündigt, ein Fair-Use-Preismodell für die API-Nutzung einzuführen. Dessen konkrete Ausgestaltung ist bisher nicht dokumentiert. Das erinnert an das Digital-Access-Modell, das für erhebliche Lizenzunsicherheit gesorgt hat. Kunden haben ein legitimes Interesse daran, mögliche Kostenimplikationen frühzeitig zu verstehen.
Auswirkungen auf laufende KI-Projekte: Viele Unternehmen arbeiten aktuell an KI-Piloten und Proof-of-Concepts, die auf der bisherigen Auslegung der API-Nutzung basieren. Die neue Policy schafft Unsicherheit darüber, ob diese Vorhaben später produktiv und richtlinienkonform betrieben werden können.
Offene Frage
Unklar ist bisher, wie SAP bei Vertragsverlängerungen oder -erweiterungen mit der neuen Policy umgeht. Unternehmen, die ihren RISE- oder Cloud-Vertrag verlängern, sollten diesen Punkt aktiv mit SAP klären.
Einordnung aus Beratungsperspektive
Wer die Policy sachlich liest, erkennt: SAP schützt sich vor den Konsequenzen einer Welt, in der autonome KI-Agenten unkontrolliert SAP-Transaktions-APIs aufrufen. Das ist ein legitimes Anliegen. Ein einziger Agent ohne Business-Kontext kann tausende API-Calls auslösen – das war für klassische Integrationsplattformen nie ausgelegt.
Gleichzeitig ist es keine versteckte Restriktion bestehender, dokumentierter Integrationen. Wer auf Published APIs setzt, ist nach dem Wortlaut der Policy nicht betroffen. Und SAPs Enforcement-Ansatz priorisiert ausdrücklich den Dialog vor technischen Maßnahmen.
Dennoch: Die Policy hat eine strukturelle Konsequenz, die über den technischen Regeltext hinausgeht. Sie verstärkt den Druck in Richtung Clean Core – und das ist für unsere Kunden direkt relevant.
Was das für Clean Core und RISE bedeutet
Die API Policy und Clean Core sind zwei verschiedene Instrumente, aber sie greifen ineinander. Clean Core ist ein Architekturprinzip: Kunden-Code und Erweiterungen sollen auf dokumentierten SAP APIs und freigegebenen Erweiterungspunkten basieren, nicht auf SAP-internen Objekten. Die neue Policy formuliert nun erstmals einen unternehmensweiten, verbindlichen Rahmen genau in diese Richtung.
Für RISE-Kunden ergibt sich daraus eine konkrete Anforderung: Bestehende Integrationen, die auf nicht-publizierten SAP APIs basieren – z.B. ODP-RFC für Non-SAP-Tooling oder Schnittstellen, die nur über Debugging oder Community-Blogs bekannt sind – sind ab sofort strukturell risikoreich. BAPIs hingegen sind in der Regel im SAP Business Accelerator Hub dokumentiert und damit published APIs – sie fallen nicht pauschal unter die Restriktion. Entscheidend ist stets die Prüfung im Hub, nicht die technische Schnittstellenart. SAP wird nicht-publizierte Schnittstellen nicht absichern, und bei Vertragserneuerungen oder Cloud-Upgrades könnten sie zum Problem werden.
Was Kunden jetzt konkret tun sollten
Die API Policy ist kein Grund zur Panik – aber ein guter Anlass, die eigene Integrationslandschaft konsequent zu bewerten. Drei Handlungsfelder sind zentral:
- Integration Landscape Assessment: Mit dem SAP Integration Assessment (Teil der SAP Integration Suite) lässt sich die bestehende Integrationslandschaft systematisch analysieren. Der ATC (ABAP Test Cockpit) mit Cloud Readiness Check identifiziert Abhängigkeiten auf nicht-publizierte SAP-Objekte im Custom Code. Beides sollte für RISE-Kunden ohnehin Standard sein – die API Policy macht es dringlicher.
- ODP-RFC Migration priorisieren: ODP-RFC ist das konkreteste Beispiel, das SAP ausdrücklich als nicht erlaubt klassifiziert (SAP Note 3255746). Kunden, die ODP-RFC für Datenextraktion nutzen – etwa über Drittanbieter-Tools – sollten jetzt mit ihrem SAP Account Executive die Migration in Richtung BDC Connect, SLT oder Analytical CDS Views besprechen.
- KI-Architektur auf endorsed Patterns ausrichten: Wer aktuell KI-Agenten entwickelt oder plant, die auf SAP-Daten oder -Prozesse zugreifen sollen, muss die SAP-endorsed Architekturen kennen: MCP Gateway auf der SAP Integration Suite (für governed API-Zugriff mit Rate Limiting, Auth und Audit Logging) sowie das Agent2Agent-Protokoll (A2A) für Multi-Agenten-Szenarien. Beide Ansätze sind im SAP Architecture Center dokumentiert.
Für RISE-Kunden besonders relevant
Die Remediation von Integrationen, die auf nicht-publizierten APIs basieren, ist nicht automatisch im RISE-Scope enthalten. Das muss explizit im Vertrag vereinbart werden. Wer gerade einen RISE-Vertrag abschließt oder verlängert, sollte diesen Punkt aktiv ansprechen.
FAQ: SAP API Policy
Die SAP API Policy (aktuelle Version: v4/2026, veröffentlicht April 2026) ist ein verbindliches Regelwerk, das festlegt, unter welchen Bedingungen Kunden und Partner auf SAP-Schnittstellen zugreifen dürfen. Laut SAP ist die Einführung eine Reaktion auf die stark steigende Nutzung von APIs durch Nicht-SAP-Systeme sowie auf neue Anforderungen durch Cloud- und KI-basierte Szenarien. Ziel ist es, Risiken für Performance, Stabilität und Sicherheit frühzeitig zu adressieren.
Als Published APIs gelten ausschließlich jene Schnittstellen, die im SAP Business Accelerator Hub oder in der jeweiligen Produktdokumentation ausgewiesen sind. „Kunden- und Drittanwendungen dürfen nicht auf APIs zugreifen, die keine Published APIs sind“, so der Wortlaut der Policy. Nicht-publizierte, interne oder als „private“ gekennzeichnete APIs sind damit explizit verboten — unabhängig davon, ob das System in der Public Cloud, Private Cloud oder via SAP BTP betrieben wird.
Die Policy verstärkt den Clean-Core-Kurs erheblich. Die Aktualisierung „bekräftigt den Wandel hin zu Clean Core und kontrollierter Erweiterbarkeit, indem Integrationen auf offiziell veröffentlichte APIs beschränkt werden“ — Organisationen müssen Integrationen, die auf privaten oder undokumentierten APIs aufgebaut sind, refaktorieren. Im Clean-Core-Modell entspricht dies Level A (vollständig upgrade-sicher, ausschließlich Released APIs). Wo noch keine Published API existiert, empfiehlt SAP, über das Customer Influence Portal eine neue API anzufordern oder einen Clean-Core-Wrapper via SAP BTP und ABAP Development Tools zu erstellen.
Nein. SAP Note 3255746 (zuletzt aktualisiert April 2026) stellt klar: Jede Nutzung von ODP-RFC durch Kunden- oder Drittanbieteranwendungen für den Zugriff auf SAP-ABAP-Systeme — ob On-Premises oder in der Private Cloud — ist verboten. Probleme, die durch nicht richtlinienkonforme ODP-RFC-Nutzung entstehen, liegen in der alleinigen Verantwortung des Kunden. Ab Juni 2026 steht ein Security Patch bereit, der nicht erlaubte ODP-RFC-Aufrufe technisch blockiert. Wichtige Klarstellung: Betroffen ist ausschließlich ODP über RFC — Table-Extraktionen, BAPIs, Funktionsbausteine und andere RFC-basierte Komponenten sind weiterhin nutzbar. Als SAP-empfohlene Alternativen gelten SAP Business Data Cloud (BDC) sowie ODP OData.
Die DSAG (Deutschsprachige SAP-Anwendergruppe) sieht erheblichen Klärungs- und Anpassungsbedarf in vier zentralen Punkten:
- Vertragliche Verankerung: Nach Auffassung der DSAG sind der SAP Business Accelerator Hub sowie nicht näher definierte Produktdokumentationen bislang nicht eindeutig als Vertragsbestandteile ausgestaltet. Daraus ergibt sich die zwingende Anforderung nach klaren und verlässlichen Rahmenbedingungen.
- Schutz bestehender Integrationen: DSAG-Technologievorstand Stefan Nogly fordert, dass der Schutz für bereits bestehende und von SAP geduldete Integrationen explizit in der API Policy festgehalten werden sollte.
- KI-Projekte und Innovationskraft: Insbesondere unklare Regelungen zur KI-Nutzung und ein mögliches Fair-Use-Preismodell sorgen für Unsicherheit bei Kunden und Partnern.
- Übergangsfristen: DSAG-Vorstandsvorsitzender Jens Hungershausen fordert, dass SAP den Kunden mehr Zeit für den Übergang gewährt und konkrete technische sowie organisatorische Hilfestellungen bereitstellt.
Dies ist der politisch heikelste Punkt der neuen Policy. Abschnitt 2.2.2 der API Policy v4/2026 verbietet die Nutzung von SAP-APIs für „die Interaktion oder Integration mit (semi-)autonomen oder generativen KI-Systemen, die Sequenzen von API-Aufrufen planen, auswählen oder ausführen“. Im Klartext: Drittanbieter-KI-Agenten dürfen SAP-Daten nur noch über von SAP freigegebene Architekturen nutzen. CEO Christian Klein ruderte im Q1-Investorengespräch zurück und betonte, der Zweck sei der Schutz des Domain-Know-hows von SAP und die Vermeidung von Performance-Degradation — nicht die Blockade des Kundenzugangs zu eigenen Daten. Die Policy-Formulierung selbst wurde jedoch nicht wesentlich abgeschwächt. Für Unternehmen bedeutet das: Wer KI-Agenten auf SAP-Daten aufsetzen möchte, ist auf SAP-endorsierte Wege wie Joule, SAP AI Foundation oder die SAP Business Data Cloud angewiesen.
RISE-Kunden sind direkt betroffen, da sie SAP-Systeme in der Cloud — Public oder Private Edition — betreiben und damit vollumfänglich unter die Policy fallen. Gerade für S/4HANA Cloud Public Edition ist die Remediation dringend, da Kunden dort weniger Kontrolle über den Upgrade-Zeitplan haben. Bestehende Integrationen, die auf nicht-publizierten APIs basieren, tragen nun ein explizites Support-Risiko: Sie mögen technisch weiter funktionieren, liegen aber außerhalb definierter Support-Grenzen — was das Risiko von unmittelbarem Ausfall zu langfristiger Instabilität verschiebt, bei der Änderungen die Funktionalität ohne Vorwarnung brechen können. Für RISE-Kunden empfiehlt sich daher eine gezielte Bestandsaufnahme aller Integrationen gegen den SAP Business Accelerator Hub sowie eine priorisierte Migrationsstrategie nach dem Prinzip „Event-Driven Remediation“ — das heißt, Migration immer dann, wenn eine bestehende Integration ohnehin Wartung erfordert.
Fazit: Eine überfällige Klarstellung – mit offenen Fragen
Die SAP API Policy ist kein Angriff auf Kunden oder Partner. Sie ist eine sachlich begründete Reaktion auf zwei strukturelle Realitäten: die Proliferation undokumentierter API-Nutzung auf der einen Seite und die neue Dynamik autonomer KI-Systeme auf der anderen.
Gleichzeitig hat die DSAG recht: Ein Ordnungsrahmen, der nicht vertraglich verankert ist, schafft keine verlässliche Planungsbasis. Hier muss SAP nacharbeiten. Die Forderung nach belastbaren Vertragsdokumenten und Transparenz über das künftige Fair-Use-Modell ist berechtigt und überfällig.
Für uns als Beratungshaus ist die Botschaft klar: Clean Core ist kein optionaler Ansatz mehr, sondern der Normalfall. Die API Policy ist ein weiterer, nun offiziell formulierter Beleg dafür. Kunden, die ihre SAP-Systemlandschaft auf Basis dokumentierter APIs und endorsed Extensibility-Patterns aufgebaut haben, sind strukturell im Vorteil – technisch, wirtschaftlich und vertragsrechtlich.
Wer noch Nachholbedarf hat, sollte jetzt handeln – bevor Vertragsverlängerungen oder Cloud-Upgrades den Druck erhöhen.
Dieser Artikel basiert auf dem offiziellen FAQ-Dokument „SAP API Policy – Frequently Asked Questions“ (Version 1.1, Mai 2026) sowie der Pressemitteilung der DSAG vom 29. April 2026. Er dient der sachlichen Einordnung und ersetzt keine individuelle Rechts- oder Vertragsberatung.
Kontakt
Michael Neuenstadt Telefon: +49 (0)40 53302-0
E-Mail: Michael.Neuenstadt@cimt-ag.de
Dr. Thorsten Kuhlmann
Telefon: +49 (0)40 53302-0
E-Mail: Thorsten.Kuhlmann@cimt-ag.de
