Das neuronale Rückgrat der Weltwirtschaft: SAP, KI und die Perspektive des autonomen Unternehmens

Autor: DerSchneider

Kaum ein Softwarekonzern ist so tief in die Blutbahn der globalen Wirtschaft eingewebt wie SAP. Wenn ein Unternehmen Finanzabschlüsse tätigt, Lieferketten managt oder Mitarbeiter bezahlt, fließt irgendwo im Hintergrund fast immer Code aus Walldorf. Doch diese jahrzehntelange Vorherrschaft als „Maschinenraum“ der Weltwirtschaft steht vor ihrer größten Bewährungsprobe – oder ihrer größten Chance. Die disruptive Kraft der Künstlichen Intelligenz (KI) zwingt den Dinosaurier der Unternehmenssoftware zu einer zweiten, vielleicht existenziellen Transformation.

Auf der diesjährigen SAP Sapphire Konferenz in Orlando hat der Konzern seine Antwort präsidiert: die Vision des „autonomen Unternehmens“ (Autonomous Enterprise). Doch hinter den visionären Ankündigungen verbirgt sich ein komplexes Spannungsfeld aus technologischen Meisterleistungen, architektonischen Zwängen, politischen Weichenstellungen und ethischen Fallstricken. Dieser Artikel taucht tief ein – in das, was möglich ist, und das, was (noch) nicht geht. Er beleuchtet die Mechanismen, die Versprechen und die harte Realität in den Rechenzentren der Kunden.

1. Die große Verheißung: Das autonome Unternehmen als Endziel

Die Vision, die SAP-CEO Christian Klein und sein Team in Orlando entwarfen, ist ambitioniert: SAP wolle sich „von einem Softwareunternehmen zu einem Unternehmen für Business-KI“ wandeln. Das Schlagwort ist das „autonome Unternehmen“ – eine Organisation, in der KI-Agenten nicht nur assistieren, sondern Geschäftsprozesse von Anfang bis Ende selbstständig ausführen.

Was bedeutet das konkret? Ein Blick auf die Bestandteile:

Die Zahlen hinter der Vision:

• Mehr als 50 domänenspezifische Joule-KI-Assistenten (für Finanzen, Lieferkette, Einkauf, HR, Customer Engagement)
• Ein Schwarm von über 200 spezialisierten Agenten, die von diesen Assistenten koordiniert werden
• Das Ziel: den monatelangen Prozess des Jahresabschlusses auf wenige Tage zu komprimieren, Lieferketten automatisch neu auszubalancieren oder Wartungsausfälle von Offshore-Windkraftanlagen vorherzusagen und zu beheben.

Christian Klein machte die Richtung unmissverständlich klar: „Wir bauen nichts Geringeres als ein neues SAP.“ Der Konzern will vom reinen Aufzeichner menschlicher Aktivitäten („Software, die aufzeichnet, was Menschen tun“) zum Akteur werden („Software, die die Arbeit selbst erledigt“).

Doch wie soll dieser Wandel gelingen? Die Antwort liegt in einer dreischichtigen technologischen Architektur, die wie ein Schichtenmodell aufeinander aufbaut: die Datenebene (Knowledge Graph), die Ausführungsebene (Autonomous Suite mit ihren Agenten) und die Interaktionsebene (Joule Work).

2. Die erste Schicht: Das Knowledge Graph – Gegenmittel gegen Halluzinationen

Das Hauptproblem jedes Large Language Models (LLM) im Unternehmenskontext ist der fehlende Kontext. ChatGPT weiß viel über die Welt, aber nichts über die spezifische Rechnungsnummer eines Kunden, die Freigabeprozesse in der Beschaffung oder die Beziehung zwischen einem Lieferanten, einem offenen Bestellwert und einem Fertigungsauftrag.

SAPs CTO Philipp Herzig brachte es auf den Punkt: „Einfach ein LLM anzuschließen, funktioniert nicht. Es halluziniert wie verrückt. Vielleicht funktioniert es für ein oder zwei Ergebnisse, aber die Resultate sind nicht skalierbar.“

Das Gegenmittel ist der SAP Knowledge Graph – eine semantische Landkarte aller Geschäftsentitäten, Prozesse und Beziehungen innerhalb der SAP-Landschaft eines Kunden. Allein für S/4HANA und SuccessFactors umfasst dieser Graph 700 Millionen Beziehungen (sogenannte Triplets).

