Das SAP-Drehbuch von 2001, rückwärts gespielt: Warum die neue API-Richtlinie Zeit kauft, aber keine Zukunft

Am 24. April 2026 veröffentlichte SAP die Version 4.2026a seiner API Policy. Das Dokument ist zwei Seiten lang. Entscheidend ist Abschnitt 2.2.2. Sofern der Weg nicht über von SAP freigegebene Architekturen und Zugänge führt, untersagt die Richtlinie die Nutzung von APIs für die „interaction or integration with (semi-) autonomous or generative AI systems that plan, select, or execute sequences of API calls“, also für die Anbindung von (teil)autonomen oder generativen KI-Systemen, die Abfolgen von API-Aufrufen planen, auswählen oder ausführen. Das ist die Lehrbuchdefinition eines KI-Agenten. SAP hat die Bedrohung im Klartext benannt und ihr den Zugriff auf SAP-APIs verboten, solange sie nicht durch SAPs eigene Vordertür kommt. Abschnitt 1.2 schließt die Hintertüren: Jeder Zugriff Dritter ist auf die „Published APIs“ im SAP Business Accelerator Hub beschränkt. Abschnitt 3 verbaut die naheliegenden Umwege und untersagt zwischengeschaltete Dienste, Proxys, Gateways, eigenen Code und Impersonation-Techniken, mit denen sich die Kontrollen umgehen ließen.

Die Richtlinie ist das ausdrücklichste Verteidigungsdokument, das SAP seit einer Generation herausgegeben hat. Um zu verstehen, warum sie geschrieben wurde und warum sie nicht ausreichen wird, lohnt ein Blick 25 Jahre zurück.

Das Retrovirus, beim ersten Mal

Im April 2001 zahlte Hasso Plattner 400 Millionen Dollar in bar für ein kleines israelisches Portal-Unternehmen namens TopTier. Der Preis stand in keinem Verhältnis zu TopTiers Umsatz von rund 30 Millionen Dollar. Plattner kaufte keinen Umsatz. Er kaufte eine Befürchtung.

TopTiers Gründer Shai Agassi hatte Plattner das Portal Drag & Relate vorgeführt. Ein Nutzer konnte einen Kundendatensatz aus SAP R/3 greifen, ihn auf eine Rechnung in Oracle ziehen und ein Ticket in Siebel schließen, alles auf einem einzigen Bildschirm, den er als TopTier wahrnahm und nicht als irgendein ERP-System. Agassi leitete daraus die strategische Konsequenz in drei Schritten ab. Wer den ganzen Tag im Portal arbeitet, vergisst, welches Backend er gerade nutzt. Wandert die Logik, die alles zusammenführt, ins Portal, werden die darunterliegenden Systems of Record austauschbar. Und der Wert fließt, wie immer, dorthin, wo Entscheidungen fallen: an die Oberfläche, nicht in die Infrastruktur darunter. SAP, sagte Agassi ihm, werde zu einem „irrelevanten Hintergrundsystem und Datenspeicher“ degradiert.

Plattner reagierte, indem er die Bedrohung kaufte, Agassi in den Vorstand holte und ihn gegenüber Kollegen als „Retrovirus“ bezeichnete: einen von außen eingeschleusten Erreger, der SAPs DNA umschreiben sollte. Das Ergebnis dieser Umschreibung waren NetWeaver und das SAP Enterprise Portal, eine defensive Wette darauf, dass SAP die oberste Schicht selbst besitzen würde, statt darunter zu verschwinden.

Die Wette ging auf, allerdings vor allem, weil Portale als Bedienkonzept scheiterten. Sie erwiesen sich als teuer, fragil und in heterogenen Systemlandschaften politisch kaum durchsetzbar. Ende der 2000er-Jahre war die Arbeitsoberfläche in den meisten Unternehmen weiterhin SAP für SAP-Kunden, Salesforce für Salesforce-Kunden und Oracle für Oracle-Kunden. Das System of Record behielt den Nutzer. Plattners Instinkt war richtig. Die Bedrohung trat nur nicht ein.

Aus dem Portal wird der Agent

Jetzt ist sie da. Spielen Sie die Demo von Drag & Relate mit heutiger Technologie noch einmal durch. Ein CFO öffnet Microsoft Copilot oder das Produkt eines von einem Dutzend spezialisierter Agenten-Startups. Der Agent greift per API auf S/4HANA zu, holt Daten, wertet sie zusammen mit Daten aus Workday, Salesforce, Snowflake und ServiceNow aus und liefert entweder eine Empfehlung oder führt eine Transaktion aus. Die Intelligenz liegt beim Agenten. Das Gespräch liegt beim Agenten. Die Ausführung liegt beim Agenten. Bei SAP liegen Datenzeilen.

