Model Risk Management

Model Risk Management im Überblick

Model Risk Management identifiziert und kontrolliert Risiken von ML-Modellen – bevor sie Schaden anrichten.

Risiko-Kategorien:

Technisch betrachtet

MRM-Framework

1. Inventar
   └── Alle Modelle dokumentieren

2. Risiko-Assessment
   └── Kritikalität bewerten

3. Validierung
   └── Vor Go-Live prüfen

4. Monitoring
   └── Laufende Überwachung

5. Governance
   └── Rollen, Prozesse, Audits

Risiko-Klassifizierung

Der regulatorische Rahmen

Model Risk Management stammt ursprünglich aus der Bankenaufsicht: Leitlinien wie SR 11-7 der US-Notenbank definieren seit Jahren, wie Finanzinstitute Modellrisiken managen müssen – unabhängige Validierung, Dokumentation, klare Verantwortlichkeiten. Mit dem EU AI Act wird dieser Ansatz auf KI generell übertragen: Hochrisiko-KI-Systeme brauchen ein Risikomanagementsystem über den gesamten Lebenszyklus, technische Dokumentation und menschliche Aufsicht.

Für die Praxis heißt das: Wer heute ein sauberes MRM aufbaut, erfüllt einen großen Teil der kommenden Compliance-Anforderungen nebenbei.

Die drei Verteidigungslinien

Bewährtes Organisationsmodell aus der Finanzwelt, das sich auf ML überträgt:

1. First Line – die Modellentwickler und Product Owner: bauen, testen und betreiben das Modell, dokumentieren Annahmen und Grenzen.
2. Second Line – unabhängige Validierung und Risk-Funktion: prüft das Modell kritisch, bevor es live geht, und überwacht Limits im Betrieb.
3. Third Line – interne Revision: prüft, ob der gesamte MRM-Prozess funktioniert und gelebt wird.

Entscheidend ist die Unabhängigkeit der zweiten Linie: Wer ein Modell gebaut hat, sollte es nicht selbst abnehmen.

Besonderheiten bei LLMs und generativer KI

Klassisches MRM prüft deterministische Vorhersagemodelle. Generative Modelle bringen neue Risikoklassen mit, die das Framework erweitern:

• Halluzinationen: Das Modell erzeugt überzeugende Falschaussagen – klassische Accuracy-Metriken greifen nicht.
• Prompt Injection: Angreifer manipulieren das Modellverhalten über Eingaben statt über Trainingsdaten.
• Nicht-Determinismus: Gleiche Eingabe, unterschiedliche Ausgaben – Validierung braucht statistische statt exakter Tests.
• Lieferantenrisiko: Bei API-Modellen ändert der Anbieter das Verhalten per Modell-Update, ohne dass das eigene Team etwas deployed hat – Regression-Tests gegen die API werden Pflicht.

Typische Fehler in der Praxis

• MRM als einmaliges Projekt statt als laufenden Prozess behandeln – Drift macht jede Validierung nach Monaten wertlos.
• Nur technische Metriken prüfen und Fachbereich/Recht erst nach dem Go-Live einbinden.
• Das Modell-Inventar veralten lassen: Schatten-Modelle in Fachabteilungen sind das häufigste Audit-Finding.