Model Registry: Warum Unternehmen ein System zur Steuerung von KI-Modellen brauchen

Bei der Entwicklung von maschinellem Lernen entstehen üblicherweise dutzende oder hunderte Varianten eines Modells. Sie unterscheiden sich in Trainingsdaten, Algorithmus, Parametern, Quellcode, Geschwindigkeit, Kosten und Ergebnisqualität.

Solange es nur ein Experiment ist, lässt sich ein Teil dieses Kontexts im Notebook, im Repository oder im Kopf der Entwicklerin halten.

Sobald ein Modell jedoch einen echten Unternehmensprozess beeinflusst, muss die Organisation konkrete Fragen beantworten:

• Welche Modellversion läuft gerade?
• Aus welchen Daten ist sie entstanden?
• Wie wurde sie getestet?
• Wer hat sie freigegeben?
• In welchen Anwendungen wird sie eingesetzt?
• Welche bekannten Einschränkungen hat sie?
• Was hat sich gegenüber der Vorversion geändert?
• Lässt sich eine fehlerhafte Version schnell zurückziehen und ersetzen?
• Wer verantwortet ihren weiteren Betrieb?

Genau diese operative Lücke schließt eine model registry.

Was eine Model Registry ist

Eine Model Registry ist ein zentrales System zur Erfassung und Verwaltung von Modellen über ihren Lebenszyklus.

Ihre Aufgabe ist nicht nur, die Datei mit dem trainierten Modell aufzubewahren. Sie verknüpft das konkrete Modellartefakt mit den Informationen, die für Verständnis, Validierung, Freigabe, Einsatz, Monitoring und eine mögliche Außerbetriebnahme nötig sind.

Eine typische Model Registry erfasst:

• Name und Zweck des Modells,
• die einzelnen Versionen,
• die Modellartefakte,
• die Herkunft des Modells,
• die verwendeten Datensätze und Trainingsläufe,
• die Evaluationsergebnisse,
• Metadaten und Dokumentation,
• den Freigabestatus,
• den Owner,
• die produktiven Einsätze,
• die Änderungshistorie.

MLflow beschreibt sie als zentralisierten Speicher, API und Benutzeroberfläche für die Verwaltung des Modelllebenszyklus. Unterstützt werden Versionierung, Lineage, Aliase, Metadaten und der Bezug zum Experiment, aus dem das Modell hervorging.[1]

Ähnliche Komponenten bieten auch AWS SageMaker, Microsoft Azure Machine Learning und Google Vertex AI.[2][3][4]

Das zeigt eine wichtige Tatsache:

Warum es nicht reicht, das Modell als Datei zu speichern

Stellen wir uns eine Datei vor mit dem Namen fraud_detection_model_v12.pkl.

Aus dem Namen lässt sich ableiten, dass es die zwölfte Variante eines Modells zur Betrugserkennung ist. Die Datei selbst sagt aber nicht:

• ob es das zwölfte Experiment oder die zwölfte Produktionsversion ist;
• aus welcher Datenversion das Modell entstand;
• welcher Commit des Quellcodes verwendet wurde;
• welche Variablen das Modell erwartet;
• welche Ergebnisse es erreicht hat;
• ob es eine unabhängige Validierung durchlaufen hat;
• wer seinen Einsatz freigegeben hat;
• ob irgendwo noch eine ältere Version im Einsatz ist.

Ein Dateiname ist kein Steuerungssystem.

Eine Model Registry sorgt dafür, dass ein Modell nicht nur ein technisches Artefakt ist, sondern ein identifizierbarer, nachvollziehbarer und verwalteter Produktivwert.

Zwei Bedeutungen, die man unterscheiden muss

Der Begriff Model Registry liegt heute im Schnittpunkt zweier verwandter Disziplinen.

1. Die technische Model Registry

Im MLOps geht es vor allem um die Verwaltung von Modellartefakten und ihren Versionen.

Sie beantwortet zum Beispiel die Fragen:

