Architektur, Betrieb und Einsatz von KI in SAP BTP

Die KI-Schichten in SAP BTP

Dieses Schichtmodell prägt auch die Nutzerrollen. KI-Entwickler bauen Modelle, Pipelines und Laufzeitartefakte auf. KI-Manager koordinieren Anforderungen, Rechenressourcen, Governance und den Weg in den Produktivbetrieb. Fachbereiche greifen erst auf das Ergebnis zu, also auf eingebettete Dienste, Assistenten oder prozessnahe Automatisierung.

AI Core und AI Launchpad richten sich damit nicht an Endanwender, sondern an Teams, die Modelle trainieren, bereitstellen und überwachen. Diese Trennung ist für Architekturentscheidungen relevant, da Bedienoberfläche, Governance und Betriebsmodell auf verschiedene Gruppen zielen.

Die Plattform selbst dient dabei nicht nur als technischer Unterbau für SAP-Anwendungen. Sie übernimmt zugleich die Rolle eines Integrationspunkts für externe Datenquellen, Drittmodelle und Nicht-SAP-Prozesse. Gerade an dieser Stelle liegt ein grundlegender Unterschied zu älteren Erweiterungsmodellen im ERP-Kern.

KI bleibt nicht im Modul verankert, sondern sitzt in einer seitlich angekoppelten Plattformarchitektur und greift über APIs, Events und Integrationsdienste auf Prozessdaten zu. Aus diesem Grund spielt die Business Technology Platform auch dann eine Rolle, wenn das Kern-ERP-System noch lokal läuft. Entscheidend ist die Cloud-Plattform, nicht der Standort des Kernsystems.

AI Foundation und der technische Maschinenraum

Die Basis für KI auf der BTP ist AI Foundation. Dazu zählen AI Core, AI Launchpad und der Generative AI Hub (Hub für generative KI). AI Core stellt die Laufzeit für Training, Inferenz und Modellbetrieb bereit. Containerisierte Artefakte aus Git-Repositories, Docker-Images oder Object Stores lassen sich dort einbinden. Die Laufzeit verwaltet Versionen, Trainingsläufe, Deployments und Zugriffspfade. Damit rückt KI auf eine betriebliche Ebene, in der Modellartefakte als isolierte Notebook-Ergebnisse vorliegen und als produktive Dienste mit definierter Ausführung, Persistenz und Rückverfolgbarkeit.

AI Launchpad bildet die Verwaltungsoberfläche für diese Laufzeit. Dort liegen Übersichten zu Szenarien, Deployments, Ausführungen, Datensätzen, Modellen und Zeitplanung. Teams sehen, welche Modelle aktiv sind, welche Trainingsläufe fehlschlagen, welche Version produktiv läuft und an welcher Stelle Retraining ansteht. Für KI-Projekte im Unternehmenskontext ist genau dieser Teil ausschlaggebend, da hier der Übergang vom Notebook in den stabilen Betrieb an fehlender Orchestrierung, unklarer Versionierung oder unzureichendem Monitoring scheitert. Die Plattform führt diese Betriebsaufgaben in einer Oberfläche zusammen.

Aus technischer Sicht arbeitet AI Core eng mit standardisierten Data-Science-Werkzeugen zusammen. Container, Python-Umgebungen, API-Endpunkte und externe Repositories lassen sich anbinden, ohne ein proprietäres Sondermodell zu erzwingen. Daraus folgt ein wichtiger Punkt für Teams mit datenwissenschaftlichem Hintergrund. Die BTP verlangt kein vollständiges Umlernen auf SAP-eigene Werkzeuge. Sie integriert aber verbreitete Entwicklungsmuster in einen SAP-nahen Betriebsrahmen. Genau diese Öffnung senkt die Hürde für Data Scientists, die mit Docker, Git, APIs und Jupyter arbeiten und ihre Modelle in eine SAP geprägte Landschaft überführen müssen.

Der Generative AI Hub ergänzt diese Basis um den Zugriff auf Sprachmodelle und generative Dienste. Dort liegen Prompt-Editor, Modellzugriff, Variantenvergleich und die Einbindung eigener Kontextdaten. Der praktische Wert liegt im zentralen Zugriff auf mehrere Modellanbieter über einen gemeinsamen Kontrollpunkt. Unternehmen koppeln damit nicht jedes Modell einzeln an die eigene Landschaft an. Sie nutzen eine von SAP verwaltete Integrationsschicht. Das senkt den Integrationsaufwand und stützt Governance, Zugriffskontrolle und Datenschutz. Für viele Unternehmen ist das der eigentliche Grund, generative KI im BTP-Kontext zu verankern.

Daten, Prozesse und Erweiterungsmodelle

KI auf der BTP ist dann sinnvoll in operative Prozesse einsetzbar, wenn Datenzugriff, Geschäftssemantik und Erweiterungsmodell zusammenpassen. Hier greift das Keep-the-Core-Clean-Konzept. Weniger tiefgreifende Anpassungen verbleiben im Kernsystem. Komplexere Erweiterungen wandern als Side-by-Side-Szenarien auf die BTP. Die eigentliche Verschiebung liegt damit im Entwicklungsmodell. Monolithische Erweiterungen im ERP verlieren an Bedeutung, API-Dienste und gekapselte Erweiterungen gewinnen an Gewicht.

