KI-gestützte Risikomodellierung

Das echte Ausmaß des Problems

Klassische aktuarielle Risikomodelle in der Versicherung arbeiten mit Merkmalgruppen: Alter, Geschlecht (wo erlaubt), Region, Fahrzeugklasse, Beruf, Schadenhistorie. Diese Merkmale sind bewährt, aber sie sind oft grob, und grobe Risikogruppen führen zu einer bekannten Dysfunktionalität: Adverse Selection. Gute Risiken zahlen mehr als sie sollten, schlechte zahlen weniger. Die guten Risiken wechseln zu günstigeren Wettbewerbern, die schlechten bleiben. Das Portfolio verschlechtert sich langsam.

Während klassische GLM-Modelle (Generalized Linear Models) mit 10 bis 30 Prädiktoren arbeiten, können Machine Learning-Methoden wie Gradient Boosting Hunderte von Variablen verarbeiten und nicht-lineare Zusammenhänge erkennen, die ein klassisches Regressionsmodell verpasst.

Laut Solvency-II-Studien können bessere Schadenprognosemodelle die Required-Capital-Anforderungen eines Versicherers um 5 bis 15 Prozent reduzieren, ein erheblicher finanzieller Hebel. Nach Deloitte-Prognosen (2025) könnten globale P&C-Versicherer durch KI-gestützte Betrugserkennung und präzisere Risikomodellierung 80 bis 160 Milliarden Dollar bis 2032 einsparen.

Mit vs. ohne KI, ein ehrlicher Vergleich

Einschätzung auf einen Blick

Zeitersparnis, sehr niedrig (1/5) KI-Risikomodellierung spart keine Arbeitszeit in der Sachbearbeitung oder Kundenkommunikation. Der Nutzen liegt vollständig in der verbesserten Portfoliomarge und Kapitaleffizienz, nicht in Prozesszeiten. Wer hier Zeitersparnisse sucht, ist bei der Schadensmeldungsverarbeitung oder den Vertrags-Analysen besser aufgehoben.

Kosteneinsparung, sehr hoch (5/5) Das ist der größte Kosten- bzw. Ertragshebel in dieser Kategorie, aber er wirkt über die Portfoliomarge, nicht über direkte Kosteneinsparung. Für einen Versicherer mit 100 Millionen Euro Prämienvolumen bedeutet eine Combined-Ratio-Verbesserung von 2 Prozentpunkten 2 Millionen Euro höhere technische Marge. Das übersteigt jeden anderen Anwendungsfall in dieser Kategorie bei weitem.

Schnelle Umsetzung, sehr niedrig (1/5) Das ist das aufwendigste Projekt in dieser Kategorie. Datenaufbereitung, Feature Engineering, Modellentwicklung, Validierung, regulatorische Dokumentation, realistisch 6 bis 18 Monate bis zum Produktiveinsatz. Feature Engineering allein nimmt erfahrungsgemäß 60 bis 70 Prozent des Projektaufwands in Anspruch (Schätzwert aus Praxisberichten). Das ist kein Projekt für Teams, die schnelle Ergebnisse brauchen.

ROI-Sicherheit, mittel (3/5) Der ROI ist real, aber braucht einen langen Messhorizont. Schadenquoten-Verbesserungen zeigen sich erst nach 12 bis 24 Monaten Schadensverlauf, weil Schäden sich zeitverzögert entwickeln. Die Modell-Performance ist statistisch messbar (Gini, RMSE, Lift-Kurven), aber der Übersetzung in Euro-Ergebnisse braucht Zeit.

Skalierbarkeit, hoch (4/5) ML-Modelle skalieren mit dem Portfolio, mehr Risiken, mehr Prädiktoren, bessere Ergebnisse. Der laufende Aufwand (quartalsweise Kalibrierung) ist handhabbar. Einschränkung: Neue Produktlinien erfordern eigenständige Modellentwicklungen.

Richtwerte, stark abhängig von Datenbasis, Produktlinien-Komplexität und Data-Science-Kapazität.

Was das System konkret macht

Schritt 1, Datenaufbereitung und Feature Engineering ML-Modelle sind nur so gut wie die Daten. Der erste Schritt ist die Inventur: Welche Daten liegen strukturiert vor? Welche externen Daten sind verfügbar (Wetterdaten für Elementarschäden, Geodaten für Einbruchsrisiken)? Feature Engineering, das Transformieren roher Datenpunkte in aussagekräftige Modellvariablen, ist oft aufwendiger als das eigentliche Modelltraining.

