Governance-Strukturen, die mit Modellveränderungen Schritt halten

# Governance-Strukturen, die mit Modellveränderungen Schritt halten

Ein Modell zur Schadenhöhe besteht im Januar sein Launch-Audit. Bis Juni haben sich drei Dinge unbemerkt verändert: der Mix der gemeldeten Schäden (mehr Hagelschäden, weniger Kollisionen), ein Vendor hat upstream seine Geocoding-APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.Vollständige Definition ansehen → aktualisiert, und eine neue Regulierung auf Staatsebene verlangt eine Fairness-Offenlegung, für die das Modell nie gebaut wurde. Niemand hat etwas davon gemeldet, weil niemand dafür zuständig war, hinzusehen. So werden compliant AI-Systeme non-compliant, ohne dass eine einzige Codezeile geändert wurde.

Die Lösung ist nicht ein besseres Audit. Es ist eine Governance-Maschinerie, die kontinuierlich läuft, nicht einmalig.

Warum Compliance am Launch-Tag nicht ausreicht

AI-Modelle in der Versicherung sind nicht statisch. Sie unterliegen Model Drift, einer allmählichen Verschlechterung der Prognosegüte, wenn die realen Daten von den Trainingsdaten abweichen. Ein Pricing-Modell, das auf Schadendaten von 2022-2023 trainiert wurde, beginnt Risiken falsch einzuschätzen, sobald sich Inflation, Klimamuster oder Fahrverhalten verschieben.

Die Regulatoren haben diese Realität eingeholt. Der AI Act der EU (seit 2024 in Kraft, mit gestaffelten Pflichten bis 2026-2027) klassifiziert die meisten Pricing- und Underwriting-Modelle in der Versicherung als „hochriskant", was laufende und nicht nur vormarktliche Pflichten auslöst: kontinuierliches Monitoring, Logging und menschliche Aufsicht über den gesamten Lebenszyklus des Modells (Überblick der Europäischen Kommission zum AI Act).

In den USA verlangt das NAIC Model Bulletin on the Use of AI Systems by Insurers (von den meisten Bundesstaaten bis 2024-2025 übernommen) ausdrücklich, dass Versicherer ein funktionierendes AI-Governance-Programm nachweisen, nicht eine einmalige Prüfung. Versicherungsaufsichten einzelner Bundesstaaten, darunter Kalifornien und Colorado, fordern diese Governance-Artefakte inzwischen bei Market-Conduct-Prüfungen an.

Die Botschaft von beiden Seiten des Atlantiks: Belegen Sie, dass Ihre Aufsicht lebt und nicht archiviert ist.

Die Kernmaschinerie: drei Komponenten

1. Model-Risk-Komitees

Ein Model-Risk-Komitee ist ein ständiges, cross-funktionales Gremium (Aktuariat, Compliance, IT, Recht und zunehmend ein Data-Ethics-Verantwortlicher), das AI-Modelle nach einem festen Zeitplan prüft, nicht nur vor dem Launch.

Konkretes Mandat: Prüfung jedes hochriskanten Modells quartalsweise, jedes Modells mit mittlerem Risiko halbjährlich. „Hochriskant" heißt hier: Modelle, die eine Pricing-, Underwriting- oder Schadenentscheidung für einzelne Verbraucher wesentlich beeinflussen, analog zur Risikostufung des AI Act selbst.

Komitees sollten sich ansehen:

• Performance Drift gegenüber der Baseline (Accuracy, Kalibrierung)
• Fairness-Metriken über geschützte Gruppen hinweg (Alter, Race-Proxys, Behinderungsstatus, Postleitzahl als Proxy-Variable)
• Volumen an Beschwerden und Widersprüchen zu modellgetriebenen Entscheidungen
• Vendor-Änderungen (z. B. ein Drittanbieter für Telematik-Scores, der seinen Algorithmus aktualisiert)

