KI-gestützte Schadenreservierung und Rückstellungsoptimierung

Das echte Ausmaß des Problems

Schadenreserven sind keine Buchhalterposition. Sie sind aktuarielle Schätzungen mit direkter Wirkung auf Eigenkapital, Solvenzquote und BaFin-Meldung. Für einen mittelständischen Schaden/Unfall-Versicherer mit 50 Millionen Euro Jahresprämie können die technischen Rückstellungen das Zweifache des Jahresprämienvolumens ausmachen, und schon eine Über- oder Unterreservierung von fünf Prozent bindet oder setzt Kapital in einer Größenordnung frei, die das Jahresergebnis merklich beeinflusst.

Diese Darstellung ist eine fachliche Orientierung, kein Rechts- oder Beratungsersatz. Konkrete HGB-, Solvency-II- und BaFin-Anforderungen sind mit einer versicherungsmathematisch zugelassenen Fachkraft (Verantwortlicher Aktuar) und dem Unternehmensjuristen abzustimmen.

Was in der Praxis häufig dazu führt, dass Reserven falsch sind:

• Manuell gesetzte Einzelreserven: In vielen mittelständischen Versicherern setzen Sachbearbeiter Reserven nach Erfahrungswerten, ohne systematischen Vergleich mit historischen Regulierungsverläufen ähnlicher Fälle. Studien der International Actuarial Association zeigen, dass selbst erfahrene Sachbearbeiter bei unvollständigen Informationen im frühen Schadenstadium systematisch zu niedrig oder zu hoch reservieren.

• Veraltete Kalibrierung: Die Chain-Ladder-Dreiecke, mit denen die Gesamtreserve auf Spartenebene berechnet wird, werden in vielen Unternehmen ein- bis zweimal jährlich aktualisiert. Inzwischen akkumulierte Schadentrends, steigende Anwaltshonorare in der Haftpflicht, Inflationseffekte in der Sachversicherung, Zunahme von Langläufern in Berufshaftpflicht, schlagen erst mit monatelanger Verzögerung durch.

• Fehlende Erklärbarkeit in der Diskussion mit dem CFO: Wenn der Aktuar sagt „Die Reserve für diese Sparte liegt bei X Euro”, aber nicht erklären kann, welche Einzelfallmuster diesen Wert treiben, bleibt die Diskussion mit Finance und Vorstand eine Verhandlung über Meinungen statt Daten.

Die BaFin erwartet nach Solvency II (EU-Richtlinie 2009/138/EG) eine angemessene Best-Estimate-Berechnung für die versicherungstechnischen Rückstellungen, ebenso wie nach HGB §341e und §341h eine vorsichtige Bewertung der Schadenrückstellungen. Mit IFRS 17, der seit dem Geschäftsjahr 2023 in Kraft ist, kommt eine dritte parallele Anforderung hinzu: die Fulfillment Cash Flows, die ebenfalls auf aktuarielle Schätzungen angewiesen sind.

Diese Darstellung ist eine fachliche Orientierung, kein Rechts- oder Beratungsersatz. Konkrete HGB-, Solvency-II- und BaFin-Anforderungen sind mit einer versicherungsmathematisch zugelassenen Fachkraft (Verantwortlicher Aktuar) und dem Unternehmensjuristen abzustimmen.

Das Ergebnis: Viele mittelständische Versicherer führen de facto drei verschiedene Reservierungsrechnungen parallel, HGB, Solvency II und IFRS 17, ohne dass diese konsistent miteinander verknüpft sind. Das bindet Aktuariatskapazität, die sinnvoller für Analyse und Entscheidungsunterstützung genutzt werden könnte.

Mit vs. ohne KI, ein ehrlicher Vergleich

Die Zahlen in der linken Spalte entstammen Erfahrungswerten aus Aktuariatsprojekten bei Versicherern mit 20.000–100.000 aktiven Schadenfällen. Die rechte Spalte ist der realistische Zielkorridor, nicht das Verkaufsversprechen von Werkzeuganbietern. Ein Teil der Zeiteinsparung entsteht daraus, dass Datenaufbereitung und Dokumentation automatisiert werden; ein anderer Teil entsteht durch schnellere Entscheidungen, wenn der Aktuar auf fertige Visualisierungen zurückgreifen kann statt Excel-Tabellen manuell zu durchsuchen.

Diese Darstellung ist eine fachliche Orientierung, kein Rechts- oder Beratungsersatz. Konkrete HGB-, Solvency-II- und BaFin-Anforderungen sind mit einer versicherungsmathematisch zugelassenen Fachkraft (Verantwortlicher Aktuar) und dem Unternehmensjuristen abzustimmen.

Einschätzung auf einen Blick

