Unter KI-Toolchain wird die technische Kette aus Werkzeugen, Plattformen und Prozessen verstanden, mit denen Unternehmen KI-Modelle entwickeln, trainieren, testen, ausrollen, betreiben und überwachen. Die Disziplin, die diesen Lebenszyklus strukturiert, heisst MLOps für klassische Machine-Learning-Modelle und LLMOps für Large Language Models und generative KI. Beide Disziplinen übertragen DevOps-Prinzipien auf KI-Systeme: Automatisierung, Reproduzierbarkeit, Überwachung und Governance über den gesamten Lebenszyklus.
Im SAP-Kontext kommt eine besondere Dimension hinzu. SAP hat seit 2023 eine eigene KI-Produktstrategie verfolgt und eine integrierte AI Foundation aufgebaut. Joule, SAP Business AI und die SAP AI Foundation auf der Business Technology Platform (BTP) sind nicht isolierte Werkzeuge, sondern eng in die SAP-Prozesslandschaft eingebettet. Das verändert die Toolchain-Anforderungen: Es geht nicht mehr nur darum, generische ML-Pipelines zu betreiben, sondern KI-Komponenten in transaktionalen SAP-Geschäftsprozessen zu verwalten, zu überwachen und zu verantworten.
Die KI-Toolchain-Entscheidung wird 2026 durch zwei Kräfte gleichzeitig geprägt: die technische Leistungsfähigkeit der verfügbaren Werkzeuge und die regulatorischen Anforderungen, die durch den EU AI Act entstehen.
Regulatorische Anforderungen an die Toolchain. Der EU AI Act fordert für Hochrisiko-KI-Systeme unter anderem: ein Qualitätsmanagementsystem (Artikel 17), eine technische Dokumentation (Artikel 11), eine Datenverwaltung (Artikel 10), Post-Market-Monitoring (Artikel 72), automatisch generierte Log-Dateien (Artikel 12) und Transparenz (Artikel 13). Diese Anforderungen müssen in der Toolchain-Architektur verankert sein. Sie lassen sich nicht nachträglich aufsetzen, wenn die Toolchain bereits im Betrieb ist.
SAP-native Toolchain. Die SAP AI Foundation auf der BTP bietet eine integrierte Umgebung für KI-Entwicklung und -Betrieb innerhalb des SAP-Ökosystems. Vorteile: tiefe Integration in SAP-Daten und -Prozesse, Single-Vendor-Verantwortlichkeit, Konformität mit SAP-eigenen Governance-Strukturen. Nachteile: begrenzte Modellauswahl, abhängig von SAPs Entwicklungsgeschwindigkeit, potenzieller Vendor Lock-in.
Generische KI-Plattformen. Azure OpenAI Service, Amazon Bedrock, Google Vertex AI und andere bieten Zugang zu den leistungsfähigsten Modellen des Markts und maximale Flexibilität. Vorteile: Best-of-Breed-Modelle, etablierte MLOps-Werkzeuge (MLflow, Kubeflow, Vertex Pipelines), breite Community und Tooling-Unterstützung. Nachteile: Integrationsaufwand mit SAP-Daten und -Prozessen, geteilte Governance-Verantwortung, höhere Komplexität in der Compliance.
Die Realität der meisten Unternehmen wird hybrid sein: SAP-native Komponenten für integrierte SAP-Anwendungsfälle, generische Plattformen für spezialisierte Modelle und Entwicklungsexperimente.
Eine belastbare KI-Toolchain-Architektur lässt sich in sechs Schichten gliedern:
Datenschicht. Qualitätsgesicherte, dokumentierte Datensätze für Training, Validierung und Produktion. Für SAP-Kontexte: SAP Datasphere oder SAP BTP Data Services als zentrale Datenhaltung, mit Lineage-Tracking und Qualitätssicherung.
Experimentier-Layer. Werkzeuge für Modellentwicklung, Experiment-Tracking und Hyperparameter-Optimierung. Typisch: MLflow, Weights & Biases, Neptune oder äquivalente Werkzeuge. Auf SAP BTP: SAP AI Core Workspaces.
Trainings-Layer. Skalierbare Trainingsinfrastruktur, reproduzierbare Trainings-Pipelines, Versionierung von Modellen und Daten. Für produktive KI-Systeme nach EU AI Act ist die Dokumentation des Trainings – welche Daten, welche Parameter, welche Ergebnisse – eine Compliance-Anforderung, keine technische Kür.
Serving-Layer. Modell-Deployment, API-Management, Latenz-Optimierung, A/B-Testing, Canary-Releases. Für SAP: SAP AI Core für Deployment, Integration in SAP-Prozesse über SAP Integration Suite oder direkte BTP-Anbindung.
Monitoring-Layer. Überwachung von Modellleistung, Datendrift, Konzeptdrift, Fairness-Metriken und technischen Fehlern im Betrieb. Artikel 72 EU AI Act verlangt Post-Market-Monitoring für Hochrisiko-KI: systematische Erfassung von Erfahrungen aus dem Einsatz, Identifizierung und Meldung schwerwiegender Vorfälle.
Governance-Layer. Dokumentation, Audit-Trail, Zugriffskontrolle, Change Management für KI-Systeme, Compliance-Nachweise. Der Governance-Layer ist der Berührungspunkt zwischen der KI-Toolchain und dem Change Management: Jede Änderung an einem produktiven KI-System – Retrain, Modellversion, Konfigurationsparameter – durchläuft den Change-Prozess und wird dokumentiert.
Shadow AI. Mitarbeitende nutzen KI-Werkzeuge ausserhalb der offiziell genehmigten Toolchain. Das können öffentlich verfügbare Modelle (ChatGPT, Claude, Gemini) für Arbeitsaufgaben sein, die sensible Geschäftsdaten involvieren, oder spezialisierte KI-Plugins für Produktivitätswerkzeuge. Shadow AI erzeugt unkontrollierte Datenflüsse: Geschäftsdaten gelangen in externe Modelle, deren Datenschutz- und Sicherheitspraktiken nicht geprüft wurden. Es erzeugt Compliance-Risiken: KI-Ausgaben, die Geschäftsentscheidungen beeinflussen, sind nicht im KI-Inventar erfasst. Und es unterhöhlt die KI-Governance, weil die tatsächliche KI-Nutzung nicht mit der dokumentierten übereinstimmt.
Vendor Lock-in. Eine starke Abhängigkeit von einem einzigen KI-Plattformanbieter erhöht strategische Risiken: Preiserhöhungen, Service-Abkündigungen, politische und regulatorische Einschränkungen (insbesondere bei US-amerikanischen Anbietern im EU-Kontext), technologische Abhängigkeit bei Modellqualität und -verfügbarkeit. Eine durchdachte Toolchain-Architektur berücksichtigt Portabilität: Modelle sollten austauschbar sein, ohne die gesamte Pipeline zu verändern.
Datenschutz und Datenlokalisierung. SAP-Systemdaten sind häufig kritische Geschäftsdaten: Finanzdaten, Personaldaten, Kundendaten, Produktionsdaten. Die Nutzung externer KI-APIs erzeugt Datenübertragungen in Drittländer, die Datenschutzrecht und gegebenenfalls Exportbeschränkungen unterliegen. Der Einsatz von SAP BTP innerhalb der EU-Rechenzentrumsregionen reduziert dieses Risiko für SAP-native Workloads.
KI-Inventar als Ausgangspunkt. Vor dem Aufbau einer KI-Toolchain – oder bei der Revision einer bestehenden – steht die Inventarisierung der tatsächlich genutzten KI-Systeme, auch der informellen und abteilungsspezifischen. Das Inventar zeigt, welche Toolchain-Anforderungen real sind und wo Shadow AI besteht. Es ist auch die Grundlage für die Klassifizierung nach EU AI Act: Ohne zu wissen, welche KI-Systeme existieren, kann keine Konformitätsbewertung stattfinden.
Governance by Design. Die wichtigste Architectural Decision: Governance-Anforderungen werden in der Toolchain-Architektur von Anfang an berücksichtigt, nicht nachträglich hinzugefügt. Das bedeutet konkret: Log-Persistenz nach Artikel 12 EU AI Act wird als Anforderung an den Serving-Layer definiert, bevor das erste Modell deployed wird. Post-Market-Monitoring nach Artikel 72 wird als Anforderung an den Monitoring-Layer definiert, bevor das erste Modell in Produktion geht. Change Management für KI-Systeme wird in den Governance-Layer eingebaut, bevor das erste Re-Training stattfindet.
Modulare Architektur und klare Schnittstellen. Eine modulare Toolchain, in der jeder Layer über definierte Schnittstellen kommuniziert, erleichtert die Austauschbarkeit einzelner Komponenten. Das reduziert Vendor Lock-in und vereinfacht die Anpassung an neue regulatorische Anforderungen, neue Modellgenerationen und neue Anwendungsfälle.
KI-Toolchain-Architektur und EU-AI-Act-Compliance müssen zusammen geplant werden. Shadow AI, Vendor Lock-in und fehlende Governance-Integration sind die drei operativen Hauptrisiken. KI-Inventar als Ausgangspunkt, Governance by Design als Prinzip.