AI auf der SAP BTP ist das Themenfeld, das die Plattform derzeit am stärksten prägt und genau damit schließen wir unsere Serie „SAP BTP verstehen“ ab. In den vergangenen sechs Teilen ging es um Integration, Erweiterbarkeit und Datenmanagement. Im letzten Teil geht es um das Thema, über das in unseren Projekten aktuell am meisten gesprochen wird: SAP AI Core, der Generative AI Hub, Joule und SAP Business AI sind längst keine Randnotiz mehr, sondern das Rückgrat vieler neuer Vorhaben auf der Plattform.
Passend dazu hat SAP auf der Sapphire im Mai 2026 mit der SAP Business AI Platform eine neue, übergeordnete Marke eingeführt, die BTP, Business Data Cloud und Business AI unter einem Dach bündelt. Keine Sorge: BTP verschwindet damit nicht. Der Name bleibt als Cockpit-Bezeichnung und technisches Fundament bestehen; nur die Erzählung darüber wird größer.
Genau dieses Fundament nehmen wir uns hier vor – Baustein für Baustein und als Abschluss unserer Serie. Wer die vorangegangenen Teile noch nicht gelesen hat, findet dort die Grundlagen zu Integration, Erweiterbarkeit und Datenmanagement, auf denen das KI-Portfolio aufsetzt.
SAP AI Core & SAP AI Launchpad
Wer verstehen will, wie SAP AI Core auf der SAP BTP technisch verankert, landet zwangsläufig bei SAP AI Core. Der Service läuft Kubernetes-basiert im Cloud-Foundry-Environment. Er übernimmt den gesamten ML-Lebenszyklus: Training, Deployment und Betrieb von Modellen und KI-Workflows. Dabei ist er mandantenfähig, für beliebig viele parallele Projekte.
In der Praxis heißt das: Ein Fachbereich lässt ein eigenes Prognosemodell trainieren. Parallel arbeitet ein zweites Team an einem generativen Assistenten. Beide Vorhaben kommen sich dabei nicht in die Quere.
Neben klassischen, selbst trainierten Modellen stellt SAP hier auch eigene Foundation-Modelle bereit, allen voran SAP-RPT-1. Das ist ausdrücklich kein Sprachmodell, sondern ein tabellen-natives Prognosemodell. Es arbeitet direkt mit strukturierten Geschäftsdaten, etwa für Bedarfsprognosen oder Ausfallwahrscheinlichkeiten. Für Projekte, die auf harte Zahlen aus S/4HANA oder dem Data Warehouse angewiesen sind, ist das oft die praktikablere Wahl als ein generisches Sprachmodell.
Bei den Sprachmodellen selbst bleibt SAP AI Core konsequent Hyperscaler-agnostisch. GPT-Modelle laufen über Azure OpenAI. Claude und Amazon Nova laufen beide über AWS Bedrock. Gemini läuft über Google Cloud Vertex AI. Eine Ausnahme lohnt den genauen Blick, weil sie in vielen Architektur-Skizzen übersehen wird: Mistral läuft, ebenso wie IBM-Modelle und diverse Open-Source-Modelle, nicht über einen Hyperscaler, sondern direkt auf AI Core selbst. Für Kunden mit strengen Vorgaben zur Datenresidenz ist das ein handfestes Argument. Das gilt besonders, wenn ein US-Hyperscaler im Beschaffungsprozess Fragen aufwirft.
Generative AI Hub: der zentrale Zugang zu AI auf der SAP BTP
Damit diese Modellvielfalt nutzbar wird, sitzt darüber der Generative AI Hub. Kein Team muss dafür eine eigene API-Anbindung bauen. Er bietet eine einheitliche Schnittstelle mit Prompt-Management, Content-Filtering und Grounding, also der Anbindung an eigene Unternehmensdaten.
Ein Punkt, der in Angeboten gerne untergeht: Der Generative AI Hub steht ausschließlich im Service-Plan Extended zur Verfügung. Im Free Tier und im Standard-Plan fehlt er. Wer mit einem günstigeren Plan gestartet ist, kann zwar ohne Datenverlust auf Extended upgraden. Den Mehrpreis sollte man aber von Anfang an einkalkulieren, nicht erst, wenn das erste generative Szenario ansteht.
Damit diese Modellvielfalt nutzbar wird, sitzt darüber der Generative AI Hub. Kein Team muss dafür eine eigene API-Anbindung bauen. Er bietet eine einheitliche Schnittstelle mit Prompt-Management, Content-Filtering und Grounding, also der Anbindung an eigene Unternehmensdaten.
Ein Punkt, der in Angeboten gerne untergeht: Der Generative AI Hub steht ausschließlich im Service-Plan Extended zur Verfügung. Im Free Tier und im Standard-Plan fehlt er. Wer mit einem günstigeren Plan gestartet ist, kann zwar ohne Datenverlust auf Extended upgraden. Den Mehrpreis sollte man aber von Anfang an einkalkulieren, nicht erst, wenn das erste generative Szenario ansteht.
Ein zweiter Punkt gehört gleich daneben: Der Service-Plan ist nur der Zugang, nicht der Preis. Abgerechnet wird die eigentliche Nutzung über Capacity Units, tokenbasiert pro Modell. Ein Aufruf gegen ein großes GPT- oder Claude-Modell schlägt anders zu Buche als derselbe Aufruf gegen ein kleineres Modell auf AI Core. Das ist im Alltag weniger eine Preis- als eine Architekturfrage: Wer Grounding großzügig einsetzt und ganze Dokumentenkontexte mitschickt, erzeugt Kosten, die im Proof of Concept mit zehn Testfragen niemandem auffallen und im Produktivbetrieb mit tausend Anfragen am Tag plötzlich sichtbar werden. Eine grobe Hochrechnung auf das erwartete Anfragevolumen gehört deshalb schon in die Konzeptphase, nicht erst in die erste Rechnungsprüfung.
SAP AI Launchpad: das Cockpit für Betrieb und Governance
Das Cockpit über all dem heißt SAP AI Launchpad. Als Multi-Tenant-SaaS-Anwendung verwaltet es Deployments und Konfigurationen zentral. Es liefert Monitoring über mehrere AI-Core-Instanzen hinweg. Von dort aus öffnet sich zudem der Zugriff auf die Werkzeuge des Generative AI Hub.
Wer in einem Konzern mehrere AI-Core-Instanzen für unterschiedliche Landschaften betreibt, bekommt hier die eine Stelle für den Überblick. Nutzung und Kosten lassen sich über alle Instanzen hinweg im Blick behalten, statt sich durch einzelne Tenants zu klicken.
SAP unterscheidet dabei zwei Rollen, die sich in Projekten schnell als hilfreiche Trennlinie erweisen. AI Scenario Producers bauen und trainieren die Modelle. Sie konfigurieren Pipelines und verantworten den technischen Betrieb. AI Scenario Consumers nutzen dagegen die fertigen Szenarien, über Anwendungen wie Joule oder eigene Frontends. Um Trainingsdaten oder Infrastruktur müssen sie sich nicht kümmern. Diese Trennung entlastet vor allem den Fachbereich: Niemand dort muss verstehen, wie ein Modell trainiert wird, um von seinen Ergebnissen zu profitieren.
Bild wurde mit Hilfe von KI generiert
Joule - SAPs KI-Copilot
Während AI Core und der Generative AI Hub die Maschinerie liefern, ist Joule das Gesicht, das Anwender im Alltag sehen. Als generativer Assistent sitzt Joule direkt in den Anwendungen, die Fachbereiche ohnehin täglich nutzen. Dazu zählen S/4HANA, SuccessFactors, die SAP Analytics Cloud, SAP Build und Datasphere. Genau darin liegt der Unterschied zu einem klassischen Chatbot-Add-on: Joule muss nicht erst gesucht oder separat geöffnet werden. Es taucht dort auf, wo gerade gearbeitet wird.
Fachlich zeigt sich das an drei Fähigkeiten, die in Projekten regelmäßig überzeugen. Erstens die natürlichsprachliche Interaktion: Eine Einkäuferin kann nach offenen Bestellungen fragen, ohne die passende Transaktion zu kennen. Zweitens das Kontextbewusstsein. Joule weiß, in welchem Modul und mit welchen Berechtigungen ein Anwender gerade arbeitet. Es liefert Antworten, die zu genau diesem Kontext passen, statt generischer Textbausteine. Drittens Joule Agents und Joule Assistants. Sie orchestrieren mehrere Schritte, etwa eine Anfrage prüfen, Daten aus mehreren Systemen zusammenziehen und einen Vorschlag zur Freigabe vorlegen. Das ist der Schritt, der Joule vom Frage-Antwort-Werkzeug zum Prozessbeteiligten macht.
Joule im BTP Cockpit
Im BTP Cockpit selbst ist Joule seit 2025 verfügbar. Wer den Rollout in der eigenen Landschaft plant, stößt schnell auf praktische Fragen: Welche User bekommen Zugriff? Über welchen Account läuft die Runtime? Und wie fügt sich das in bestehende Berechtigungskonzepte ein? Der Zugriff ist strikt berechtigungsgebunden. Joule zeigt und tut nur, wozu der jeweilige Anwender ohnehin autorisiert ist, ein Punkt, der in Governance-Gesprächen mit dem Fachbereich fast immer als Erstes geklärt werden muss. Die gute Nachricht für den Einstieg: Joule Base, also die grundlegenden Navigations- und Auskunftsfunktionen, ist in allen SAP-Cloud-Subscriptions ohne Zusatzkosten enthalten. Wer darüber hinaus eigene Skills oder Agenten bauen will, landet beim kostenpflichtigen Premium-Umfang. Der Grundstock aber kostet nichts extra.
Joule in SAP Build
Wer eigene Agenten bauen will, statt nur vorgefertigte zu nutzen, findet in SAP Build das passende Werkzeug. Prozesse, Formulare und Skripte lassen sich per Sprache anlegen. Dazu kommt Joule for Developers für die Code-nahe Arbeit und Joule Studio als vereinheitlichte Umgebung fürs Agenten-Bauen, mit Low-Code-Builder auf der einen und Pro-Code-Editor auf der anderen Seite. In der Praxis lohnt hier ein genauer Blick, bevor man sich für einen Weg entscheidet. Das Agent2Agent-Protokoll, über das Agenten sich gegenseitig aufrufen, funktioniert nativ derzeit nur für Agenten aus dem Code Editor. Wer im Low-Code-Builder arbeitet, kann A2A zwar ebenfalls nutzen, allerdings nur über einen Workaround, den A2A Client Service, nicht als eingebaute Funktion. Für einfache, in sich geschlossene Assistenten spielt das selten eine Rolle. Für Szenarien mit mehreren zusammenarbeitenden Agenten aber schon, und genau das sollte in die Entscheidung für Low-Code oder Pro-Code einfließen, nicht erst danach zum Problem werden.
SAP Business AI – KI im Geschäftsprozess
Bild wurde mit Hilfe von KI generiert
SAP Business AI ist kein Produkt, das man kauft, sondern eine Strategie, die man in jedem Modul wiederfindet: Joule und die dahinterliegenden Modelle sitzen dort, wo Mitarbeitende ohnehin arbeiten, statt als separates KI-Tool danebenzustehen. Diese Konsequenz zeigt sich am deutlichsten, wenn man die Bereiche nebeneinanderlegt.
Bereich | Typisches Szenario |
|---|---|
Finance | Joule unterstützt bei Belegprüfung, Abweichungsanalysen und beantwortet Fragen zu offenen Posten direkt im S/4HANA-Kontext, ohne Umweg über separate Reports. |
Procurement | In Ariba hilft Joule bei der Lieferantensuche und bei Empfehlungen, etwa wenn ein Einkäufer schnell einen Ersatzlieferanten für einen ausgefallenen Vertragspartner braucht. |
HR | SuccessFactors nutzt Joule für Job-Beschreibungen, Zusammenfassungen von Kandidaten-Feedback und für Datenabfragen in natürlicher Sprache, etwa zur Fluktuation in einer Abteilung. |
Supply Chain | In SAP Integrated Business Planning unterstützt Joule bei der Suche in Dokumentationen und bei der KI-gestützten Analyse von Supply-Optimierungsläufen. |
Analytics | In der SAP Analytics Cloud läuft die Funktion aktuell unter dem Namen „Joule, Analytical Insights“ und beantwortet Fragen zu Kennzahlen direkt im Dashboard, per „Just Ask“-Eingabe. |
Der gemeinsame Nenner dieser fünf Beispiele: Niemand muss eine neue Oberfläche lernen. Wer heute mit SAP Analytics Cloud arbeitet, tippt seine Frage einfach dort ein, wo er ohnehin die Zahlen ansieht. Für IT-Leitung und Fachbereich bedeutet das gleichzeitig, dass sich der Erfolg dieser Szenarien nicht an einer neuen Lizenz misst, sondern daran, ob die bestehenden Prozesse spürbar schneller werden.
Relevanz, Ethik und Verantwortung
Bei aller Begeisterung für generative Modelle stellt sich in jedem Projekt irgendwann dieselbe Frage: Wem gehören eigentlich die Daten, die Joule und der Generative AI Hub verarbeiten? SAP beantwortet das mit drei Leitprinzipien, die als Relevant, Reliable, Responsible durch das gesamte KI-Portfolio ziehen. Relevant heißt, dass KI dort ansetzt, wo sie einen echten Geschäftsnutzen stiftet, statt als Selbstzweck eingebaut zu werden. Reliable steht für nachvollziehbare, konsistente Ergebnisse, gerade bei Prognosemodellen wie SAP-RPT-1, die harte Zahlen liefern sollen. Responsible schließlich adressiert genau die Frage aus dem ersten Satz.
Praktisch bedeutet das: SAP durchläuft für neue KI-Funktionen einen internen KI-Ethik-Prozess, bevor sie ausgerollt werden. Für Kunden zählt aber vor allem ein Punkt aus der Vertragspraxis: Die Datenhoheit bleibt beim Kunden, und Dritt-LLMs wie GPT oder Claude werden nicht mit Kundendaten trainiert. Wer also über Azure OpenAI oder AWS Bedrock eigene Prompts durch den Generative AI Hub schickt, füttert damit kein fremdes Modell für andere Kunden. In Vertragsgesprächen mit dem Datenschutzbeauftragten ist genau das oft der Satz, der die Zustimmung bringt.
AI-Architektur auf der BTP - Überblick
Nach so vielen Einzelbausteinen lohnt sich der Zoom auf das große Bild: Wie greifen AI Core, Generative AI Hub, Joule und die übrigen Komponenten eigentlich ineinander, und wer im Projekt hat womit zu tun? Die folgende Tabelle fasst das zusammen, als Nachschlagewerk für genau die Momente, in denen jemand fragt: „Und wo im Stack sitzt das jetzt eigentlich?“
Baustein | Rolle im Gesamtbild | Wer damit arbeitet |
|---|---|---|
SAP AI Core | Kubernetes-basierte Runtime für Training, Deployment und Betrieb von Modellen, mandantenfähig | AI Scenario Producers, Data Scientists |
Generative AI Hub | Einheitliche API zu GPT, Claude, Gemini, Nova, Mistral & Co. mit Prompt-Management und Grounding, nur im Extended-Plan | Entwickler, die eigene generative Szenarien bauen |
SAP AI Launchpad | Zentrales Cockpit für Deployment, Monitoring und Kostenüberblick über mehrere AI-Core-Instanzen | IT-Betrieb, Plattform-Administratoren |
Joule | Eingebetteter Copilot in S/4HANA, SuccessFactors, SAC, SAP Build und Datasphere | Fachbereich, AI Scenario Consumers |
Joule Studio | Umgebung zum Bauen eigener Agenten, per Low-Code-Builder oder Pro-Code-Editor | Entwickler, Citizen Developer |
SAP Business AI | Strategischer Rahmen, der KI-Fähigkeiten in bestehende Geschäftsprozesse einbettet | Fachbereich, Prozessverantwortliche |
SAP Cloud SDK for AI | Bibliotheken und Werkzeuge, um KI-Funktionen aus eigenem Code heraus anzusprechen | Entwickler, Architekten |
Wer die Tabelle von oben nach unten liest, erkennt das Prinzip dahinter: Je weiter unten, desto näher am Geschäftsprozess und desto weniger technisches Vorwissen ist nötig. AI Core und der Generative AI Hub bleiben Sache der IT und der Entwicklung, Joule und SAP Business AI landen direkt beim Fachbereich. Für die Projektplanung heißt das ganz praktisch: Nicht jede Rolle im Team braucht Zugriff auf jeden Baustein, sondern genau auf den, der zu ihrer Aufgabe passt.
Einordnung aus CubeServ-Sicht
Nach sieben Teilen und unzähligen Projektgesprächen bleibt am Ende eine einfache Erkenntnis: Wer bei SAP-KI mit der komplexesten Frage anfängt, verliert wertvolle Zeit. Diese Frage lautet meist „Sollen wir ein eigenes LLM anbinden?“. Der pragmatischere Einstieg beginnt woanders.
Starten Sie mit eingebetteter KI. Joule in S/4HANA, in SuccessFactors oder in der SAP Analytics Cloud liefert schnelle, sichtbare Erfolge. Das gelingt ganz ohne eigenes ML-Team, ohne Trainingsdaten und ohne Deployment-Aufwand. Genau diese frühen Erfolge sichern in Steuerkreisen oft das Budget für die nächsten Schritte. Sie zeigen nämlich, dass KI nicht nur eine Folie im Strategiepapier ist.
Erst wenn eigene Szenarien anstehen, kommt der Generative AI Hub ins Spiel. Das kann ein individueller Assistent für einen Nischen-Prozess sein, oder eine Textgenerierung mit unternehmensspezifischem Kontext. Sein größter praktischer Wert liegt dabei selten im Modell selbst. Er liegt vielmehr darin, dass Sie GPT, Claude, Gemini oder Mistral über eine einzige Schnittstelle ansprechen. Einen eigenen Vertrag und eine eigene Integration pro Anbieter brauchen Sie so nicht mehr. Das spart nicht nur Zeit in der Beschaffung. Es hält Sie auch flexibel, falls sich in einem Jahr ein anderes Modell als besser geeignet erweist.
Bild wurde mit Hilfe von KI generiert
Datenqualität und Governance von Anfang an mitdenken
Was in vielen Projekten unterschätzt wird: Bevor überhaupt ein Modell trainiert oder ein Prompt geschrieben wird, entscheidet die Datenqualität über Erfolg oder Frust. Ein Prognosemodell wie SAP-RPT-1 ist nur so gut wie die Stammdaten, auf denen es rechnet. Wer hier nicht vorab in SAP Datasphere oder der Business Data Cloud für saubere, konsistente Datenstrukturen sorgt, bekommt am Ende schnelle Antworten. Nur sind sie dann falsch, und das ist schlimmer als gar keine Antwort.
Und ein letzter Punkt gehört von Anfang an auf den Tisch, nicht als Nachgedanke nach dem Go-Live: Governance. Welche Daten dürfen überhaupt an ein Dritt-LLM gehen? Und wer im Fachbereich prüft, ob eine generierte Antwort tatsächlich stimmt, bevor sie in eine Entscheidung einfließt? Diese beiden Fragen lassen sich nicht nachträglich anflicken. Wer sie gleich am Anfang des Projekts klärt, statt nach dem ersten Vorfall, spart sich genau die Diskussion, die sonst jedes KI-Projekt irgendwann einholt.