Zeitersparnis, niedrig bis mittel (2/5) Reservierungsarbeit spart durch KI-Unterstützung signifikante Aktuar-Stunden pro Quartal, aus drei Wochen können realistisch drei bis vier Tage werden. Aber: Für die meisten anderen Use Cases im Versicherungsbereich ist der reine Zeithebel höher, weil dort Massenvolumen automatisiert wird. Hier geht es um eine spezialisierte Hochqualifikationsaufgabe, bei der KI die Vorbereitung übernimmt, nicht die Durchführung selbst. Das rechtfertigt keinen hohen Zeitersparniswert, der Hauptnutzen ist nicht Zeit, sondern Qualität.

Kosteneinsparung, hoch (4/5) Genauere Reserven haben direkte Bilanzwirkung. Chronische Überreservierung bindet Kapital, das anderswo renditeträchtig eingesetzt werden könnte. Chronische Unterreservierung erzeugt stille Lasten, die sich bei Nachreservierungen in schlechten Quartalsergebnissen entladen. In beiden Fällen geht es um Beträge, die in der Haftpflichtversicherung schnell sechsstellig werden. Damit steht dieser Use Case im Versicherungsbereich unter den stärker bilanznah wirkenden Anwendungsfällen, vergleichbar nur mit der Echtzeit-Tarifierung.

Schnelle Umsetzung, niedrig (2/5) Die Implementierung ist komplex. Historische Schadendaten müssen über mehrere Schadenjahre exportiert, bereinigt und in auswertbare Dreiecksform gebracht werden. Dieser Schritt allein dauert in der Praxis Wochen, und das, bevor das erste Modell trainiert ist. Hinzu kommen Validierungsschritte, die der Verantwortliche Aktuar verantworten muss. Wer in sechs Wochen einen produktiven Piloten erwartet, wird enttäuscht. Realistisch sind vier bis acht Monate bis zum Produktivbetrieb.

ROI-Sicherheit, mittel (3/5) Der Nutzen ist messbar: Man kann Modellergebnisse gegen spätere tatsächliche Regulierungsbeträge halten und die Reservierungsgenauigkeit objektiv auswerten. Aber der konkrete Kapitalnutzen hängt davon ab, wie groß die aktuelle Unter- oder Überreservierung ist, und das ist vor dem Projekt schwer zu wissen. Unternehmen, die bereits sehr gut reservieren, sehen weniger ROI als Unternehmen mit systematischer Schieflage. ROI-Sicherheit ist daher mittel, real, aber kontextabhängig.

Skalierbarkeit, mittel (3/5) Das Modell skaliert gut innerhalb einer kalibrierten Sparte. Neue Sparten erfordern jedoch eigene Kalibrierungsprojekte mit eigenen historischen Daten, ein Haftpflicht-Modell überträgt sich nicht auf Hausrat, ein Kfz-Modell nicht auf Berufshaftpflicht. Das begrenzt die Skalierbarkeit auf einen mittleren Wert.

Richtwerte, stark abhängig von Unternehmensgröße, Spartenbreite und Qualität der historischen Schadensdaten.

Was das System konkret macht

KI-gestützte Reservierung arbeitet auf zwei Ebenen, die man klar auseinanderhalten sollte:

Ebene 1: Einzelfallreservierung. Das Modell schaut sich jeden offenen Schadenfall an und vergleicht ihn mit historischen Fällen, die zum Zeitpunkt der Reservierung ähnlich aussahen, nach Schadenkategorie, Schadenstadium, Deckungsart, Meldeverzug, beteiligten Parteien und weiteren Merkmalen. Auf dieser Basis schätzt es den wahrscheinlichsten Endregulierungsbetrag. Wenn die aktuelle Sachbearbeiterreserve signifikant abweicht, wird der Fall für eine manuelle Überprüfung markiert.

Ebene 2: Aggregatreservierung (IBNR). Auf Portfolioebene übernimmt Machine Learning die Aktualisierung der klassischen Chain-Ladder-Dreiecke. Statt eine einmalige Jahresrechnung zu produzieren, kann das Modell monatlich oder auch unterjährig neue Entwicklungsfaktoren berechnen. Das ist besonders relevant für die ORSA-Berichterstattung unter Solvency II, die eine laufende Risikobewertung erfordert.

Diese Darstellung ist eine fachliche Orientierung, kein Rechts- oder Beratungsersatz. Konkrete HGB-, Solvency-II- und BaFin-Anforderungen sind mit einer versicherungsmathematisch zugelassenen Fachkraft (Verantwortlicher Aktuar) und dem Unternehmensjuristen abzustimmen.

Was das System nicht macht und nicht machen kann: Es entscheidet keine aktuarielle Fachfrage selbst. Es schlägt einen Wert vor, erklärt welche Merkmale den Vorschlag treiben, und zeigt die statistische Unsicherheitsspanne. Der Aktuar prüft, interpretiert und übernimmt die fachliche Verantwortung. Das ist kein Konstruktionsfehler, es ist eine regulatorische und professionelle Notwendigkeit (siehe Abschnitt “Was der Aktuar validieren muss”).