Das spiegelt das Modell der three lines of defense, das im Bankenrisikomanagement lange etabliert ist: der Model Owner (erste Linie), eine unabhängige Model-Risk-/Compliance-Funktion (zweite Linie) und die interne Revision (dritte Linie). Versicherer wie Allianz und AXA haben öffentlich beschrieben, wie sie diese Struktur speziell für AI-Governance angepasst haben.

2. Version-Control-Logs

Jedes Modell, das in Produktion läuft, braucht ein Version-Control-Log: eine mit Zeitstempel versehene Aufzeichnung darüber, was sich geändert hat, warum, wer es genehmigt hat und welche Tests vor dem Release durchgeführt wurden.

Das ist keine optionale Buchhaltung. Nach dem EU AI Act müssen Anbieter hochriskanter AI technische Dokumentation und Logs vorhalten, die einem Regulator ausreichen, um die Entscheidungslogik des Modells im Nachhinein zu rekonstruieren. Ohne Versionierung kann ein Versicherer ein Jahr später buchstäblich nicht beantworten: „Welches Modell hat diese Schadenablehnung im März getroffen?"

Ein minimaler Log-Eintrag sollte erfassen:

model_id: claims_severity_v4.2
deployed_date: 2026-03-14
change_summary: retrained on 2023-2025 claims data; added 2 new features
approved_by: model_risk_committee (ref: MRC-2026-011)
validation_results: AUC 0.81 (prior: 0.79); fairness delta <2% across tested groups
rollback_plan: revert to v4.1, tested rollback time 12 min

Das ist das AI-Äquivalent eines Flugdatenschreibers. Wenn etwas schiefgeht (ein Anstieg der Beschwerden, eine Anfrage der Aufsicht), ist das Log das Erste, was geprüft wird.

3. Retraining-Trigger

Die schwierigste Governance-Frage: Wann trainieren Sie ein Modell neu? Auf die Jahresprüfung zu warten ist zu langsam; bei jedem Datenausschlag neu zu trainieren ist verschwenderisch und destabilisierend.

Die Antwort sind vordefinierte Retraining-Trigger: quantitative Schwellen, die im Vorfeld festgelegt werden, damit die Entscheidung keine Ermessensfrage unter Druck ist.

In der Praxis übliche Trigger:

• Performance-Verfall: ein Rückgang der Modell-Accuracy (z. B. AUC fällt um mehr als 3-5 Prozentpunkte gegenüber der Baseline), der über zwei aufeinanderfolgende Monitoring-Perioden anhält
• Population Drift: eine statistische Verschiebung der Verteilung der Eingangsdaten, häufig gemessen mit einem Population Stability Index (PSI); ein PSI über 0,25 ist eine verbreitete Daumenregel der Branche für „signifikanten Drift", der Handeln erfordert
• Externer Trigger: ein neues Gesetz (z. B. ein Bundesstaat, der kreditbasierte Versicherungsscores verbietet), ein Katastrophenereignis, das Risikomuster verändert (eine schwere Hurrikan-Saison), oder ein Vendor, der einen Data Feed einstellt
• Fairness-Trigger: eine Disparate-Impact-Ratio, die eine festgelegte Schwelle überschreitet (häufig referenziert: die „four-fifths rule" aus dem US-Arbeitsrecht, informell teils auf Fairness-Tests in der Versicherung übertragen)

Durchgerechnetes Beispiel: Ein Kfz-Versicherer setzt eine PSI-Schwelle von 0,25 für die Verteilung seines Risikoscores. Nach einem Ölpreisschock, der das Fahrverhalten verändert, zeigt die Quartalsprüfung einen PSI von 0,31. Diese einzelne, automatisch berechnete Zahl löst laut interner Richtlinie des Versicherers innerhalb von 10 Arbeitstagen eine verpflichtende Prüfung durch das Model-Risk-Komitee aus. Keine Debatte darüber, ob man hinsehen soll. Nur eine terminierte Reaktion.

Alles zusammengesetzt: ein Governance-Kalender

Versicherer, die das gut machen, arbeiten mit etwas, das eher einem wiederkehrenden Compliance-Kalender gleicht als einem einzelnen Audit-Ereignis:

| Frequenz | Aktivität |

|---|---|

| Kontinuierlich (automatisiert) | Drift- und PSI-Monitoring, Dashboards für Fairness-Metriken |

| Monatlich | Prüfung von Beschwerden/Widersprüchen zu Modellentscheidungen |

| Quartalsweise | Prüfung hochriskanter Modelle durch das Model-Risk-Komitee |

| Halbjährlich | Prüfung der Modelle mit mittlerem Risiko; Re-Zertifizierung von Vendor-Modellen |

| Jährlich | Vollständige unabhängige Validierung, Aktualisierung der regulatorischen Meldung |

| Ereignisgesteuert | Überschreiten eines Retraining-Triggers, neue Regulierung, großererThe ratio of interactions (likes, comments, shares) to reach for a given piece of content, used to gauge how well audiences respond relative to how many people saw it.Vollständige Definition ansehen → externer Schock |

Diese Struktur beantwortet auch eine Frage, die Regulatoren zunehmend direkt stellen: „Zeigen Sie mir Ihr Governance-Framework-Dokument", nicht nur „Zeigen Sie mir die Accuracy Ihres Modells". Die britische Prudential Regulation Authority und die Financial Conduct Authority haben in ihrer gemeinsamen Arbeit zu AI in Financial Services die gleiche Erwartung signalisiert (Bank of England AI Survey), auch ohne ein UK-spezifisches AI-Gesetz analog zum EU AI Act.

Typische Failure Modes, gegen die Sie sich absichern sollten

• Governance nur auf Papier: Eine Komitee-Charta existiert, aber das Gremium hat sich seit einem Jahr nicht getroffen. Regulatoren prüfen Sitzungsprotokolle, nicht nur Chartas.
• Kein Owner für Third-Party-Modelle: Ein Versicherer kauft ein Fraud-Detection-Modell von einem Vendor und geht davon aus, dass die Compliance des Vendors ihn abdeckt. Tut sie nicht; der Versicherer, der das Modell nutzt, bleibt nach NAIC- und EU-Frameworks in der Regel verantwortlich.
• Trigger gesetzt, aber nicht befolgt: Eine PSI-Überschreitung wird geloggt, aber keine Komitee-Prüfung folgt. Das ist schlechter als kein Trigger, weil es einen Papierweg schafft, der Untätigkeit beweist.
• Version-Logs ohne Narrativ: Zu loggen, dass „v4.2 deployed" wurde, ohne das *Warum* festzuhalten, macht das Log für eine tatsächliche Audit-Rekonstruktion unbrauchbar.

🎬 [VIDEO: "Model Risk Management Explained" - youtube.com/results?search_query=model+risk+management+explained - ein Durchgang durch das Three-Lines-of-Defense-Framework angewandt auf Prognosemodelle, nützlicher Hintergrund, bevor Sie es auf AI-spezifische Trigger übertragen]

Key Takeaways

• Compliance ist eine Eigenschaft des Lebenszyklus, kein Zertifikat vom Launch-Tag; sowohl der EU AI Act als auch das NAIC Model Bulletin verlangen kontinuierliche Aufsicht, nicht eine einmalige Prüfung.
• Ein Model-Risk-Komitee braucht eine feste Prüffrequenz (quartalsweise für hochriskante Modelle ist ein vernünftiger Default) und cross-funktionale Besetzung: Aktuariat, Compliance, IT, Recht.
• Version-Control-Logs müssen das „Warum" erfassen, nicht nur das „Was", damit eine Entscheidung Monate oder Jahre später bei einer Anfrage der Aufsicht rekonstruiert werden kann.
• Retraining-Trigger sollten quantitativ und vorab vereinbart sein (z. B. PSI über 0,25, AUC-Rückgang über eine festgelegte Schwelle), damit Retraining-Entscheidungen nicht reaktiv unter Druck getroffen werden.
• Das größte Problem in der Praxis ist nicht ein fehlendes Framework, sondern eines, das auf Papier existiert, aber bei Überschreiten der Schwellen keine Handlung auslöst.