KI-Exit für SAP-Bestandskunden

Agnostische KI-Modelle

Ein technischer Fluchtweg aus der KI-Abhängigkeit führt über agenten-agnostische Modelle. Dieser Ansatz zielt darauf ab, das geschäftskritische Prozesswissen und die prozessuale Logik vollständig von den zugrunde liegenden KI-Plattformen zu entkoppeln. Das Ziel ist, dass sich die KI-Plattform bei Bedarf oder bei unvorhersehbaren Marktkonsolidierungen verhältnismäßig kurzfristig austauschen lässt, wodurch die getätigten Investitionen sowie das Prozess-Know-how im Unternehmen verbleiben und nicht unwiederbringlich in externe, oftmals außereuropäische Plattformen abfließen.

Eine weitere Alternative zur BTP manifestiert sich im Aufbau von hybriden IT-Landschaften und dem Konzept des Composable ERP, bei dem unabhängige Integrationsplattformen (iPaaS) wie Boomi die prozessuale Orchestrierung übernehmen. Anstatt sich dem lizenztechnischen Diktat der BTP zu unterwerfen, nutzen ERP-Anwender etwa Plattformen wie Boomi, um SAP-Kerndaten nahtlos und ohne aufwendige Entwicklungen in jeden beliebigen Cloud-Data-Lake oder an externe KI-Modelle einzuspeisen. Dies ermöglicht es den SAP-Bestandskunden, skalierbare, cloudnative und KI-gesteuerte Datenstrategien zu entwickeln, die vollkommen anbieterunabhängig sind und die Kontrolle über autonome KI-Agenten in den eigenen Händen belassen.

Für SAP-Bestandskunden, die aus Gründen des Datenschutzes, der Compliance oder der Kosteneffizienz den Weg in die Public Cloud scheuen, bieten spezialisierte Open-Source-Betriebsplattformen wie Red Hat OpenShift AI oder Suse AI (siehe auch E3-Coverstory September 2026) eine souveräne und sichere Lösung für den rein lokalen Betrieb von künstlicher Intelligenz.

Anstatt sensible Unternehmensdaten zur Verarbeitung an amerikanische Hyperscaler oder in die SAP-Cloud zu übertragen, können auf diesen Plattformen lokale Open-Source-Large-Language-Models (LLMs) wie Llama oder Mistral auf unternehmenseigener Hardware oder in der Private Cloud betrieben werden. Architektonisch bleibt das SAP-System in diesem Side-by-Side-Modell das Backend für die strukturierten Geschäftsdaten, während die eigentliche KI-Logik in einer separaten Infrastruktur läuft und lediglich über standardisierte Schnittstellen wie OData, MCP-Server oder REST kommuniziert.

Diese radikale Entkopplung garantiert nicht nur die absolute Datenhoheit, sondern ermöglicht im Sinne einer KI-Exit-Strategie jederzeit einen nahtlosen Wechsel der eingesetzten Sprachmodelle, ohne dass bestehende SAP-Kernprozesse beeinträchtigt werden.

SAP Business AI und der Knowledge Graph

SAP-Chef Christian Klein und sein Vorstandsteam haben auf den hauseigenen Sapphire-Konferenzen das Autonomous Enterprise ausgerufen, in dem Hunderte von spezialisierten KI-Agenten die Geschäftsprozesse weitgehend eigenständig abwickeln sollen. Technisch stützt sich dieses Szenario im Wesentlichen auf zwei Säulen: SAP Business AI und SAP Knowledge Graph (Hana).

Das grundlegende Problem bei der Nutzung generischer Large Language Models (LLMs) im Unternehmen ist deren mangelnder geschäftlicher Kontext. LLMs kennen weder spezifische Tabellenbeziehungen noch interne Genehmigungsrichtlinien. Der Knowledge Graph (SAP Hana) fungiert hierbei als der semantische Kompass, um in dem hochkomplexen ERP-Universum mit über sieben Millionen Datenfeldern den Überblick zu behalten.

