MLOps und Model Governance

Isabel Bär

Dr. Larysa Visengeriyeva

This article is also available in English

Am 1. Dezember 2021 hält Isabel Bär im Rahmen des INNOQ Technology Day den Vortrag „MLOps und Model Governace“. Dort geht sie detailliert auf die in diesem Artikel beschriebenen Aspekte ein und beantwortet gerne all Eure Fragen. Anmelden könnt Ihr Euch unter technologyday.innoq.com

ML Operations (MLOps) hat in letzter Zeit viel Aufmerksamkeit bekommen, da es verspricht, Machine Learning-Modelle (ML-Modelle) schnell, effektiv und langfristig in Produktion zu bringen und zu halten. Als Äquivalent zu DevOps im Software Engineering ist MLOps die Erweiterung von DevOps für das Design, die Entwicklung und das nachhaltige Deployment von ML-Modellen in Software-Systemen. Dabei umfasst MLOps eine Reihe an Prozessen und Frameworks, die bei der Bereitstellung von ML helfen. Durch die Automatisierung reproduzierbarer Daten- und ML-Pipelines wird die Zeitspanne, um Modelle nachhaltig in Produktion zu bringen (time-to-market), effektiv verringert. Abb. 1 zeigt die wichtigsten Phasen des ML-Lebenszyklus nach CRISP-ML(Q). Insgesamt gibt es sechs interaktive Phasen im ML Development Prozess:

• Geschäftskontext und Daten verstehen (Business and Data Understanding)
• Data Engineering
• Model Engineering
• Qualitätssicherheit für ML Systeme
• Deployment
• Monitoring und Wartung.

Allerdings ist die Operationalisierung von ML-Modellen nicht die einzige Herausforderung, vor der viele Unternehmen stehen. Der Einsatz von ML bringt v.a. Verantwortung und Verpflichtungen mit sich. Um diesen Anforderungen nachkommen zu können, benötigt ein Unternehmen Prozesse, durch die es

• die Zugriffe auf ML-Modelle kontrolliert,
• Richtlinien/gesetzliche Vorgaben umsetzt und
• die Interaktionen mit den ML-Modellen und deren Ergebnisse verfolgt
• ​​festhält, auf welcher Grundlage ein Modell erzeugt wurde.

Insgesamt werden diese Prozesse als Model Governance bezeichnet.

Model Governance als neue Herausforderung

Die Wichtigkeit von Model Governance ergibt sich für viele Unternehmen oft erst dann, wenn ML-Modelle in die Produktion gehen sollen. Viele haben die ML-Pipelines automatisiert, doch stehen nun vor der Aufgabe, die Modelle in Einklang mit gesetzlichen Regelungen zu bringen. Darauf sind einige nicht vorbereitet: so geben nach einer Algorithmia Studie von 2021 56 Prozent der Befragten die Implementierung von Model Governance als eine der größten Herausforderungen an, um ML-Anwendungen langfristig erfolgreich in Produktion zu bringen. In Deutschland sind es nach der Studie „ML 2021“ von IDG Research Services 26,2% der Unternehmen, die Compliance-Risiken als größte Herausforderung sehen. 35.8 % stufen rechtliche Fragestellungen, wie z.B. die Nachvollziehbarkeit der algorithmischen Entscheidungsfindung, als noch zu lösendes Problem ein.

Der Einsatz von KI in Deutschland

Wo genau wird in deutschen Firmen ML eingesetzt? Nach der Machine Learning 2021- Studie setzen 73 Prozent der großen Unternehmen (mit mehr als 10.000 Beschäftigten) und 59 Prozent der kleineren Firmen ML ein. Die Unternehmensbereiche, in denen ML zum Einsatz kommt, sind IT (76%), Produktion (57%), Forschung und Entwicklung (54,1%), Logistik (52,9%) und der Vertrieb (50,6 %). Konkrete Use Cases sind die Qualitätssicherung in der Produktion (53,8 %), Fehlerreduzierung (43,8%), Automatisierung von Prozessen (40,2 %), automatisierte Vorgangsbearbeitung (36,7%), Optimierung der Supply-Chain (34,9%), Chatbots (30,2 %), Routenoptimierung (30,2%), Predictive Maintenance (29,6%), Customer-Self-Service (29,6 %) und intelligente Produktentwicklung (29,6%). Für alle diese Anwendungsfälle müssen Unternehmen zum einen MLOps implementieren, um ML-Modelle zu deployen und zum anderen Model-Governance-Frameworks aufbauen, sodass die Modelle im Einklang mit Regelungen stehen und die Qualität der Systeme gewährleistet ist.