Für ABAP-geprägte Landschaften spielen dabei das ABAP RESTful Application Programming Model (RAP) und die BTP ABAP Environment eine zentrale Rolle. RAP strukturiert Geschäftsobjekte über CDS-Views, Verhaltensdefinitionen und OData-Services. Ein Geschäftsobjekt bildet fachliche Entitäten, Relationen, Sperrlogik, Validierung und CRUD-Operationen in einem release-festen Modell ab. Wer bestehende ABAP-Anwendungen in Richtung BTP überführt, analysiert darum zunächst das Datenmodell, ordnet fachliche Entitäten neu und baut daraus ein API-fähiges Objektmodell. Der Schritt von der klassischen WRICEF/RICEFW-Logik in Richtung RAP ist keine reine Codeportierung. Es geht um Re-Engineering von Datenmodell, Verhalten, Serviceexposition und Bedienoberfläche.

Für CAP und Cloud Foundry gilt ein ähnlicher Grundgedanke. Dienste laufen gekapselt, kommunizieren über APIs und lassen sich mit SAP und Nicht-SAP-Systemen koppeln. In beiden Fällen verlagert sich komplexe Entwicklung aus dem ERP-Kern in eine getrennte Laufzeitumgebung. Das vereinfacht spätere Upgrades im Kernsystem und schiebt Innovation in eine Ebene, die schneller angepasst werden kann. Genau aus diesem Grund lässt sich KI auf der BTP nicht losgelöst vom Erweiterungsmodell betrachten. Ohne API-fähige Dienste, harmonisierte Daten und ein klares Zielbild für Side-by-Side-Entwicklungen bleibt KI ein Zusatzwerkzeug ohne tiefen Prozesseingriff.

Hinzu kommt die Datenfrage. Für Vorhersagen, Klassifikation oder generative Auswertung reichen einzelne Tabellen nicht aus. Benötigt wird eine zusammengeführte Datenbasis aus SAP und Nicht-SAP-Quellen. Hier greifen Datenkomponenten wie Datasphere, Business Data Cloud oder HANA Cloud. HANA Cloud bringt dazu Vektorverarbeitung und embedding-nahe Verarbeitung in den Datenbankkontext. Daraus ergibt sich ein enger technischer Zusammenhang. Je näher Semantik, Transaktionsdaten und Vektorsuche zusammenliegen, desto direkter lassen sich kontextbezogene Antworten, Suchvorgänge oder Retrieval-Szenarien in Fachprozesse einbinden.

Dokumente, Finance und operative Prozessketten

Ein gut greifbarer Einstieg in KI auf der BTP liegt in der Dokumentverarbeitung. Der Dienst zur Informationsextraktion liest Rechnungen, Belege und ähnliche Dokumente aus, extrahiert Felder und führt das Ergebnis in Folgeprozesse zurück. Der Mehrwert liegt nicht nur in optischer Zeichenerkennung (OCR), sondern in der fortlaufenden Verbesserung über Korrekturen und Wiederholung ähnlicher Dokumenttypen. Bei eingehenden Rechnungen mit wiederkehrenden Lieferanten sinkt dadurch der manuelle Aufwand im Erfassungsprozess. Zugleich bleibt die Anbindung an den Buchungsprozess erhalten, da die extrahierten Daten über Workflows, APIs oder ERP-Integrationen weiterlaufen.

Gerade im Finanzbereich schiebt SAP das Thema weit in den Abschlussprozess hinein. KI arbeitet dort in Buchhaltung, Abstimmung, Abschlusskalender, Risikoanalyse und Berichtswesen. In Abschlussprozessen rückt die Kombination aus Echtzeitstatus, Eskalationen, Vorlagen, Anomalieerkennung und systemübergreifender Orchestrierung in den Vordergrund. KI greift dort ein, wo viele Wiederholungen, klare Regelwerke und große Datenmengen zusammentreffen.

Ein weiterer Schwerpunkt liegt in Prognosen und Risikobewertung. KI wertet Zahlungsströme, Transaktionshistorien und Bewegungsmuster aus und liefert Hinweise auf Abweichungen, Betrugsmuster oder Kreditrisiken. Im Unterschied zu losgelösten Analysewerkzeugen erfolgt die Einbettung hier direkt im Prozesskontext von ERP, Reporting und Freigaben.

Joule, eingebettete KI und Agenten

Joule bildet die sichtbare Schicht dieser Architektur. Der Assistent arbeitet kontextbezogen auf Geschäftsdaten, ruft Informationen aus Anwendungsdaten, Hilfssystemen oder internen Dokumenten ab und kann Transaktionsschritte anstoßen. Joule dient als Einstieg in Navigation, Datenauswertung, Zusammenfassung und Prozessauslösung. Das führt zu einer neuen Bedienlogik, in der Menüs und Transaktionen nicht verschwinden, ihre Dominanz aber verlieren.