Jede Schwäche des Portal-Ansatzes von 2001 ist inzwischen beseitigt. Agenten brauchen keinen Rollout in Millionenhöhe: Sie laufen in einem Chatfenster. Sie brauchen keine Integrationsprojekte: Das Model Context Protocol (MCP), ein offener Standard für die Anbindung von KI-Agenten an Daten und Werkzeuge, und Agent-to-Agent-Protokolle standardisieren die Konnektoren. Sie verlangen keine Verhaltensänderung: Sie holen die Nutzer dort ab, wo diese ohnehin arbeiten. Agassis drei Punkte passen auf Agenten im Jahr 2026 sauberer als auf Portale im Jahr 2001.

Auf diese Bedrohung reagiert die API Policy. Die Richtlinie ist rational, vorhersehbar und genau das, was jeder dominante Anbieter an SAPs Stelle tun würde. Halten wird sie sich wahrscheinlich nicht.

Die Asymmetrie, die die Strategie verrät

SAP wird die Einschränkungen in der Sprache der Governance begründen: Datenqualität, Nachvollziehbarkeit für Prüfungen, Sicherheitsgrenzen, Identität von Agenten, Konformität mit der europäischen KI-Verordnung. Diese Anliegen sind berechtigt, und Kunden, die sie teilen, werden echten Nutzen aus der Richtlinie ziehen. Es ist aber auch genau die öffentliche Begründung, die ein dominanter Anbieter wählt, wenn es ihm im Kern darum geht, wer den Wert abschöpft. Das eine schließt das andere nicht aus. Die Frage ist, was die Richtlinie antreibt.

Die Antwort liegt in der Asymmetrie. SAPs eigene Joule-Agenten erhalten über die native Integration in die Suite privilegierten, tief verankerten Zugriff auf SAP-Daten. Agenten von Drittanbietern werden über kontrollierte, vermittelte und durch Richtlinien beschränkte Wege geleitet und dürfen nur über von SAP vermittelte Protokolle teilnehmen. Ginge es tatsächlich um Governance, würden die Kontrollen für beide gleichermaßen gelten. Das tun sie nicht. Sie gelten ungleich, und zwar genau so, dass sie SAPs Position als die Intelligenzschicht schützen, mit der die Nutzer arbeiten.

Warum das keine langfristige Antwort sein kann

Abgeschottete Ökosysteme funktionieren als Verteidigungsstrategie nur, solange Kunden keine brauchbare Alternative haben. Diese Bedingung ist für SAP nicht mehr gegeben.

Beginnen wir mit dem, was SAPs eigene Kunden bereits tun. Für den Investitionsreport 2026 der Deutschsprachigen SAP-Anwendergruppe (DSAG) wurden knapp 200 Mitgliedsunternehmen befragt, überwiegend aus Deutschland, Österreich und der Schweiz. 43 Prozent haben bereits KI-Anwendungsfälle umgesetzt. Von diesen betreiben 77 Prozent sie produktiv mit Lösungen außerhalb von SAP, etwa von Microsoft, OpenAI oder Anthropic. Nur 3 Prozent setzen dafür auf SAP. Das ist kein Frühindikator dafür, dass Kunden SAP bei agentischer KI eines Tages umgehen könnten. Es ist der Beleg, dass dieses Umgehen bereits in großem Umfang stattfindet, schon bevor die neue Richtlinie geschrieben wurde. Die Richtlinie richtet sich gegen eine Abwanderung, die längst in vollem Gang ist.

Der Zeitpunkt verschärft die Zwickmühle. Die Mainstream-Wartung für SAP ECC 6.0 endet am 31. Dezember 2027. Rund 10.000 SAP-Kunden weltweit stehen in den nächsten zwanzig Monaten vor einer Migrationsentscheidung, und SAP hat Joule als zentralen Grund für den Wechsel in die Cloud positioniert: Joule gibt es ausschließlich mit RISE with SAP oder GROW with SAP, für On-Premise-Bestandskunden ist kein Weg vorgesehen. Diese Konstruktion sollte aus dem Migrationszeitpunkt einen Joule-Einführungszeitpunkt machen. Doch wenn Joule der Köder ist und Joule nach dem, was SAP-Kunden selbst über ihre Nutzung berichten, auf der Agentenebene noch nicht wettbewerbsfähig ist, wird der Migrationszeitpunkt zu etwas anderem: zu dem Moment, in dem Kunden den Markt neu prüfen. Workday, Oracle Fusion, NetSuite und Composable-Enterprise-Architekturen werden zu echten Alternativen, wie sie es im letzten Migrationszyklus nicht waren. Eine Migration in ein Produkt zu erzwingen, das die Kundenbasis noch nicht für gut befunden hat, ist ein riskantes Spiel, besonders wenn der Zwang sichtbar ist.

Hinzu kommt die regulatorische Dimension. Celonis verklagt SAP bereits wegen der mutmaßlichen Blockade seiner Process-Mining-Werkzeuge, und der vorläufige Burgfrieden, dem SAP zugestimmt hat, klärt die zugrunde liegende kartellrechtliche Frage nicht. Europäische Regulierer haben wiederholt gezeigt, dass sie gegen Gatekeeper-Verhalten bei Softwareplattformen vorgehen. Der Digital Markets Act, die Transparenzpflichten der KI-Verordnung und eine aktive Wettbewerbspolitik schaffen zusammen ein erhebliches Risiko. Eine Richtlinie, die KI-Agenten ausdrücklich benennt und ihnen den Datenzugriff untersagt, solange sie nicht den bevorzugten Kanal des Plattformbetreibers nutzen, liest sich für einen Regulierer wie ein Lehrbuchfall für eine Kartellbeschwerde. SAP mag im Einzelfall die besseren juristischen Argumente haben. Es wird trotzdem Jahre und erhebliches politisches Kapital kosten, sie zu verteidigen.

Das tiefere Problem: Die Richtlinie löst nicht, was sie lösen will. Ein abgeriegelter API-Zugang verschafft SAP Zeit. Er macht Joule nicht zum besten Agenten für SAP-Daten, sondern nur zum einzigen zugelassenen. Das sind zwei verschiedene Dinge, und Kunden spüren den Unterschied. Die Geschichte dominanter Plattformen, die mit API-Beschränkungen die Ebene verteidigen wollten, auf der sie den Wert abschöpfen, verläuft einheitlich: Die Verteidigung hält, bis die Alternative gut genug ist oder der Regulierer interessiert genug. Dann öffnet sich die Plattform unter Druck oder verliert ihre Position. Microsoft und der Internet Explorer, Apple und der App Store, Twitter und seine Entwicklerplattform: Das Muster ist bekannt. SAP gehört jetzt dazu.

Wie die eigentliche Antwort aussähe

Die ehrliche Antwort ist für SAP schwieriger als die Richtlinie. Sie verlangt anzuerkennen, dass die Agentenebene eine echte neue Ebene im Enterprise-Stack ist, auf der Wert abgeschöpft wird, und auf ihr mit dem Produkt zu konkurrieren statt mit Richtlinien. Das heißt: Joule muss bei der Auswertung von SAP-Daten wirklich besser sein als jede Alternative von Drittanbietern, besser verankert, genauer, schneller und tiefer im semantischen Kontext der Suite. Es heißt auch: eine Architektur, in der Agenten von Drittanbietern als gleichberechtigte Teilnehmer mit demselben Datenzugriff mitwirken können wie SAPs eigene Agenten, geregelt durch transparente und symmetrische Kontrollen. Und es heißt, neu zu denken, wie SAP die Agentenebene monetarisiert, etwa über transaktionsbasierte Preise für Agentenaufrufe oder über kostenpflichtige Zusatzdienste, die Agenten verlässlich in SAP-Daten verankern (Grounding), statt sich auf Lizenzen pro Nutzer für eine Oberfläche zu verlassen, die Kunden womöglich gar nicht mehr nutzen.

Nichts davon ist mit der aktuellen Richtlinie unvereinbar. Nicht veröffentlichte APIs zu beschränken und nicht autorisierte Datenextraktion zu untersagen, sind vernünftige Schritte in einem durchdachten Governance-Regime für Agenten. Das Problem ist, dass die Richtlinie derzeit die gesamte sichtbare Antwort ist. Ohne eine parallele, glaubwürdige Produktantwort auf der Agentenebene wirken die Einschränkungen wie Angst und nicht wie Strategie.

Fazit

2001 erkannte Plattner die Bedrohung früh und schleuste ein Retrovirus in SAPs DNA ein: Er kaufte das Unternehmen, das die Gefahr verkörperte, und machte dessen Gründer für den Umbau verantwortlich. Die Verteidigung funktionierte, auch weil die eigentliche Bedrohung verpuffte.

Fünfundzwanzig Jahre später ist dieselbe architektonische Bedrohung zurück, in einer Form, die nicht verpuffen wird. Die Verteidigung hat sich umgekehrt. Wo Plattner einst das Retrovirus einschleuste, soll die neue Richtlinie eines draußen halten. Gleicher Instinkt, gespiegelte Richtung.

Quarantäne ist eine Taktik, keine Strategie. Je länger SAP sich darauf verlässt, ohne gleichzeitig eine Agentenebene zu liefern, die Kunden tatsächlich nutzen wollen, desto wahrscheinlicher ist es, dass Kunden den Migrationszeitpunkt 2027 für eine offene Prüfung der Alternativen nutzen, die SAP nicht steuern kann.

Plattner hat die Bedrohung einmal gekauft. Diesmal ist sie existenziell, und kaufen lässt sie sich nicht. Die schwierigere Frage, vor der nun seine Nachfolger stehen: Können sie diesmal von innen eine Antwort bauen, oder verbringen sie das nächste Jahrzehnt damit, eine Grenze zu verteidigen, die der Rest des Marktes längst umgeht?