Das erklärende Element ist dabei oft genauso wertvoll wie die Zahl selbst: Wenn das Modell sagt „Diese Reserve liegt 23 Prozent über dem Erwartungswert, weil der Fall drei Merkmale aufweist, die historisch mit höheren Endbeträgen korrelieren, namentlich Beteiligung eines Rechtsanwalts, zwölf Monate Meldeverzug und Schadenzone Köln/Bonn”, dann kann Vivienne Hartmann das in die Diskussion mit dem CFO einbringen. Das ist eine Datenbasis. Keine Meinung.

Was der Aktuar validieren muss, und was das Modell nicht entscheiden kann

Dies ist ein Abschnitt, der in vielen KI-Marketing-Materialien fehlt und deshalb hier explizit steht.

Nach VAG §141a muss jedes Versicherungsunternehmen eine versicherungsmathematische Funktion einrichten, deren Inhaber die fachliche Verantwortung für die versicherungstechnischen Rückstellungen trägt. Der Verantwortliche Aktuar unterzeichnet. Das KI-Modell unterzeichnet nicht.

Diese Darstellung ist eine fachliche Orientierung, kein Rechts- oder Beratungsersatz. Konkrete HGB-, Solvency-II- und BaFin-Anforderungen sind mit einer versicherungsmathematisch zugelassenen Fachkraft (Verantwortlicher Aktuar) und dem Unternehmensjuristen abzustimmen.

Was der Aktuar bei jedem KI-Modell für die Reservierung prüfen und dokumentieren muss:

1. Methodenvalidierung. Welche Methoden hat das Modell angewandt? Sind es BaFin-anerkannte Methoden (Chain-Ladder, Bornhuetter-Ferguson) oder proprietäre ML-Ansätze, die keine etablierte aktuarielle Grundlage haben? Bei letzteren muss der Aktuar eine eigene fachliche Begründung für den Einsatz dokumentieren.

2. Datenbasis-Prüfung. Welche historischen Daten wurden für die Kalibrierung verwendet? Sind Sonderjahre (z. B. COVID-19-Regulierungen 2020–2022, Starkregenereignisse, Großschadenjahre) angemessen behandelt oder verzerren sie das Modell systematisch? Ein Modell, das auf einem unbereinigten Datensatz trainiert wurde, kann plausibel klingende, aber methodisch falsche Ergebnisse produzieren.

3. Aufsichtsrechtliche Konsistenz. Unterscheiden sich die Modellergebnisse für HGB, Solvency II und IFRS 17? Wenn ja: Sind die Unterschiede methodisch begründbar, oder entstehen sie durch unterschiedliche Dateninputs oder inkonsistente Parameter? Das Modell muss für jeden Rechnungslegungsrahmen separat dokumentiert sein.

4. Modellrisiko-Quantifizierung. Welche Parameterunsicherheit weist das Modell aus? Liegt das Ergebnis nahe an der Untergrenze des Konfidenzintervalls (Unterreservierungsrisiko) oder nahe an der Obergrenze (überhöhte Kapitalbelastung)? Der Aktuar muss entscheiden, an welchem Punkt des Intervalls die verantwortete Reserve festgesetzt wird.

5. Ausreißeranalyse. Welche Einzelfälle weicht das Modell am stärksten von den historischen Mustern ab? Sind das Datenfehler (der Fall ist falsch erfasst), echte Ausreißer (ungewöhnliche Konstellation), oder Modelldefizite (das Modell kennt diesen Typ nicht)?

Das ist keine Checkliste für den einmaligen Piloten, das ist der laufende Betrieb. Die Deutsche Aktuarvereinigung (DAV) hat in ihrem Ergebnisbericht “Regulierung und Validierung von KI-Modellen” (Februar 2024) dargelegt, dass KI-Modelle im Versicherungskontext denselben Validierungsanforderungen unterliegen wie klassische aktuarielle Modelle, und zusätzlich Erklärbarkeitsanforderungen erfüllen müssen, die aus dem EU AI Act resultieren.

Wenn die historischen Schadensdaten lügen

Die gefährlichste Annahme bei KI-Reservierungsprojekten lautet: „Unsere historischen Daten sind repräsentativ für die Zukunft.”

Sie sind es in vier Szenarien systematisch nicht, und jedes davon ist in deutschen Versicherungsbeständen real präsent:

Inflationsverzerrung. Kfz-Reparaturkosten sind seit 2022 um 25–35 Prozent gestiegen. Haftpflicht-Schmerzensgeld-Urteile orientieren sich an aktualisierten Schmerzensgeldtabellen. Ein Modell, das auf Schadendaten aus 2018–2021 trainiert wurde, unterschätzt systematisch die künftigen Endregulierungsbeträge. Inflationsbereinigung der historischen Daten ist keine Kür, sie ist methodische Pflicht.