• Welche Modellversion ist produktiv?
• Welches Experiment hat sie erzeugt?
• Wo liegt ihr Artefakt?
• Welche technischen Parameter hat sie?
• Welche Version soll die Anwendung laden?
• Wie lässt sich ein Rollback durchführen?

Diese Ausprägung nutzen MLflow und die großen Cloud-ML-Plattformen.

2. Das Enterprise Model Inventory

Im Model Risk Management und in der KI-Governance ist der Umfang breiter.

Die Erfassung konzentriert sich nicht nur auf die Modelldatei, sondern auch auf:

• den geschäftlichen Zweck,
• den Owner,
• die Kritikalität des Modells,
• erlaubte und verbotene Nutzung,
• die verwendeten Datenquellen,
• den Validierungsstand,
• bekannte Einschränkungen,
• die Abhängigkeit vom Anbieter,
• die Incident-Historie,
• das Datum der nächsten Überprüfung,
• den Plan zur Außerbetriebnahme.

Die US-Aufsichtsleitlinien zum Model Risk Management verwenden den Begriff model inventory als die Gesamtheit der Informationen, die nötig sind, um die Risiken einzelner Modelle und des gesamten Modellportfolios zu verstehen.[5]

Technische Registry und Enterprise Inventory müssen nicht immer ein System sein.

Die technische Registry kann an Entwicklungs- und Deployment-Pipelines angebunden sein. Das Enterprise Inventory kann Teil einer Governance-Plattform, eines Risikosystems oder eines internen Registers sein.

In einer reifen Organisation sollten sie jedoch ein verbundenes Ganzes bilden.

Was eine Model Registry erfassen sollte

Der Basiseintrag lässt sich in sechs Schichten gliedern:

Identität

Ein Modell braucht einen stabilen Namen und einen klar abgegrenzten Zweck. Zum Beispiel:

Eine allgemeine Bezeichnung wie „KI für den Vertrieb“ reicht nicht. Ohne konkreten Zweck lassen sich weder passende Kennzahlen noch akzeptables Risiko oder Nutzungsgrenzen bestimmen.

Herkunft

Die Model Lineage beschreibt die Kette, aus der das Modell entstanden ist:

• den Trainingslauf,
• die Version des Datensatzes,
• den verwendeten Code,
• die Parameter,
• die Bibliotheken,
• die Rechenumgebung,
• die Autorin oder den Autor,
• das Erstellungsdatum.

Ohne Lineage lässt sich ein Modell vielleicht wieder laden, aber nicht zuverlässig reproduzieren und seine Herkunft nicht erklären.

Evaluation

Ein einzelner Genauigkeitswert reicht nicht. Je nach Zweck können zum Beispiel wichtig sein:

• Genauigkeit,
• Precision und Recall,
• die Rate falsch positiver Ergebnisse,
• die Stabilität zwischen Datengruppen,
• Robustheit,
• Latenz,
• Betriebskosten,
• Erklärbarkeit,
• Sicherheitstests.

Die Registry soll nicht nur festhalten, welches Modell gewählt wurde, sondern auch unter welchen Bedingungen es angenommen wurde.

Freigabe

Eine Modellversion kann zum Beispiel sein:

• experimentell,
• Kandidat,
• wartend auf Validierung,
• freigegeben,
• produktiv,
• in Ablösung,
• archiviert,
• gesperrt.

Der Eintrag soll zugleich ausweisen, wer die technische Prüfung durchgeführt hat, wer die geschäftliche Nutzung freigegeben hat und wer das Modell verantwortet.

Einsatz

Die Registry muss zeigen, wo eine Version eingesetzt wird. Das kann zum Beispiel sein:

• eine Online-API,
• Batch-Verarbeitung,
• eine mobile Anwendung,
• ein internes Entscheidungssystem,
• Geräte am Netzwerkrand,
• mehrere Regionen oder Umgebungen.

Tritt ein kritischer Fehler auf, muss das Unternehmen schnell alle betroffenen Prozesse und Anwendungen bestimmen können.

