Für SAP-Kunden ist die entscheidende Frage nicht, ob künftig jedes externe Tool ausgesperrt wird. Wichtiger ist: SAP zieht die Nutzung seiner APIs für Kern-ERP-Daten und Geschäftsprozesse enger auf veröffentlichte Schnittstellen, Produktdokumentation, SAP-anerkannte Architekturen, Datenservices oder ausdrücklich vorgesehene Servicepfade zusammen.^[1][7][10]

Wer KI-Agenten, RPA, iPaaS, ETL-Strecken, Data-Lakehouse-Synchronisierung oder eigene Automatisierung an SAP-Systeme hängt, muss deshalb nicht nur den Code prüfen. Es geht um die gesamte Integrationsarchitektur: Welche Schnittstelle wird genutzt? Ist sie dokumentiert? Wie viel wird gelesen oder repliziert? Und entscheidet ein Agent selbst, welche API-Aufrufe als Nächstes folgen?^[1][13]

Was SAP tatsächlich enger zieht

Laut einer von CIO zitierten SAP-Stellungnahme gelten nur die Schnittstellen als veröffentlichte APIs, die im SAP Business Accelerator Hub oder in der jeweiligen Produktdokumentation aufgeführt sind.^[7] Der SAP Business Accelerator Hub ist dabei der zentrale Katalog, über den SAP APIs und Integrationsartefakte für Entwickler auffindbar macht.

The Register berichtete zudem, dass die neue Policy API-Nutzung nur innerhalb von

SAP-endorsed architectures, data services, or service-specific pathways

[2]

[10]

Die in der Policy beschriebenen API Controls umfassen unter anderem funktionale und technische Nutzungsgrenzen, Quoten, Ablöse- beziehungsweise Deprecation-Zeitpläne, Daten-Ein- und -Ausgangsquoten, Vorgaben für Bulk-Extraction und Replikation sowie weitere Sicherheits- und Technikauflagen.^[9] SAPinsider weist außerdem darauf hin, dass nicht dokumentierte APIs zwar in vielen Landschaften genutzt werden, nach der Aktualisierung aber außerhalb der Support-Grenzen liegen und damit langfristige Integrations- und Betriebsrisiken erhöhen.^[1]

Der Punkt ist also größer als eine einzelne KI-Klausel. SAP verschiebt die Debatte von der Frage „Kann ich diese Schnittstelle technisch aufrufen?“ hin zu „Ist diese Nutzung veröffentlicht, unterstützt, mengenmäßig zulässig und architektonisch von SAP vorgesehen?“^[7][9][13]

Warum KI-Agenten besonders heikel sind

Die meistdiskutierte Passage betrifft agentische KI. Mehrere Berichte zitieren die Policy dahingehend, dass SAP API-Nutzung für die Interaktion oder Integration mit halbautonomen oder generativen KI-Systemen untersagt, wenn diese Systeme Sequenzen von API-Aufrufen planen, auswählen oder ausführen – außer über SAP-anerkannte Architekturen, Datenservices oder ausdrücklich vorgesehene Wege.^[5][10]

Genau hier liegt der Unterschied zwischen klassischer Integration und KI-Agenten. Eine klassische Schnittstelle folgt meist einem fest programmierten Ablauf: System A ruft API B auf, um Aufgabe C zu erledigen. Ein KI-Agent kann dagegen aus einem Ziel heraus Zwischenschritte selbst bestimmen – zum Beispiel erst Lieferantendaten abrufen, dann Lagerbestände prüfen, danach eine Beschaffungsempfehlung erstellen und anschließend einen Genehmigungsprozess anstoßen.

Sobald ein Agent eigenständig mehrere SAP-API-Aufrufe auswählt und verkettet, kann er in den Bereich fallen, den die Policy beschreibt. Ob ein konkreter Fall zulässig ist, hängt aber von den genutzten APIs, der Architektur, den Datenservices und dem SAP-anerkannten Pfad ab.^[5][10]

