SAP API Policy 2026: Wie Sie Sprachmodelle an SAP anbinden, ohne gegen Nutzungsregeln zu verstoßen

Die SAP API Policy (Version 4.2026a) ist seit dem 27. April 2026 veröffentlicht. Sie untersagt die Anbindung von KI-Systemen, die Abfolgen von API-Aufrufen selbst planen oder ausführen, außer über von SAP gebilligte Wege. Wer ein Sprachmodell an SAP anbinden will, klärt deshalb zuerst die Zugriffsarchitektur und danach die Modellwahl.

Was die Policy regelt

Die Policy ist Teil der Dokumentation der jeweiligen SAP-Lösung. Veröffentlichte APIs aus dem SAP Business Accelerator Hub oder der Produktdokumentation dürfen für den dokumentierten Zweck genutzt werden, etwa Integration, Erweiterungen und Datenaustausch. Nicht veröffentlichte APIs sind für Kunden- und Drittanwendungen unzulässig, außer Dokumentation oder SAP erlauben sie; ausgenommen sind selbst entwickelte ABAP-Schnittstellen in Private-Cloud- und On-Premise-Systemen.

Für KI maßgeblich ist Abschnitt 2.2.2. Außerhalb gebilligter Architekturen, Datendienste oder eigens dafür vorgesehener Wege verbietet er die Integration mit „(semi-) autonomous or generative AI systems that plan, select, or execute sequences of API calls“ sowie Scraping und großvolumige Extraktion oder Replikation. SAP darf die Nutzung überwachen und den Zugriff drosseln, aussetzen oder beenden; Umgehungen über Zwischendienste, Proxys oder Gateways sind unzulässig.

Was sich nicht ändert

Die FAQ (Version 1.3, Juni 2026) stellt klar: „The policy does not change contractual license grants, functional entitlements, or licenses.“ Sie gilt ausdrücklich auch für S/4HANA Private Cloud (RISE). Durchgesetzt wird laut SAP per Überwachung und Dialog statt Sanktionen.

Für Bestandssysteme wichtig:

• Eigene Schnittstellen im Kundennamensraum, eigene RFCs, BAPIs, Funktionsbausteine und OData-Services sind Kundencode. Die Beschränkung greift dort nicht, solange sie keine Kontrollen umgehen und ihre Aufrufe an SAP-APIs regelkonform sind.
• Regelbasierte RPA mit festgelegten, deterministischen Aufrufen fällt nicht unter Abschnitt 2.2.2.
• Eigene Agenten und MCP-Server auf SAP BTP unterliegen der Policy, sobald sie SAP-APIs aufrufen.

SAP begründet die Regel mit Last und Sicherheit: Ein einzelner Prompt an eine KI-Orchestrierung könne Tausende API-Aufrufe erzeugen. Die Beschränkung gelte unkontrollierten, undokumentierten Zugriffsmustern, nicht agentischer KI im Allgemeinen.

Wo die Grenze bereits verläuft

• ODP-RFC: laut FAQ kein gebilligtes Integrationsmuster für Nicht-SAP-Werkzeuge (SAP-Hinweis 3255746).
• ABAP Development Tools (ADT): SAP-interne Entwicklungsschnittstellen, nicht vorgesehen für das Auslesen von Anwendungstabellen, Datenexporte, SQL gegen SAP-Backends oder agentische KI-Abläufe auf Geschäftsdaten.

Welche Wege SAP vorsieht

SAP hat die offenen Standards Model Context Protocol (MCP) und Agent2Agent (A2A) übernommen. Der passende Weg hängt davon ab, ob das Modell Daten auswertet oder handelt.

Auswerten. Für große Datenmengen nennt die FAQ SAP Business Data Cloud mit Delta Sharing und SLT für die Echtzeit-Replikation. Als Mittelweg dienen analytische CDS-Views und OData-V4-Analytikservices mit Filter, Aggregation und dem Operator $apply. Die Zielplattform, etwa Databricks oder Snowflake, bleibt Kundenwahl.