Model Governance wird nicht optional sein

Unternehmen müssen bereits mehrere regulative Verordnungen einhalten. Dazu kommt, dass neue und KI-spezifische Auflagen den bestehenden Katalog an Regulierungen ergänzen und noch komplexer gestalten werden. So veröffentlichte die EU im April 2021 eine Verordnung als ersten Rechtsrahmen für KI. Der Entwurf verfolgt einen Ansatz, der die verschiedenen Arten von KI-Systemen in vier unterschiedliche Risikokategorien einteilt.

• Kategorie 1 („Unzulässiges Risiko“): KI-Software, die als eindeutige Bedrohung für die Sicherheit, den Lebensunterhalt und Menschenrechte eingestuft wird, ist verboten (z.B Social-Scoring-Systeme)
• Kategorie 2 („Hohes Risiko”): KI-Software, die in die „hohe“ Risikokategorie fällt, ist an strenge Auflagen gebunden. Dazu zählen folgende Aspekte: Robustheit, Sicherheit, Genauigkeit (Accuracy), Dokumentation und Protokollierung sowie angemessene Risikobewertung und Risikominderung. Weitere Anforderungen sind eine hohe Qualität der Trainingsdaten, Diskriminierungsfreiheit, Nachvollziehbarkeit, Transparenz, menschliche Überwachung sowie die Erforderlichkeit einer Konformitätsprüfung und der Nachweis der Konformität durch CE-Kennzeichnung. Beispiele für die ML-Systeme in dieser Kategorie sind private und öffentliche Dienstleistungen (Kreditwürdigkeitsprüfung) oder Systeme, die in der Schul- oder Berufsausbildung eingesetzt werden, um über den Zugang zu Bildung und den beruflichen Werdegang einer Person zu entscheiden (z. B. Bewertung von Prüfungen).
• Kategorie 3 („Begrenztes Risiko”): Diese KI-Software unterliegt lediglich einer Transparenzpflicht. Beispielsweise müssen Chatbot-Nutzer*innen aufgeklärt werden, dass sie mit KI-Software interagieren.
• Kategorie 4 („Minimales Risiko”): Diese KI-Software unterliegt keinen Auflagen (z.B Spam-Filter).

Da die Verordnung nicht nur für in der EU ansässige Unternehmen und Einzelpersonen gelten soll, sondern auch für jedes Unternehmen, das KI-Dienste innerhalb der EU anbietet, hätte das Gesetz einen ähnlichen Anwendungsbereich wie die DSGVO. Die Verordnung muss sowohl vom EU-Parlament gebilligt werden als auch die Gesetzgebungsverfahren der einzelnen Mitgliedsstaaten passieren. Tritt das Gesetz frühestens 2024 in Kraft, müssen Hochrisiko-Systeme während der Entwicklung eine Konformitätsbewertung für KI-Auflagen durchlaufen. Erst danach kann die Registrierung des KI-Systems in einer EU-Datenbank erfolgen. Im letzten Schritt ist eine Konformitätserklärung notwendig, sodass KI-Systeme die notwendige CE-Kennzeichnung erhalten können.

Der EU-Entwurf ist allerdings noch ausbaufähig. Die wahrscheinlich größte Herausforderung bei der Verordnung ist dabei die Definition eines „KI-Systems“, auf die sich der gesamte Entwurf stützt. Diese Definition ist sehr weit gefasst, was zu verschiedenen Auslegungen führen könnte und wahrscheinlich das größte Hindernis für die Einführung darstellt. Unternehmen werden damit ringen, ihre technische Arbeit mit den Definitionen der Verordnung in Einklang zu bringen, da mit dem allgemeinen Charakter der Verordnung unklar bleibt, wie die Definitionen, Bewertungskriterien und Anforderungen in die Praxis umgesetzt werden sollen. Um den dadurch entstehenden Verunsicherungen auf Unternehmensseite entgegenzuwirken, sollte der Entwurf in Zusammenarbeit mit dem KI-Entwicklungsteam ausformuliert werden und sich auf konkrete Sektoren, Branchen und Anwendungsfälle beziehen.