Die Einschränkungen betreffen außerdem Scraping, Harvesting sowie systematische oder großvolumige Datenextraktion und Replikation.^[5][10] Damit geht es nicht nur um Agenten, die in SAP schreiben. Auch Designs, bei denen SAP-Daten in großer Menge für externe KI-Plattformen, Lakehouses oder Orchestrierungsschichten ausgelesen werden, müssen neu bewertet werden.^[9][13]

Innovation: PoCs werden nicht unmöglich, aber formeller

Für Innovationsteams, Systemintegratoren und ISVs bedeutet die Policy vor allem: Vor dem schnellen Prototyp kommt mehr Governance. Ein Proof of Concept für automatische Abstimmung, Einkaufsunterstützung, Bestandsanalyse oder Prozessautomatisierung muss klären, ob die genutzten APIs im SAP Business Accelerator Hub oder in der Produktdokumentation stehen, ob die Architektur zu einem SAP-anerkannten Pfad gehört, ob Quoten oder Bulk-Extraction-Grenzen berührt werden und ob der Agent selbst mehrstufige API-Aufrufe plant.^[5][7][9]

Das heißt nicht, dass KI-PoCs mit SAP-Daten grundsätzlich nicht mehr möglich sind. Sie ähneln aber stärker einem regulären Integrationsprojekt: API-Inventar, Berechtigungsmodell, Nutzungsabschätzung, Datenflussprüfung und Compliance-Klärung werden früher nötig. ERP Today beschreibt die Policy deshalb als Verschiebung eines eigentlich technischen Integrationsthemas in eine breitere ERP-Architekturfrage, weil bestehende Integrationen auf nicht formal dokumentierten Schnittstellen beruhen können und neue KI-Anwendungen kontrollierten Zugriff auf Unternehmensdaten und Transaktionsprozesse benötigen.^[13]

Die Unsicherheit selbst kann Innovation verlangsamen. The Register berichtete, dass die Deutschsprachige SAP-Anwendergruppe DSAG die neue Policy wegen ihrer Unklarheit kritisiert; im selben Bericht wird auch die Kritik erwähnt, SAPs Liste genehmigter Schnittstellen sei möglicherweise nicht ausreichend gepflegt oder aktuell.^[2]

Datenkontrolle: Es geht nicht nur um Eigentum

Die Debatte dreht sich nicht allein darum, wem die Daten gehören. Für Unternehmen ist ebenso wichtig, ob sie ihre bevorzugten KI-Plattformen, Data Stacks und Automatisierungstools direkt und dauerhaft an SAP-Daten und Transaktionsprozesse anbinden können. The Register beschreibt die Sorge, dass Drittanbieter-KI-Tools vom Zugriff auf Kundendaten in SAP ausgeschlossen werden könnten; ERP Today ordnet das Thema in die größere Architekturfrage von ERP-Integration, Datenreplikation und KI-Zugriff ein.^[10][13]

Wenn SAP-Daten in ein externes Lakehouse, eine KI-Plattform, eine Agent-Orchestrierung oder ein Drittanbieter-Automatisierungssystem fließen sollen, sollten Unternehmen deshalb besonders auf Daten-Ein- und -Ausgangsquoten, Voraussetzungen für Bulk-Extraction oder Replikation, den Umfang veröffentlichter APIs und mögliche SAP-anerkannte Pfade achten.^[7][9][10]

Solche Regeln können Last, Sicherheit, Auditierbarkeit und Governance stärker bündeln. Der Preis kann jedoch sein, dass die Gestaltungsfreiheit für plattformübergreifende KI-Architekturen sinkt – vor allem bei Anwendungsfällen, die große Mengen an SAP-Transaktionsdaten lesen oder schreiben müssen.^[9][13]

Lock-in: Das Risiko steigt, ist aber kein Automatismus