Regulierungs-Sonderjahre. Die COVID-19-Jahre 2020 und 2021 haben in nahezu allen Sparten anomale Schadenverläufe produziert: weniger Kfz-Unfälle, Einbruch im Berufsunfähigkeits-Neugeschäft, aber gleichzeitig steigende Cyber-Schäden. Ein Modell, das diese Jahre unbereinigt einschließt, lernt Muster, die strukturell nicht wiederkehren werden. Gleichzeitig darf man sie nicht einfach ausschließen, denn in zukünftigen Ausnahmejahren möchte man, dass das Modell weiß, wie solche Jahre verlaufen. Das ist eine aktuarielle Urteilsfrage, keine algorithmische.

Rare-Event-Bias bei Großschäden. Die International Actuarial Association (IAA) hat in ihrer Auswertung von ML-Methoden für IBNR-Reservierung (Kristian André Jakobsen, 2025) festgestellt, dass kein ML-Ansatz in allen Szenarien besser abschneidet als der klassische Chain-Ladder. Besonders bei Portfolios mit seltenen Großschadenereignissen, einer Haftpflichtklage mit Urteil im zweistelligen Millionenbereich, einem Massenrückruf, tendieren ML-Modelle dazu, diese Ereignisse zu unterschätzen, weil sie im Trainingsdatensatz unterrepräsentiert sind.

Muster aus veränderten Regulierungspraktiken. Wenn ein Versicherungsunternehmen seine Schadenregulierungsstrategie geändert hat, z. B. durch Einführung eines Telemedizin-Gutachters, eine neue Anwalts-Beauftragungspolitik oder durch den Wechsel eines Schadendienstleisters, spiegeln historische Daten aus der Zeit davor eine andere Regulierungsrealität wider. Das Modell wird dann Muster lernen, die nicht mehr zutreffen.

Diese Darstellung ist eine fachliche Orientierung, kein Rechts- oder Beratungsersatz. Konkrete HGB-, Solvency-II- und BaFin-Anforderungen sind mit einer versicherungsmathematisch zugelassenen Fachkraft (Verantwortlicher Aktuar) und dem Unternehmensjuristen abzustimmen.

Die praktische Konsequenz: Der Aktuar muss vor der Modellkalibrierung entscheiden, welche historischen Zeiträume wie gewichtet werden und welche Sonderjahre mit welcher Bereinigung behandelt werden. Diese Entscheidung ist methodisch zu dokumentieren, sie ist Teil der aktuariellen Verantwortung und kann nicht vom Modell übernommen werden.

Konkrete Werkzeuge, was wann passt

Diese Darstellung ist eine fachliche Orientierung, kein Rechts- oder Beratungsersatz. Die regulatorische Eignung einzelner Tools (BaFin-Anforderungen, Solvency-II-Dokumentationspflichten, IFRS-17-Kompatibilität) ist im Einzelfall mit dem Verantwortlichen Aktuar und dem Unternehmensjuristen zu prüfen.

ADDACTIS Reserving, wenn strukturierte Aktuariatsplattform gefragt ist Die bekannteste spezialisierte SaaS-Plattform für Non-Life-Reservierung in Europa. Unterstützt alle gängigen aktuariellen Methoden (Chain-Ladder, Bornhuetter-Ferguson, Mack-Bootstrap), produziert Native-Solvency-II-Best-Estimates und IFRS-17-Risikoanpassungen und erzeugt prüfungsfeste Dokumentation. EU-Datenhosting. Kosten: auf Anfrage, typisch im Bereich 15.000–60.000 €/Jahr je nach Modultiefe. Richtige Wahl für Versicherer, die eine auditierbare, aktuarielle Plattform ohne eigene Entwicklung wollen.

SAS Viya, wenn Aktuariat in eine breitere Analytik-Infrastruktur integriert wird Enterprise-Plattform mit Reservierung als einem von vielen Bausteinen. SAS Viya hat starke Versicherungs-Module, insbesondere für Underwriting und Risikomodellierung. Wenn das Unternehmen bereits in SAS investiert ist und die Reservierung dort integrieren will, ist das der naheliegende Weg. Teurer als spezialisierte Reservierungslösungen, dafür breiter einsetzbar. EU-Hosting verfügbar.

Python mit ChainLadder-Bibliothek, wenn ein Data-Science-Team aufgebaut wird Das Open-Source-Paket chainladder-python (frei, gepflegt durch eine aktive Aktuariats-Community) implementiert alle Standardmethoden und erlaubt vollständige Kontrolle über Modellparameter. Keine Lizenzkosten. Volle Flexibilität für Inflationsbereinigung, Sonderjahr-Handling und eigene ML-Erweiterungen. Voraussetzung: Ein Aktuar mit Python-Kenntnissen oder ein Data Scientist mit aktuariellem Grundverständnis. Für Unternehmen, die ein internes Modell aufbauen und langfristig weiterentwickeln wollen, oft die bessere Wahl als eine Plattformlizenz.

Julius AI, für explorative Datenanalyse und Reserve-Reporting ohne Code Kein Reservierungstool im aktuariellen Sinn, aber nützlich für die Datenexploration: historische Schadendreiecke hochladen, Entwicklungsmuster visualisieren, Ausreißer identifizieren. Sinnvoll als Ergänzung, wenn Reservierungsleitung und CFO auf schnell verständliche Visualisierungen angewiesen sind. US-Hosting, für die explorative Phase mit anonymisierten Aggregatdaten vertretbar; für den Produktivbetrieb mit personenbezogenen Schadendaten nicht geeignet.

