Man kann nicht steuern, was man nicht auflisten kann. Ein Modellinventar ist der maßgebliche Nachweis über jedes Modell, das in Ihrem Institut läuft: was es ist, wer dafür verantwortlich ist, worüber es entscheidet und was es speist. Eine Registry ist der darunterliegende Engineering-Speicher, der versionierte Artefakte und Lineage vorhält. Zusammen versetzen sie Risiko und Revision in die Lage, zu jeder Entscheidung eine konkrete Frage zu beantworten statt nur eine allgemeine über Ihre Policy.
Die meisten Institute entdecken die Lücke auf dieselbe Weise. Ein Prüfer verlangt eine Liste der Modelle in Produktion, jemand exportiert eine Tabelle, und drei Teams weisen sofort auf Modelle hin, die darin fehlen. Der Scoring-Service, den ein Data-Science-Team im letzten Quartal aufgesetzt hat, steht nicht drin. Die Extraktionspipeline, die Kontoauszüge ausliest, steht nicht drin, weil niemand sich darauf geeinigt hat, dass sie als Modell zählt. Die Vendor-API, die jemand in den Inkasso-Workflow eingebunden hat, steht nicht drin, weil sie eingekauft und nicht selbst gebaut wurde. Die Tabelle war nie absichtlich falsch. Sie war nur nie die Quelle der Wahrheit, und deshalb ist sie schon am Tag nach dem Ausfüllen von der Realität abgedriftet.
Was tatsächlich ins Inventar gehört
Das Inventar ist ein Governance-Artefakt. Seine Aufgabe ist es, einem Risk Officer oder einem Prüfer zu ermöglichen, ein Modell zu finden, seinen Wirkungsradius zu verstehen und die daran hängenden Personen und Nachweise zu erreichen. Die Felder bilden also Verantwortlichkeit und Materialität ab. Die Interna des Modells leben in der Registry, eine Ebene tiefer.
Für jedes Modell erfassen wir mindestens:
- Einen stabilen Identifier, der dem Modell über alle Umgebungen hinweg folgt und niemals wiederverwendet wird, sodass eine im März protokollierte Entscheidung exakt dem Eintrag zugeordnet werden kann, der sie erzeugt hat
- Owner und verantwortliche Führungskraft, benannte Personen statt eines Team-Postfachs, denn Materialitätsprüfungen und Freigaben landen bei einem Menschen
- Zweck und Entscheidungsbefugnis, was das Modell ausgibt, ob ein Mensch prüft und wo es in der Straight-Through-Processing- gegenüber der beratenden Nutzung einzuordnen ist
- Materialitätsstufe, die steuert, wie viel Aufsicht das Modell bekommt; ein Modell, das Kredite automatisch ablehnt, wird nicht auf dieselbe Weise gesteuert wie eines, das interne Kommentare entwirft
- Inputs und Datenquellen, einschließlich der Frage, ob ein Feature Point-in-Time-Beschränkungen unterliegt, denn ein Modell, das mit einem Feld gespeist wird, das zum Entscheidungszeitpunkt gar nicht bekannt gewesen wäre, ist ein Leakage-Vorfall, der nur darauf wartet, gefunden zu werden
- Vendor und Hosting, einschließlich der Frage, ob Gewichte hinter einer API liegen, die Sie nicht inspizieren können, und ob sich der Anbieter das Recht vorbehält, das Modell ohne Vorankündigung zu aktualisieren
Die Materialitätsstufe ist das Feld, das sich seinen Platz verdient. Ohne sie sieht jedes Modell gleich wichtig aus, und der Governance-Prozess ertrinkt entweder oder winkt alles durch. Mit ihr können Sie verteidigen, wofür Sie Ihren Validierungsaufwand eingesetzt haben.
In der Registry lebt das Engineering
Das Inventar sagt, dass ein Modell existiert und relevant ist. Die Registry sagt, was es tatsächlich ist, in einem Detailgrad, den ein Engineer reproduzieren kann. Das ist der Speicher, in den Ihre CI-Pipeline schreibt und aus dem Ihr Serving-Layer liest.
Ein brauchbarer Registry-Eintrag enthält das trainierte Artefakt, die exakten Trainings- und Evaluierungsdatensätze per Hash, die Feature-Definitionen, von denen es abhängt, das Eval-Set und die Scores, die diese Modellversion erreicht hat, und bei einem LLM die versionierte Prompt- und Retrieval-Konfiguration. Es geht um Rekonstruierbarkeit. Wenn jemand eine Entscheidung aus dem letzten Quartal anzweifelt, sollten Sie die Modellversion, den Datenstand, den Prompt und die Eval-Ergebnisse benennen können, die den Go-Live ermöglicht haben, und zwar ohne Archäologie über fünf Systeme hinweg.
Lineage ist der Teil, den Teams am häufigsten überspringen und am häufigsten brauchen. Wenn eine Spalte im Feature Store ihre Definition ändert, wollen Sie jedes Modell kennen, das sie konsumiert hat. Wenn sich herausstellt, dass ein Trainingsdatensatz ein geleaktes Feld enthält, wollen Sie die Liste der darauf trainierten Modelle, solange noch Zeit bleibt, sie zurückzuziehen, bevor eine Aufsichtsbehörde es zuerst findet. Diese Abfrage ist nur dann günstig, wenn Lineage zum Registrierungszeitpunkt festgehalten wurde und nicht später aus der Commit-Historie rekonstruiert werden muss.
Metadaten, die das Register erhaltenswert machen
Ein Inventar, das nur eine Liste ist, verkommt zur Compliance-Pflichtübung, der niemand traut. Die Metadaten sind das, was es in etwas verwandelt, das Risiko und Revision tatsächlich abfragen. Drei Kategorien tragen das meiste Gewicht.
Ownership und Lifecycle-Status: Ist das Modell in Development, Shadow, Produktion oder außer Betrieb? Ein Modell im Shadow Deployment, das neben einem Champion mitscored, hat andere Monitoring-Erwartungen als eines, das Live-Entscheidungen trägt, und das Register sollte diese Unterscheidung maschinenlesbar machen statt zu implizitem Wissen zu verkommen.
Monitoring- und Drift-Status: das letzte Eval-Datum, die aktuelle Performance gegenüber realisierten Ergebnissen und die Frage, ob das laufende Eval-Set noch grün ist. Hier hört das Inventar auf, eine statische Ablage zu sein, und wird zu einer operativen Sicht. Ein Modell, dessen Eval-Set seit sechs Wochen rot ist, sollte an derselben Stelle als rot sichtbar sein, an der Sie auch seinen Owner nachschlagen.
Nachweis-Links: der Validierungsbericht, die Model Card, der Freigabe-Nachweis, das mit dem Fachbereich vereinbarte False-Positive-Budget. Das Inventar muss diese Dokumente nicht selbst vorhalten, aber es muss verlässliche Verweise darauf enthalten, sodass ein Modell zu finden und seine Audit-Spur zu finden ein und dieselbe Handlung sind.
Der schwierige Teil ist nicht, diese Felder zu entwerfen. Er besteht darin, sie wahr zu halten. Ein von Hand gepflegtes Inventar ist innerhalb eines Quartals veraltet. Der Registrierungsschritt muss also im Deployment-Pfad sitzen: Ein Modell, das nicht registriert, eingestuft und mit einem Owner versehen wurde, bekommt kein Serving Credential. Anschließend gleichen Sie das Register in einem festen Turnus gegen das ab, was tatsächlich Traffic empfängt, und behandeln jedes Modell, das Requests bedient, ohne einen passenden Eintrag zu haben, als Vorfall und nicht als Papierkram-Lücke. Dieser Abgleich ist der ganze Sinn der Sache. Das Register ist nur dann etwas wert, wenn die Antwort auf „Ist das alles?” eine ist, die Sie verteidigen können, wenn jemand Unabhängiges sie gegen die Produktion prüft.
Häufige Fragen
Worin unterscheiden sich ein Modellinventar und eine Model Registry?
Das Inventar ist der Governance-Nachweis darüber, was existiert und wer dafür verantwortlich ist; die Registry ist der Engineering-Speicher für Artefakte, Versionen und Lineage. Beide sollten auf denselben Identifier verweisen, beantworten aber unterschiedliche Fragen und werden in der Regel von unterschiedlichen Teams gepflegt.
Gehören Prompts und Retrieval-Konfiguration ins Inventar?
Ja. Bei einem LLM verändern der Prompt und die Retrieval-Einstellungen das Verhalten genauso stark wie die Gewichte, sie sind also versionierte Inputs. Ein Inventar, das sie auslässt, kann nicht rekonstruieren, warum eine frühere Entscheidung so ausgefallen ist, wie sie ausgefallen ist.
Wie verhindern wir, dass das Inventar veraltet?
Hört auf, die Registrierung als Formular zu behandeln. Verdrahtet sie in den Deployment-Pfad, sodass ein Modell ohne Eintrag nicht in Produktion gelangen kann, und gleicht das Inventar in einem festen Turnus gegen das ab, was tatsächlich Traffic bedient.