Wichtig ist außerdem, dass die EU-Regulierungen nicht der einzig ausschlaggebende Aspekt für Model Governance sind. Denn auch für ML-Systeme außerhalb einer regulierten Domäne, die zwar in niedrige Risiko-Kategorien fallen, aber mit einem hohen unternehmerischen Risiko verbunden sind, ist Model Governance relevant. Verkauft ein Unternehmen beispielsweise Spam-Filter, die regelmäßig wichtige E-Mails löschen, ist die Position am Markt gefährdet. Model Governance wird also nicht nur zur Erfüllung rechtlicher Vorgaben, sondern auch zur Qualitätssicherung von ML-Systemen benötigt.

Die Integration von Model Governance und MLOps

Die Frage, wie die Integration von Model Governance und MLOps aussehen kann, ist von zwei Aspekten abhängig:

• Stärke der Regulierung – festgelegt durch die Hauptgeschäfts-Domäne, die Risiko-Kategorie eines ML-Modells und das unternehmerische Risiko: Zum einen gibt es Branchen, die eine lange Tradition strenger Regelungen haben – dazu gehören beispielsweise der Gesundheits- und Finanzsektor. Auf der anderen Seite wird zukünftig auch die EU-Kategorisierung entscheiden, welche Auflagen zu erfüllen sind – je geringer die Risikozuordnung, desto schwächer sind die zu erfüllenden Auflagen. Das bedeutet, dass bereits bestehende Vorgaben durch die neuen KI-Regelungen ergänzt werden können. Und schließlich ist der Einfluss der KI-Systeme auf den Geschäftserfolg ausschlaggebend: hängt dieser stark von KI-Systemen ab, müssen Vorgaben der Geschäftsführung streng ausfallen.
• Anzahl der ML-Modelle, die in Software-Systemen integriert werden müssen: Die Anzahl der ML-Modelle spiegelt zwei Aspekte wider: erstens, wie stark ein Unternehmen ML in die Hauptgeschäfts-Domäne integriert und/oder zweitens, wie reif das Unternehmen technisch als auch organisatorisch für die Umsetzung dieses Vorhabens ist. So kann eine geringe Anzahl von ML-Modellen entweder bedeuten, dass ML keine wichtige Rolle für das Geschäftskonzept eines Unternehmens spielt oder aber, dass Unternehmen noch daran arbeiten müssen, ML im geplanten Umfang anzuwenden.

Abb. 3 visualisiert die Integration von Model Governance und MLOps entlang des Regulierungsgrades und der Anzahl der Modelle als Mengendiagramme:

Im Folgendem erklären wir jeden dieser vier Quadranten:

Variante 1: Viele Modelle und starke Regulierung

Viele Modelle und eine stark regulierte Geschäftsdomäne sind das komplexeste Szenario der vier Varianten. Model Governance und MLOps sind hier gleichermaßen wichtig und stark verzahnt: Model Governance muss in jeden Abschnitt des MLOps-Lifecycles (Development, Deployment & Operations) integriert werden.

Beispiele: welche Domänen unterliegen strikten Regulierungen?

Modelle, die im Gesundheits- und Finanzsektor eingesetzt werden, sind Beispiele für strikt regulierte Domänen. Aber auch Modelle, die in die hohe Risiko-Kategorie fallen, zählen dazu. Das sind beispielsweise solche, die zur Prozessautomatisierung in kritischen Infrastrukturen (Verkehr) oder zur automatisierten Vorgangsbearbeitung in Schul- oder Berufsausbildungen zur Bewertung eingesetzt werden.

Model Governance Framework