Zusammenfassung: Wann welcher Ansatz

• Spezialisierte Reservierungsplattform mit Compliance-Output → ADDACTIS Reserving
• Reservierung als Teil einer größeren Analytics-Infrastruktur → SAS Viya
• Internes Modell mit voller Kontrolle, Data-Science-Kapazität vorhanden → Python + chainladder-python
• Explorative Analyse und CFO-Reporting-Visualisierungen → Julius AI (nur für Aggregatdaten)

Datenschutz und Datenhaltung

Schadendaten sind besonders schützenswert. Sie enthalten personenbezogene Daten der Versicherten (Name, Adresse, Schadenhergang), potenziell Gesundheitsdaten (bei Personenschäden), Bankverbindungen (Auszahlungsempfänger) und betriebliche Informationen (bei Betriebshaftpflicht).

Für KI-Reservierungsprojekte bedeutet das:

• DSGVO Art. 28 (Auftragsverarbeitung): Sobald ein Cloud-Anbieter Schadendaten verarbeitet, ist ein Auftragsverarbeitungsvertrag (AVV) zwingend abzuschließen. Das gilt auch für spezialisierte Reservierungsplattformen wie ADDACTIS Reserving.

• EU-Hosting als Mindestanforderung: ADDACTIS Reserving und SAS Viya bieten EU-Hosting. Julius AI hostet in den USA, für Produktivbetrieb mit personenbezogenen Schadendaten nicht geeignet. Für exploratorische Analysen können aggregierte, pseudonymisierte Dreiecksdaten ohne Personenbezug auch über US-Tools verarbeitet werden, das ist mit dem Datenschutzbeauftragten abzustimmen.

• Selbst gehostete Open-Source-Lösung: Python mit ChainLadder kann vollständig on-premises oder in einer eigenen Cloud-Instanz (z. B. Azure Deutschland, AWS Frankfurt) betrieben werden. Das ist die datenschutzrechtlich unkomplizierteste Option, die Daten verlassen die eigene Infrastruktur nicht.

• EU AI Act: KI-Modelle, die Entscheidungen im Schadensbereich unterstützen, müssen nach dem EU AI Act auf ihre Risikokategorie geprüft werden. Reservierungsmodelle, die ausschließlich interne Managemententscheidungen unterstützen und nicht unmittelbar gegenüber Versicherten wirken, sind in der Regel kein Hochrisikosystem, aber das ist im Einzelfall zu dokumentieren. Modelle, die direkte Auswirkungen auf Leistungsentscheidungen gegenüber Versicherten haben, können anders einzustufen sein.

Zuständig für die Datenschutzprüfung ist neben dem Datenschutzbeauftragten der Versicherungsunternehmen auch die IT-Sicherheit, insbesondere bei On-Premises-Installationen mit Anbindung an die Schadenssysteme.

Was es kostet, realistisch gerechnet

Die Gesamtkosten eines KI-Reservierungsprojekts setzen sich aus drei Komponenten zusammen, die in der Praxis oft falsch kalkuliert werden:

Lizenz und Plattform (laufend)

• ADDACTIS Reserving: 15.000–60.000 €/Jahr je nach Schadensvolumen und Modultiefe (Preise auf Anfrage)
• SAS Viya (mit Versicherungsmodulen): fünf- bis sechsstelliger Jahresbetrag, Preise auf Anfrage
• Python + ChainLadder (Open Source): 0 € Lizenzkosten; Infrastrukturkosten je nach Einsatzform

Implementierung und Kalibrierung (einmalig)

• Datenaufbereitung (Export, Bereinigung, Dreiecksstruktur): 20–40 Personentage intern oder 15.000–30.000 € extern
• Modellkalibrierung je Sparte: 5–10 Aktuar-Tage pro Sparte bei professioneller Begleitung
• Validierungsprojekt (inklusive Backtesting über 3–5 historische Schadenjahre): 10–20 Personentage
• Gesamtimplementierungsaufwand: typisch 50.000–150.000 € bei professioneller Begleitung, je nach Systemkomplexität und Spartenanzahl

Laufender Betrieb

• Aktuar-Zeit für Quartalsvalidierung und Modellanpassung: 2–4 Tage pro Quartal (statt 15–20 Tage ohne Werkzeug)
• Plattformpflege, IT-Support: je nach Einsatzform 3.000–10.000 €/Jahr