Schritt 2, Zweistufiges Modell für regulatorische Akzeptanz ML-Modelle ersetzen klassische aktuarielle Modelle nicht, sie ergänzen sie. Der empfohlene Ansatz: Das klassische GLM-Modell liefert die Grundstruktur und Interpretierbarkeit, das ML-Modell identifiziert Residualmuster (was das GLM nicht erklärt). Die Kombination verbessert die Prognosegenauigkeit, ohne die regulatorische Nachvollziehbarkeit zu opfern.

Schritt 3, Validierung und Monitoring Ein Risikomodell, das einmal trainiert und nie überprüft wird, driftet. Das System überwacht kontinuierlich die Modellgüte (Gini-Koeffizient, RMSE, Lift-Kurven) und meldet, wenn das Modell signifikant von seinen Vorhersagen abweicht.

Konkrete Werkzeuge, was wann passt

Python (scikit-learn, XGBoost, LightGBM) Standard-Toolkit für ML-Risikomodelle. XGBoost und LightGBM sind in der Versicherungsbranche die meistgenutzten Algorithmen für tabularische Daten. Kostenlos, gut dokumentiert, breite Community. Für interne Modellentwicklungsteams.

Julius AI Für explorative Datenanalysen ohne ausgeprägtes Data-Science-Know-how: Julius AI kann strukturierte Versicherungsdaten (als CSV) analysieren, Korrelationen identifizieren und erste Modell-Insights liefern, ohne Code schreiben zu müssen. Ab 20 Dollar/Monat. Gut als Einstieg für eine erste Machbarkeitsstudie.

Azure Machine Learning Für Versicherungsunternehmen, die bereits auf Azure-Infrastruktur setzen: Vollständige Plattform für Modellentwicklung, -einsatz und -monitoring in einer regulatorisch auditierbaren Umgebung. Preise nach Computing-Nutzung.

Power BI Für die Visualisierung von Modell-Outputs und Monitoring-Dashboards: Wenn Schadenprognosen und Modell-Performance regelmäßig an das Management kommuniziert werden müssen. Ab 9 Euro/Nutzer/Monat.

SAS Viya Für Versicherungsunternehmen mit etablierter SAS-Infrastruktur: SAS Viya bietet Aktuarmodellierungs-Module, die spezifisch auf Versicherungsdaten und regulatorische Anforderungen ausgelegt sind. Enterprise-Preise.

Claude Für die Interpretation von Modell-Outputs und das Verfassen von Modell-Dokumentationen: Wenn ML-Modelle für BaFin-Governance-Prozesse dokumentiert werden müssen, hilft Claude dabei, technische Ergebnisse in verständliche Sprache zu übersetzen.

Rechtliche Besonderheiten

KI-gestützte Risikomodellierung berührt die striktesten regulatorischen Anforderungen dieser Kategorie.

EU AI Act, Hochrisiko-Pflicht: Systeme, die über den Zugang zu privaten Versicherungsleistungen entscheiden oder Prämien berechnen, gelten nach Anhang III Nr. 5b als Hochrisiko-KI-Systeme. Das bedeutet: Registrierungspflicht, Risikoabschätzung, Dokumentation des Trainingsdatensatzes, laufende Qualitätsüberwachung, menschliche Aufsicht und Conformity Assessment. Frist: August 2026 für Hochrisiko-Systeme. Dieser Prozess sollte bereits jetzt gestartet werden.

Solvency II, Modell-Governance: Interne Risikomodelle, die in die Solvabilitätsberechnung einfließen, unterliegen den Solvency-II-Anforderungen an Modell-Governance: Validierung, Dokumentation, Management-Überprüfung und BaFin-Genehmigung für wesentliche Modellvariationen. ML-Modelle als Ergänzung zu klassischen GLMs sind weniger regulierungsintensiv als vollständige interne Modelle.

DSGVO Art. 22, Automatisierte Tarifentscheidungen: Wenn ML-Modelle direkt Prämien berechnen, ohne menschliche Prüfung, handelt es sich um automatisierte Einzelentscheidungen mit rechtlicher Wirkung. Art. 22 DSGVO erfordert: Recht auf menschliche Prüfung, Erläuterung der Entscheidungslogik, Widerspruchsmöglichkeit.