Es ist wichtig, Model Governance-Prozesse von Beginn an in jeden Abschnitt des ML-Lebenszyklus zu integrieren. Ein guter Ausgangspunkt ist das in „The Framework for Model Governance“ beschriebene Model Governance-Framework, das sowohl rechtliche als auch unternehmensinterne Anforderungen abdeckt und das wir in diesem Kapitel vorstellen.

Die folgende Tabelle beschreibt die Hauptkomponenten des Model Governance Frameworks, die in jedes Stadium des ML-Lebenszyklus integriert werden müssen:

Reproduzierbarkeit und Validierung

In der ersten Phase des ML-Lifecycles müssen Reproduzierbarkeit hergestellt und das Modell validiert werden.

Reproduzierbarkeit ist die Fähigkeit, zweimal zu dem gleichen Ergebnis zu kommen. Ähnlich wie Naturwissenschaftler*innen Versuchsabläufe genau spezifizieren, muss ML-Reproduzierbarkeit relevante Metadaten bereitstellen, um Modelle nach Anleitung reproduzieren zu können. Zum Modell-Metadaten-Management zählen die Art des Algorithmus, Features und Transformationen, Daten-Snapshots, Hyperparameter, Performance-Metriken, überprüfbarer Code aus der Quellcodeverwaltung und der Training Environment.

In regulierten Domänen sind Dokumentationen bereits oft Bestandteil der Anforderungen. Doch auch unternehmensintern profitiert das Projekt von guter Dokumentation, da durch die Schaffung von Transparenz und Nachvollziehbarkeit Risiken von technical debt minimiert werden. Zu einer Dokumentation gehören folgende Aspekte: die Erklärung des Business Context, eine Highlevel-Erklärung des Algorithmus, Modellparameter, Auswahl und Definition von Features, Anpassungen des Algorithmus/der Algorithmen, Anweisungen zur Reproduktion des Modells und Beispiele für das Training der Algorithmen sowie Beispiele für das Treffen von Predictions durch den Algorithmus. Die Dokumentation lässt sich durch Toolkits wie Model Cards und Data Sheets praktisch unterstützen. Data Sheets halten fest, welche Mechanismen oder Verfahren für die Datenerhebung verwendet wurden oder ob ethische Überprüfungsverfahren stattgefunden haben. Model Cards ergänzen Data Sheets und informieren über die Art der Modellerstellung, die bei der Entwicklung getroffenen Annahmen sowie Erwartungen bezüglich des Modellverhaltens bei verschiedenen kulturellen, demografischen oder phänotypischen Gruppen.

Die Validierung von ML-Modellen ist ein mehrstufiger Prozess mit verschiedenen Metriken. Dazu zählen Performance-Metriken wie Accuracy oder die statistisch signifikante Verbesserung im Vergleich zu einer Kontrollgruppe bezüglich des Key Performance Indicator (KPI) im A/B-Testing. Die Prüfung, ob das ML-Problem selbst richtig formuliert ist, kann ebenfalls auf KPIs basieren. Zudem sollte das Entwicklungsteam die Reproduzierbarkeit des Modells aus den Metadaten prüfen.

Eine weitere wichtige Komponente der Validierung ist die Erklärbarkeit: kann die Performance des Modells erklärt werden? Kann erklärt werden, wie sich einzelne Features auf die Prediction auswirken? Oft lassen sich Erklärungen für Modelle mit Explainable AI nur approximieren.

Nach der Entwicklungsphase müssen die Model-Governance-Prozesse auch in die Deployment- und Operationsphase des ML-Lebenszyklus integriert werden:

Beobachtung, Sicherheit und Kontrolle

Durch diese Komponente sind Unternehmen in der Lage, Transparenz über Modellzugriffe, Modell- und Datenänderungen, Modelle und Daten zu gewährleisten und damit Erklärbarkeit des Prozesses nach Außen zu schaffen. Dazu gehören Logging, Metriken und Prüfungen: Werte aus dem Model-Logging werden in Metriken aufbereitet und in Dashboards zu Protokollierungs-, Analyse- und Kommunikationszwecken visualisiert. Die Kostentransparenz stellt Transparenz über die Kosten und die damit verbundene Ressourcennutzung her und erleichtert die Abrechnung verschiedener Teams für die spezifische Modell- und Ressourcennutzung. Modellnutzungs-Berichte (Usage Reports) schaffen Transparenz über Erfolg und Akzeptanz der einzelnen Modelle und können die Zugriffskontrolle unterstützen.