Was du dagegen rechnen kannst Der Hauptnutzen ist nicht die Aktuar-Zeitersparnis, obwohl sie real ist. Der Hauptnutzen ist Kapitaloptimierung. Wenn ein Versicherer mit 60 Millionen Euro technischen Rückstellungen seine IBNR-Reservierung um fünf Prozent präzisiert, also weder systematisch über- noch unterreserviert, sind das drei Millionen Euro Kapital, die nicht gebunden oder nicht freigesetzt werden. Bei einer Eigenkapitalrendite von acht Prozent entspricht das einem jährlichen Opportunitätswert von 240.000 Euro. Diese Rechnung hängt stark von der aktuellen Reservierungsqualität ab: Wer schon sehr präzise reserviert, hat weniger Potenzial. Wer systematisch über 10 Prozent daneben liegt, hat entsprechend mehr.

ROI-Messung in der Praxis: Der einzige robuste Nachweis ist das Backtesting. Lass das Modell auf historischen Daten schätzen, für die du die tatsächlichen Endbeträge kennst, und vergleiche systematisch Modellprognose vs. Realität vs. damalige Sachbearbeiterreserve. Wenn das Modell näher an der Realität liegt als die Sachbearbeiterreserve, hast du deinen Business Case.

Drei typische Einstiegsfehler

1. Mit dem Modell starten, bevor die Datenbasis steht Der häufigste Fehler ist Ungeduld. Das Schadenssystem kann keine sauberen Dreiecke exportieren, aber man fängt trotzdem mit dem Modell an, und erhält Ergebnisse, die methodisch korrekt, aber inhaltlich unbrauchbar sind, weil die Daten Lücken, Doppelerfassungen oder inkonsistente Buchungslogiken enthalten. Die Datenbasisprüfung (Wie vollständig ist die Schadendokumentation? Sind Sparten konsistent kodiert? Wie werden Wiedereröffnungen erfasst?) muss vor dem Modelleinsatz stehen. Das kostet Zeit, ist aber unverzichtbar.

2. Nur das Aggregatmodell kalibrieren, Einzelfallreservierung ignorieren Viele Projekte beginnen mit dem Chain-Ladder-Replacement auf Portfolioebene, weil das das technisch Einfachere ist. Die größten Reservierungsrisiken liegen aber oft in einzelnen Großschadenläufern, nicht in der Aggregatschieflage. Ein Haftpflichtfall, der im dritten Jahr nach dem Schadensereignis plötzlich einen Anwalt einschaltet und in Richtung gerichtlicher Auseinandersetzung geht, sollte anders reserviert werden als ein analoger Fall, der sich im dritten Jahr seiner Regulierung befindet. Ein reines Aggregatmodell sieht diese Differenzierung nicht.

3. Das Modell wird eingeführt, und dann nie mehr aktualisiert Dies ist der gefährlichste Fehler, weil er still passiert. Ein Reservierungsmodell, das auf Schadendaten bis 2023 kalibriert wurde und seitdem nicht mehr angefasst wurde, lernt weder die gestiegenen Reparaturkosten 2024 noch eine geänderte Regulierungspraxis. Im Unterschied zu einer einfachen Suchfunktion, die offensichtlich nichts findet, wenn nichts da ist, produziert ein veraltetes ML-Modell selbstbewusste Schätzungen, auf Basis eines Weltbildes, das nicht mehr stimmt. Die Kalibrierungsfrequenz muss vor der Einführung festgelegt werden: Wer aktualisiert wann, auf welchen Daten, mit welcher Validierungsprozedur? Diese Frage muss vor dem ersten produktiven Einsatz beantwortet sein.

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

Was passiert: Das Aktuariat entlastet sich von Routinearbeit. Der erste Quartalsdurchlauf mit dem Werkzeug dauert oft länger als ohne, weil Datenfehler auftauchen, die bisher im manuellen Prozess überdeckt wurden und jetzt sichtbar werden. Das ist kein Scheitern des Systems, sondern sein erstes nützliches Ergebnis: Es zeigt, wo die Datenbasis lückenhaft ist.

Was nicht passiert: Der CFO hört nach der ersten KI-Auswertung nicht automatisch auf, die Reserven zu hinterfragen. Er hört dann auf, wenn das Modell über mehrere Quartale hinweg nachweislich besser prognostiziert hat als die manuelle Schätzung, und wenn der Aktuar das mit Backtesting-Daten belegen kann. Das dauert ein bis zwei Jahre.

Widerstandsmuster, die auftreten:

• Die Sachbearbeitung sieht das System als Kontrollinstrument. Wenn das Modell systematisch sagt „deine Reserve liegt zu niedrig” und das intern als Fehler-Scoring wahrgenommen wird, entsteht Widerstand. Richtig kommuniziert ist das Werkzeug eine Unterstützung für schwierige Fälle, kein Prüfsystem für Sachbearbeiterqualität.
• Der Wirtschaftsprüfer will Nachweise für das Modell. Das ist kein Problem, sofern das Modell dokumentiert ist. Undokumentierte ML-Modelle ohne BaFin-gerechte Methodenbeschreibung werden in der Prüfung zum Problem.
• Das IT-System kann die nötigen Daten nicht liefern. In manchen Unternehmen ist der Schadenssystem-Export das eigentliche Projekt. Vor Beginn des Reservierungsprojekts muss klar sein, dass ein sauberer, automatisierbarer Datenexport existiert.

