Wo KI-Modelle in der Produktion still und leise versagen

# Wo KI-Modelle in der Produktion still und leise versagen

Im September 2022, wenige Tage nach dem Landfall von Hurrikan Ian in Florida, begannen die Betrugs- und Schadenhöhemodelle mehrerer Versicherer, legitime Schadenmeldungen als verdächtig einzustufen. Am Code hatte sich nichts geändert. Geändert hatte sich die Welt: Schadenmuster nach einer Katastrophe sehen statistisch wie Betrugsmuster aus (schnelle Meldung, hohe Beträge, geclusterte Standorte), auch wenn sie es nicht sind. Die Modelle waren für dieses Regime nicht neu trainiert worden. Das ist kein Bug. Es ist eine Risikokategorie, die in einem üblichen Accuracy-Report nie auftaucht.

Diese Lektion entwickelt eine praktikable Taxonomie dafür, wo KI-Modelle in der Versicherung nach dem Deployment versagen, und welche Checks jedes dieser Versagen auffangen, bevor es Geld kostet oder eine aufsichtsrechtliche Feststellung auslöst.

Warum „Accuracy“ die falsche erste Frage ist

Ein Modell kann in der Validierung 95 % Accuracy erreichen und trotzdem unsicher sein. Accuracy ist ein Durchschnitt über eine Verteilung, die nicht mehr existiert, sobald das Modell live geht. Drei versicherungsspezifische Failure Modes erklären das:

1. Feature Drift nach Schockereignissen. Katastrophenereignisse (Hurrikane, Waldbrände, Pandemien) verschieben die statistische Beziehung zwischen Inputs und Outcomes. Ein Betrugsmodell, das auf der Schadenfrequenz „normaler Zeiten“ trainiert wurde, behandelt einen legitimen Anstieg nach einem Hurrikan als Anomalie. Das nennt man Covariate Shift: Die Input-Verteilung ändert sich, obwohl dem Modell die zugrunde liegende Labeling-Logik nicht neu beigebracht wurde.

2. Proxy-Diskriminierung. Ein Pricing- oder Underwriting-Modell verwendet Ethnie oder eine geschützte Klasse nicht explizit, aber eine korrelierte Variable (kreditbasierter Versicherungsscore, Postleitzahl, Bildungsniveau) rekonstruiert dasselbe Signal. Regulierer in den USA (die Versicherungsaufsichten der Bundesstaaten, unter den Model Bulletins der NAIC, National Association of Insurance Commissioners) und in der EU (AI Act, 2024 in Kraft getreten, die Hochrisiko-Klassifizierung deckt wahrscheinlich viele Pricing- und Claims-Anwendungen in der Versicherung ab) weisen beide ausdrücklich darauf hin. Kreditbasierte Scores sind ein bekanntes Proxy-Risiko, weil Kredithistorie mit Ethnie und Einkommen auf Weisen korreliert, die Versicherer nicht beabsichtigen, aber auch nicht vollständig herausfiltern kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen. Die regulatorische Einordnung finden Sie in den AI-Model-Bulletin-Materialien der NAIC.

3. Stille Degradation. Die Performance eines Modells verfällt allmählich, nicht mit einem Crash. Ein Fraud-Scoring-Modell verliert über 18 Monate an Precision, weil sich Betrugstaktiken weiterentwickeln (neue Staged-Accident-Schemata, synthetische Identitäten), aber niemand merkt es, weil das Modell weiterhin Scores zurückgibt und Schäden weiterhin bearbeitet werden. Kein Alert feuert, weil im IT-Sinne nichts „kaputt“ ist.

Eine praktikable Taxonomie des Modellrisikos

Gruppieren Sie diese Failures in vier Buckets, entlehnt und adaptiert aus Model-Risk-Management-Frameworks (MRM) aus dem Bankenbereich (siehe die SR 11-7 Guidance der Federal Reserve, der Referenzstandard auch außerhalb des Bankensektors):

| Risikotyp | Wie es in der Versicherung aussieht | Erkennungssignal |

|---|---|---|

| Datenrisiko | Feature Drift nach Katastrophen, veraltete Kreditdaten, Lücken bei Sensor-/Telematikdaten | Verteilungsverschiebung der Input-Features gegenüber der Trainings-Baseline |

| Fairness-/Proxy-Risiko | Kreditscore, Postleitzahl oder Beruf rekonstruieren das Signal einer geschützten Klasse | Disparate-Impact-Ratio, Outcome-Audits nach Subgruppen |

| Risiko des Performance-Verfalls | Betrugsmodell verliert Precision, während sich Taktiken ändern; Churn-Modell veraltet nach einer Produktänderung | Rollierende Precision/Recall über Zeit, Kalibrierungsdrift |

| Governance-/Prozessrisiko | Kein dokumentierter Owner, kein Retraining-Trigger, Vendor-Modell als Black Box behandelt | Fehlender Eintrag im Modellinventar oder fehlende Review-Kadenz |

Jeder Bucket braucht einen anderen Check. Accuracy-Metriken allein erfassen (teilweise) nur Bucket 3, und das erst, wenn der Schaden entstanden ist.

Konkretes Beispiel: Proxy-Diskriminierung beim kreditbasierten Scoring

Kreditbasierte Versicherungsscores sind im US-Kfz- und Wohngebäude-Underwriting weit verbreitet, in einigen Bundesstaaten verboten oder eingeschränkt (Kalifornien, Massachusetts und Hawaii untersagen ihre Verwendung im Kfz-Pricing, nach jüngerem Landesrecht; prüfen Sie den aktuellen Stand je Bundesstaat, da sich das verschiebt). Der Mechanismus:

• Kredithistorie korreliert mit Einkommen, und Einkommen korreliert aufgrund historischer und struktureller Faktoren mit Ethnie, ohne Bezug zum Fahrrisiko.
• Ein Modell, das auf Minimierung der Schadenquote trainiert ist, greift das Kreditsignal auf, weil es prädiktiv ist, ohne zu „wissen“, dass es ein Proxy ist.
• Ergebnis: Eine dem Anschein nach neutrale Variable erzeugt einen Disparate Impact auf geschützte Gruppen, angreifbar über Fair-Lending-Analogien, die von den Aufsichten der Bundesstaaten auf Versicherungen angewendet werden, und im Prinzip nach EU-Antidiskriminierungsrecht.

Ein einfacher durchgerechneter Check: die Four-Fifths-Rule (entlehnt aus dem US-Arbeitsdiskriminierungsrecht, EEOC-Guidance) als erstes Screening.

selection_rate(group_A) = approved_A / applicants_A
selection_rate(group_B) = approved_B / applicants_B
impact_ratio = min(selection_rate_A, selection_rate_B) / max(selection_rate_A, selection_rate_B)

# Daumenregel: impact_ratio < 0.80 markiert den Fall für ein tieferes Fairness-Review

Das ist eine Screening-Heuristik, kein rechtlicher Safe Harbor. Sie sagt Ihnen, wo Sie hinschauen sollen, nicht ob Sie compliant sind. Eine Ratio von 0,78 in einer Pricing-Stufe sollte vor dem Deployment einen vollständigen Subgruppen-Audit auslösen, kein Pass/Fail-Urteil.

Das Katastrophen-Drift-Problem, mechanisch betrachtet

Warum bricht ein Betrugsmodell speziell nach einem Hurrikan ein? Weil seine Trainingsdaten eine Welt kodieren, in der gilt:

• Hohe Schadenfrequenz in einem kurzen Zeitfenster = verdächtig
• Mehrere Schäden aus demselben geografischen Cluster = verdächtig
• Schäden, die von öffentlichen Schadenregulierern gebündelt eingereicht werden = verdächtig

Nach Ian, Ida oder einer beliebigen großen Katastrophe werden alle drei *normal*. Das Modell hat kein Konzept von „ausgewiesenem Katastrophengebiet“, es sei denn, jemand hat dieses Feature explizit gebaut und neu trainiert.

Die Checks, die das vor dem Deployment oder vor dem Schaden auffangen:

1. Szenario-Stresstests. Testen Sie das Modell vor dem Go-live gegen eine synthetische Schadenverteilung nach einer Katastrophe, nicht nur gegen historische Validierungsdaten.

2. Feature-Monitoring mit Drift-Alarmen. Verfolgen Sie wöchentlich die statistische Verteilung (nicht nur den Mittelwert) der wichtigsten Inputs; Alarm, wenn sie eine definierte Toleranz verlässt (z. B. Population Stability Index über 0,25).

