Die SAP-API-Policy und ECC: Was sich für Bestandskunden wirklich ändert

Am 27. April 2026 hat SAP die API Policy v.4/2026a veröffentlicht. Der entscheidende Abschnitt 2.2.2 untersagt die Nutzung von SAP-APIs für „(semi-)autonome oder generative KI-Systeme, die Sequenzen von API-Aufrufen planen, auswählen oder ausführen" — außer über die von SAP freigegebenen Wege. Die Reaktionen waren deutlich: Die Anwendergruppe DSAG kritisierte die Policy öffentlich scharf, und SAP-Chef Christian Klein stellte auf dem Q1-Investorencall klar, es gehe „vor allem um SAPs Domänenwissen, nicht um die Daten der Kunden". Eine überarbeitete Version gilt als wahrscheinlich.

Für Mittelstand-Unternehmen auf SAP ECC, Business One oder S/4HANA on-premise stellt sich eine praktischere Frage: Was heißt das konkret für uns? Die Antwort fällt nüchterner aus, als die Schlagzeilen vermuten lassen.

Was die Policy tatsächlich regelt

Die Policy betrifft von SAP publizierte APIs — und sie regelt, wie KI-Agenten diese aufrufen dürfen. Die freigegebenen Wege sind der SAP-eigene Stack: AI Core und Joule Studio als Laufzeit, das MCP Gateway in der Integration Suite (seit Q1 2026 allgemein verfügbar, Techzine), das A2A-Protokoll für die Agent-zu-Agent-Kommunikation und BDC Connect auf der Datenseite. Wer auf RISE oder GROW ist und Agenten gegen SAP-APIs laufen lassen will, hat damit einen klaren, sanktionierten Pfad.

Was das für ECC- und B1-Kunden bedeutet

Drei Beobachtungen, die in der Aufregung untergehen:

Erstens: Joule war für Sie nie verfügbar — es setzt RISE- oder GROW-Verträge voraus. An Ihrer Ausgangslage hat sich durch die Policy nichts verschlechtert; der native SAP-Agentenpfad stand Ihnen vorher nicht offen und steht Ihnen nachher nicht offen.

Zweitens: Die sanktionierten Kanäle leben im BTP-Cloud-Stack. Für ein ECC- oder Business-One-System ohne BTP-Anbindung ist die Policy heute vor allem eines: ein Signal, wohin SAP die Agentenwelt lenken will — in die eigene Cloud.

Drittens, und am wichtigsten: Nicht jeder KI-Agent ruft SAP-APIs auf. Ein Agent, der mit den Exporten arbeitet, die Ihre Anwender ohnehin täglich ziehen — ein IDoc-Fehlerprotokoll aus WE02, eine Lieferblockliste, ein Frachtkosten-Export — berührt keine SAP-Schnittstelle. Er liest ein Dokument, das ein Mensch erzeugt hat, und gibt eine Analyse zurück. Dieses Muster liegt außerhalb dessen, was eine API-Policy regeln kann, und es funktioniert auf ECC 6.0 genauso wie auf S/4HANA.

Was wir empfehlen

Erstens: Inventarisieren Sie geplante Agenten-Anwendungsfälle danach, ob sie SAP-APIs aufrufen oder auf Exporten und Dokumenten arbeiten. Zweitens: Für API-gebundene Fälle auf RISE / GROW führt der Weg über die freigegebenen Kanäle — MCP Gateway und A2A. Drittens: Beobachten Sie die angekündigte Überarbeitung der Policy, bevor Sie langfristige Architekturentscheidungen von der aktuellen Fassung abhängig machen.

Wir bauen Agenten des dritten Musters: Sie arbeiten auf Exporten, laufen auf Ihrer eigenen Infrastruktur und brauchen weder BTP noch eine Policy-Ausnahme. Der SAP Logistics Copilot ist das erste Beispiel — kostenlos auf Ihren eigenen Daten testbar. Wenn Sie einordnen wollen, in welches Muster Ihr Anwendungsfall fällt: 30-Minuten-Erstgespräch.