Diese Darstellung ist eine fachliche Orientierung, kein Rechts- oder Beratungsersatz. Konkrete HGB-, Solvency-II- und BaFin-Anforderungen sind mit einer versicherungsmathematisch zugelassenen Fachkraft (Verantwortlicher Aktuar) und dem Unternehmensjuristen abzustimmen.

Was konkret hilft:

• Den Verantwortlichen Aktuar von Anfang an in das Projekt einbinden, nicht als Abnehmer der Ergebnisse, sondern als fachlichen Mitgestalter des Modells
• Eine klare interne Kommunikation: Das System schlägt vor, der Aktuar entscheidet
• Einen internen Validierungsbericht nach dem ersten Produktivquartal erstellen, Modellprognose vs. aktuelle Sachbearbeiterreserve vs. tatsächlicher Endregulierungsbetrag früherer Fälle

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände, und was dahintersteckt

„Das Chain-Ladder-Dreieck funktioniert seit 20 Jahren.” Stimmt, in stabilen Jahren mit stabilen Schadenverläufen. Das Chain-Ladder-Verfahren ist methodisch robust, aber es reagiert langsam auf strukturelle Veränderungen im Schadenportfolio. Wenn sich Regulierungspraktiken, Kostenstrukturen oder Schadenfrequenzen verschieben, braucht Chain-Ladder mehrere vollständige Entwicklungsjahre, bis diese Verschiebungen im Dreieck sichtbar werden. ML-Modelle können Frühwarnsignale in Einzelfällen erkennen, bevor sie im Aggregatdreieck auftauchen, das ist der methodische Mehrwert, nicht die reine Rechengeschwindigkeit.

„Wir haben nicht genug Daten.” Das ist ein valides Argument für bestimmte Sparten. Für eine kleine Sparte mit hundert Schadenfällen pro Jahr ist ein ML-Modell methodisch kaum zu rechtfertigen, Chain-Ladder oder Bornhuetter-Ferguson bleiben dann der richtige Ansatz. Für die Hauptsparten eines mittelständischen Versicherers mit mehreren tausend Fällen pro Jahr hingegen ist die Datenmenge in der Regel ausreichend, sofern die historischen Daten sauber digitalisiert und exportierbar sind.

„Wer haftet, wenn das Modell falsch liegt?” Der Verantwortliche Aktuar haftet, wie er es immer getan hat. Das KI-Modell verändert die Verantwortungsstruktur nicht. Es verändert nur, auf welcher Informationsgrundlage die fachliche Entscheidung getroffen wird. Ein Aktuar, der ein schlecht dokumentiertes Modell übernimmt und dessen Ergebnisse unkritisch übernimmt, trägt dieselbe Verantwortung wie ein Aktuar, der einen manuellen Fehler in einem Excel-Dreieck übersieht. Die Haftung sitzt beim Menschen, nicht beim Algorithmus.

Diese Darstellung ist eine fachliche Orientierung, kein Rechts- oder Beratungsersatz. Konkrete HGB-, Solvency-II- und BaFin-Anforderungen sind mit einer versicherungsmathematisch zugelassenen Fachkraft (Verantwortlicher Aktuar) und dem Unternehmensjuristen abzustimmen.

Woran du merkst, dass das zu dir passt

Du profitierst von diesem Use Case, wenn Folgendes zutrifft:

• Du bist Reservierungsleiter oder Verantwortlicher Aktuar bei einem Schaden/Unfall-Versicherer mit mindestens 5.000 aktiven Schadenfällen pro Jahr
• Dein Quartalsabschluss für die Reservierung bindet mehr als zehn Personentage, davon mindestens die Hälfte für Routineaufgaben (Datenaufbereitung, Formatierung), nicht für Analyse
• Du führst Reservierungsrechnungen für mehrere Sparten durch, die derzeit in getrennten Excel-Strecken laufen
• Dein Schadenssystem kann historische Schadendaten über mindestens fünf Schadenjahre exportieren (auch wenn der Export heute noch manuell angestoßen wird)
• Du stehst unter Druck, gegenüber CFO, Wirtschaftsprüfer oder BaFin besser begründen zu können, wie du auf deine Reservehöhen kommst

Drei harte Ausschlusskriterien, wann du es lassen solltest:

Diese Darstellung ist eine fachliche Orientierung, kein Rechts- oder Beratungsersatz. Konkrete HGB-, Solvency-II- und BaFin-Anforderungen sind mit einer versicherungsmathematisch zugelassenen Fachkraft (Verantwortlicher Aktuar) und dem Unternehmensjuristen abzustimmen.

1. Unter ca. 3.000–5.000 Schadenfällen aktiv pro Jahr je Sparte. Mit weniger historischen Daten liefert die aktuarielle Standardmethodik (Bornhuetter-Ferguson, Chain-Ladder mit Bornhuetter-Priorität) bereits das methodisch Optimale. ML-Mehrwert ist bei kleinen Datensätzen statistisch nicht nachweisbar, und ein Modell zu kalibrieren, das dasselbe Ergebnis liefert wie Chain-Ladder, ist Aufwand ohne Ertrag.