Technische Herausforderung: Diese 700 Millionen Beziehungen sind viel zu umfangreich, um in das Kontextfenster (Context Window) eines LLM zu passen – selbst bei Modellen mit Millionen von Tokens. Die ingenieurstechnische Meisterleistung von SAP besteht darin, aus diesem Ozean an Beziehungen dynamisch nur den relevantesten Teil zu extrahieren, der für die spezifische Anfrage eines Nutzers oder Agenten benötigt wird.

2.1 Was geht – und was nicht geht

Die kritische Einschränkung: Der Knowledge Graph produziert keine saubere Semantik aus schmutzigen Quelldaten; er spiegelt lediglich wider, was existiert. Wenn die Kostenstellen-Hierarchie seit der ursprünglichen ECC-Einführung vor 15 Jahren inkonsistent gepflegt wurde, wird der Knowledge Graph diese Inkonsistenz widerspiegeln. Das führt zu fehlerhaften Agenten-Entscheidungen und schafft Misstrauen.

3. Die zweite Schicht: Die Autonomous Suite und die Agenten-Orchestrierung

Auf dem Knowledge Graph aufbauend präsentierte SAP die SAP Autonomous Suite – die Sammlung der Agenten, die tatsächlich handeln. Im Gegensatz zu einfacher Automatisierung (RPA), die starren Regeln folgt, sind diese Agenten zielorientiert.

3.1 Die drei Governance-Ebenen für Agenten

Jonathan von Rueden, Head of AI Innovation & Data bei SAP, beschrieb ein mehrlagiges Governance-Modell, das für Akzeptanz und Kontrolle sorgen soll:

Ebene 1 – Der Business User:
Der Fachanwender sieht, welche Agenten aktiv sind, in welchem Prozessschritt sie sich befinden, und – entscheidend – die Begründung hinter einer Entscheidung, inklusive der Quellen, auf denen diese Begründung basiert. Eine nicht-technische Person kann also genau nachvollziehen, warum ein Agent eine bestimmte Aktion vorgeschlagen hat.

Ebene 2 – Der IT- und Compliance-Verantwortliche:
Die SAP Agent Hub bietet einen organisationsweiten Überblick über alle Agenten – sowohl SAP-eigene als auch Drittanbieter wie ServiceNow, Microsoft, Databricks und AWS. Hier sieht das Compliance-Team, wie oft ein Agent ausgeführt wurde, wo Runs fehlgeschlagen sind und wo ein Endbenutzer eine Genehmigung verweigert hat.

Ebene 3 – Der Audit- und Entwickler:
Vollständige Log-Level-Tracing ermöglicht die Rekonstruktion jeder einzelnen Entscheidung eines Agenten – Werkzeug für Werkzeug, Entscheidung für Entscheidung. Von Rueden betont: „Jedes ausgewählte Werkzeug und die Begründung dafür ist nachverfolgbar.“

Voraussetzung für Vertrauen: Diese Transparenz ist die Grundlage für den Betrieb agentischer KI in regulierten Umgebungen. Ohne sie bleibt autonome KI ein nicht auditierbares, nicht versicherbares Risiko.

3.2 Lernen aus Ausnahmen: Die Company Memory

Eine besonders interessante Innovation ist die Company Memory (Unternehmensgedächtnis). Sie fungiert als lernender Puffer zwischen Agenten und menschlichen Experten.

Der Mechanismus:

1. Ein Agent stößt auf einen mehrdeutigen Fall und pausiert seine Aktion.
2. Der Agent fordert den Menschen zur Entscheidung auf (z. B. via Push-Benachrichtigung).
3. Der Mensch trifft eine Entscheidung oder gibt eine Richtlinie vor.
4. Die Company Memory analysiert diese manuelle Entscheidung und prüft, ob sie ein neues Geschäftsbedürfnis repräsentiert, das zur Standardregel werden sollte.
5. Nach Validierung wird die neue Regel als strukturierte Daten in den Knowledge Graph eingespeist.
6. Alle Agenten im Unternehmen passen sich sofort an.

Muhammad Alam, SAP-Vorstand für Produktentwicklung, erklärte: „Wenn eine Ausnahme auftritt, wird sie zum Unternehmensgedächtnis hinzugefügt, und alle Agenten passen sich sofort an.“

Was geht – und was nicht geht

4. Die dritte Schicht: Joule Work – Die neue Benutzeroberfläche