Betrieb

Die Registrierung endet nicht mit dem Einsatz. Der Eintrag sollte mit Informationen verknüpft sein über:

• die Leistung im Produktivbetrieb,
• Änderungen der Eingangsdaten,
• Qualitätsverluste,
• Incidents,
• Ausnahmen,
• Einschränkungen,
• Rekalibrierungen,
• Ablösung oder Außerbetriebnahme des Modells.

Ein Modell, das beim Einsatz geeignet war, muss es nicht für immer bleiben.

Wie der Lebenszyklus eines Modells aussieht

Der typische Prozess hat mehrere Schritte:

1. Experimentieren: das Team probiert verschiedene Datensätze, Algorithmen und Konfigurationen aus.
2. Auswahl des Kandidaten: eine oder mehrere Varianten erfüllen die Basiskriterien.
3. Registrierung: der Kandidat wird als neue Version in der Model Registry eingetragen.
4. Evaluation und Validierung: das Modell wird mit den Anforderungen und der aktuellen Produktionsversion verglichen.
5. Freigabe: eine berechtigte Person oder Pipeline erlaubt seine Nutzung.
6. Einsatz: die freigegebene Version wird in die Test- oder Produktivumgebung ausgerollt.
7. Monitoring: Leistung, Datenqualität, Kosten und Abweichungen werden beobachtet.
8. Ablösung oder Rollback: eine neue Version übernimmt den Betrieb, oder das System kehrt zur älteren zurück.
9. Außerbetriebnahme: eine nicht mehr genutzte Version wird archiviert, ihre Historie bleibt aber nachvollziehbar.

Eine Model Registry ist also kein passives Archiv.

Sie ist der Kontrollpunkt zwischen Experiment und Produktivbetrieb.

Was eine Model Registry nicht ist

Eine Model Registry ist Teil einer größeren Landschaft. Sie ersetzt mehrere andere Systeme nicht.

Experiment tracking

Erfasst alle Entwicklungsversuche, ihre Parameter und Ergebnisse.

Model registry

Verwaltet ausgewählte Modelle und Versionen mit operativer Bedeutung.

Model monitoring

Beobachtet das Verhalten des Modells nach dem Einsatz.

Model Hub oder Katalog

Hilft dabei, verfügbare Modelle zu entdecken.

AI system inventory

Erfasst ganze KI-Systeme, ihre Nutzung, Owner, Daten, Anbieter und Risiken.

Diese Schichten können in einer Plattform liegen, beantworten aber unterschiedliche Fragen.

Was generative KI verändert

Klassische Model Registries entstanden vor allem für Modelle, die ein Unternehmen selbst trainiert hat.

Bei generativer KI besitzt ein Unternehmen die Modellgewichte oft nicht und steuert das Training nicht. Es nutzt ein externes Foundation Model über eine API und baut darauf die eigene Anwendung.

Das Verhalten einer solchen Anwendung bestimmt nicht nur das Modell. Das Ergebnis beeinflussen auch:

• der System-Prompt,
• die Modellparameter,
• die Wissensbasis,
• das Embedding-Modell,
• die Retrieval-Logik,
• die verfügbaren Werkzeuge,
• die Berechtigungen des Agenten,
• die Guardrails,
• die Nachverarbeitung der Ausgabe.

Bei einem RAG-System kann eine Änderung der Dokumente oder der Retrieval-Pipeline das Verhalten genauso grundlegend verändern wie der Austausch des Sprachmodells.

Die gesteuerte Einheit ist deshalb nicht mehr nur die Modellversion, sondern eher:

Eine moderne Model Registry erweitert sich damit in Richtung Erfassung von KI-Komponenten, Agenten und ganzen Systemkonfigurationen.

Ein externes Modell hebt die Verantwortung nicht auf

Beim Einsatz eines externen Modells hat ein Unternehmen weniger Informationen und weniger technische Kontrolle. Der Anbieter kann ändern:

• das Modell oder sein Verhalten,
• die verfügbaren Versionen,
• den Preis,
• die Limits,
• die Sicherheitsfilter,
• die Bedingungen der Datenverarbeitung.

Der Eintrag eines externen Modells sollte deshalb mindestens enthalten:

• den Anbieter,
• die Modellbezeichnung,
• die Zugriffsart,
• die genutzte Version oder den Endpunkt,
• das Einführungsdatum,
• die verarbeiteten Datenkategorien,
• bekannte Einschränkungen,
• den Preis,
• das Ersatzmodell,
• das Vorgehen bei Einstellung des Dienstes.

Dass ein Unternehmen ein Modell nicht trainiert hat, heißt nicht, dass es dieses nicht steuern muss.

Im Gegenteil: Bei einem proprietären Modell kann die Erfassung noch wichtiger sein, weil die Organisation keinen Zugang zu allen Informationen über Konstruktion, Daten und interne Änderungen hat.

Model Registry und KI-Governance

Eine Model Registry allein sorgt nicht für verantwortungsvolle Nutzung von KI. Sie liefert aber die Infrastruktur, ohne die Governance kaum umsetzbar ist.

Sie hilft zu belegen:

• welche Version verwendet wurde,
• wie sie getestet wurde,
• wer sie freigegeben hat,
• wo sie eingesetzt wurde,
• welche Einschränkungen sie hatte,
• wann sie geändert wurde,
• ob sie später abgelöst wurde.

EU AI Act schreibt Organisationen kein Produkt namens „Model Registry“ vor.[6]

Bei regulierten KI-Systemen arbeitet er jedoch mit Risikomanagement, technischer Dokumentation, Aufzeichnungen, menschlicher Aufsicht, Monitoring und Verantwortung über den Lebenszyklus des Systems.

Eine Model Registry kann eine der technischen Schichten sein, die diese Prozesse stützen.

Man muss jedoch das Modell selbst und das gesamte KI-System unterscheiden.

Eine Model Registry kann Modellkomponenten erfassen. Die rechtliche, sicherheitsbezogene und geschäftliche Bewertung bezieht sich in der Regel auf das konkrete KI-System und die Art seiner Nutzung.

Wann ein Unternehmen eine Model Registry wirklich braucht

Eine umfassende technische Registry braucht nicht jede Organisation.

Ein Unternehmen, das nur einige fertige SaaS-Anwendungen nutzt, wird vor allem ein AI System Inventory und Regeln für Anbieter brauchen.

Eine Model Registry wird vor allem dann wichtig, wenn eine Organisation:

• selbst Modelle entwickelt oder feinjustiert;
• mehrere Versionen desselben Modells betreibt;
• Modelle in wichtigen Entscheidungsprozessen einsetzt;
• formale Validierung und Freigaben braucht;
• Reproduzierbarkeit sicherstellen muss;
• einen schnellen Rollback braucht;
• mehrere Clouds oder Deployment-Umgebungen nutzt;
• eine größere Zahl von RAG-Anwendungen und Agenten aufbaut;
• strengeren Anforderungen aus Audit oder Model Risk Management unterliegt.

Die erste Umsetzung muss nicht umfangreich sein. Sie muss aber eine einzige verbindliche Quelle der Wahrheit schaffen und mit dem tatsächlichen Deployment-Prozess verbunden sein.

Eine Registry, die man umgehen kann, indem eine Entwicklerin ein anderes Modell direkt in die Produktion lädt, steuert nicht den echten Betrieb. Sie dokumentiert nur dessen idealisierte Fassung.

Die häufigsten Fehler

Die Registry wird zur Abstellkammer für Experimente

Wird darin automatisch jeder Versuch abgelegt, füllt sie sich schnell mit hunderten Varianten ohne operative Bedeutung.

Für die Erfassung aller Experimente ist das Experiment Tracking da. In die Registry gehören Modelle, die Kandidat für Validierung, Einsatz oder weitere gesteuerte Nutzung geworden sind.