Durch die automatische Generierung von Ontologien aus Metadaten der SAP Hana Cloud verknüpft die Hana Graph Engine relationale Datenstrukturen, Geschäftsobjekte (wie Kunden, Bestellungen und Rechnungen) sowie kundenspezifische Erweiterungen zu einem semantischen Beziehungsgeflecht. Diese semantische Grundierung ermöglicht es dem KI-Assistenten Joule und den kooperierenden Agenten, präzise und logische Schlussfolgerungen zu ziehen und das gefürchtete Halluzinieren von KI-Modellen drastisch zu reduzieren.

SAP Hana Cloud Graph Engine

Als technische Datenbank-Maschine im Hintergrund dient die Hana Cloud Graph Engine, die seit dem Update im ersten Quartal 2025 nativen Support für das Speichern und Abfragen von Knowledge Graphs bietet. Damit schließt SAP eine funktionale Lücke, da Kunden zuvor für relationale Daten und Graph-Datenbanken unterschiedliche Systeme (wie z. B. Neo4j) parallel betreiben mussten.

Nun lassen sich beide Welten in einer Datenbank konsolidieren und über graphbasierte Abfragesprachen wie openCypher oder SPARQL ansteuern. Ein LLM kann dadurch natürlichsprachliche Anfragen in eine SPARQL-Abfrage übersetzen und ausführen, ohne dass Entwickler im Vorfeld mühsam starre APIs programmieren müssen. Aus technischer Sicht ist dieser Ansatz ein eleganter Weg zur Datenharmonisierung.

Das BTP-Korsett und das Rebranding zu SAP BAIP

Unternehmerisch verbirgt sich hinter dieser Hana-Architektur jedoch eine kaufmännische und lizenzrechtliche Strategie, die darauf abzielt, die mühsam erarbeitete Unabhängigkeit der SAP-Bestandskunden einzuschränken. Die Business Technology Platform ist der exklusive Austragungsort für die SAP-KI-Szenarien. Um die Kontrolle über das gesamte Daten- und KI-Ökosystem zu zentrieren, hat SAP im Jahr 2026 die BTP, die Business Data Cloud (BDC) und das Business Transformation Management zu einem einzigen, konsolidierten Stack unter dem Namen SAP Business AI Platform (BAIP) verschmolzen.

Die Umbenennung der BTP zur BAIP-Kompetenz erfolgte zum 30. Juni 2026, während die neuen, verschärften Anforderungen an die KI-Lieferfähigkeit ab Januar 2027 greifen sollen. Für den SAP-Bestandskunden bedeutet dieser strategische Schwenk vor allem eines: Der Einzug der künstlichen Intelligenz wird unlösbar mit dem restriktiven BTP-Lizenzmodell und dem Zwang zu Cloud-Verträgen verknüpft.

Wer den KI-Assistenten Joule oder den Generative AI Hub nutzen möchte, muss in die teuren BTP-Vertragsmodelle wie das Cloud Platform Enterprise Agreement (CPEA) oder das BTP Enterprise Agreement (BTPEA) einsteigen, bei denen die unübersichtlichen Abrechnungen über sogenannte Capacity Units (CUs) und Token-Verbräuche erfolgen.

Der SAP-Anwenderverein DSAG kritisiert diesen BTP-Zwang scharf: Da die verbrauchsbasierten AI-Punkte nicht auf das Folgejahr übertragbar sind, verfallen ungenutzte Kontingente am Jahresende, während jede Übernutzung unrabattiert zu Listenpreisen abgerechnet wird. Zudem blockiert die im April 2026 verschärfte SAP API Policy den direkten Datenabfluss und schränkt die unlizenzierte Anbindung von Drittanbieter-KI-Agenten drastisch ein, was den BTP-Zwang und die damit verbundenen Transaktionsgebühren weiter zementiert.

