Ein funktionsfähiges MLOps-Team braucht fünf Kernrollen: Data Engineer, ML Engineer, Platform/MLOps Engineer, Product/Domain Owner und eine Governance-Funktion. Entscheidend sind drei Prinzipien: eindeutige Ownership pro Repository und Modellstufe, automatisierte Trainings- und Deployment-Pipelines statt manueller Übergaben, und messbare Metriken, die Plattformnutzung genauso erfassen wie Fehlerraten. Bei Hochrisiko-Anwendungen kommt eine vierte Pflicht hinzu: dokumentierte menschliche Aufsicht nach EU AI Act.
Kurz gesagt:
- Ein MLOps-Team sollte klare Ownership-Strukturen im Code und bei Modellstufen haben, um Verantwortlichkeiten eindeutig zu sichern.
- Das Team wächst idealerweise im Verhältnis von ein Plattform- zu vier bis sechs modellbauenden Personen, bei föderaler Organisation mit zentralen Guardrails.
- Automatisierte Übergabeprozesse mit Versionierung, Model-Registry und SLAs sind essenziell, um Verantwortlichkeiten bei Modellerstellung und -freigabe zu klären.
- Für Hochrisiko-Anwendungen ist eine dokumentierte menschliche Aufsicht nach EU AI Act Pflicht, inklusive eines Vier-Augen-Prinzips bei Freigaben.
- Neben der Tool-Auswahl ist organisatorisches Design, insbesondere klare Rollenverteilung und Ownership, der entscheidende Faktor für den Erfolg eines MLOps-Teams.
Inhaltsverzeichnis
- Wie strukturiert man ein MLOps-Team richtig?
- Welche Übergabeprozesse sichern die Zusammenarbeit?
- Welche Tools und Infrastruktur braucht ein MLOps-Team?
- Welche Metriken zeigen, ob ein MLOps-Team funktioniert?
- Was verlangt der EU AI Act von MLOps-Teams?
- Warum Besetzung über Erfolg oder Scheitern entscheidet
- Warum Rollenklarheit wichtiger ist als jedes Tool
- Wie Polydigital beim Teamaufbau konkret unterstützt
- Quellen
- FAQ
Wie strukturiert man ein MLOps-Team richtig?
Die Rollenverteilung entscheidet darüber, ob ein MLOps-Team skaliert oder in Reibungsverlusten versinkt. Fehlende Ownership ist laut einer Untersuchung zur Rollenabgrenzung in MLOps einer der häufigsten Gründe, warum Teams an internen Übergaben scheitern. Wer MLOps Team aufbauen will, sollte deshalb zuerst Aufgaben schneiden, nicht Stellenanzeigen schreiben.
Folgende Profile bilden das Rückgrat:
- Data Engineer: baut und pflegt Datenpipelines, verantwortet Feature-Qualität und Datenverfügbarkeit.
- ML Engineer: entwickelt Trainingscode, führt Experimente durch, verantwortet Modellgüte vor dem Rollout.
- Platform/MLOps Engineer: betreibt Serving-Infrastruktur, CI/CD, Monitoring und Rollback-Mechanismen.
- ML-Product/Domain Owner: übersetzt Geschäftsanforderungen in Modellziele und entscheidet über Release-Reife.
- AI Governance Officer: prüft Dokumentation, Risikobewertung und Aufsichtspflichten vor produktivem Einsatz.
Ownership sollte man nicht nur im Organigramm, sondern technisch abbilden. Wer besitzt welches Verzeichnis, welchen Registry-Eintrag, welche Serving-Konfiguration? Diese Frage muss vor dem ersten Sprint geklärt sein, sonst wird jede Störung zur Schuldfrage statt zur Behebung.
Bei der Skalierung gilt eine Faustregel aus der Praxis: Plattformteams sollten im Verhältnis von etwa 1:4 bis 1:6 zu modellbauenden Kolleginnen und Kollegen wachsen. Ein Plattform-Engineer betreut also vier bis sechs Data- und ML-Engineers, bevor ein zweiter dazukommt. Organisatorisch stehen zwei Modelle zur Wahl: zentral, mit einem Center of Excellence, das alle Modellteams bedient, oder föderiert, mit MLOps-Kompetenz direkt in den Fachbereichen. Föderierte Strukturen sind flexibler, brauchen aber zwingend zentrale Guardrails, sonst entsteht Schatten-KI ohne Aufsicht.
Welche Übergabeprozesse sichern die Zusammenarbeit?
Ein Repository ohne klare Struktur ist die häufigste Ursache für unklare Verantwortlichkeit. Empfohlen wird eine Trennung in /data, /models und /serving, jeweils mit eigenem CODEOWNERS-Eintrag und separatem CI-Workflow. So löst eine Änderung im Serving-Code nicht versehentlich einen Trainingslauf aus, und Pull Requests landen automatisch bei der richtigen Person.
Der Übergabeprozess selbst lässt sich als feste Sequenz definieren:
- Datenversionierung über ein Tool wie DVC, inklusive Validierung gegen ein Schema.
- Training mit reproduzierbaren Parametern, dokumentiert im Experiment-Tracking.
- Registrierung des Modells in der Model Registry mit Metadaten zu Datenherkunft und Metriken.
- Freigabe durch den Domain Owner, danach automatisiertes Deployment über die Plattform.
Für jede Übergabe lohnt sich ein SLA: etwa maximal 24 Stunden zwischen Registry-Eintrag und Freigabeentscheidung, oder eine wöchentliche Review-Runde, in der Platform Engineer und ML Engineer gemeinsam offene Incidents durchgehen. Eskalationspfade sollten vorher feststehen, nicht erst im Störfall.
Profi-Tipp: Legen Sie ein wöchentliches, maximal 20-minütiges „Ownership-Sync“ zwischen Data-, ML- und Platform-Team fest. Kurze, feste Termine verhindern mehr Reibung als jede Dokumentation.
Welche Tools und Infrastruktur braucht ein MLOps-Team?
Der technische Stack folgt der Logik von CI/CD, erweitert um Continuous Training (CT). Google Cloud beschreibt dieses Muster als Kombination aus Model Registry, automatisierten Tests und Validierungsschritten vor jedem Rollout.
Zentrale Bausteine:
- Model Registry: verwaltet Versionen, Metadaten und Freigabestatus jedes Modells.
- Feature Store: stellt konsistente Features für Training und Serving bereit.
- Orchestrator: steuert Pipeline-Schritte und Abhängigkeiten automatisiert.
- Observability-Stack: erfasst Latenz, Drift und Fehlerraten in Produktion.
Continuous Training braucht klare Trigger, etwa Data-Drift über einem Schwellenwert oder ein fester Zeitplan. Jeder automatische Trainingslauf sollte gegen Validierungsmetriken geprüft werden, bevor er die Registry erreicht, und ein Rollback-Mechanismus muss ein fehlerhaftes Modell binnen Minuten zurücksetzen können. Auf Infrastrukturebene gehören saubere Namespaces, rollenbasierte Zugriffskontrolle (RBAC) und automatisierte Guardrails zur Grundausstattung, nicht zur Kür.
Welche Metriken zeigen, ob ein MLOps-Team funktioniert?
Zwei Metrikfamilien ergänzen sich. Für ML-Teams eignen sich DORA-adaptierte Kennzahlen: Deployment-Frequenz, Lead-Time for Changes, Change Failure Rate und Time-to-Restore. Für das MLOps-Team selbst zählen andere Größen: Plattform-Adoption, Nutzerzufriedenheit, Kosten pro Nutzer, Automation Coverage und der Population Stability Index (PSI) zur Erkennung von Data-Drift.
Eine thematische Auswertung der MLOps-Bewertungspraxis fasst diese Kriterien in acht Bereichen zusammen: Data Management, Automation, Model Performance, Deployment, Resource Efficiency, Usability, Monitoring und Compliance. Usability und Kosten pro Nutzer werden dabei genauso ernst genommen wie technische Deployment-Metriken.
Wichtig ist, dass die Ziele beide Metrikfamilien abdecken. Ein Team, das nur Deployment-Frequenz optimiert, aber die Nutzerzufriedenheit ignoriert, baut irgendwann an der Realität der Fachbereiche vorbei.
Was verlangt der EU AI Act von MLOps-Teams?
Artikel 14 des AI Act verpflichtet Betreiber von Hochrisiko-KI-Systemen zu wirksamer menschlicher Aufsicht. Für bestimmte Anwendungen schreibt das Gesetz eine getrennte Überprüfung durch mindestens zwei natürliche Personen vor, ein Vier-Augen-Prinzip, das MLOps-Teams organisatorisch abbilden müssen.
Praktisch bedeutet das:
- Prüfer- und Entwicklerrolle dürfen bei kritischen Freigaben nicht identisch sein.
- Jede Freigabeentscheidung braucht eine dokumentierte Begründung, keine mündliche Zusage.
- Ein Stop-Mechanismus muss jederzeit verfügbar sein, um ein laufendes System anzuhalten.
- Post-Market-Monitoring gehört fest in den Betriebsplan, nicht in eine spätere Nachrüstung.
Die AI Governance Officer-Rolle trägt hier die Verantwortung, Technical Documentation und Incident Reports aktuell zu halten, unabhängig davon, wer das Modell gebaut hat.
Warum Besetzung über Erfolg oder Scheitern entscheidet
Ein Spezialist für die Besetzung von Fachkräften im Kontext der KI-Transformation legt einen klaren Fokus auf die menschliche Komponente der KI-Integration. Über eigene Methoden identifiziert Polydigital gezielt Fachkräfte für Rollen, die im bisherigen Organigramm oft noch nicht existieren, etwa MLOps Engineer oder AI Governance Officer. Diese Praxiserfahrung zeigt: Die technisch beste Pipeline nützt wenig, wenn die Rolle dahinter unbesetzt oder falsch besetzt ist.
Warum Rollenklarheit wichtiger ist als jedes Tool
Die gängige Annahme lautet: Wer die richtige Plattform kauft, hat MLOps im Griff. Das ist rückwärts gedacht. Tools lösen keine Ownership-Konflikte, sie machen sie nur sichtbarer, weil jede ungeklärte Zuständigkeit im Pull-Request-Verlauf oder im Incident-Log auftaucht. Die eigentliche Arbeit beim MLOps Team aufbauen ist Organisationsdesign, nicht Software-Auswahl.
Unterschätzt wird zudem, wie sehr sich Verantwortung in Richtung Plattform und IT verschiebt, sobald Governance-Pflichten ernst genommen werden. Wer glaubt, ein Data-Science-Team könne Compliance nebenbei mitverwalten, wird an der Dokumentationslast scheitern. Governance braucht eine eigene, klar geschnittene Rolle, keine Nebenaufgabe.
Mein Rat: Beginnen Sie nicht mit der Metrik-Diskussion, sondern mit der Ownership-Frage. Wer besitzt was, wer prüft wen, wer darf ein Modell stoppen? Erst danach lohnt sich die Debatte über DORA-Kennzahlen oder Dashboards. Teams, die diese Reihenfolge umdrehen, bauen beeindruckende Reportings für ein Chaos, das darunter unverändert weiterläuft.
— Ingmar
Wie Polydigital beim Teamaufbau konkret unterstützt
Ein MLOps-Team aufzubauen scheitert selten an der Strategie, sondern an der Besetzung. Es gibt spezialisierte Anbieter, die sich auf die passgenaue Vermittlung von Fachkräften für Rollen konzentrieren, die im klassischen Organigramm noch fehlen. Dazu zählen Head of AI, MLOps/AI Platform Engineer, AI Governance Officer und weitere Positionen der KI-Transformation, jeweils individuell geprüft statt aus veralteten Standarddatenbanken gezogen.
Wer erst einschätzen will, welche Rollen im eigenen Unternehmen in den nächsten Monaten entstehen, findet im Signal Report eine Einordnung aktueller und kommender Bedarfe. Für eine konkrete Besetzungsanfrage sind Anbieterseiten mit Rollenübersichten hilfreich, die Profile und Auswahlprozesse darstellen.
Quellen
- Artikel 14 - Menschliche Aufsicht - Gesetze (AI Act)
- Team structure for MLOps | Mlops Fundamentals Advanced Course | The Neural Base
- MLOps: Continuous Delivery and Automation Pipelines in Machine Learning (Google Cloud)
FAQ
Wie viele Personen braucht ein MLOps-Team am Anfang?
Ein Minimalteam funktioniert oft schon mit drei bis vier Personen: einem Data Engineer, einem ML Engineer, einem Platform Engineer und einem Domain Owner in Teilzeit. Governance-Aufgaben lassen sich anfangs noch von einer bestehenden Rolle mitgetragen werden, sollten aber spätestens bei Hochrisiko-Anwendungen eigenständig besetzt sein.
Was unterscheidet MLOps von DataOps?
DataOps konzentriert sich auf Datenqualität, Pipelines und Datenintegration, unabhängig von Modellen. MLOps deckt zusätzlich Training, Deployment, Monitoring und Governance von Machine-Learning-Modellen ab und baut dabei häufig auf DataOps-Praktiken auf.
Welche Skills braucht ein MLOps Engineer konkret?
Gefragt sind Kenntnisse in CI/CD-Systemen, Containerisierung, Model-Registry-Werkzeugen und Monitoring-Stacks, ergänzt durch Grundverständnis von Trainingsprozessen. Ebenso wichtig ist die Fähigkeit, mit Data Engineers und ML Engineers klare Übergabepunkte zu definieren.
In welchem Verhältnis sollte das Plattformteam zu den Modellteams wachsen?
Eine gängige Empfehlung liegt bei einem Plattform-Engineer je vier bis sechs modellbauenden Personen. Wächst das Verhältnis darüber hinaus, häufen sich typischerweise Wartezeiten bei Deployments und Self-Service-Anfragen.
Was kostet die Unterstützung durch Polydigital bei der Besetzung?
Polydigital veröffentlicht keine pauschalen Preise für die Rollenbesetzung. Details zu Konditionen und dem passenden Vorgehen für die jeweilige Rolle lassen sich direkt über die Rollenübersicht anfragen.