Zudem spielt das Management der Modell-APIs eine wichtige Rolle: die Verantwortlichkeiten zur Verwaltung der Endpoints (darunter Berechtigungen zur Erstellung, Änderung oder Löschung) müssen definiert werden. Die letzte Komponente ist die Versionierung von Modellen und Datensätzen. Die Versionierung dient der Wahrung des Unveränderlichkeits-Grundsatzes der Modelle, sodass alle Modelle ohne Datenverluste und Veränderung wiederhergestellt werden können. Damit ist auch gewährleistet, dass eine Model Prediction der Modellversion, die sie produziert hat, zugeordnet werden kann.

Überwachung und Alarmierung

Die Überwachung und Alarmierung muss automatisiert erfolgen, sodass wichtige Metriken kontinuierlich beobachtet und Abweichungen zeitnah festgestellt werden. Dieses Monitoring-System benötigt eine geeignete Plattform- und Infrastrukturintegration mit Dashboard und Monitoring Tools, eine laufende Überwachung der Betriebszeit-SLA als Metrik für die Stabilität und Verfügbarkeit der Anwendung und Alarm-Funktionalitäten bei aufgetretenen Problemen. Durch das Überwachungs- und Alarmierungssystem wird sichergestellt, dass produktive Modelle alle relevanten Anforderungen erfüllen.

Model Service Katalog

Der Model Service Katalog ist ein interner Marketplace aller ML-Modelle im Unternehmen. Der Katalog selbst sollte über eine gute UX verfügen, mit dem Ort der Modell-Abspeicherung verbunden sein und laufend die relevanten Metadaten für ein Modell wie die neueste Version, Eingaben und Ausgaben anzeigen. Mitarbeiter mit den entsprechenden Rechten können auf den Katalog zugreifen, Modelle suchen und Informationen über die benötigten Modelle abfragen. Auf diese Weise erleichtert der Katalog intern die Wiederverwend- und Nutzbarkeit von Modellen. Gleichzeitig erfüllt der Model Service Katalog auch eine Funktion nach außen: da er eine strukturierte Übersicht aller Services gibt, können sich potenzielle zukünftige Benutzer über das Leistungsspektrum der Modelle informieren.

Sicherheit

ML-Security ist ein wichtiger Punkt auf der Model-Governance Agenda. So schätzt die Gartner-Studie, dass bis 2022 30 Prozent der Cybersecurity Attacken ML-spezifischer Natur sein werden.

Um sich gegen diese Angriffe abzusichern, müssen Maßnahmen zur Erfüllung des Sicherheitsstandards ergriffen werden. Modelle können beispielsweise durch die Freigabe eines HTTP-Endpunktes zugänglich gemacht werden, wodurch gleichzeitig das Risiko der missbräuchlichen Nutzung entsteht. Daher ist die Einhaltung von IT-Standards (DNS, Proxies und Lastausgleiche für den Datenverkehr) so wichtig – doch diese Komplexität erfordert unter Umständen die Dienste spezialisierter Drittanbieter. Ein geeignetes Management muss die Endpunkte absichern (beispielsweise durch Token) und verwalten, sodass nur berechtigte Nutzer Endpunkte erstellen, bearbeiten oder löschen können. Die Authentifizierung, SSO und RBAC sind weitere wichtige Punkte auf der Security-Liste. ML-Modelle müssen in token-basierte Authentifizierungslösungen integriert werden, sodass nur berechtigte Nutzer Anfragen an das Modell stellen können. Zur Zugriffskontrolle braucht es auch eine rollenbasierte Zugriffskontrolle (RBAC), die Berechtigungen kontrolliert. Zur Sicherung der Infrastruktur muss auch diese über RBAC abgesichert werden. Zusätzlich sollte ein Schlüssel- und Secret-Management die Modelle mit einer Lösung zum Erstellen, Speichern und Verwalten aller Geheimnisse und Schlüssel integrieren. Schließlich müssen die Modelle einer Sicherheitsüberprüfung unterzogen werden. Auch aus diesem Grund ist es so wichtig, sich frühzeitig mit IT- und Betriebsexpert:innen abzustimmen, um alle Sicherheitsanforderungen in vollem Umfang zu berücksichtigen.