Die Alternativen zur SAP-Plattform: Simplifier und Boomi

SAP-Bestandskunden sind diesem Lizenzdiktat keineswegs schutzlos ausgeliefert. Es gibt herstellerunabhängige Alternativen, die den Anspruch auf technische Souveränität ernst nehmen. Wer side-by-side entwickeln und dennoch die Lizenzgebühren der SAP BTP umgehen möchte, findet im Low-Code-Bereich mit Simplifier einen profilierten Gegenentwurf.

Während BTP die Anwender immer enger an das proprietäre SAP-SaaS-Korsett bindet, setzt Simplifier auf offene Web-Standards und das UI5-Framework, wodurch ein Vendor-Lock-in vermieden wird. Simplifier ermöglicht es mittelständischen Unternehmen, Fiori-Anwendungen bis zu zehnmal schneller zu entwickeln, SAP- und Non-SAP-Systeme flexibel zu integrieren und gleichzeitig den S/4-Kern absolut sauber (Clean Core) zu halten.

Für die Datenorchestrierung und Integration bietet sich die herstellerunabhängige iPaaS-Plattform von Boomi an. Boomi hat sich im Gartner Magic Quadrant als Marktführer neben der BTP etabliert, unterscheidet sich jedoch in seiner offenen Philosophie. Die im Mai 2026 verkündete strategische Partnerschaft von Boomi mit Red Hat liefert hierbei den entscheidenden Hebel. Durch die Kombination von Boomis Agentstudio und Red Hat AI können Unternehmen einen souveränen, Kubernetes-nativen Open-Source-KI-Stack aufbauen. Dieser Stack ermöglicht eine echte Private-AI-Strategie und eine mautfreie KI-Exit-Strategie.

Token-Panik: Intelligentes Routing und Open Source

Der unregulierte Einsatz von generativer KI führt in vielen Unternehmen derzeit zu einer Kostenexplosion. Angesichts der teuren Frontier-Modelle von OpenAI (wie GPT-5) und Anthropic (wie Claude/Fable) sprechen Marktbeobachter bereits von einer weltweiten Token-Panik, bei der die Token-Ausgaben die tatsächliche Wertschöpfung in den Schatten stellen. Um diese Kosten effektiv zu reduzieren oder gänzlich zu vermeiden, setzen IT-Architekten zunehmend auf sogenannte LLM-Gateways und LLM-Router.

Open-Source-Modelle

Der Markt verschiebt sich massiv in Richtung lokal gehosteter Open-Source-Modelle. Leistungsfähige Systeme wie LLaMA von Meta, Mistral oder die chinesischen Open-Weights-Modelle wie DeepSeek, Qwen und Kimi sind technisch nur noch wenige Monate hinter den Frontier-Modellen her, kosten aber nur einen Bruchteil. Selbst Microsoft-CEO Satya Nadella prüft den Einsatz von DeepSeek für den hauseigenen Copiloten, um die Margen zu sichern. Ein SAP-Bestandskunde kann diese Open-Source-Modelle kostengünstig und datenschutzkonform auf eigener Hardware betreiben, was den teuren Umweg über die BTP-Abrechnung vollständig einspart.

Die lehrreiche Antwort auf die Frage, ob ein SAP-Bestandskunde die hauseigenen Lösungen wie Joule, den SAP Knowledge Graph oder die Business AI zwingend nutzen muss, lautet: Nein, es gibt keinen technischen oder funktionalen Zwang. Die SAP-Community und innovative ERP-Anwender sind längst weiter als die Entwicklungsabteilung bei SAP. Der DSAG-Investitionsreport 2026 belegt, dass die Mehrheit der SAP-Bestandskunden und DSAG-Mitglieder ihre produktiven KI-Anwendungsfälle mit Fremdlösungen und nicht mit SAP-Werkzeugen umsetzt.