Schadenhöhe, Prozesswahrscheinlichkeit & Schadenreservierung vorhersagen

Sobald ein Schaden gemeldet ist, muss der Versicherer entscheiden, wie viel er reserviert, wer den Schaden bearbeitet und ob er in einen Rechtsstreit münden wird. Maschinelles Lernen auf Schadenmerkmalen, Schadenverlauf und Sachbearbeiternotizen bewertet jeden Schaden früh, sodass einfache Schäden in die Schnellspur gehen und komplexe oder prozessanfällige Schäden früher bei erfahrenen Sachbearbeitern landen. Auf Portfolioebene ergänzt maschinelles Lernen die klassischen Dreiecksverfahren bei IBNR- und Endschadenschätzungen. Menschen, insbesondere Schadensachbearbeiter und die Aktuarfunktion, bleiben für Reserven und Entscheidungen verantwortlich.

Problem & Nutzen

• Heute: Fallreserven setzen einzelne Sachbearbeiter nach Erfahrung und Richtlinien; Weiterleitungsregeln sind starr; ein Rechtsstreit wird oft erst erkannt, wenn bereits ein Anwalt beteiligt ist. Portfolioreserven leiten Aktuare mit Dreiecksverfahren (Chain-Ladder, Bornhuetter-Ferguson, GLMs) und eigener Einschätzung ab.
• KI-Nutzen: frühere und konsistentere Signale zu Schadenhöhe, Rechtsstreit und Großschadenentwicklung; bessere Arbeitsverteilung; Vergleichsschätzungen (Challenger) für die Reservierung; feinere Reservierung auf Schadenebene statt nur über aggregierte Dreiecke.
• Belege: Anbieter wie CLARA Analytics positionieren Produkte für Schadentriage und Prozessvorhersage zur frühen Erkennung teurer oder anwaltlich begleiteter Schäden [1]; ihre öffentlichen Seiten nennen wenige geprüfte Zahlen, rechnen Sie also damit, den Nutzen auf Ihren eigenen Rückvergleichsdaten zu messen. Behandeln Sie veröffentlichte Verbesserungszahlen von Anbietern als Marketing, bis sie auf Ihren Daten reproduziert sind.
• Berichtskontext: IFRS 17 regelt die Bewertung von Verbindlichkeiten aus Versicherungsverträgen für IFRS-Bilanzierer [2]; die Solvency-II-versicherungstechnischen Rückstellungen gelten für EU-Versicherer; das CRAN-Paket ChainLadder dokumentiert Standardverfahren einschließlich des Solvency-II-Schadenabwicklungsergebnisses [3]. Bessere Endschadenschätzungen fließen in beides ein.

Varianten