Am radikalsten ist vielleicht der Wandel der Benutzeroberfläche. Joule Work ersetzt zunehmend das klassische GUI durch ein gesprächsorientiertes Erlebnis.

Der Nutzer beschreibt das gewünschte Outcome in natürlicher Sprache (z. B. „Ich brauche eine Risikoanalyse für Lieferant X im dritten Quartal“). Joule orchestriert dann den Aufruf der notwendigen Agenten, Workflows und Daten – auf Desktop, mobil und per Sprache, sowohl innerhalb als auch außerhalb von SAP-Systemen.

Jonathan von Rueden fasst den Paradigmenwechsel zusammen: „Die Erwartungen der Nutzer ändern sich schnell. Die Menschen wollen Prozesse immer weniger über separate Anwendungen oder komplexe Oberflächen angehen, sondern direkt von einer Aufgabe oder Frage ausgehend. KI-Agenten ermöglichen diese Verschiebung.“

Der aktuelle Stand der Tools (Mai 2026):

Die Lehre aus den Verzögerungen: Die ursprüngliche Version von Joule Studio war zu sehr auf Low-Code-Einfachheit und zu wenig auf professionelle Code-Flexibilität ausgelegt. Kunden brachten „große Pläne“ mit, benötigten aber strenge Regeln und Genehmigungsabläufe, die die erste Version nicht nativ unterstützte. Mit Version 2.0 können Entwickler nun eigene Agenten bauen, diese mit GitHub verbinden und gängige Frameworks wie LangGraph nutzen.

5. Die unbequeme Wahrheit: Der Clean Core als notwendige Voraussetzung

So visionär die Ankündigungen klingen, so ernüchternd ist die Realität in vielen Kundeninstallationen. Eine Studie von ASUG und SAP zeigt, dass nur 3 % der SAP-Kunden SAP Business AI produktiv nutzen. 77 % der KI-aktiven SAP-Enterprise-Kunden setzen auf Nicht-SAP-Tools wie Snowflake Cortex oder Databricks Mosaic AI.

Der Grund: Der Zugang zu Joule erfordert einen RISE- oder GROW-Vertrag – und damit eine Cloud-Migration. Noch wichtiger: Die Daten sind nicht bereit.

Matt Florian, Practice Director bei Hakkoda, bringt es auf den Punkt: *„Die Migration hat die Daten verschoben, aber sie hat sie nicht repariert. Jahre von benutzerdefinierten Z-Tabellen, modifizierten Standardfeldern und Workarounds, die 2009 Sinn ergaben, sind Ihnen in die neue Umgebung gefolgt. Sie sitzen jetzt in Ihrer Hybrid-Cloud-Plattform und warten darauf, dass ein Joule-Agent oder ein KI-Modell versucht, über sie zu schlussfolgern.“*

Die Botschaft der Referenzkunden auf der Sapphire (ExxonMobil, Levi Strauss, Lockheed Martin) war einstimmig: KI kann keinen kaputten Prozess reparieren, und Clean Core ist eine Voraussetzung für KI-Geschwindigkeit.

SAP hat reagiert und ein formelles Clean Core Certification Programme eingeführt, das BTP-Erweiterungen als upgrade-kompatibel über drei S/4HANA Cloud-Release-Zyklen zertifiziert. Clean Core ist keine Empfehlung mehr – es ist eine Infrastrukturrichtlinie mit Compliance-Pfad.

6. Die API-Politik: Offenheit als Rhetorik, Kontrolle als Strategie

Der wohl kontroverseste Aspekt der SAP-KI-Strategie ist die API-Politik. Im April 2026 veröffentlichte SAP die Version 4 seiner API-Richtlinie mit einer folgenreichen Klausel.

Abschnitt 2.2.2 verbietet die Nutzung von SAP-APIs für „die Interaktion oder Integration mit (semi-)autonomen oder generativen KI-Systemen, die Sequenzen von API-Aufrufen planen, auswählen oder ausführen“ – es sei denn, dies geschieht über von SAP befürwortete Architekturen.

Die praktische Bedeutung:

• Drittanbieter-KI-Agenten (z. B. Microsoft Copilot, Salesforce Einstein) haben formelle Beschränkungen
• Nur SAPs eigene Joule, Business Data Cloud und der kommende Agent Gateway sind die erlaubten Pfade
• Nicht dokumentierte oder private APIs sind sofort verboten; die ODP-RFC-Schnittstelle wird ab Juli 2026 blockiert
• SAP behält sich das Recht vor, nicht konformen Zugriff zu drosseln, auszusetzen oder zu beenden