Handeln. Für den Zugriff externer KI-Agenten auf Geschäftsprozesse empfiehlt SAP den MCP Gateway der SAP Integration Suite statt community-gebauter oder selbst betriebener MCP-Server. Begründung: Die MCP-Spezifikation decke Authentifizierung, Autorisierung und Sicherheit im Unternehmenseinsatz noch nicht vollständig ab. Der Gateway bündelt SAP- und Nicht-SAP-APIs, externe MCP-Server und Integrationsflüsse hinter einem gesteuerten Einstiegspunkt mit OAuth und Ratenbegrenzung.

Backend-Berechtigungen und Richtlinien verantwortet dabei der Kunde. Joule und Joule Studio sind laut FAQ nicht verpflichtend.

Für Agent-zu-Agent-Szenarien verweist SAP auf A2A über den SAP Agent Gateway. Dieser ist laut SAP Architecture Center noch nicht allgemein verfügbar; die bidirektionale Kommunikation mit Drittanbieter-Agenten wird noch nicht unterstützt.

Drittanbieter-MCP-Server: zulässig unter Bedingungen

Das SAP Architecture Center lässt Drittanbieter-MCP-Server zu, wenn die Policy vollständig eingehalten wird, jede Verbindung authentifiziert und autorisiert ist, die Ratenlimits der SAP-APIs respektiert werden und der Betrieb abgesichert ist. Die Verantwortung liegt dann vollständig beim Kunden oder Partner. SAP empfiehlt also den Gateway, schließt Drittanbieter-Server aber nicht aus.

Die technischen Vorgaben dazu:

• Das Token des Aufrufers nie an SAP-APIs durchreichen, sondern per Token-Austausch (RFC 8693) ein eng gefasstes Token mit Agentenidentität und Nutzerkontext erzeugen.
• Keine langlebigen Zugangsdaten im MCP-Server speichern.
• Jeden Werkzeugaufruf protokollieren, personenbezogene Parameter geschwärzt.

MCP ist laut SAP ein Verbindungsprotokoll: Es liefert weder Geschäftskontext noch genauere KI-Ergebnisse.

Lizenz: eine eigene Frage

Die Policy regelt Zugriffswege, keine Lizenzen. Die DSAG sieht Klärungsbedarf: Business Accelerator Hub und Produktdokumentation seien nicht eindeutig als Vertragsbestandteile ausgestaltet, die Ausgestaltung des angekündigten Fair-Use-Modells sei unklar, und für die indirekte Nutzung gebe es mit Digital Access bereits ein Preismodell. Nach DSAG-Informationen sind bestehende Kundenintegrationen und autorisierte Partnerlösungen nicht betroffen.

Unsere Einschätzung: Öffentlich lesbare SAP-Quellen sagen nicht ausdrücklich, ob Zugriffe von Sprachmodellen unter Digital Access fallen. Das gehört vor dem Produktivbetrieb schriftlich mit dem SAP-Account-Team geklärt; dieser Beitrag ist keine Rechtsberatung.

Was Sie jetzt tun können

1. Zugriffe erfassen. Listen Sie bestehende und geplante KI-Zugriffe auf: Schnittstelle, Zweck, Datenumfang und ob ein Modell Aufrufe selbst plant. Nutzt ein Nicht-SAP-Werkzeug ODP-RFC, prüfen Sie SAP-Hinweis 3255746.
2. Muster je Anwendungsfall festlegen. Auswertungen laufen über analytische CDS-Views oder Business Data Cloud, handelnde Agenten über den MCP Gateway oder abgesicherte Drittanbieter-Server. Technische Nutzer erhalten nur die Rechte, die der Fall braucht.
3. Lizenz und Fassung dokumentieren. Klären Sie die lizenzrechtliche Einordnung mit dem SAP-Account-Team und halten Sie fest, auf welche Versionen von Policy und FAQ sich Ihre Architektur stützt.

Gern gehen wir Ihre geplante Anbindung in einem Erstgespräch mit Ihnen durch.