• Schadenhöhe und Triage auf Schadenebene (FNOL): Klassifikation und Regression bei der Schadenmeldung; Kfz, Sach, Haftpflicht, Arbeitsunfall (Workers' Compensation), Kranken.
• Prozess- bzw. Anwaltsbeteiligungswahrscheinlichkeit: besonders relevant in Haftpflicht- und Personenschadensparten; in Deutschland und den meisten EU-Märkten sind Prozessquoten strukturell niedriger als in den USA, daher kann das Ziel stattdessen „Eskalation des Streitfalls“ oder „Beschwerde beim Ombudsmann“ lauten.
• Frühwarnung bei Großschäden und Reserveentwicklung: offene Schäden bei jedem Ereignis neu bewerten, um ungünstige Entwicklungen zu erkennen.
• Regress- und Rückforderungspotenzial: ein verwandtes Ziel auf denselben Daten.
• ML-Reservierung im Portfolio: Modelle auf Einzelschadenebene (Mikro), neuronale oder Gradient-Boosting-Entwicklungsmodelle, Bayessche Dreiecke mit Unsicherheit, eingesetzt als Challenger zu Chain-Ladder.
• Selbstversicherte Unternehmen / Captives und TPAs: dieselben Modelle bei weniger Schäden; wird typischerweise als Dienstleistung zugekauft.
• Private Nutzung: nicht anwendbar.

So funktioniert es

1. Schadensystem (FNOL, Zahlungen, Notizen, Statusereignisse)
2. Datenaufbereitung (Verlaufs-Snapshots je Schaden, Stichtage, Textbereinigung, Leakage-Kontrolle)
3. Merkmalsbildung (strukturierte Merkmale + Embeddings der Notizen + externe Indizes)
4. Modelle (Schadenhöhen-Regression / Quantilmodelle, Prozess-Klassifikator, Entwicklungsmodell)
5. Kalibrierung + Erklärung (SHAP, Begründungscodes) + Unsicherheitsintervalle
6. Scoring-Dienst (bei FNOL und bei jedem Schadenereignis)
7. Arbeitsplatz des Sachbearbeiters: Triage, Reservevorschlag, Warnungen [Entscheidung des Menschen]
8. Portfolioaggregation
9. aktuarielle Reserveprüfung [Entscheidung des Aktuars]
10. Überwachung: Rückvergleich mit tatsächlicher Regulierung, Drift, Fairness-Prüfungen

• Kernmodelle: Gradient Boosting (XGBoost, LightGBM, CatBoost) bleibt das Arbeitspferd für tabellarische Schadendaten; XGBoost ist Open Source unter Apache-2.0 [4]. Tabellarische Foundation-Modelle wie TabPFN können bei kleinen Schadenbeständen helfen, prüfen Sie aber die Lizenz: Die aktuellen TabPFN-Gewichte sind nicht-kommerziell, mit einer kommerziellen Enterprise-Edition [5].
• Schwertailige Zielgrößen: Modellieren Sie die Schadenhöhe mit Gamma-/Tweedie- oder Quantil-Zielfunktionen, setzen Sie für Großschäden ein Tail-Modell an und berichten Sie Intervalle statt einer einzelnen Zahl.
• Text: Sachbearbeiternotizen und Berichte werden über Embeddings oder Klassifikatoren in Merkmale überführt; LLMs fassen Notizen zusammen und extrahieren strukturierte Fakten (Verletzungsart, Hinweise auf Haftung). Lassen Sie ein LLM die Reserve nie selbst festlegen.
• Zeitbehandlung: Trainingszeilen müssen Snapshots „wie zum Zeitpunkt t bekannt“ sein; sonst bläht Label-Leakage die Genauigkeit auf.
• Mensch-in-der-Schleife (Human-in-the-Loop): Vorschläge gehen an den Sachbearbeiter; Reserven und Regulierungen zeichnen Schaden- und Aktuarfunktion ab.

Datenaufbereitung

Die Kerndaten sind Schadenstammsätze, Zahlungs- und Reserveverläufe, Statusereignisse und Sachbearbeiternotizen. Sie liegen typischerweise im Schaden- oder Bestandsverwaltungssystem, in einem Data Warehouse für das Aktuariat, im DMS (medizinische und Gutachterberichte als PDF oder Scan) und in E-Mails. Reservierungsdreiecke werden oft in Excel gepflegt.

Typische Lücken: Freitextnotizen ohne Struktur, gescannte Berichte, über die Jahre geänderte Kodierungsschemata, doppelte Anspruchsteller, fehlende Prozesskennzeichen und ein Verlauf, der nur den aktuellen Status statt Snapshots „wie zum Zeitpunkt t bekannt“ speichert. Ohne Snapshots bläht Label-Leakage die Genauigkeit auf.

Schritte der Aufbereitung: (1) Quellen und Verantwortliche erfassen (PREP-001, PREP-004); (2) Schadenverläufe über APIs oder ETL exportieren (PREP-005); (3) OCR und Textextraktion für Berichte (PREP-006, DOC-014); (4) Stichtags-Snapshots bilden und Codes vereinheitlichen; (5) Labels (Endkosten, Anwaltsbeteiligung) aus abgeschlossenen Schäden gewinnen (PREP-020); (6) Anspruchsteller für die Modellentwicklung pseudonymisieren (PREP-022); (7) mit Schadenexperten eine Hold-out- und Rückvergleichsmenge anlegen (PREP-018). Werkzeuge: SQL/dbt, Python (pandas), Paperless-ngx oder ein OCR-Dienst, ein Feature Store, wenn die Mengen es rechtfertigen.

Grober Aufwandsanteil: 50 bis 60 Prozent des Projekts, überwiegend Leakage-Kontrolle und Rekonstruktion der Historie. Siehe auch GUIDE-003.

Umsetzungswege

Welcher Weg für wen

• KMU (kleine Versicherer, MGAs, TPAs): Weg A, weil ausgereifte Schadenanalyse-Module von Kernsystem- und Insurtech-Anbietern existieren und ein kleines Portfolio ein eigenes Data-Science-Team selten rechtfertigt.
• Enterprise: Weg B, weil Schadenbewertung und Reservierung Kernprozesse sind, bei denen die eigene Historie der Wettbewerbsvorteil ist und die Modelle auf das eigene Portfolio abgestimmt und von der Aktuarfunktion gesteuert werden müssen.
• Entwickler: Weg C, weil Gradient-Boosting-Stacks (XGBoost, LightGBM) und Embedding-Modelle mit offenen Gewichten auf bescheidener Hardware laufen und volle Kontrolle über Leakage-Behandlung und Rückvergleich geben.

Weg A — Kaufen (Standardsoftware)

• Anbieter von Schadenanalytik: CLARA Analytics (Triage, Prozessvorhersage) [1], Gradient AI (Analytik für Schaden/Underwriting in Sach- und Krankenversicherung) [6] sowie ML-Module von Schaden-Kernsystemen (Guidewire, Duck Creek, Sapiens) und Analytikanbieter wie Shift Technology (EU, Frankreich; am stärksten bei Betrugserkennung, siehe ANOM-003).
• Reservierungssoftware: Milliman Arius, Willis Towers Watson ResQ sowie R/Python-Werkzeuge; Akur8 (EU, Frankreich) konzentriert sich auf Pricing (PRED-010).
• Wählen Sie A, wenn: Sie bewährte Abläufe wollen, wenig Data-Science-Personal haben und Ihr Schadenvolumen moderat ist. Prüfen Sie EU-Hosting, Modelltransparenz, die Möglichkeit zum Rückvergleich auf Ihrer eigenen Historie und die AI-Act-Rollen (Anbieter vs. Betreiber).

Weg B — Auf Cloud-KI-Diensten aufbauen

• ML-Plattform: Azure ML, Google Vertex AI, AWS SageMaker (EU-Regionen), Databricks oder Snowflake für Schadendaten; Boosting-Modelle auf verwalteter Rechenleistung trainieren.
• LLM-Schicht: ein Frontier- oder EU-gehostetes LLM (z. B. Mistral, Claude, Gemini oder GPT über EU-Regionen) für Notizzusammenfassung, Extraktion von Verletzungs-/Haftungsfakten und Begründungscodes; Notizen für Merkmale einbetten.
• Integration: Scoring per REST ins Schadensystem; Vorschläge in eine Aufgabenwarteschlange schreiben.
• Wählen Sie B, wenn: Sie ein Data-Science-Team haben und Kontrolle über Merkmale und Zielgrößen wollen, ohne eigene GPUs zu betreiben; beachten Sie, dass numerische Modelle LLMs selten überhaupt brauchen.

Weg C — Selbst betreiben (Open Source)

• Stack: Python mit XGBoost / LightGBM / CatBoost, scikit-learn, statsmodels, SHAP; R ChainLadder für Dreiecksverfahren [3]; MLflow als Modellregister; PostgreSQL / Parquet als Feature Store.
• Text: offene Embedding-Modelle und ein kleines offenes LLM (z. B. Qwen, Mistral, Llama-Klasse) über vLLM oder Ollama zur Notizextraktion.
• Hardware: Die numerischen Modelle laufen auf CPU-Servern (HW1); nur die optionale LLM-Notizverarbeitung braucht eine GPU (HW2). Die meisten Versicherer verlangen für Schadendaten ohnehin On-Premises- oder souveränes Hosting, daher ist Weg C realistisch und bei der Hardware günstig.
• Betriebsaufwand: MLOps, Dateningenieurwesen aus Alt-Schadensystemen und Modell-Governance dominieren, nicht die Rechenleistung.

Weg D — Eigenes Training

Dies ist der Standardweg für große Versicherer: Die Modelle werden auf der eigenen Schadenhistorie des Versicherers trainiert (typischerweise Jahre abgeschlossener Schäden mit Entwicklungs-Snapshots; mindestens Tausende Schäden je Segment, mehr für seltene Großschäden). Sequenz- und neuronale Reservierungsmodelle lassen sich im Haus trainieren; vergleichen Sie stets mit Boosting- und Chain-Ladder-Basislinien und behalten Sie diese, wenn der Gewinn marginal ist.

Stand der Technik (2026)

• Boosting auf aufbereiteten Schaden-Snapshots ist bei strukturierten Daten weiterhin schwer zu schlagen; tiefe Modelle bringen vor allem bei Text und bei Entwicklungssequenzen auf Mikroebene Mehrwert.
• Mikroreservierung (Einzelschaden) und verteilungsbasierte / Quantilmodelle sind aktive aktuarielle Forschungsfelder, die in Arbeitsgruppen wie CAS und IFoA diskutiert werden; klassische Dreiecksverfahren bleiben die regulatorische und prüferische Basislinie.
• LLMs werden inzwischen routinemäßig auf der Textseite eingesetzt: Notizen zusammenfassen, schadenrelevante Fakten extrahieren und Begründungscodes entwerfen. Sie ersetzen keine kalibrierten numerischen Modelle.
• Erklärbarkeit und Unsicherheit (SHAP, konforme Intervalle) erwarten Modellrisiko-Funktionen und Aufsichten; die EIOPA-Stellungnahme vom August 2025 zu KI-Governance und Risikomanagement legt die Aufsichtserwartungen an den KI-Einsatz von Versicherern fest [7].
• Grenzen und Fehlerbilder: Label-Leakage durch Informationen aus der Zeit nach dem Ereignis; soziale und rechtliche Inflation, die historische Muster aufbricht; Strukturbrüche (neue Gesetze, geänderte Schadenbearbeitung, COVID-ähnliche Ereignisse); Rückkopplungsschleifen (ein Kennzeichen „hohe Schadenhöhe“ ändert die Bearbeitung und damit das Ergebnis); kleine Stichproben bei Großschäden; und Proxy-Diskriminierung, wenn persönliche Merkmale ins Modell einfließen.

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack (tabular-ml + time-series): PRED-010 Versicherungs-Pricing (teilt Schadenhistorien und Merkmale; sein Schadenhöhenmodell ist das Gegenstück vor dem Schaden), PRED-025 Prognose von Gewährleistungsfällen, PRED-030 Telematik-Scoring, PRED-016 Liquiditätsprognose (Reserven bestimmen erwartete Auszahlungen).
• Nachbarn: ANOM-003 Betrugserkennung (teilt Merkmale, anderes Ziel und andere rechtliche Behandlung), AGENT-014 durchgängige Automatisierung der Schadenbearbeitung (verwendet Triage-Scores), DOC-024 Eingang gewerblicher Anträge (Schadenverläufe als Eingabe), PRED-038 Prozessausgangsprognose & Legal Analytics (Gerichtsseite; hier ist das Ziel die Wahrscheinlichkeit je Schaden).
• Bausteine: Schaden-Data-Warehouse / Feature Store, MLOps-Register, SHAP-Erklärdienst, Embedding-Dienst für Notizen. Ein CPU-Cluster plus ein optionaler HW2-GPU-Server bedient all das.

Aufwand, Kosten & Kennzahlen

• Weg A: 2–6 Monate für Integration und Kalibrierung; Abo- oder Preis je Schaden.
• Weg B: 4–9 Monate für das erste Produktivmodell inklusive Dateningenieurwesen; die Cloud-Kosten sind im Verhältnis zu den Personalkosten gering.
• Weg C / D: 6–12+ Monate mit einem Team aus Dateningenieuren, Data Scientists und Aktuaren; der Hauptteil der Kosten entfällt auf Altdaten und Governance.
• Kennzahlen: rückvergleichender Fehler der Endkosten (MAE, Kalibrierung nach Dezil, Lift bei Großschäden); AUC/Präzision im Top-k für Prozesse; Anteil der in die Schnellspur gegebenen Schäden ohne spätere ungünstige Entwicklung; Reserveangemessenheit / Abwicklungsergebnis gegenüber früheren Schätzungen; Übersteuerungsquote der Sachbearbeiter; Durchlaufzeit und Leakage; Drift- und Fairness-Kennzahlen.

Menschen & Veränderung

Beginnen Sie mit der Geschäftsleitung (Budget, Risikoappetit) und dem Schadenleiter als Prozessverantwortlichem; beziehen Sie die Aktuarfunktion und Legal/Compliance früh ein, weil Reserven und Fairness regulierte Themen sind. IT und Datenverantwortliche werden für Exporte und Integration gebraucht; die Datenschutzbeauftragte bzw. der Datenschutzbeauftragte prüft Rechtsgrundlage und Datenschutz-Folgenabschätzung (DSFA), da Daten von Anspruchstellern und Gesundheitsdaten in großem Umfang verarbeitet werden (Art. 35 DSGVO) und jeder externe Anbieter einen AVV braucht (GUIDE-005).

Betriebsrat: kommt darauf an. Die Bewertung von Schäden ist als solche keine Überwachung von Beschäftigten, aber Arbeitsplätze von Sachbearbeitern, die Entscheidungen, Übersteuerungsquoten oder Bearbeitungszeiten protokollieren, eignen sich zur Leistungskontrolle, daher greift wahrscheinlich § 87 Abs. 1 Nr. 6 BetrVG; § 90 Abs. 1 Nr. 3 verlangt eine rechtzeitige Unterrichtung bei Änderung von Arbeitsverfahren. Beziehen Sie den Betriebsrat vor dem Pilotbetrieb ein (GUIDE-004).

Maßnahmen zur Förderung der KI-Kompetenz (Art. 4 KI-Verordnung) für Sachbearbeiter und Aktuare: wie Scores entstehen, wie unsicher sie sind und wann man übersteuert (GUIDE-006). Wählen Sie als Pilotgruppe erfahrene Sachbearbeiter in einer Sparte und vergleichen Sie mit deren eigener Einschätzung. Typische Sorgen: Angst vor Dequalifizierung, davor, am Score gemessen zu werden, und vor unfairer Behandlung von Anspruchstellern. Begegnen Sie ihnen mit Transparenz, Begründungscodes und der Regel, dass Scores nur Triage und Reservevorschläge unterstützen; Sachbearbeiter und Aktuare entscheiden, und die Übersteuerungsquote wird beobachtet, nicht bestraft (GUIDE-008).

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): Die Einstufung hängt von der Nutzung ab. Anhang III Nummer 5 Buchstabe c führt KI-Systeme zur Risikobewertung und Preisbildung bei natürlichen Personen in der Lebens- und Krankenversicherung als Hochrisiko auf [8][9]. Modelle zu Schadentriage, Schadenhöhe, Prozess und Reservierung in der Schaden-/Unfallversicherung (P&C) sind als solche nicht aufgeführt, und die Portfolioreservierung auf aggregierten Daten betrifft keine Entscheidungen über natürliche Personen; sie gelten daher typischerweise als Systeme mit minimalem oder begrenztem Risiko. Bestimmt ein Score jedoch die Leistungen eines Anspruchstellers (z. B. Ansprüche in der Krankenversicherung, automatisierte Ablehnung), braucht der Fall eine rechtliche Prüfung, und die Ausnahmen für Betrugserkennung gelten nur für Finanzbetrug. Art. 4 (KI-Kompetenz) gilt in allen Fällen.
• DSGVO: Schadenakten enthalten personenbezogene und oft Gesundheitsdaten (Art. 9). Art. 22 beschränkt ausschließlich automatisierte Entscheidungen mit rechtlicher oder ähnlich erheblicher Wirkung — halten Sie bei Ablehnungs-, Reserve- und Regulierungsentscheidungen einen Menschen im Prozess. Wenden Sie Datenminimierung und eine DSFA an; Prozess-Scores über identifizierbare Anspruchsteller sind Profiling.
• Versicherungsaufsicht: Solvency-II-Governance, Anforderungen an Modellrisiko und Aktuarfunktion, IFRS 17 für Bilanzierer [2], EIOPA-Stellungnahme zu KI-Governance [7]; DORA für IKT-Drittparteirisiken beim Einsatz von Cloud-Anbietern; BaFin-Vorgaben (VAIT bzw. Nachfolgeregeln) in Deutschland.
• Fairness und Verhalten: Vermeiden Sie Proxys für geschützte Merkmale; nutzen Sie die Prozesswahrscheinlichkeit nicht, um Anspruchsteller schlechter zu behandeln (Pflichten zu fairer Schadenregulierung und Treu und Glauben); dokumentieren Sie, wie Scores die Bearbeitung beeinflussen.
• Gegenmaßnahmen: menschliche Freigabe, zurückhaltender Einsatz als Entscheidungsunterstützung, Champion/Challenger mit klassischen Verfahren, Rückvergleich, Begründungscodes, Audit-Protokolle.

