Welche Version Ihres Modells wird derzeit produziert, und wer hat sie genehmigt?
Ihre Datenabteilung weiß, welche Version die erfolgreiche ist. Bei einem Audit geht es jedoch um etwas anderes: Wer hat entschieden, diese Version in Betrieb zu nehmen, welche Kontrollmaßnahmen gab es und welche Dateien genau waren am Tag des Vorfalls in Betrieb?
Was MLflow bereits weiß – und was nicht
MLflow ist der De-facto-Standard für die Protokollierung von Modellen. Es ist ersichtlich, welche Ausführung zu jeder Version geführt hat, mit welchen Daten das Modell trainiert wurde und welche Metriken erzielt wurden. Für das Datenteam reicht das aus.
In puncto Governance fehlen drei Dinge: Kontrollen mit Nachweisen. Eine Freigabe vor der Produktion, denn derzeit kann jeder mit Schreibberechtigung den Produktions-Alias ändern, ohne dass dies protokolliert wird. Und der Nachweis, dass die heutigen Dateien dieselben sind, die am Tag des Audits in der Produktion waren.
Sechs Kontrollen, reproduzierbare Ergebnisse
„Verifiable AI MLOps Governance“ liest den MLflow des Unternehmens, ohne jemals darin zu schreiben, und bewertet jede Version anhand von sechs Kontrollen – ganz ohne Sprachmodell:
Eingangsdiagramm.
Das Modell soll angeben, welche Daten es erwartet.
Serialisierung.
Es darf nicht in Formaten gespeichert werden, die beim Laden Code ausführen können.
Voraussetzungen.
Bibliotheken, die an eine bestimmte Version gebunden sind und für die keine Sicherheitswarnungen bekannt sind.
Datenherkunft.
Mit welchen Datensätzen wurde die jeweilige Version trainiert?
Beschreibung und Lizenz.
Was ist das Modell und unter welcher Lizenz wird es genutzt?
Sonderangebot.
Was sich in der Produktion befindet, muss genehmigt sein.
Im MLflow-Demo-Beispiel besteht ein ordnungsgemäß verwaltetes Modell 6 von 6 Tests. Ein anderes Modell, das ohne Genehmigung in der Produktion läuft, besteht 0 von 6 Tests und löst eine Warnmeldung aus. Der Unterschied wird nicht durch eine subjektive Einschätzung bestimmt, sondern durch eine Regel. Bei gleichen Eingaben, Regeln und Bewertungsquellen ist das Ergebnis reproduzierbar.
Vor der Produktion sagt jemand „Ja“
Die Freigabe für die Bereitstellung wird von einer verantwortlichen Person unterzeichnet und mit einer Bestätigung versehen. Gelangt eine Version ohne diese Bestätigung in die Produktion, wird in „Überwachung“ eine Warnmeldung ausgelöst; bei der nächsten Durchführung der Kontrollen wird die Freigabe überprüft und der Status der Warnmeldung aktualisiert. Dies ist die manuelle Überwachung gemäß Artikel 14, die dort angewendet wird, wo das Risiko entsteht.
Das Modell „ V-Seal “: Was genau war das für eine Version?
Durch das Versiegeln einer Version wird der Fingerabdruck jeder Datei des Modells, seiner Datensätze und seiner Ergebnisse mit einem kryptografischen Nachweis erfasst. Wenn sich eine Metrik oder eine Datei ändert, ist ein neues Siegel erforderlich.
Das Unternehmen veröffentlicht lediglich ein verschlüsseltes Manifest mit Fingerabdrücken und Zählwerten. Weder das Modell noch die Daten noch der Wert einer Metrik verlassen die Infrastruktur des Unternehmens. Jeder kann das Siegel auf der öffentlichen Seite überprüfen, ohne ein Konto zu benötigen.
Warum ist das gerade jetzt wichtig?
Was die EU-KI-Verordnung von einem System mit hohem Risiko verlangt (Daten, Dokumentation, Aufzeichnung, Überwachung und Genauigkeit: Artikel 10, 11, 12, 14 und 15), hat seinen Ursprung im Lebenszyklus des Modells. Dort liegt der Nachweis – oder fehlt er.
Um ehrlich zu sein: Die Synchronisierung wird manuell gestartet, sodass eine Änderung des Alias erst bei der nächsten Ausführung erkannt wird, nicht sofort. Und bei MLflow in Databricks ist die Berechnung der Fingerabdrücke noch nicht getestet; dies wird durch das Pipeline-Skript abgedeckt.
Jede Version wurde geprüft. Jede Bereitstellung wurde genehmigt und ist nachweisbar.
Ein Modell, seine Varianten und der Test jedes einzelnen Modells.
Aufzeichnung über das V-PROOF-Portal, das mit einem MLflow-Demo-Projekt verbunden ist.
Demo ansehen