MLOps-Reife: Wie Organisationen den KI-Betrieb systematisch aufbauen
Nicht jede Organisation braucht dieselbe MLOps-Infrastruktur. Was eine Organisation braucht, hängt davon ab wie viele Modelle sie betreibt — und was schiefgehen darf.
Die drei Reifegrade, die Maturity-Falle, und warum SDLC-Prozesse für ML nicht funktionieren.
Drei Reifegrade — und was sie wirklich bedeuten
MLOps-Reife folgt einer klaren Progression. Was eine Organisation braucht, ist eine Funktion der Anzahl ihrer Produktions-Modelle — nicht ihrer Größe oder ihres Budgets.
1–3 Modelle
- Data Scientists können selbst deployen
- Manuelle Prozesse reichen
- Monitoring per Augenschein
- Reproduzierbarkeit nice-to-have
- Kein dediziertes ML Engineering nötig
5–20 Modelle
- ML Engineering wird unverzichtbar
- Pipelines brauchen Automatisierung
- Monitoring muss strukturiert sein
- Feature-Management entsteht als Thema
- Ein Deployment-Prozess, nicht fünf verschiedene
20+ Modelle
- Dedizierte MLOps-Engineers, Platform-Team
- Standardisierte Toolchain
- CI/CD für Modelle
- Automatisches Retraining auf Drift-Signal
- Compliance-Dokumentation für relevante Use Cases
„Die Frage ist nicht welche MLOps-Infrastruktur ihr bauen wollt. Die Frage ist bei wie vielen Modellen ihr gerade seid — und bei wie vielen ihr in zwei Jahren sein werdet."
Was das für euch bedeutet
Mit drei Modellen eine MLOps-Platform für zwanzig zu bauen ist Overengineering. Mit zwanzig Modellen noch manuell zu deployen ist ein Betriebsrisiko.
Batch → Streaming → Real-Time: Die Architektur-Reifeleiter
ML-Systeme entwickeln sich durch drei Architektur-Stufen — und jede Stufe schaltet neue Use Cases frei, aber bringt neue Engineering-Komplexität mit.
Batch (Stufe 1)
Features täglich oder stündlich berechnet und gespeichert. Predictions laufen offline.
Sinnvoll für: Lead Scoring, Churn Prediction, Empfehlungs-Baselines. Einstiegspunkt für fast alle Organisationen.
Streaming (Stufe 2)
Features aus Echtzeit-Events (Kafka, Kinesis). Features sind frisch, nicht stale. Komplexere Datenverarbeitung nötig.
Sinnvoll für: Near-real-time Fraud Detection, Preisoptimierung, Session-basierte Recommendations.
Real-Time (Stufe 3)
Features direkt aus dem Request-Payload beim Inferenz-Zeitpunkt. Die wertvollsten Features sind oft die direkt mitgesendeten Kontext-Daten.
Sinnvoll für: Suchoptimierung, Personalisierung, Echtzeit-Scoring.
Die Faustregeln
Batch zuerst — viele Use Cases funktionieren gut mit täglichen Refreshes.
Vor dem Sprung zu Streaming: Simulieren ob freshere Features überhaupt besser performen.
Stufen nicht überspringen — jede Stufe hat eigene Daten-Engineering-Herausforderungen.
Was das für euch bedeutet
Der ROI von Streaming-Infrastruktur ist nachweisbar — nicht angenommen. Investiert in Streaming wenn die Simulation zeigt, dass frischere Features den Unterschied machen. Nicht früher.
Team-Komposition: Wer bei wie vielen Modellen nötig ist
MLOps-Teams wachsen nicht linear mit der Organisations-Größe — sie wachsen mit der Anzahl der Produktions-Modelle.
Data Scientist (ab Modell 1)
Entwickelt Features, trainiert Modelle, evaluiert Qualität. Kann bei wenigen Modellen auch deployen. Wird bei mehr Modellen zum Flaschenhals wenn er auch Infrastruktur betreibt.
ML Engineer (ab ~5 Modellen)
Baut und betreibt die Pipelines die Modelle produktionstauglich machen. Feature-Engineering in Produktionsqualität, Deployment-Automatisierung, Infrastruktur-Integration. Das ist der fehlende Baustein in den meisten frühen ML-Teams.
MLOps Engineer (ab ~20 Modellen)
Betreibt die ML-Plattform für andere Teams. CI/CD für Modelle, automatisches Monitoring, Toolchain-Standardisierung. Ist für ML-Systeme was der SRE für klassische Infrastruktur ist.
Domain Expert + UX (mit LLMs)
Generative KI-Systeme brauchen Fachleute die beurteilen ob Outputs stimmen — und UX-Expertise die versteht was Nutzer wirklich brauchen. Nicht optional wenn die Anwendung komplex ist.
Was das für euch bedeutet
Der häufigste Team-Aufbau-Fehler: zu viele Data Scientists, zu wenige ML Engineers. Data Scientists können Modelle bauen. Modelle in Produktion bringen und betreiben braucht ML Engineering.
SDLC → MLDLC: Warum Software-Prozesse für ML nicht funktionieren
In der Software-Entwicklung ist der Lifecycle klar: Code schreiben, testen, in die Ops-Pipeline, in Produktion. Für Machine Learning funktioniert das nicht — weil ML-Artefakte keine Code-Artefakte sind.
SDLC
- Deterministisch, testbar, reproduzierbar
- Ein bestandener Test garantiert Funktion
- Deployment ist ein Event
MLDLC
- Probabilistisch, datenabhängig, driftanfällig
- Ein bestandener Test garantiert keine Production-Qualität
- Deployment ist ein Prozess-Anfang
Was daraus folgt
- Jeder Use Case braucht angepassten Lifecycle
- Mit Daten-Validierung und Bias-Check
- Staged Rollout und klaren Retraining-Trigger
„Man kann SDLC-Prozesse nicht auf ML kopieren. Man kann sie auch nicht ignorieren. Man muss sie anpassen — Use Case für Use Case."
Der EU AI Act macht MLDLC für Hochrisiko-Systeme zur Pflicht. Für HR-Tools, Kredit-Scoring, und andere Hochrisiko-Anwendungen braucht es dokumentierte Qualitätsprozesse, menschliche Aufsicht, und Audit-Logs.
Was das für euch bedeutet
„Wir deployen wie Software" ist keine MLOps-Strategie. Es ist ein Risiko-Statement.