6.1 Zwei Perspektiven auf dieselbe Politik

Die offizielle Begründung (SAP):
CEO Christian Klein betonte im Q1-Investoren-Call, SAP wolle eine „offene Plattform“. Die Politik diene dem Schutz der Stabilität. KI-Agenten erzeugen fundamental andere Lastprofile als menschliche Nutzer: Sie pausieren nicht, drosseln nicht und beachten keine natürlichen Rhythmen menschlicher Interaktion. Für mission-critical ERP-Infrastruktur ist das ein echtes Engineering-Problem.

Die kritische Perspektive (Markt & Nutzer):
Die DSAG (deutschsprachige SAP-Anwendergruppe) hat formal festgestellt, dass die Beschränkungen „breiter erscheinen, als es der Infrastrukturschutz allein rechtfertigen würde“. Der praktische Effekt beschränkt nicht nur Integrationspartner, sondern die Unternehmen selbst.

Die Asymmetrie ist offensichtlich: Unternehmen, die SAP-eigene KI nutzen, erhalten einen strukturell schnelleren und leistungsfähigeren Integrationspfad als Unternehmen, die unabhängige Tools verwenden. Das ist keine neutrale Infrastrukturentscheidung – es ist eine wettbewerbsorientierte Positionierungsentscheidung, ausgedrückt durch API-Politik.

Der Vergleich mit Wettbewerbern:

SAPs CTO definierte APIs in einem Q&A als „veraltete Technologie“ und A2A/MCP als „neu und modern“. SAP unterstützt A2A für die Kommunikation externer Agenten mit Joule, erlaubt aber keinen direkten Zugriff über MCP. Die Folge ist eine potenzielle doppelte Inferenz: Ein externer Agent führt bereits eine Inferenz durch, dann führt Joule eine zusätzliche Inferenz durch, um die Anfrage zu verstehen. Das verdoppelt Latenz und Kosten – eine architektonische Anforderung von SAP, keine Kundenentscheidung.

7. Perspektiven 2026–2027: Wo steht SAP in zwölf Monaten?

Die nächsten zwölf bis 24 Monate werden zeigen, ob SAPs Gamble aufgeht. Mehrere Entwicklungen sind zu beobachten:

7.1 Der Partnerfonds und das Ökosystem

SAP hat einen 100-Millionen-Euro-Partnerfonds aufgelegt, um die Lücke zwischen Produktvision und Implementierung zu schließen. Freie Entwickler und Berater sollen auf der neuen Plattform KI-Helfer entwickeln.

7.2 Das Pricing-Modell im Wandel

Eine Sorge an der Börse ist, dass die Zahl der Nutzer und damit der Umsatz im KI-Zeitalter stark zurückgeht, weil weniger Nutzer dank KI viel mehr erreichen können. SAP hat angekündigt, die Bezahlung künftig mehr am Nutzen und nicht mehr an der Nutzerzahl zu orientieren. Details dazu sollen in den kommenden Wochen veröffentlicht werden.

7.3 Die offenen Fragen

• EU Data Act: Das ab September 2025 geltende Gesetz verankert das Recht der Kunden auf Daten, die sie in vernetzten Systemen generieren. Wie SAP diesen rechtlichen Rahmen mit seiner restriktiven API-Politik vereinbaren will, ist noch nicht vollständig geklärt.
• Joule Studio 2.0: Die verspätete GA (Q3 2026) wird der Lackmustest für die professionelle Entwickler-Community sein.
• Adoption vs. Vision: Die Diskrepanz zwischen der Vision des autonomen Unternehmens und den 3 % produktiver Nutzung ist gewaltig.

8. Fazit: Die zweite Transformation

SAP steht vor einer existenziellen Bewährungsprobe. Die KI-These „KI frisst Software“ bedroht das klassische Lizenz- und Implementierungsmodell des Konzerns. Doch SAP dreht den Spieß um: Wer vom einzigartigen Datenpool und dem jahrzehntelangen Prozesswissen profitieren will, soll künftig nach SAPs Regeln spielen.

Was geht:

• Die technologische Architektur (Knowledge Graph, Company Memory, dreistufiges Governance-Modell) ist durchdacht und adressiert die zentralen Probleme von KI im Unternehmenskontext: Halluzinationen, fehlende Nachvollziehbarkeit und Kontrollverlust.
• Für Cloud-Kunden mit Clean Core sind reale Effizienzgewinne von 35 % bei Migrationsprojekten plausibel.