2. Kein designierter Verantwortlicher Aktuar nach VAG §141a. BaFin erwartet eine versicherungsmathematische Funktion, die die technischen Rückstellungen fachlich verantwortet. Wer kein aktuarielles Fachpersonal hat, das Modelloutputs validieren, dokumentieren und fachlich vertreten kann, sollte kein KI-Reservierungsmodell in Betrieb nehmen. Das Modell allein macht niemanden zum Aktuar.

3. Schadenssystem ohne exportierbaren, strukturierten Datensatz. Wenn der heutige Datenexport mehr als zwei Tage dauert, manuell zusammengestellt wird und Inkonsistenzen in Spartenkodierungen aufweist: Erst Datenbasis sanieren, dann Modell aufbauen. Kein ML-Modell kompensiert eine kaputte Datengrundlage, es verstärkt die Fehler nur.

Das kannst du heute noch tun

Für einen ersten Realitätscheck, ohne Softwarelizenz, ohne externe Beratung, kannst du folgendes tun: Exportiere die Schadendaten einer deiner Hauptsparten als CSV-Datei (Schadenjahr, Entwicklungsjahr, kumulative Zahlungen je Quartal). Lade diese in Julius AI hoch und bitte das System, ein Entwicklungsdreieck zu visualisieren und die impliziten Entwicklungsfaktoren auszurechnen. Das dauert 30 Minuten. Was du danach weißt: Ob deine Datenbasis für eine maschinelle Auswertung grundsätzlich geeignet ist, und ob die Chain-Ladder-Faktoren, die du manuell angewendet hast, mit den Rohdaten konsistent sind.

Wenn du tiefer einsteigen willst: Das Python-Paket chainladder-python (open source, MIT-Lizenz) erlaubt dir, alle Standardmethoden selbst zu implementieren, ohne Lizenzkosten, mit voller Kontrolle über die Parameter. Es gibt detaillierte Tutorials und eine aktive Aktuariats-Community.

Für die Diskussion mit dem CFO auf Basis deiner aktuellen Reserven: Hier ist ein Prompt, den du direkt in Claude oder ChatGPT einfügen kannst:

Quellen & Methodik

• IAA, Machine Learning für IBNR-Reservierung: Kristian André Jakobsen, “Evaluating Machine Learning Methods for IBNR Claims Reserving on Real Claims Data”, International Actuarial Association (2025). Kernaussage: Kein ML-Verfahren übertrifft in allen Szenarien den klassischen Chain-Ladder-Ansatz, besonders bei Portfolios mit seltenen Großschadenereignissen tendieren ML-Modelle zu systematischer Unterschätzung. Verfügbar über actuaries.org.

• DAV, KI-Modell-Validierung: Deutsche Aktuarvereinigung, “Regulierung und Validierung von KI-Modellen”, Ergebnisbericht (26. Februar 2024). Legt dar, dass KI-Modelle im Versicherungskontext denselben Validierungsstandards unterliegen wie klassische aktuarielle Modelle, plus zusätzlicher Erklärbarkeitsanforderungen. Verfügbar unter aktuar.de.

• Solvency II (EU-Richtlinie 2009/138/EG): Technische Rückstellungen (Best Estimate), SCR-Berechnung, ORSA-Anforderungen. BaFin-Rechtsgrundlagen verfügbar unter bafin.de.

• BaFin Solvency-II-Berichtswesen (November 2025): Hinweisschreiben zu Berichtspflichten und QRT-Formaten, verfügbar als PDF unter bafin.de.

• HGB §341e und §341h: Vorschriften zu Schadenrückstellungen (§341e) und Rückstellungen für drohende Verluste (§341h). In der aktuell geltenden Fassung.

• VAG §141a: Anforderungen an die versicherungsmathematische Funktion (Verantwortlicher Aktuar). In der aktuell geltenden Fassung.

• ADDACTIS Reserving: Produktbeschreibung und Methodenübersicht, addactis.com (Stand Mai 2026).

• chainladder-python: Open-Source-Bibliothek für aktuarielle Schadenreservierung in Python. Dokumentation und Codebase: chainladder-python.readthedocs.io.

• Implementierungsaufwände und ROI-Schätzwerte: Erfahrungswerte aus Aktuariatsprojekten bei deutschen und österreichischen Schaden/Unfall-Versicherern (Stand April 2026). Keine repräsentative Studie, Größenordnungen für die Planungsphase, keine verbindliche Kostenzusage.

Du willst wissen, ob die Reservierungsgenauigkeit in eurem Bestand groß genug ist, um das Projekt zu rechtfertigen, und welche Datenvorbereitung realistisch notwendig wäre? Meld dich. Das lässt sich in einem kurzen Gespräch mit den richtigen Fragen klären.