Im April 2026 hat SAP seine API-Policy aktualisiert. Seitdem ist die Frage, ob ein KI-Agent eines Drittanbieters direkt mit SAP-Systemen arbeiten darf, nicht mehr nur eine technische Integrationsfrage. Sie betrifft auch Architektur, Vertragsrechte, Daten-Governance und Supportgrenzen.^[5][6][10]

Die Policy selbst beschreibt ihren Zweck vergleichsweise nüchtern: Sie regelt die Verfügbarkeit und Grenzen von APIs und legt Kontrollen fest, um Solution Health und Sicherheit zu schützen, fairen Zugriff zu fördern und API-Missbrauch zu verhindern.^[9] Der Streitpunkt ist jedoch die neue KI-Klausel.

Externe Analysen und Medienberichte verweisen insbesondere auf Abschnitt 2.2.2 der API Policy v4/2026. Danach wird 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 — es sei denn, dies geschieht über von SAP anerkannte Architekturen, Datendienste oder ausdrücklich dafür vorgesehene Servicepfade.^[6][8][10]

Die entscheidende Grenze: Berät die KI nur — oder handelt sie selbst?

Die neue Policy bedeutet nicht, dass Unternehmen SAP-Daten grundsätzlich nicht mehr für KI verwenden dürfen. Die kritische Linie verläuft dort, wo ein KI-Agent SAP-APIs als frei orchestrierbare Handlungsebene nutzt.

Weniger heikel ist ein Szenario, in dem eine Anwendung bereits autorisiert exportierte Daten zusammenfasst, Prognosen erstellt oder Handlungsempfehlungen gibt — und ein Mensch die eigentliche Aktion anschließend in SAP prüft und ausführt. Deutlich sensibler wird es, wenn die KI selbst Lagerbestände abfragt, Aufträge ändert, Bestellungen anlegt, Freigaben auslöst, Stammdaten aktualisiert oder mehrere SAP-Schritte zu einem End-to-End-Prozess verbindet. Solche Muster ähneln genau jener mehrstufigen API-Orchestrierung mit Veränderung des Geschäftszustands, die die Policy adressiert.^[6][8][10]

Vier praktische Folgen für Unternehmen

1. Drittanbieter-Agenten brauchen einen von SAP vorgesehenen Weg

The Register fasst die neue Klausel so zusammen: SAP untersagt API-Integrationen mit externen KI-Systemen außerhalb anerkannter Architekturen. Das hat Sorgen ausgelöst, Drittanbieter-KI könne vom direkten Zugriff auf SAP-Daten und -Prozesse der Kunden ausgeschlossen werden.^[10] Fivetran hebt ebenfalls hervor, dass die Policy ausdrücklich KI-Systeme nennt, die API-Aufrufketten selbst planen, auswählen oder ausführen.^[8]

Für Unternehmen heißt das: Nur weil ein Connector technisch funktioniert, ist seine Nutzung nicht automatisch policy-konform. Wer einen Drittanbieter-KI-Agenten SAP-Prozesse ausführen lassen möchte, muss klären, ob der konkrete Use Case unter eine SAP-endorsed architecture, einen Datendienst oder einen service-specific pathway fällt.^[10]

2. Veröffentliche und dokumentierte APIs werden zur Mindestanforderung

SAPInsider berichtet, dass SAP den Systemzugriff stärker auf veröffentlichte, dokumentierte APIs beschränkt. Nicht dokumentierte APIs liegen demnach außerhalb der Supportgrenzen und erhöhen langfristige Integrations- und Betriebsrisiken.^[5] Die SAP API Policy definiert „Published APIs“ als APIs, die etwa im SAP Business Accelerator Hub — früher oft als API Hub bezeichnet — oder in produktspezifischer Dokumentation ausgewiesen sind.^[9]

Für Unternehmen mit gewachsenen Eigenentwicklungen, älteren Schnittstellen oder kundenspezifischen Integrationen ist das ein Warnsignal. Auch wenn eine Verbindung heute noch läuft, kann sie bei Upgrades, Supportfällen oder Compliance-Prüfungen schwieriger zu rechtfertigen sein.^[5][9]

3. Massendatenabzug und Replikation sind ebenfalls im Fokus

Die Policy betrifft nicht nur KI-Agenten, die SAP-APIs in mehreren Schritten orchestrieren. Fivetran und The Register weisen darauf hin, dass auch Scraping, Harvesting sowie systematische oder groß angelegte Datenextraktion und Replikation erfasst werden — sofern sie nicht über SAP-kontrollierte oder SAP-anerkannte Architekturen und Pfade erfolgen.^[8][10]

Wer SAP-Daten in großem Umfang in einen externen Data Lake, ein Warehouse oder eine Nicht-SAP-KI-Plattform kopieren will, sollte daher nicht nur Durchsatz, Latenz und Kosten betrachten. Zu prüfen sind auch API-Policy, Vertragsrechte, API-Limits, Audit-Anforderungen und der jeweils zulässige Integrationspfad.^[8][9][10]

4. SAPs eigene KI-Architektur wird naheliegender

SAP beschreibt selbst, dass Unternehmen KI-Agenten auf SAP BTP entwickeln und mit Joule sowie der darunterliegenden KI-Infrastruktur von SAP BTP integrieren können. Das SAP Cloud SDK for AI unterstützt zudem verbreitete Agent-Frameworks, unter anderem über Adapter wie LangChain.^[1]

SAP positioniert außerdem den SAP Knowledge Graph als Grundlage, um Joule und andere KI-Anwendungen — einschließlich KI-Agenten — mit geschäftlichem Kontext aus SAP-Anwendungen zu versorgen. Ziel ist, Antworten genauer und relevanter für SAP-spezifische Geschäftsfragen zu machen.^[4]

Das heißt nicht, dass Drittanbieter-Lösungen grundsätzlich ausgeschlossen sind. Aber je enger die Policy-Grenzen gezogen werden, desto attraktiver werden offiziell vorgesehene Wege für Architektur-, Rechts-, Risiko- und Compliance-Teams.^[1][4][10]

Welche KI-Projekte sind besonders betroffen?

Szenario	Betroffenheit	Warum es relevant ist
BI, Reporting oder Offline-Analysen mit autorisiert extrahierten Daten	niedrig bis mittel	Wenn die KI keine SAP-APIs orchestriert, ist das agentische Risiko geringer. Bei großvolumiger Extraktion oder Replikation bleiben Policy-Grenzen aber relevant.[8][10]
Chatbot gibt Empfehlungen, ein Mensch führt die Aktion in SAP aus	eher niedrig	Die zentrale Policy-Frage betrifft KI-Systeme, die API-Aufrufketten planen, auswählen oder ausführen. Reine Empfehlungssysteme unterscheiden sich von ausführenden Agenten.[6][8]
KI prüft Bestände, ändert Aufträge, legt Bestellungen an oder aktualisiert Stammdaten	hoch	Solche Abläufe beinhalten meist mehrstufige API-Aufrufe, Write-back und Änderungen am Geschäftsstatus — genau der Bereich, den die KI-Klausel adressiert.[6][8][10]
SAP-Daten werden großflächig in externe KI-Plattformen repliziert	hoch	Die Policy nennt auch Scraping, Harvesting sowie systematische oder groß angelegte Datenextraktion und Replikation.[8][10]
Altere Connectoren oder Eigenintegrationen nutzen nicht dokumentierte APIs	mittel bis hoch	Laut SAPInsider liegen undokumentierte APIs außerhalb der Supportgrenzen; laut SAP Policy zählen veröffentlichte APIs zu den im API Hub oder in Produktdokumentation ausgewiesenen Schnittstellen.[5][9]

Innovation wird nicht unmöglich — aber früher prüfpflichtig

Aus Plattform- und Betriebslogik ist nachvollziehbar, dass SAP unbegrenzte externe API-Aufrufe auf Kernsysteme begrenzen will, insbesondere bei schreibenden Zugriffen, Transaktionsprozessen und Systemlast. Die API Policy nennt ausdrücklich den Schutz von Solution Health und Security, fairen Zugriff und die Verhinderung von Missbrauch als Ziele.^[9]

Für Entwicklungs- und Innovationsteams steigen dennoch die Vorarbeiten. Ein Proof of Concept bestand früher oft aus API-Berechtigung, Connector, Testdaten und einem schnellen Prozessdurchlauf. Wenn die KI aber selbst entscheidet, welcher SAP-API-Aufruf als Nächstes erfolgt, und dabei mehrere Schritte ausführt, muss vorher geklärt werden, ob dieser Aufbau über einen zulässigen SAP-Pfad läuft.^[8][10]

Die Folge ist nicht zwingend weniger Innovation, sondern mehr Governance am Anfang. Eigenentwickelte Agenten, Partnerprodukte und Drittanbieter-KI-Plattformen sollten früh durch Vertragsprüfung, Architekturreview und Daten-Governance laufen — auch dann, wenn sie technisch problemlos mit SAP-APIs sprechen können.^[5][8][10]

Datenkontrolle: Zugriff ist nicht gleich Handlungsfreiheit

Die Policy regelt vor allem API-Verfügbarkeit, API-Limits und Kontrollmechanismen. Sie ist keine umfassende Erklärung zum Dateneigentum.^[9] In agentischen KI-Szenarien geht es aber nicht nur darum, ob ein Unternehmen Daten aus SAP lesen oder Berichte herunterladen kann. Entscheidend ist, wer in Echtzeit lesen, schreiben, API-Aufrufe priorisieren und Geschäftsobjekte im SAP-System verändern darf.^[6][8][10]

Externe Analysen beschreiben die Policy deshalb als Anlass für eine Neubewertung der Datenintegration: Unternehmen müssen nicht nur fragen, ob sie SAP-Daten nutzen können, sondern auch, ob der von ihnen gewählte KI-Agent auf Basis dieser Daten unmittelbar handeln darf.^[6]

Wichtig ist dabei eine faire Einordnung: Eine externe Analyse von Kai Waehner verweist auf eine Klarstellung von SAP-CEO Christian Klein, wonach die Policy SAP-Domänenwissen schützen und Performance-Probleme vermeiden solle, nicht aber Kunden am Zugriff auf ihre eigenen Daten hindern solle.^[6] Für Unternehmen bleibt dennoch entscheidend, diese Interpretation in konkrete Verträge, Policy-Ausnahmen, freigegebene Architekturen und Use-Case-Genehmigungen zu übersetzen.^[6][9][12]

Vendor Lock-in verlagert sich auf die Prozessebene

Lock-in bedeutet in diesem Kontext nicht zwingend, dass Daten gar nicht mehr exportiert werden können. Im KI-Agenten-Zeitalter kann Bindung subtiler entstehen: auf der Ebene der Prozessorchestrierung. Wenn der risikoärmste und am einfachsten genehmigungsfähige Weg darin besteht, Agenten auf SAP BTP, Joule, SAP AI Core oder im Umfeld des SAP Knowledge Graph zu bauen, wird die langfristige KI-Architektur stärker vom SAP-Ökosystem geprägt.^[1][4][10]

The Register berichtet ausdrücklich von Lock-in-Bedenken, weil Drittanbieter-KI-Tools schwerer direkten Zugriff auf SAP-Daten und -Prozesse erhalten könnten.^[10] Fivetran sieht ebenfalls höhere Risiken und neue Abwägungen für die KI-Strategie von Unternehmen, insbesondere wenn KI-Agenten auf ERP-Daten zugreifen sollen.^[8]

Was Unternehmen jetzt tun sollten

1. KI-Use-Cases sauber trennen. Geht es nur um Lesen, um Empfehlungen, um menschlich bestätigte Aktionen oder um autonome Mehrschritt-Ausführung? Das Risiko steigt vor allem bei Write-back und eigenständiger API-Orchestrierung.^[6][8][10]
2. SAP oder den Systemintegrator nach dem zulässigen Pfad fragen. Für jeden Anwendungsfall sollte klar sein, ob er über eine SAP-endorsed architecture, einen Datendienst, einen service-specific pathway oder SAP-BTP-/Joule-nahe Architektur umgesetzt werden kann.^[1][10]
3. API-Bestand prüfen. Unternehmen sollten erfassen, ob Integrationen auf veröffentlichten und dokumentierten APIs beruhen. Wo undokumentierte APIs im Einsatz sind, müssen Refactoring- und Supportrisiken eingeplant werden.^[5][9]
4. Datenrechte und Verantwortlichkeiten schriftlich regeln. Besonders wichtig sind Drittanbieter-KI-Nutzung, Datenextraktion und Replikation, API-Limits, Auditierbarkeit, Incident-Verantwortung und Haftung bei KI-gestützten Schreibvorgängen in SAP.^[8][9][10]
5. FAQ und Policy-Updates laufend verfolgen. SAPs FAQ zur API Policy soll häufige Fragen beantworten und kann laut SAP von Zeit zu Zeit aktualisiert werden. Eine einmalige mündliche Einschätzung reicht für kritische Projekte kaum aus.^[12]

Fazit

Die Botschaft der neuen SAP-API-Policy ist klar: Drittanbieter-KI-Agenten können nicht mehr stillschweigend davon ausgehen, SAP-APIs frei orchestrieren zu dürfen. Für Reporting, Offline-Analysen oder Chatbots mit menschlicher Bestätigung kann die Auswirkung begrenzt bleiben. Für KI-Systeme, die SAP-Kernprozesse direkt ausführen, in ERP-Daten zurückschreiben oder Daten großflächig in externe Plattformen replizieren, ist die Policy dagegen ein wichtiger Prüfpunkt für Architektur, Vertrag und Governance.^[8][10]

Wer ohnehin auf SAP BTP, Joule und SAP AI Core setzt, erhält durch die Policy wahrscheinlich einen klareren offiziellen Rahmen.^[1][4] Unternehmen, die eine offene, systemübergreifende Agentenschicht über ERP, CRM, Supply Chain und Datenplattformen hinweg aufbauen wollen, sollten dagegen vor der Entwicklung sehr genau prüfen, welche SAP-Architekturen anerkannt sind, welche API-Rechte gelten und wo die Grenzen der Datenextraktion liegen.^[5][10]