Das Lock-in-Risiko entsteht aus einer einfachen Architekturfrage: Wenn Drittanbieter-KI-Agenten nicht frei mit SAP-APIs interagieren dürfen, werden Kunden eher auf SAP-anerkannte Architekturen, offizielle Datenservices oder ausdrücklich erlaubte Integrationswege verwiesen. The Register bezeichnete die KI-Klausel deshalb als Auslöser von Lock-in-Sorgen, weil sie Drittanbieter-KI-Tools den Zugriff auf SAP-Daten von Kunden erschweren könnte.^[10]

Die Reaktion der DSAG zeigt, dass es nicht nur um technische Detailfragen geht. E3 Magazine berichtete, die DSAG halte es für inakzeptabel, dass SAP die API-Nutzung für nicht dokumentierte Zwecke, systematische Massendatenextraktion und die Interaktion mit autonomen generativen KI-Systemen von Drittanbietern stark einschränke.^[11]

Gleichzeitig ist Lock-in nicht das zwangsläufige Ergebnis. Entscheidend wird sein, wie klar SAP anerkannte Pfade definiert, wie vollständig und aktuell die API-Kataloge bleiben und ob Drittanbieter unter nachvollziehbaren Regeln weiter innovieren können. Dass Kritiker bereits die Pflege und Aktualität der genehmigten Liste infrage stellen, macht diesen Punkt für Einkauf, Architektur und Compliance besonders wichtig.^[2][7]

Was Unternehmen jetzt tun sollten

1. Alle SAP-Integrationen inventarisieren. Jede Verbindung sollte als veröffentlichte API, dokumentierte Produkt-API, nicht dokumentierte Schnittstelle, Bulk-Extraction, Echtzeit-Lese- oder Schreibzugriff, RPA, iPaaS oder externer Workflow- beziehungsweise Agent-Aufruf markiert werden.^[1][7][13]

2. Agentische KI gesondert prüfen. Alles, was durch ein Modell oder einen Agenten mehrere SAP-API-Aufrufe plant, auswählt oder ausführt, verdient vor dem PoC eine Policy-Prüfung.^[5][10]

3. Datenabzüge und Replikation neu bewerten. Großvolumige Extraktion, Replikation, Scraping und Harvesting stehen ausdrücklich im Fokus der Einschränkungen. Bestehende Data-Lake-, Lakehouse-, BI-, KI-Trainings- oder Synchronisationsarchitekturen sollten Quoten, Voraussetzungen und erlaubte Pfade erneut prüfen.^[5][9][10]

4. Schriftliche Klärung einholen. Bei agentischer KI, automatisierten Transaktionsupdates, systemübergreifender Orchestrierung oder großen Datenexporten sollte nicht allein auf mündliche Einschätzungen vertraut werden. Die DSAG-Kritik an der Unsicherheit zeigt, wie wichtig klare Abgrenzungen sind.^[2]

5. Architektur nicht unnötig verengen. Auch wenn ein SAP-anerkannter Pfad genutzt wird, sollten KI-Orchestrierung, Berechtigungen, Audit-Logs, Daten-Governance und Geschäftsregeln möglichst modular bleiben. So lässt sich verhindern, dass die komplette Innovationslogik an einen einzigen technischen Weg gebunden wird.

Fazit

SAPs API-Policy 2026 bedeutet nicht, dass KI mit SAP grundsätzlich unmöglich wird. Sie bedeutet aber, dass Drittanbieter-KI-Agenten nicht mehr voraussetzen können, SAP-APIs frei zu orchestrieren. Für Unternehmen steigen damit Sicherheits-, Performance- und Governance-Anforderungen – zugleich aber auch Compliance-Aufwand, Vorbereitungszeit für Experimente und das Risiko einer stärkeren Bindung an SAP-vorgegebene Wege.^[10][13]

Kurzfristig ist der pragmatische Weg klar: Integrationen erfassen, agentische KI-Fälle identifizieren, Datenabzüge prüfen, SAP-anerkannte Pfade bestätigen lassen und neue Architekturen so bauen, dass plattformübergreifende Optionen erhalten bleiben.