Dazu ist auch der Schutz gegen ML-spezifische Cybersecurity-Angriffe relevant. Daten- und Informationssicherheit spielen hier eine wichtige Rolle, da Modelle oft mit sensiblen Daten trainiert werden. Dazu kommt, dass feindliche Angriffe auf ML-Systeme häufig mit Daten arbeiten, sodass die Datensicherheit Unternehmen vor eine große Herausforderung stellt. Hier bietet sich die Adversarial ML Threat Matrix an. Diese Matrix ähnelt dem klassischen Attack Chain Modelling und baut auf dem etablierten MITRE Att&CK als weltweit zugängliche Wissensbasis über Taktiken und Techniken von Angriffen. MITRE Att&CK wird als Grundlage für die Entwicklung spezifischer Bedrohungsmodelle und -methoden im privaten Sektor, in der Regierung und in der Gemeinschaft der Cybersicherheitsprodukte und -dienstleistungen verwendet. Dieses Konzept greift die Adversarial ML Threat Matrix für ML Security auf: sie enthält eine Sammlung bekannter Schwachstellen und der dazugehörigen Angriffe und ist damit ein praktikables Framework für Sicherheit.

Konformität und Überprüfbarkeit

Für Modelle der Hochrisiko-Kategorie schreibt die EU im Entwurf eine Konformitätsprüfung und CE-Kennzeichnung vor. Um die Compliance- und Auditierbarkeitsanforderungen einer stark regulierten Domäne zu erfüllen und eine Konformitätsbescheinigung zu erhalten, muss das Model Governance-Framework möglichst automatisiert, transparent und vollständig sein. Doch auch Systeme außerhalb der Hochrisiko-Kategorie müssen eine Konformitätsprüfung bestehen, wenn sie eng an das unternehmerische Risiko gebunden sind. Zur nachweislichen Erfüllung der Konformität und Überprüfbarkeit sind die Modellprotokollierung, Metriken und Audits, die die Einhaltung der Vorgaben beweisen, von zentraler Bedeutung. Dazu zählen gesammelte und visuell aufbereitete Modellinformationen als Metriken in geeigneten Dashboards, Modell- und Datenversionierungen und Ergebnisse der Audits (geprüfte Komponenten der Validation in der Development-Phase). Aber auch die Erfüllung der Security-Anforderungen muss nachgewiesen werden. Berechtigungen und Zugänge zur ML-Anwendung müssen ebenso wie funktionierende rollenbasierte Authentifizierungen vorliegen. Jede Domäne unterliegt anderen Regulierungen, die unterschiedlich streng ausfallen. Konformität und Überprüfbarkeit sind sehr komplex und erfordern oft jahrelange Expertise. Umso wichtiger ist es, Compliance- und Sicherheitsexperten von Beginn an in die Model Governance-Strategie einzubeziehen, sodass keine Lücken entstehen.

Variante 2: Viele Modelle und geringe Regulierung

Geringe Regulierung liegt vor, wenn die Domäne nicht stark reguliert, das ML-Modell nicht in eine hohe Risiko-Kategorie fällt und das verbundene Unternehmensrisiko gering ist. Aber auch hier kommen Unternehmen nicht ohne grundlegende Model Governance aus, da die hohe Anzahl der Modelle verwaltet werden muss. Gleichzeitig liegt hier der Fokus auf Operationalisierung: viele Modelle benötigen effizientes MLOps.