Erste Schritte

1. Definieren Sie die Zielgröße genau (Endzahlung, Incurred an Tag 90, Anwalt beteiligt innerhalb von 12 Monaten) und die Entscheidung, die sie unterstützt (Triage, Fallreserve, IBNR-Challenger).
2. Bauen Sie Stichtags-Snapshot-Daten aus dem Schadensystem und eine leakage-sichere Trainings-/Validierungsaufteilung nach Schadendatum.
3. Passen Sie eine Boosting-Basislinie an und vergleichen Sie sie mit den aktuellen Fallreserven und Chain-Ladder-Ergebnissen [3][4]; berichten Sie Kalibrierung, nicht nur Genauigkeit.
4. Pilotieren Sie mit rein lesenden Vorschlägen für eine Sparte mit Rückmeldungen der Sachbearbeiter; prüfen Sie parallel einen Anbieter (Weg A) anhand Ihrer eigenen Rückvergleichsdaten [1][6].
5. Führen Sie die Prüfung nach KI-Verordnung, DSGVO und Modell-Governance (DSFA, Rolle als Anbieter oder Betreiber) durch, bevor Sie in den Produktivbetrieb gehen.

Quellen

1. CLARA Analytics (product overview: triage, litigation) — https://claraanalytics.com/
2. IFRS Foundation — IFRS 17 Insurance Contracts — https://www.ifrs.org/issued-standards/list-of-standards/ifrs-17-insurance-contracts/
3. CRAN — ChainLadder package (claims reserving in R; v0.2.21, Feb 2026) — https://cran.r-project.org/web/packages/ChainLadder/index.html
4. XGBoost project (Apache-2.0) — https://github.com/dmlc/xgboost
5. Prior Labs — TabPFN (licence and limits) — https://github.com/PriorLabs/TabPFN
6. Gradient AI — https://www.gradientai.com/
7. EIOPA — Opinion on AI governance and risk management (Aug 2025) — https://www.eiopa.europa.eu/publications/opinion-artificial-intelligence-governance-and-risk-management_en
8. EU AI Act, Annex III (high-risk systems, point 5) — https://artificialintelligenceact.eu/annex/3/
9. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj