KI in der Versicherung 2026: Aktuariat, Claims, Daten

Pexon Consulting | 10 Min. Lesezeit | 16.07.2026

TL;DR

KI in der Versicherung scheitert 2026 selten am Modell, fast immer an den Daten. Aktuariat in Excel, Vertragsbestände in zehn Silos, Fixlizenzen ohne Ausweg. Wer IFRS 17 sauber umgesetzt hat, besitzt bereits das Fundament für KI in Aktuariat, Schaden und Underwriting. Pexon Consulting (80 Mitarbeiter, Microsoft-Partner, Deutschland) baut diese Datenplattform und setzt die KI-Use-Cases darauf.

Das Problem: Das Aktuariat rechnet noch in Excel

Fast jeder Versicherer hat seine Kundendaten über mindestens zehn getrennte Systeme verteilt: CRM, Bestandsführung, Schaden, Contact Center, Vertriebspartner, Abrechnung, Rückversicherung. Das Aktuariat baut darüber seine Projektionen, oft in gewachsenen Excel-Landschaften, die niemand mehr vollständig versteht. Jede Anfrage, jede Prüfung, jede Meldung wird zur manuellen Datensammlung.

Das ist nicht nur ineffizient, es ist regulatorisch riskant. IFRS 17 verlangt eine granulare, vertragsgenaue Bewertung der Verpflichtungen, für die die meisten Alt-Architekturen in der DACH-Region nie gebaut wurden. Solvency II fordert aus prudenzieller Sicht dieselbe granulare Datenqualität für die ORSA. Beide verlangen eine lückenlose Datenherkunft von der Quelltransaktion bis zum Bericht. Und wer KI auf aktuarielle Daten aufsetzt, muss diese Modelle in dieselbe Lineage einbinden, denn genau danach fragt die Aufsicht in der Prüfung.

Dieser Artikel klärt drei Dinge: warum die Datenbasis das Nadelöhr ist, welche KI-Use-Cases auf derselben Plattform laufen, und warum die Reihenfolge Datenplattform vor KI heißt.

IFRS 17 und Solvency II: die Datenbasis ist das Nadelöhr

Die kurze Antwort: Die Infrastruktur, die IFRS 17 verlangt, ist exakt die Infrastruktur, die gute KI-Modelle erst ermöglicht. Eine moderne Datenplattform mit dokumentierter Lineage, automatisierten Qualitätskontrollen und nahezu echtzeitfähiger Verarbeitung ist die Voraussetzung für belastbare Berichte und für belastbare ML-Modelle im Underwriting und in der Schadenbearbeitung.

Das ist die gute Nachricht für alle, die IFRS 17 bereits gestemmt haben: Sie besitzen das Fundament schon. Die schlechte für alle anderen: Die erste ernsthafte Investition ist selten die KI, sondern Data Engineering und Master Data Management. Wer das überspringt, baut KI auf Sand. Wie eine solche Plattform risikoarm startet, zeigt unser Weg über eine KI-fähige Datenplattform auf Microsoft Fabric.

Vier KI-Use-Cases auf einer Datenplattform

Der eigentliche Hebel entsteht, wenn mehrere Use-Cases auf derselben konsolidierten Datenbasis laufen, statt für jeden ein neues Silo zu bauen.

Besonders die Meta-Suche unterschätzen viele. Wenn eine Kundenanfrage heute bedeutet, dass ein Sachbearbeiter fünf Systeme einzeln durchsucht, ist eine RAG-gestützte Suche über den konsolidierten Bestand der schnellste sichtbare Nutzen. Die Schaden-Automatisierung vertiefen wir in unserem Beitrag zu Claims Automation mit KI.

Warum die Datenplattform vor der KI kommt

Unsere klare Position: Wir raten davon ab, KI-Piloten zu starten, solange das Aktuariat in Excel rechnet und die Bestände in Silos liegen. Ein Modell auf inkonsistenten Daten produziert Ergebnisse, die weder das Aktuariat noch die Aufsicht akzeptieren. Der teure Fehler ist, mit einem sichtbaren KI-Showcase zu beginnen und die Datenarbeit zu verschieben. Dann steht nach sechs Monaten ein Demo, das nie in Produktion geht.

Die richtige Reihenfolge ist unbequem, aber sie zahlt sich aus: erst die Datenplattform mit Lineage und Qualität, die IFRS 17 und Solvency II ohnehin verlangen, dann die KI-Use-Cases darauf. So finanziert die Regulatorik den ersten Schritt, und die KI wird zum zweiten, der auf einem tragfähigen Fundament steht. Für regulierte Häuser gilt zusätzlich der EU AI Act, dessen Hochrisiko-Pflichten nach Anhang III ab dem 2. Dezember 2027 gelten und der KI in Underwriting oder Schaden schnell zum Hochrisiko-System macht. Wie eine KI-Plattform unter DORA, BAIT und EU AI Act aussieht, ordnen wir in den verwandten Themen am Ende ein.

Raus aus dem Vendor-Lock-in

Der stille Kostentreiber ist die Fixlizenz, die niemand mehr ablösen kann, weil das ganze Aktuariat darauf aufbaut. Eine offene Datenplattform bricht diese Abhängigkeit auf: Die Daten liegen in einem standardisierten Format, die Modelle sind portabel, der Anbieter austauschbar. Das ist kein Selbstzweck, sondern Risikomanagement. Wer heute in eine geschlossene Suite investiert, tauscht ein Excel-Problem gegen ein Lock-in-Problem. Unsere Empfehlung: die Konsolidierung so bauen, dass sie den Anbieterwechsel offen hält, statt den nächsten goldenen Käfig zu errichten.

Häufig gestellte Fragen

Warum scheitern KI-Projekte bei Versicherern?

Fast immer an den Daten, nicht am Modell. Bestände liegen in zehn oder mehr Systemen, das Aktuariat arbeitet in Excel, und es fehlt eine Datenplattform mit Lineage und Qualität. Ein KI-Modell auf inkonsistenten Daten liefert Ergebnisse, die weder fachlich noch aufsichtsrechtlich tragen. Deshalb kommt die Datenarbeit vor der KI.

Was hat IFRS 17 mit KI zu tun?

Mehr, als viele denken. IFRS 17 verlangt eine granulare, vertragsgenaue Datenarchitektur mit dokumentierter Herkunft. Genau diese Infrastruktur ist die Voraussetzung für belastbare ML-Modelle in Underwriting und Schaden. Wer IFRS 17 sauber umgesetzt hat, besitzt das Fundament für KI bereits.

Welche KI-Use-Cases lohnen sich in der Versicherung?

Vier zahlen besonders schnell: aktuarielle Modellierung statt Excel, automatisierte Schaden- und Underwriting-Prüfung, Konsolidierung der Vertragsbestände und eine Meta-Suche über die Altsysteme. Der größte Hebel entsteht, wenn alle auf einer gemeinsamen Datenplattform laufen statt in neuen Silos.

Ist KI im Underwriting nach EU AI Act erlaubt?

Erlaubt ja, aber oft als Hochrisiko-System eingestuft, mit Dokumentations-, Aufsichts- und Transparenzpflichten. Die Hochrisiko-Pflichten nach Anhang III gelten ab dem 2. Dezember 2027, Transparenzpflichten schon seit dem 2. August 2026. Für Versicherer heißt das, KI-Modelle in dieselbe Daten- und Governance-Lineage einzubinden, die IFRS 17 und Solvency II ohnehin verlangen.

Wie starte ich, ohne alles auf einmal umzubauen?

Mit einem risikoarmen Datenplattform-Piloten auf einem klar umrissenen Bestand, nicht mit einem Big-Bang. Ein Use-Case, etwa die Meta-Suche oder ein aktuarieller Teilprozess, liefert sichtbaren Nutzen und das Muster für den Ausbau. So bleibt das Risiko klein und der Lerneffekt groß.

Nächster Schritt

Bevor Sie einen KI-Showcase bauen, klären wir mit Ihnen, welche Datenbasis Aktuariat, Claims und Bestand wirklich brauchen. Ehrlich, auch wenn der erste Schritt Data Engineering statt KI heißt.

Verwandte Themen