Was nicht geht:

• Die Nutzung moderner Agenten-KI ohne vorherige Datenbereinigung und Prozessharmonisierung. Wer hier spart, baut auf Sand.
• Die freie Wahl des KI-Tools für den Zugriff auf SAP-Kerndaten – zumindest nicht ohne Mehrkosten, Latenz oder den Umweg über Joule.
• Eine vollständig autonome, unbeaufsichtigte Agentenausführung in hochkritischen, regulierten Bereichen (Finanzabschluss, Gehaltsabrechnung) – dafür ist das Vertrauen noch nicht da, und die Technik ist es auch nicht.

Die Perspektive für den Kunden:
Es entsteht der Druck, nicht nur technisch in die Cloud zu migrieren, sondern die gesamte Prozesslogik auf Autonomie zu trimmen. Das ist teuer und aufwendig. Aber es verspricht einen Wettbewerbsvorsprung für diejenigen, die die Reise antreten. Gelingt SAP der Spagat zwischen technologischer Exzellenz, politischer Kontrolle und echter Kundenfreiheit, sichert der Konzern seine Marktmacht für die nächsten zwei Jahrzehnte. Scheitert SAP an der Komplexität oder der Hybris seiner API-Politik, könnten schlankere, KI-native Konkurrenten Marktanteile erobern.

Eines ist sicher: Das Zeitalter der einfachen Automatisierung ist vorbei. Die Zukunft gehört dem Unternehmen, dessen digitales Nervensystem am schnellsten und zuverlässigsten aus Daten Handlungen werden lässt – ohne dabei die Kontrolle zu verlieren. Ob SAP dieser Architekt sein wird, entscheidet sich in den nächsten 24 Monaten im Rechenzentrum des Kunden, nicht auf der Bühne in Orlando.

Quellen

1. Hakkoda. (2026, Mai 18). *The Data Problem Your S/4HANA Migration Didn’t Solve*. https://hakkoda.io/resources/the-data-problem-your-s-4hana-migration-didnt-solve/ 
2. CData Software. (2026, Mai 12). SAP’s API Policy Is a Warning Shot. Is Your AI Strategy Ready? https://www.cdata.com/blog/sap-api-policy-ai-strategy 
3. Emerce. (2026, Mai 21). SAP: wie AI-agents inzet zonder governance, bouwt op drijfzand. https://www.emerce.nl/wire/sap-wie-aiagents-inzet-zonder-governance-bouwt-drijfzand 
4. ZDNet France. (2026, Mai 20). « Brancher un LLM seul ne fonctionne pas » : le CTO de SAP dévoile les rouages son IA. https://www.zdnet.fr/actualites/brancher-un-llm-seul-ne-fonctionne-pas-le-cto-de-sap-devoile-les-rouages-son-ia-495378.htm 
5. Waehner, K. (2026, Mai 2). Data Ownership in the Age of Agentic AI: Why SAP’s API Policy Forces a Data Integration Reckoning for Every Enterprise. https://www.kai-waehner.de/blog/2026/05/02/data-ownership-in-the-age-of-agentic-ai-why-saps-api-policy-forces-a-data-integration-reckoning-for-every-enterprise/ 
6. Frankfurter Allgemeine Zeitung. (2026, Mai 11). SAP will die Kontrolle über KI. https://www.faz.net/aktuell/wirtschaft/unternehmen/sap-schaltet-auf-attacke-und-will-die-kontrolle-ueber-ki-200824994.html 
7. 至顶网 (Zhiding.com). (2026, Mai 20). SAP去年的AI承诺大多仍在推进中. https://ai.zhiding.cn/2026/0521/3187683.shtml 
8. Computer Sweden. (2026, Mai 12). SAP gör sin största AI-satsning hittills. https://computersweden.se/article/4170606/saps-hittills-storsta-satsning-pa-ai-agenter-som-utfor-uppgifter-inte-bara-assisterar.html 
9. E3-Magazin. (2026, Januar 14). KI mit ERP: Wer braucht das? https://e3mag.com/de/ki-mit-erp-wer-braucht-das/ 
10. Digital Today (Korea). (2026, Mai 15). SAP blocks external AI agent access to platform while Salesforce, ServiceNow open up. https://www.digitaltoday.co.kr/en/view/55870/sap-blocks-external-ai-agent-access-to-platform-while-salesforce-servicenow-open-up