BaFin-Erklärbarkeitsanforderungen: Die BaFin hat in Konsultationsdokumenten klargestellt, dass ML-Modelle bei ausreichender Dokumentation und Validierung regulatorisch akzeptabel sind, aber die Erklärbarkeit jeder Tarifentscheidung muss gewährleistet sein. SHAP-Werte (SHapley Additive exPlanations) sind das Standardwerkzeug für die Interpretierbarkeit.

Was es kostet, realistisch gerechnet

Einstieg (Explorative Analyse + erste ML-Modelle):

• Julius AI: 20 Dollar/Monat + Python-Bibliotheken: kostenlos
• Personalaufwand: 4–8 Wochen Data-Science-Expertise (intern oder extern)
• Erwarteter Effekt: Identifikation der 5–10 stärksten Prädiktoren, erste Modell-Validierung

Skaliert (Vollständige ML-Modellierungsplattform):

• Data Scientist intern: 70.000–90.000 Euro/Jahr
• Cloud-Computing (Azure ML): 200–1.000 Euro/Monat
• SAS Viya oder vergleichbar: 10.000–50.000 Euro/Jahr
• Erwarteter Effekt: 10–20 Prozent Verbesserung der Schadenquoten durch präzisere Risikoselektion (Schätzwert aus Praxisberichten)

ROI-Beispiel: Versicherer mit 100 Millionen Euro Prämieneinnahmen, aktueller Combined Ratio 97 Prozent. Durch präzisere Risikoselektion: Combined Ratio auf 95 Prozent verbessert. Effekt: 2 Millionen Euro höhere technische Marge, bei Entwicklungskosten von 200.000–400.000 Euro über zwei Jahre.

Wie du den Nutzen tatsächlich misst: Gini-Koeffizient des neuen Modells vs. altes Modell auf Holdout-Daten. Combined Ratio nach Portfoliosegmenten vor und nach Einführung (12-Monate-Messzeitraum). Adverse-Selection-Monitoring: Veränderung der Schadenquote nach Risikogruppe.

Vier typische Einstiegsfehler

1. Feature Engineering unterschätzen. Das Modelltraining selbst ist oft nicht der Bottleneck, die Aufbereitung der Daten ist es. In der Praxis entfallen 60 bis 70 Prozent des Projektaufwands auf Feature Engineering, Datenbereinigung und die Integration externer Datenquellen (Schätzwert aus Praxisberichten). Konkret: Ein 6-Monats-Projekt wird zum 10-Monats-Projekt, weil Schaden- und Vertragsdaten in getrennten Systemen liegen und erst verknüpft werden müssen. Abhilfe: Den Daten-Audit (welche Daten existieren, in welchem Format, mit welcher Qualität) als eigenständige Phase vor Projektstart planen, 2 bis 4 Wochen, kein Data Scientist nötig, aber ein IT-Ansprechpartner zwingend.

2. Overfitting auf Trainingsdaten. Ein ML-Modell, das auf den Trainingsdaten hervorragend funktioniert, aber auf echten neuen Daten versagt, ist ein klassisches Overfitting-Problem. Rigorose Holdout-Validierung mit zeitlich getrennten Daten (Train auf 2019–2022, Validierung auf 2023) ist Pflicht.

3. Regulatorische Dokumentation als Nachgedanken behandeln. BaFin-Anforderungen an Modell-Dokumentation und -Governance sind von Anfang an mitzudenken, nicht als letzten Schritt einzuplanen. Wenn die Dokumentation im Nachhinein erstellt wird, fehlen typischerweise drei Dinge: die Begründung für verworfene Features, die Herkunft der Trainingsdaten und der genaue Kalibrierungszeitpunkt, alles Pflichtangaben für EU AI Act Hochrisiko-Systeme. Konkrete Abhilfe: Für jede Modellentscheidung ein kurzes Protokoll führen (welche Features getestet, warum verworfen, welche Datenschnitte verwendet). Das kostet 30 Minuten pro Woche und erspart später Wochen der Rekonstruktion.

4. Ohne ausreichende Datenbasis starten. Als Faustformel braucht ein ML-Modell mindestens 10.000 bis 20.000 Schäden für stabile Schätzungen. Unter diesem Schwellenwert sind klassische GLMs robuster und sollten bevorzugt werden.

Was mit der Einführung wirklich passiert, und was nicht

