11. Nov. 2025
Operationalisierung von KI-Lösungen: Monitoring, Backup & Model-Retraining

Wie wird die langfristige Qualität von KI-Lösungen sichergestellt und aufrechterhalten?

Backup und Recovery Strategien

Die Implementierung robuster Backup-Strategien wird häufig als „nice-to-have“ behandelt. Doch genau hier liegt eine kritische Fehleinschätzung vor: Während PoC und MVP mit minimalistischen Architekturen auskommen, erfordert eine produktive KI-Lösung durchdachte Backupkonzepte, um Rollbacks zur Desaster Recovery nahtlos durchführen sowie Nachvollziehbarkeit in Audit Prozessen gewährleisten zu können.

In produktiven KI-Systemen müssen drei Ebenen archiviert werden, die jeweils unterschiedliche Anforderungen mitbringen.

• Trainingsdaten: Die Datensätze, auf denen das Modell trainiert wurde, sind oft nicht trivial reproduzierbar und stellen Intellectual Property dar.
• Modelle und Parameter: Das trainierte Modell, seine Parameter, die Hyperparameter-Konfiguration und alle kundenspezifischen Anpassungen.
• Operationaler Zustand: Feature-Caches, Embeddings, Inference-Logs und alle Laufzeit-Artefakte, die für schnelle Recovery erforderlich sind.

Automatisierte Backup-Orchestrierung

Im operativen Alltag hat sich folgendes Vorgehen bewährt: Backup-Pipelines werden als dedizierte Prozesse implementiert, nicht als Nebenwirkung von Training-Pipelines. Ein kritischer Erfolgsfaktor ist die Automatisierung dieses gesamten Prozesses über CI/CD-Pipelines, da manuelle Backups nicht skalieren und vergessen werden.

Die Implementierung erfolgt durch automatisierte, Ereignis-gesteuerte Backup-Systeme. Anstatt manuelle Snapshots zu erstellen, sollten Backup-Prozesse an kritische Ereignisse gekoppelt werden: nach jedem erfolgreichen Modell-Training, nach Datenbeschaffungszyklen, oder zeitgesteuert nach festgelegten Intervallen (z.B. via Cron-Jobs).

Für die Modell-Artefakte selbst bietet sich eine Versionskontrolle von Modellen (Model Registry) an, bei der jede trainierte Version mit Metadaten wie Accuracy-Metriken, Trainingsdatum und verwendeter Datensatz-Version gespeichert wird. Tools wie MLflow oder Neptune AI ermöglichen hier eine strukturierte Verwaltung. Als Identifier bieten sich Commit-IDs oder Hashes der Modelle an. Für das Backup des operationalen Zustands können ggf. Container-Registries mit individuellen retention policies für eine bewusste Aufbewahrungsstrategie genutzt werden. Neben direkten Backups bietet sich auch das Nutzen von Infrastructure-as-Code an, um mithilfe von Tools wie Terraform/Pulumi, uv und Airflow Umgebungen und Pipelines mit geringer Komplexität reproduzierbar bzw. instanziierbar zu halten.

Für ein Cloud-basiertes Deployment einer Anwendung bei dem Daten in Multi-Region Buckets (z.B. Google Cloud Storage, AWS S3) gesichert werden, bietet sich je nach Kritikalität die 3-2-1 Regel an: 3 Kopien der Daten, auf 2 verschiedenen Medien, mit 1 Kopie off-site. Für KI-Systeme bedeutet dies konkret: Das Modell liegt im produktiven System, eine Kopie im Cold Storage der gleichen Cloud-Region, und eine dritte im Backup-System einer anderen geografischen Region.

In jedem Fall ist allerdings essenziell, dass Prüfsummen für die Backups erstellt werden, um ihre Integrität sicherzustellen. Außerdem sollten Restore Tests automatisiert durchgeführt werden, denn nur ein wiederherstellbares Backup ist ein verwendbares Backup.

Recovery Objectives

Hilfreich ist auch die Auseinandersetzung mit Recovery Time (RTO) und Recovery Point Objectives (RPO). Das RTO definiert, wie lange eine KI-Lösung maximal ausfallen darf, bis der Geschäftsbetrieb kritisch leidet. Das RPO definiert, wie viel Datenverlust (im Sinne von nicht erhobenen Daten) akzeptabel ist – gemessen in Zeit. Die anwendungsspezifisch definierten Objectives treiben direkt die Backup Infrastruktur: Während ein 5-Minuten-RTO automatisiertes Failover zu Standby-Systemen erfordert, können längere RTOs mit gestaffelten Restore-Prozessen aus der Cloud Storage auskommen.

Monitoring zur Früherkennung von Performance-Degradation

91% der Machine-Learning Modelle zeigen Performance-Degradation über die Zeit [1], d.h. die Qualität der Vorhersagen bzw. des generierten Outputs sinkt. Im Gegensatz zu einem klassischen Software-Service der, wenn er ausfällt, nicht mehr erreichbar ist, verschlechtern sich KI-Services leise und häufig unbemerkt. Strukturiertes Monitoring ist also essenziell, um Performance-Degradation frühzeitig zu erkennen und gegenzusteuern.

Gemessene Metriken können in drei Kategorien aufgeteilt werden:

• Stabilitäts-Metriken überwachen die Stabilität der zugrundeliegenden Verteilungen. Als Data Drift werden sich ändernde statistische Eigenschaften der Eingabe-Daten bezeichnet z.B. durch häufigeres Auftreten bestimmter Events (z.B. Zahlungen mit Smartphones) die in den Trainingsdaten seltener auftraten. Concept Drift ist subtiler – die Datenverteilungen sehen ähnlich aus, aber die Beziehung zwischen Input und Output hat sich verändert, zum Beispiel durch Saisonal abhängiges Kaufverhalten. Model Drift betrifft das KI-Modell selbst, z.B. im Fall von online-learning. Durch Methoden wie Population Stability Index, Sliding Window Comparisons, Kolmogorov-Smirnov oder chi-squared Tests können diese Drifts quantifiziert werden.
• Performance-Metriken sind Use-Case-spezifisch. Bei Classification-Modellen zum Beispiel sind dies häufig Accuracy, Precision, Recall und F1-Score. Wohingegen bei Regressionsproblemen Mean Absolute Error (MAE), Root Mean Squared Error (RMSE) und R² u.a. verwendet werden. Diese Metriken erfordern jedoch Ground Truth – die richtigen Labels. In vielen Produktiv-Systemen sind diese nur verzögert verfügbar oder gar nicht (z.B. bei Recommendations). In solchen Szenarien sind Proxy-Metriken wie User Engagement nötig.
• Operationale Metriken sind der dritte Pfeiler: Uptime, Latenz der Inferenz, CPU/Memory-Auslastung und API-Response-Codes. Eine Lösung mit perfekt funktionierendem Modell, das aber für den konkreten Use-Case zu langsam antwortet, ist im Zweifel unbrauchbar.

Ein geeignetes Monitoring System (z.B. AWS Model Monitor) sammelt kontinuierlich Inference-Daten (Inputs und Outputs), vergleicht sie gegen ein Baseline-Dataset (typischerweise die Test-Daten aus der Trainingsphase), und berechnet Abweichungen anhand unterschiedlicher Metriken um False Positives zu vermeiden. Diese werden automatisch geloggt und können ggf. je nach Ausprägung des Performance Drops unterschiedliche Maßnahmen auslösen: von einfachen Benachrichtigungen über dokumentierte Incidents bis hin zum automatischen Nachtrainieren der Modelle. Bei Benachrichtigungen und Dokumentation ist Kontext wichtig: neben der Accuracy Änderung sollten die auffälligsten Metriken und mögliche Auslöser, identifiziert durch Feature Importance Analysen, protokolliert werden. Ebenso wichtig ist das Tracing, die Protokollierung der internen Abläufe im KI-System mittels Sentry oder Langfuse.

Dashboards mit Trend-Grafiken (z.B. Accuracy über Zeit, Feature-Verteilungen über Zeit) sind für schnelle Diagnosen hilfreich und können in Tools wie Prometheus/Grafana oder Datadog umgesetzt werden.

[1] Vela, Daniel, et al. „Temporal quality degradation in AI models.“ Scientific reports 12.1 (2022): 11654.

Maintenance

Neben den üblichen Argumenten für Wartung von Software-Lösungen im Allgemeinen (Sicherheit, Updates von Abhängigkeiten, Weiterentwickelbarkeit, Reaktion auf geänderte Systemkontexte) ist Wartung für KI-Lösungen auch durch die oben beschriebenen Drifts essenziell.

So kann zwischen den folgenden Wartungskategorien unterschieden werden:

• Korrektive Wartung: Fehler oder Störungen werden behoben, sobald sie im laufenden Betrieb auftreten.
• Adaptive Wartung: Modelle werden an veränderte Umgebungen oder neue Geschäftsanforderungen angepasst.
• Perfektionierende Wartung: Die Systemleistung wird verbessert und neue Funktionen werden im Laufe der Zeit hinzugefügt.
• Vorbeugende Wartung: Überwachung und Stresstests werden durchgeführt, um Störungen frühzeitig zu erkennen und zu verhindern, bevor sie den Betrieb beeinträchtigen​

Im Rahmen der korrektiven Wartung von KI-Systemen sind Data-Pipelines zu nennen. Diese sind anfällig gegen sich ändernde Systemumgebungen wie Umstellung oder Aktualisierung der Quellsysteme und müssen ggf. wieder in Stand gesetzt werden.

Gerade die adaptive Wartung unterscheidet sich von klassischen Software-Systemen. So kann sich ein wesentlicher Anteil der Wartungskosten im Nachtrainieren der Modelle, finden, weswegen dies maßvoll stattfinden sollte [2]. Ein, wie im vorherigen Kapitel beschriebenes, solides Monitoring bietet demnach die Grundlage, auf der effektive adaptive Wartungs-Strategien entworfen werden können, wobei Event-basiertes, ggf. automatisiertes Nachtrainieren häufig rein intervallbasierten Ansätzen überlegen ist. Ein weiterer Aspekt ist, welche Daten für das Nachtrainieren verwendet werden. So muss entschieden werden, ob basierend auf allen jetzt verfügbaren Daten oder auf einem sliding window (z.B. den Daten der letzten 12 Monaten) von Grund auf neu trainiert oder das Modell nur mit den neu aufgetretenen Daten nachtrainiert wird. Idealerweise wird das Ausrollen der neu- bzw. nachtrainierten Modelle von A/B-Tests begleitet, um den Erfolg der ergriffenen Maßnahmen direkt quantifizieren zu können.

Zusammenfassend lässt sich sagen, dass mithilfe einer soliden MLOps Infrastruktur inklusive Monitoring und Versionierung manuelle Wartungsaufwände deutlich reduziert werden können und durch geeignete Backup-Strategien Systeme schnell wiederhergestellt werden können. Ein weiterer zentraler Bestandteil der Operationalisierung ist Security. Im dritten Beitrag schließen wir die Serie mit Security-by-Design und gesammelten Best Practices ab, um zu zeigen, wie aus PoCs bzw. MVPs nachhaltig sichere, wartbare und skalierbare KI-Produkte werden.

[2] Zanotti, Marco. „Do global forecasting models require frequent retraining?.“ arXiv preprint arXiv:2505.00356 (2025).