Das Modell hat keinen konkreten Owner

Das technische Team hat das Modell erstellt, aber niemand verantwortet seinen geschäftlichen Zweck, die richtige Nutzung und den weiteren Betrieb.

Ein Register ohne Verantwortung wird zum Dateikatalog.

Die Verbindung zu Daten und Code fehlt

Das Unternehmen erfasst das Modellartefakt, weiß aber nicht, aus welchem Datensatz und Code es entstanden ist.

Ein solches Modell lässt sich weder zuverlässig reproduzieren noch erklären.

Die Freigabe ist bloß formal

Das Modell ist als freigegeben markiert, aber es ist unklar:

• wer es freigegeben hat,
• nach welchen Kriterien,
• für welchen Zweck,
• für welchen Zeitraum,
• was die Freigabe ungültig machen soll.

Die Registry ist nicht mit dem Deployment verbunden

Das Modell wird zwar registriert, aber das Produktionsteam kann ein beliebiges Artefakt am Freigabeprozess vorbei ausrollen.

Die Registry erfasst dann eine andere Realität als die, die tatsächlich läuft.

Erfassung ersetzt Steuerung

Detaillierte Metadaten allein bestimmen nicht, ob ein Modell geeignet, sicher oder geschäftlich sinnvoll ist.

Eine Model Registry kann einen Prozess erzwingen und festhalten. Sie kann Entscheidung, Verantwortung und echte Aufsicht nicht ersetzen.

Fazit

Eine Model Registry löst eine grundlegende operative Frage:

Ohne Registry existieren Modelle als isolierte Dateien, API-Endpunkte und Experimente.

Mit Registry werden daraus verwaltete Werte mit nachvollziehbarer Herkunft, Verantwortung und Lebenszyklus.

Ihre wichtigsten Vorteile sind:

• Versionierung,
• Lineage und Reproduzierbarkeit,
• gesteuerte Freigaben,
• die Verbindung zum produktiven Einsatz,
• die Möglichkeit eines Rollbacks,
• die Erfassung von Ownern und Verantwortung,
• die Unterstützung von Audit und Governance.

Im klassischen Machine Learning war das Modell selbst das Hauptobjekt der Steuerung.

In der generativen KI ist das Modell nur ein Teil einer breiteren Konfiguration aus Prompts, Daten, Werkzeugen und Berechtigungen. Die Model Registry wandelt sich deshalb schrittweise vom technischen Speicher zur Steuerungsschicht der Unternehmens-KI.

Ein Unternehmen muss nämlich nicht nur wissen, welches Modell es einsetzt.

Es muss erklären können, wie das Verhalten seiner KI zustande kommt.

Häufige Fragen

Quellen und weiterführende Literatur

1. MLflow: ML Model Registry. Referenz-Open-Source-Implementierung: Versionierung, Lineage, Aliase und Bezug zum Experiment. mlflow.org
2. Amazon Web Services: SageMaker Model Registry. Model Groups, Versionen und Freigabestatus, angebunden an die Deployment-Pipeline. docs.aws.amazon.com
3. Microsoft: Register and work with models in Azure Machine Learning. Registrierung von Modellen, Versionierung und Verwaltung innerhalb des Workspace. learn.microsoft.com
4. Google Cloud: Vertex AI Model Registry. Zentrale Übersicht der Modelle und ihrer Versionen über alle Einsätze hinweg. cloud.google.com
5. Federal Reserve: SR 26-2 — Revised Guidance on Model Risk Management. Aktualisierte US-Leitlinien zum Management von Modellrisiken (ersetzen SR 11-7 und SR 21-8). federalreserve.gov
6. Verordnung (EU) 2024/1689 — Artificial Intelligence Act. Der Grundtext der europäischen KI-Regulierung: Risikomanagement, Dokumentation, Aufzeichnungen und menschliche Aufsicht. eur-lex.europa.eu

Der Artikel hat informativen Charakter und stellt keine Rechtsauskunft dar.