3. Ein „Disaster Mode“-Override. Viele erfahrene Versicherer bauen heute ein explizites Katastrophen-Flag ein, das das Modellverhalten ändert oder Schäden während ausgewiesener Ereignisse an die menschliche Prüfung routet, statt dem Basismodell zu vertrauen.

Guardrails vor dem Deployment: eine praktische Checkliste

Model Risk Management in der Versicherung konvergiert auf einige nicht verhandelbare Gates vor dem Deployment, die sich in den Model-Governance-Prinzipien der NAIC und in den Anforderungen des EU AI Act an Hochrisikosysteme wiederfinden (Dokumentation, menschliche Aufsicht, Logging, Accuracy-/Robustheitstests):

• Eintrag im Modellinventar: Jedes Modell in Produktion hat einen benannten Owner, einen dokumentierten Zweck und ein Review-Datum. Keine Ausnahmen für Vendor-/Black-Box-Modelle (genau hier haben viele Versicherer Lücken, die Fraud- oder Telematik-Scoring-Tools von Dritten nutzen).
• Subgruppen-Performance-Audit: Testen Sie Accuracy, False-Positive-Rate und Genehmigungsquote aufgeschlüsselt nach geschützten und quasi-geschützten Klassen, nicht nur aggregiert.
• Drift-Monitoring-Plan: Definieren Sie, wie eine „normale“ Input-Verteilung aussieht und was ein Retraining oder eine menschliche Prüfung auslöst.
• Explainability-Artefakt: Ein Schadenregulierer oder ein Regulierer kann eine Begründung in einfacher Sprache für einen bestimmten Score oder eine Entscheidung erhalten (relevant für die Transparenzpflichten des EU AI Act und für die Adverse-Action-Notice-Anforderungen auf Ebene der US-Bundesstaaten, die deutlich älter sind als KI und aus dem Fair-Credit-Recht stammen).
• Kill Switch / Rollback-Plan: ein dokumentierter, getesteter Weg, auf das Vormodell oder einen manuellen Prozess zurückzugehen, wenn das neue Modell nach dem Launch aus dem Ruder läuft.

Nichts davon ersetzt aktuarielle oder Accuracy-Tests. Es kommt daneben.

🎬 [VIDEO: „Algorithmic Bias in Insurance Pricing“ - youtube.com/results?search_query=algorithmic+bias+insurance+pricing+NAIC - suchen Sie nach aktuellen NAIC- oder Branchen-Paneldiskussionen zu Proxy-Diskriminierung in Underwriting-Modellen, ein nützlicher visueller Durchgang, wie Proxys entstehen]

Key Takeaways

• Accuracy-Metriken messen die Vergangenheit, nicht das Produktionsrisiko. Ein Modell kann die Validierung bestehen und im Deployment dennoch an Feature Drift, Proxy-Diskriminierung oder stiller Degradation scheitern, und keines davon zeigt eine einzelne Accuracy-Zahl.
• Feature Drift nach Katastrophenereignissen ist ein bekanntes, wiederkehrendes Failure-Muster in Fraud- und Claims-Modellen; die Lösung sind Szenario-Stresstests plus ein explizites „Disaster Mode“-Handling, nicht nur ein Retraining im Nachhinein.
• Proxy-Diskriminierung versteckt sich in scheinbar neutralen Variablen wie kreditbasierten Scores oder Postleitzahlen; die Four-Fifths-Rule ist eine nützliche Screening-Heuristik, keine Compliance-Garantie, deshalb sind tiefere Subgruppen-Audits erforderlich.
• Stille Degradation hat kein Crash-Signal. Sie erfordert aktives rollierendes Performance-Monitoring (Precision, Recall, Kalibrierung über Zeit), weil Sie standardmäßig nichts alarmiert.
• Governance ist ein Deployment-Gate, kein Papierkram: Modellinventar, Subgruppen-Audits, Drift-Monitoring, Explainability und Rollback-Pläne sollten alle vor dem Go-live existieren, abgestimmt auf die NAIC-Guidance in den USA und die Anforderungen des EU AI Act an Hochrisikosysteme.