Hinzu kommen eingebettete KI-Dienste in Cloud-Anwendungen. SAP ordnet dem Portfolio bereits mehr als hundert operative Szenarien zu und baut den Katalog weiter aus. In Fachanwendungen laufen diese Dienste häufig im Hintergrund und liefern Textvorschläge, Klassifikation, Forecasts oder Zusammenfassungen. Für den Betrieb relevant ist das zugehörige Lizenzmodell. Ein Teil der Basisszenarien liegt in Cloud-Paketen oder in der Joule-Base-Variante, weitergehende Szenarien samt Studio, Agenten und komplexerer Orchestrierung liegen in Premium-Varianten oder verbrauchsgebundenen AI Units. Damit koppelt SAP Kosten an Modellnutzung, Prompt-Komplexität und Agentenaktivität. Für Architektur und Governance folgt daraus eine Pflicht zur Verbrauchssteuerung.

Die nächste Ausbaustufe liegt in Agentensystemen. Dort verarbeitet KI Eingaben und plant mehrstufige Abläufe, ruft Werkzeuge auf, holt Daten ein und stößt Folgeaktionen an. Im SAP-Kontext verschmilzt dieser Ansatz mit Prozessautomatisierung, Integration und fachlicher Orchestrierung. Agenten stützen Ersteller, Prüfer und Genehmiger im Abschlussprozess, unterstützen Beratungswissen, analysieren Code oder begleiten Transformationsprojekte. Technisch setzt das eine Plattform voraus, in der Daten, Zugriffsrechte, Prozesslogik und Modellorchestrierung bereits zusammenspielen.

Prozessautomatisierung, Integration und der Weg in den Betrieb

SAP Build Process Automation zeigt, wie eng KI und Prozesssteuerung inzwischen zusammenliegen. Formulare, Regeln, Genehmigungen, Benachrichtigungen und API-Aufrufe lassen sich grafisch modellieren. Generative KI unterstützt dabei schon beim Aufbau der Formulare, bei Datentypen, Regeln und Script-Aufgaben. Im operativen Ablauf ist die Modellierung allein jedoch nicht der kritische Punkt. Entscheidend ist der Datenfluss zwischen Formular, Workflow, Schnittstelle und Zielsystem. Viele Projekte scheitern an der Frage, wie Daten aus System A in den Prozess gelangen und nach dem Entscheidungsweg wieder in System A oder ein anderes Zielsystem zurückgehen.

Für genau diesen Punkt bindet die Plattform Integration Suite, API Hub und Business Accelerator Hub ein. Teams greifen dort auf vordefinierte APIs für Public Cloud, On-Premises-Systeme und Nicht-SAP-Landschaften zu. Gekoppelt mit Eventing und hybrider Integration ergibt das eine tragfähige Grundlage für End-to-End-Szenarien. E-Rechnung, Rechnungsfreigabe, Bestellprozesse, Transportlogistik oder Self-Service-Prozesse im HR-Umfeld greifen genau auf diesen Stack zurück. Der fachliche Wert liegt in der Verbindung aus Prozessschritt, Datenaustausch und Rückmeldung ins operative System.

Der Betrieb verlangt zusätzlich eine durchdachte Konten- und Landschaftsstruktur auf der BTP. Global Account, Subaccounts, Entwicklungs-, Test- und Produktivumgebungen, IAM, Cloud Connector, Monitoring-Service und Health-Monitoring gehören früh in die Planung. Dasselbe gilt für Shared Responsibility, Sizing, Preismodell und CI/CD. KI als Dienst auf der BTP ist damit Teil einer Cloud-Betriebsarchitektur mit Transporten, Versionen, Rollen, Überwachung und technischen Leitplanken.

Einordnung der Möglichkeiten

KI auf der SAP BTP ist weder auf Assistenten noch auf einzelne Modelle reduzierbar. Das Thema greift tiefer. Es verbindet Datenharmonisierung, API-basierte Erweiterung, Laufzeit für Modelle, Prozessautomatisierung, generative Dienste und fachliche Orchestrierung in einer gemeinsamen Plattformlogik. Daraus folgt auch die nüchterne Einordnung. Der technische Unterbau ist vorhanden, die Breite der einsetzbaren Szenarien ist groß, die Umsetzung hängt jedoch an Datenqualität, Architekturdisziplin, sauberer Integrationsarbeit und einem realistischen Betriebsmodell.

Für Unternehmen mit SAP-Schwerpunkt liegt der sachliche Kern daher nicht in der Frage, ob KI auf der BTP grundsätzlich läuft. Die wichtigere Frage betrifft den Einstiegspunkt. Kleine, gut abgegrenzte Use Cases in Dokumentverarbeitung, Rechnungsfreigabe, Abschlusssteuerung oder Forecasting tragen oft weiter als große Visionen ohne Datenbasis. Wer den Kern sauber hält, APIs sauber begrenzt, die BTP als Betriebsplattform ernst nimmt und Fachprozesse als Ausgangspunkt wählt, trägt KI von der Demo in den Produktivkontext. Genau an dieser Stelle liegt der Unterschied zwischen einem Zusatzwerkzeug und einem belastbaren Service auf Plattformebene.