Aus der schwachen Regulierung und dem Fokus auf MLOps ergibt sich, dass Model Governance in dieser Variante ein Teil von MLOps ist und kein eigenständiges Framework wie in der zuvor vorgestellten Variante. Um zu verstehen, wie Model Governance in MLOps integriert werden kann, ist ein Überblick über MLOps hilfreich. Das Google-Paper „Practitioners guide to MLOps: A framework for continuous delivery and automation of machine learning“ unterteilt MLOps in sechs integrierte und iterative Prozesse: ML Development, Training Operationalization, Continuous Training, Model Deployment, Prediction Serving, Continuous Monitoring sowie Data and Model Management. Wir stützen uns auf dieses MLOps-Framework, um die Integration von Model Governance und MLOps für die zweite Variante vieler Modelle und geringer Regulierung darzulegen.

Die ML-Development-Phase endet nicht mit einem fertigen Modell, sondern der Implementierung einer Trainings-Pipeline. Stehen neue Daten zur Verfügung oder wird ein Leistungsabfall des Modells festgestellt, wirkt das als Trigger, der die (kontinuierliche) Trainings-Pipeline anstößt. Das Modell durchläuft ein Re-Training und soll dann erneut in Produktion gehen. Damit besteht die Trainings-Pipeline aus einer Data-Engineering-Komponente (Dateneingabe, Datenvalidierung, Datentransformation) und einer Modell-Komponente (Modelltraining, Modellevaluation, Modellvalidation), wobei die Trainings-Pipeline selbst versioniert und getestet werden muss. Zu Trainingsbeginn werden aus dem Data Repository neue Trainingsdaten geladen. Data- und Feature-Repositories vereinheitlichen die Definition und Speicherung der Daten, gewährleisten Datenkonsistenz für Training und Inferenz und verkürzen die Abläufe von Data-Pre-Processing sowie Feature-Engineering. Die Daten durchlaufen alle Schritte des Data Engineering-Prozesses und werden dann genutzt, um das Modell zu re-trainieren. Nach dem Training wird das Modell evaluiert und nach Prüfung aller Performance-Metriken als Modell-Kandidat im Modell-Register gespeichert. Alle Metadaten und Artefakte, die während des Trainingsdurchlaufes entstehen, werden im ML Metadata & Artifact Repository gespeichert. Zu den ML-Artefakten gehören beispielsweise Statistiken und Datenschemata, trainierte Modelle und Metriken; ML-Metadaten sind die Informationen über diese Artefakte (Pipeline-Lauf-ID, Auslöser, Prozesstyp, Schritt, Start- und Endzeitpunkt, Status, Umgebungskonfigurationen und Eingabeparameterwerte).

Modell-Register verwalten den Lebenszyklus von ML-Modellen. Nach der Registrierung im Register wird durch Model Governance-Prozesse in verschiedenen Schritten überprüft, ob der Modell-Kandidat ins produktive System deployed wird (Model Deployment). Nach erfolgtem Deployment gibt das Modell Predictions für jeden Input ab (Prediction Serving). Model Governance überwacht die Performance des produktiven Systems laufend (Continuous Monitoring) und sammelt sämtliche relevanten Metriken in einem Bericht (beispielsweise Accuracy). Durch das Monitoring werden Leistungsabfälle oder sich verändernde Input-Daten sofort diagnostiziert und das Re-Training angestoßen - der Kreislauf beginnt von vorne.

Model Governance als Teil des Modell-Managements

Model Governance umfasst die Registrierung, Überprüfung, Validierung, Genehmigung und Überwachung von Modellen für das Deployment und ist die letzte Kontrollinstanz, die ein Modell durchlaufen muss, bevor es in die Produktivumgebung deployed werden darf. Die Liste fasst die Model Governance-Komponenten mit den benötigten Aufgaben und Artefakten zusammen. Zur Umsetzung dieser Aufgaben greift Model Governance auf Informationen aus den ML-Metadaten, dem Artefakt-Repository und dem Modellregister zurück.

• Speicherung/ Versionierung von Modellen
• Auswertung und Erklärbarkeit
• Prüfung
• Freigabe
• Bericht (Zusammenfassung, Visualisierung, Hervorhebung von Metriken) zur Qualitätssicherung des produktive Modells

Die Speicherung und Versionierung von Modellen beinhaltet das Hinzufügen oder Aktualisieren von Modelleigenschaften sowie das Tracken von Modellversionen und Eigenschaftsänderungen. Dazu speichert die Model Registry alle Modellversionen, um Reproduzier- und Nachvollziehbarkeit zu gewährleisten (ähnlich der Modellversionierung in der Komponente „Beobachtung und Kontrolle von Model Governance“).

Die Auswertung und Erklärbarkeit spielt eine zweite wichtige Rolle. Hier wird ein Modell mit einem bereits in der Produktion laufenden Modell durch Sammlung von Metriken und mit Business-KPIs verglichen (ähnlich der Validierung der Development-Phase).

Die Prüfung ist ein elementarer Bestandteil: hier müssen Änderungen überprüft und genehmigt werden, um Risiken verschiedener Kategorien zu kontrollieren (beispielsweise geschäftliche, finanzielle, rechtliche, sicherheitstechnische, datenschutzrechtliche, reputationsbezogene und ethische Risiken), wie in diesem End-to-End-Framework zur internen Prüfung von Algorithmen beschrieben. Diese Komponente entspricht einer weniger strengen Variante der Konformitätsbescheinigung.Die Freigabe regelt die Steuerung des Modell-Deployments und kontrolliert den Datenverkehr, der an das Modell geleitet wird. Hier wird besonders deutlich, wie Model Governance und MLOPs zusammenspielen: das automatisierte Deployment ist an die Erfüllung der Model-Governance-Aufgaben gebunden.

Schließlich trägt ein Bericht die Zusammenfassung, Visualisierung und Hervorhebung von Modellleistungsmetriken, die während des Überwachungsprozesses gesammelt werden, zusammen.

Variante 3: Wenige Modelle und geringe Regulierung

Die Konstellation trifft für Unternehmen zu, die abseits regulierter Branchen Modelle entwickeln, die nicht zur Hochrisiko-Kategorie nach dem Entwurf gehören und deren Einsatz kein hohes Unternehmensrisiko birgt. Die geringe Anzahl an ML-Modellen kann entweder bedeuten, dass ML keine zentrale Rolle in der Geschäftsstrategie des Unternehmens spielt oder dass Unternehmen noch in der Experimentierphase der ML-Entwicklung sind.

Wenige Modelle in Kombination mit schwacher Regulierung sind der simpelste Fall, da der Umfang der Regularien und die Anzahl der Modelle überschaubar ist. Durch das Fehlen von Auflagen und der geringen Anzahl der Modelle ist Model Governance zwar optional, für die Gewährleistung hoher technischer Qualität aber dennoch empfehlenswert: die Komponenten der Development-Phase sind auch für dieses Szenario relevant.

Variante 4: Wenige Modelle und starke Regulierung

Setzen Unternehmen wenige Modelle in stark regulierten Bereichen ein, unterscheidet sich dieses Szenario von Variante 1 nur durch die geringe Anzahl der Modelle. Da weniger Modelle verwaltet werden müssen, ist MLOps weniger umfangreich als in Szenarien, in denen viele Modelle eingesetzt werden. Die Integration des Model Governance-Frameworks mit MLOps bleibt aber unverändert: in stark regulierten Domänen muss Model Governance den kompletten MLOps-Lifecycle abdecken, auch wenn nur wenige Modelle eingesetzt werden (siehe Variante 1).

Zusammenfassung - Die Hauptkomponenten von Model Governance

Obwohl die Stärke der Regulierung und die Anzahl der Modelle festlegen, wie Model Governance umgesetzt werden sollte, findet sich mit Ausnahme des dritten Szenarios ein kleinster Nenner technischer Artefakte:

• Vollständige Modell-Dokumentation oder Berichte. Dazu gehört auch das Reporting der Metriken durch geeignete Visualisierungstechniken und Dashboards
• Versionierung aller Modelle zur Herstellung von Transparenz nach außen (Erklär- und Reproduzierbarkeit)
• Prüfungsprozesse (automatisierte Freigabe-Prüfung oder CE-Zertifizierung im Zuge einer Konformitätsprüfung)
• Vollständige Daten-Dokumentation zur Gewährleistung hoher Datenqualität und Einhaltung des Datenschutzes
• Management von ML-Metadaten
• Validierung von ML-Modellen
• Laufende Überwachung und Protokollierung von Modell-Metriken