Die MLOps-Toolchain-Landschaft wurde für Unternehmen mit 50-köpfigen ML-Teams und Tausenden von Modellen in Produktion gebaut. Ein 200-Personen-Industrieunternehmen, das seine ersten drei KI-Workflows ausrollt, braucht weder Kubeflow noch einen Feature Store, weder einen Experiment Tracker mit GPU-Cluster-Orchestrierung noch eine dedizierte Drift-Detection-Plattform — und erst recht kein eigenes ML-Platform-Team.
Was es braucht, ist etwas anderes: einen Stack, der schlank genug bleibt, um nicht selbst zur Baustelle zu werden, und gleichzeitig sauber genug dokumentiert, um zu bestehen, wenn jemand fragt, welches Modell am 14. März eine bestimmte Entscheidung getroffen hat. Diese zweite Anforderung ist seit 2026 keine Kür mehr. Der größte Fehler im Mittelstand ist nicht, zu wenig zu kaufen — es ist, das Falsche zu kaufen, weil ein Anbieter-Reifegradmodell suggeriert, man hänge hinterher.
MLOps-Anforderungen skalieren mit dem Reifegrad — nicht mit dem Verkaufsgespräch
Die meisten DACH-Mittelständler fallen in Stufe 1 oder Stufe 2. Fast keiner braucht Stufe 3. Wer das einmal sauber einordnet, spart sich die teuersten Fehlinvestitionen.
Stufe 1: API-first — kein klassisches MLOps erforderlich. Sie nutzen KI über APIs von OpenAI, Anthropic, Azure AI oder einem vergleichbaren Anbieter. Ihr „Deployment" besteht aus einem API-Schlüssel und einer Integrationsschicht. Was Sie tatsächlich brauchen, lässt sich an einer Hand abzählen: Prompt-Versionierung (Git genügt), Kostenmonitoring (das Dashboard des Anbieters plus eine monatliche Durchsicht), stichprobenbasierte Output-Qualitätskontrolle durch Menschen und eine belastbare Fehlerbehandlung, wenn die API ausfällt oder halluziniert. Das ist keine abgespeckte Version von MLOps, sondern der korrekte operative Ansatz für ein bis fünf KI-gestützte Workflows über verwaltete APIs. Eine MLOps-Plattform in dieser Phase aufzubauen, erzeugt Kosten und Komplexität, ohne einen einzigen Wert hinzuzufügen.
Stufe 2: Managed Inference — leichtes MLOps. Sie betreiben fein abgestimmte oder Open-Source-Modelle auf verwalteter Infrastruktur — Azure ML, AWS SageMaker oder einem dedizierten Inference-Provider. Jetzt brauchen Sie echte Modell-Versionierung (welche Version ist in Produktion, was hat sich gegenüber der letzten geändert), grundlegendes Monitoring von Latenz, Fehlerraten und Output-Qualität, eine Deployment-Automatisierung, die eine neue Modellversion ohne manuellen Eingriff ausrollt, und vor allem einen getesteten Rollback-Mechanismus. MLflow, die am breitesten eingesetzte Open-Source-Plattform für diesen Zweck, deckt Modell-Versionierung, Stage-Übergänge (Staging, Production, Archived) und Lineage-Tracking ab; die Model Registry verknüpft jede Modellversion mit dem zugehörigen Lauf, dem Code und den Auswertungsergebnissen. Mit MLflow 3 reicht dieselbe Registry inzwischen bis in die GenAI-Welt hinein — sie versioniert auch Prompts und verbindet Modelle mit Evaluation-Runs und Deployment-Metadaten. Kombiniert mit den Deployment-Werkzeugen Ihres Cloud-Providers deckt das den Großteil der Stufe-2-Anforderungen ab, ohne dass eine kommerzielle Plattformlizenz nötig wird.
Stufe 3: Vollständig selbst gehostet — echtes MLOps. Sie betreiben eigene GPU-Infrastruktur, fahren Trainingspipelines, verwalten parallel mehrere Modellversionen und verantworten den gesamten Lebenszyklus von der Datenaufbereitung bis zum Produktions-Serving. Hier kommt alles aus Stufe 2 hinzu, plus Pipeline-Orchestrierung, Feature-Management, automatisierte Drift-Erkennung und Ressourcensteuerung über teure GPU-Kontingente. Diese Stufe erfordert mindestens zwei dedizierte ML Engineers und bindet schnell einen sechsstelligen Eurobetrag pro Jahr allein an Personal und Infrastruktur — bevor das erste Modell produktiven Wert liefert. Sie ist gerechtfertigt, wenn Sie viele Modelle parallel in Produktion halten, sehr hohe Inferenzvolumina fahren oder regulatorische Gründe haben, Modelle nachweislich on premise zu trainieren. Für den typischen Mittelständler mit drei bis fünf KI-Workflows ist sie es nicht.
Die Vendor-Komplexitätsfalle
Die MLOps-Anbieterlandschaft bietet leistungsfähige Plattformen — Databricks Mosaic AI, AWS SageMaker, Azure Machine Learning, Weights & Biases, Comet. Diese Werkzeuge sind hervorragend für Organisationen, die sie brauchen. Die Falle besteht darin, Stufe-3-Tooling für Stufe-1-Probleme einzukaufen, weil ein Vertriebsdeck den eigenen Reifegrad als rückständig darstellt.
Ein Hersteller, der eingehende Qualitätsberichte klassifizieren lässt, braucht keinen Feature Store. Ein Finanzdienstleister, der einen API-basierten Assistenten für Compliance-Anfragen betreibt, braucht keine Trainingspipeline. Ein Logistikunternehmen, das Kundenanfragen über ein verwaltetes LLM routet, braucht keine A/B-Testing-Infrastruktur für Modellexperimente. Die entscheidenden Auswahlkriterien für den Mittelstand sind Integrationsaufwand, ein Pricing, das mit der Nutzung mitwächst statt vorab eine Plattform zu finanzieren, und die Zeit bis zum ersten messbaren Ergebnis — nicht Feature-Vollständigkeit. Die Plattform, die fünf Dinge kann, die Sie tatsächlich nutzen, schlägt die Plattform, die fünfzig Dinge kann, von denen Sie fünf jemals anfassen.
Der eine Bereich, in dem auch Stufe 1 nachrüsten muss: Auditierbarkeit
Hier liegt die Nuance, die viele Reifegradmodelle übersehen. Schlank zu bleiben heißt nicht, ohne Nachweis zu arbeiten. Seit dem 2. August 2026 gelten die zentralen Pflichten des EU AI Act (Verordnung 2024/1689) für Hochrisiko-KI-Systeme in vollem Umfang. Ob ein System darunterfällt, hängt vom Einsatzzweck ab — Bonitäts- und Kreditentscheidungen, Personalauswahl und bestimmte Anwendungen in kritischer Infrastruktur zählen ausdrücklich dazu, und genau das sind Felder, in denen mittelständische Industrie-, Finanz- und Personaldienstleister bereits KI einsetzen.
Für solche Systeme verlangt Artikel 12 die automatische Aufzeichnung von Ereignissen (Logs) über die gesamte Lebensdauer hinweg. „Automatisch" ist dabei wörtlich gemeint: Eine nachträglich gepflegte Dokumentation erfüllt die Pflicht nicht — das System selbst muss protokollieren, und zwar von der Inbetriebnahme bis zur Stilllegung, nicht nur in der aktuellen Version. Betreiber müssen diese Logs mindestens sechs Monate aufbewahren, sofern keine anderen Fristen greifen. Verstöße gegen die Pflichten für Hochrisiko-Systeme können mit Bußgeldern von bis zu 15 Millionen Euro oder 3 Prozent des weltweiten Jahresumsatzes geahndet werden — je nachdem, welcher Betrag höher ist.
Die praktische Konsequenz ist unbequem, aber befreiend: Wer einen Hochrisiko-Use-Case über eine reine API-Integration fährt, kann sich die schwere Plattform weiterhin sparen — muss aber sicherstellen, dass jeder Inferenz-Aufruf mit Zeitstempel, Modellversion, Eingabe-Referenz und Ergebnis revisionssicher und unveränderbar abgelegt wird. Das ist kein Feature-Store-Problem. Das ist ein Logging- und Aufbewahrungsproblem, das Sie mit Ihrem bestehenden Observability- und Storage-Stack lösen — vorausgesetzt, Sie haben es von Anfang an als Anforderung mitgedacht und nicht als spätere Pflichtübung.
Der praktische Startpunkt
Für ein Mittelstandsunternehmen am Anfang seiner KI-Reise sieht der minimale, aber tragfähige operative Stack so aus. Die Versionskontrolle läuft über Git für Prompts, Konfigurationen und Deployment-Skripte — das existiert in jedem Engineering-Team bereits. Das Monitoring stützt sich auf Ihren vorhandenen Observability-Stack, ob Datadog, Grafana oder vergleichbar, erweitert um KI-spezifische Metriken: Latenz, Fehlerrate, Token-Verbrauch und Kosten pro Aufgabe. Eine neue Plattform ist dafür nicht nötig.
Die Kostenverfolgung beginnt als monatliche Gegenüberstellung der API-Ausgaben und des gelieferten Geschäftswerts; eine Tabellenkalkulation genügt, bis die Ausgaben spürbar in den fünfstelligen Bereich pro Monat wandern. Die Qualitätsstichprobe besteht aus einer menschlichen Prüfung von 50 bis 100 zufällig gezogenen Outputs pro Woche — das erkennt eine schleichende Qualitätsverschlechterung oft schneller als ein automatisiertes System und kostet weniger als jede Monitoring-Lizenz. Und parallel dazu, von Tag eins an, läuft das revisionssichere Audit-Log für jeden Use-Case, der unter den AI Act fallen könnte: vollständig, unveränderbar, mindestens sechs Monate vorgehalten.
Führen Sie darüber hinausgehendes Tooling erst dann ein, wenn ein konkretes operatives Problem es erzwingt — ein realer Engpass, eine reale Regulierungspflicht, ein realer Skalierungsdruck. Nicht, weil ein Anbieter-Reifegradmodell die nächste Stufe nahelegt.
Ein Fit Call bestimmt in 30 Minuten die richtige MLOps-Stufe für Ihre KI-Operationen — und zeigt, wo Sie schlank bleiben dürfen und wo der AI Act ab August 2026 echte Auditierbarkeit verlangt, bevor ein Plattformkauf Budget bindet, das Sie nicht ausgeben müssen.
Referenzen: Europäische Union, Verordnung (EU) 2024/1689 (EU AI Act), Artikel 12 „Record-Keeping" (artificialintelligenceact.eu/article/12); Europäische Kommission, „Regulatory framework on AI" (digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai); MLflow, „Model Registry" und „MLflow 3" (mlflow.org).