Der Aktuars-Widerstand. Erfahrene Aktuare, die jahrelang GLM-Modelle entwickelt haben, begegnen ML-Ansätzen oft mit Skepsis, aus guten Gründen: Die regulatorische Akzeptanz war lange unklar, und der zweistufige Ansatz (GLM + ML-Residual) klingt komplizierter, als er ist. Was hilft: Früh zeigen, dass das ML-Modell das GLM nicht ersetzt, sondern die Punkte aufdeckt, wo das GLM systematisch daneben liegt. Das ist keine Bedrohung, das ist nützliche Information.

Das IT-Infrastruktur-Problem. ML-Modellproduktion (Einsatz, Monitoring, Versionierung) erfordert Data-Engineering-Kapazitäten, die in vielen Versicherungs-IT-Umgebungen nicht existieren. Azure ML löst das managed, aber die Integration ins Kernsystem für Echtzeit-Tarifierungsanfragen bleibt ein technisches Projekt.

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände, und was dahintersteckt

„ML-Modelle sind eine Black Box, für Regulatoren nicht akzeptierbar.” Das war ein legitimer Einwand vor fünf Jahren. Mit SHAP-Werten (SHapley Additive exPlanations) haben Gradient-Boosting-Modelle heute gute Interpretierbarkeits-Werkzeuge. Der empfohlene zweistufige Ansatz (GLM + ML-Residualmodell) behält zudem die volle Interpretierbarkeit des Basismodells. Die BaFin hat signalisiert, dass ML-Modelle mit dokumentierter Validierung und Governance akzeptiert werden.

„Wir haben nicht genug Schadendaten.” Als Faustformel: Unter 10.000 bis 20.000 Schäden sind klassische GLMs robuster. Für kleinere Versicherer: Branchen-Benchmarks oder externe Schadendatenbanken des GDV können die eigene Datenbasis ergänzen.

„Das können wir mit unserem Team nicht umsetzen.” Vollständige ML-Modelle erfordern Data-Science-Expertise. Optionen: Partnerschaft mit spezialisierten Aktuarberatungen (Milliman, Willis Towers Watson), Einstellung eines Data Scientists, oder schrittweiser Einstieg über explorative Werkzeuge wie Julius AI.

Woran du merkst, dass das zu dir passt

• Du beobachtest, dass deine Schadenquote in bestimmten Segmenten systematisch schlechter wird, auch wenn das Marktumfeld das nicht erklärt
• Dein Actuarial-Team verbringt viel Zeit damit, Modell-Residuen manuell zu analysieren, ohne eine strukturierte Methode für die Verbesserung zu haben
• Wettbewerber (insbesondere InsurTechs) bieten für bestimmte Risikosegmente deutlich günstigere Prämien, was darauf hindeutet, dass sie feinkörnigere Modelle nutzen

Wann es sich (noch) nicht lohnt: Unter 50.000 Verträgen und ohne eigenes Data-Science-Team ist der Investitionsaufwand für ein eigenes ML-Modell schwer zu rechtfertigen. Hier sind spezialisierte Tarifkalkulations-Services (als Saas-Lösung) effizienter als eine Eigenentwicklung.

Das kannst du heute noch tun

Exportiere einen Datensatz mit mindestens 500 historischen Schadensfällen aus deinem System (anonymisiert) und lade ihn in Julius AI hoch. Lass die KI nach den stärksten Korrelationen zwischen Kundenmerkmalen und Schadenshäufigkeit suchen.

Das dauert 30–60 Minuten und zeigt dir, welche Prädiktoren in deinen Daten prädiktiv sind, als erste Machbarkeitsstudie für ein vollständiges ML-Modell.

Quellen & Methodik

• Adverse Selection und ML-Risikomodelle: Deloitte, „Insurance Industry Outlook 2025”; NTT Data InsurTech Report 2024.
• Solvency-II-Kapitalanforderungen: EIOPA-Leitlinien zur internen Modellentwicklung; Studien zur Quantitative Impact Study (QIS) 2023.
• EU AI Act, Anhang III Nr. 5b: Verordnung (EU) 2024/1689, Hochrisiko-KI-Systeme im Versicherungswesen.
• DSGVO Art. 22: Anforderungen bei automatisierten Tarifierungsentscheidungen.
• SHAP (SHapley Additive exPlanations): Lundberg & Lee, „A Unified Approach to Interpreting Model Predictions”, NeurIPS 2017.
• XGBoost/LightGBM: Chen & Guestrin (2016); Microsoft Research (2017), Standard-ML-Bibliotheken für tabularische Versicherungsdaten.