Schadenleistungs-Leakage-Erkennung

Das echte Ausmaß des Problems

Schadenleistungs-Leakage ist kein Randthema. Branchenanalysten und Implementierungspartner, die systematisch Schadenportfolios auditieren, kommen immer wieder auf denselben Bereich: 5 bis 10 Prozent der gesamten Schadenaufwendungen werden vermeidbar zu viel ausgezahlt (Industry-Benchmark laut VCA Software und NTT DATA CLIP-Auswertungen). Für einen Versicherer mit 500 Millionen Euro Schadenvolumen im Jahr sind das 25 bis 50 Millionen Euro, jährlich, strukturell.

Die NTT DATA Claims Leakage Identification Platform (CLIP), die bei rund 15 deutschen Versicherern im Einsatz ist, hat in quantitativen Audits folgende durchschnittliche Einsparungspotenziale ermittelt:

• 6–12 % in Kfz-Haftpflicht, Kfz-Kasko und Unfallversicherung
• 7–11 % in der Personenschadenregulierung
• 10–18 % in der Hausratversicherung

Wichtig: Das sind keine Betrugsfälle. Es handelt sich um legitime Schadensfälle von legitimen Versicherungsnehmern, die jedoch aus Prozessfehlern, Klauselunkenntnis oder Verhandlungsschwäche zu viel ausgezahlt wurden.

Worum geht es genau, die Leakage-Taxonomie

Schadenleistungs-Leakage ist nicht homogen. Es gibt zwei grundlegend unterschiedliche Kategorien, die verschiedene ML-Ansätze erfordern:

Hartes Leakage, technische Fehler mit direktem Rückforderungspotenzial:

• Auszahlungen jenseits von Policensublimits
• Regulierung von Schäden, die durch Deckungsausschlüsse eigentlich nicht gedeckt waren
• Doppelzahlungen (derselbe Schadensfall mehrfach reguliert, unterschiedliche Sachbearbeiter)
• Falsch angewendete Selbstbeteiligungen (zu gering oder nicht abgezogen)
• Fälle ohne gültige Police zum Schadenzeitpunkt

Weiches Leakage, nicht regelwidrig, aber systematisch suboptimal:

• Auszahlungsbeträge, die statistisch deutlich über dem Median vergleichbarer Fälle liegen, ohne erkennbaren Grund
• Verhandlungsergebnisse mit Anwälten oder Werkstätten, die unter dem erzielbaren Benchmark liegen
• Schadenfälle ohne Subrogationsprüfung (hätte ein Dritter in Anspruch genommen werden können? → dazu mehr im Subrogation Mining)
• Reservierungen, die konsistent zu hoch angesetzt sind und durch langsamere Rückstellungsauflösung Kapitalkosten erzeugen

Der Unterschied ist entscheidend: Hartes Leakage lässt sich oft retrospektiv zurückfordern (je nach Verjährung und Policenbedingungen). Weiches Leakage ist in der Vergangenheit verloren, aber in Zukunft vermeidbar.

Diese Unterscheidung ist auch das, was Claims-Leakage-Erkennung fundamental von der Betrugserkennung trennt: Betrug setzt absichtliche Täuschung voraus. Leakage passiert, weil Prozesse und Klauseln komplex sind und Menschen Fehler machen, auch ohne jeden Vorsatz.

Mit vs. ohne KI, ein ehrlicher Vergleich

Zahlen aus NTT DATA CLIP-Auswertungen (de.nttdata.com, 2024) und Shift Technology AXA Switzerland Case Study (shift-technology.com, 2025).

Einschätzung auf einen Blick

Zeitersparnis, mittel (3/5) Die direkte Arbeitszeitentlastung betrifft primär Schadenauditoren und die Innenrevision: Eine manuelle Aktenprüfung, die 45–90 Minuten kostet, wird durch KI-Vorfilterung auf 5–15 Minuten gedrückt, NTT DATA CLIP nennt 50–80 % schnellere Closed-Files-Reviews. Sachbearbeiter in der laufenden Regulierung profitieren durch klare Markierungs-Hinweise, was genau geprüft werden soll. Dennoch bleibt dies nicht die primäre Stärke dieses Anwendungsfalls: Die eigentliche Wirkung liegt in der Kostensenkung, nicht in der direkten Stundenentlastung. Verglichen mit Schadensmeldungsverarbeitung oder Angebotsautomatisierung, die täglich Bearbeitungszeit für viele Sachbearbeiter einsparen, ist der Effekt hier konzentrierter.

Kosteneinsparung, sehr hoch (5/5) Das ist die stärkste Achse dieses Anwendungsfalls. Die identifizierten 6–18 % Einsparung auf dem Schadenvolumen sind direkt in Euro messbar, kein indirekter Effekt, kein Annäherungswert. Für einen Versicherer mit 200 Millionen Euro Schadenaufwand bedeuten bereits 8 % Leakage-Reduktion 16 Millionen Euro weniger Aufwand. Unter den Versicherungs-Anwendungsfällen in dieser Kategorie teilt sich diese Bewertung mit Betrugserkennung, Echtzeit-Tarifierung und Reparaturpreisinflations-Erkennung, allesamt Kostenhebel mit direktem Euro-Bezug. Die Bewertung ist trotzdem gerechtfertigt, weil Leakage-Erkennung das gesamte Schadenportfolio scant, nicht nur verdächtige Fälle.

Schnelle Umsetzung, schwierig (2/5) Kein Schönreden: Ein vollständiges Leakage-Erkennungssystem braucht 9–18 Monate bis zum Produktivbetrieb. Es braucht strukturierte Schadensdaten aus mehreren Jahren, eine saubere Datenmigration in ein Analytics-System, eine Verbindung zum Claims-Management-System (Guidewire, SAP FS-CM, msg.Insurance), und einen validierten ML-Ansatz. Wer mit einem retroaktiven Portfolio-Audit beginnt, kann erste Ergebnisse schneller sehen (3–6 Monate für die Pilot-Analyse), aber das ist der Audit, nicht das Echtzeit-System. Eine der anspruchsvollsten Implementierungen unter den hier verglichenen Versicherungs-Anwendungsfällen.

ROI-Sicherheit, hoch (4/5) Was Claims Leakage von vielen anderen Use Cases unterscheidet: Der Nutzen ist direkt messbar. Du kannst das identifizierte Leakage-Volumen in Euro ausweisen, die Rückforderungen (bei hartem Leakage) tracken, und die Differenz zu Vergleichsfällen dokumentieren. Ein sauber durchgeführtes Pilot-Audit nach 3–6 Monaten gibt belastbare Zahlen. Der eine fehlende Punkt zur Höchstwertung: Bei weichem Leakage (Verhandlungsschwäche, schlechte Benchmarks) ist die Attribution schwieriger, du weißt, dass du teuer reguliert hast, aber nicht immer, ob du günstiger hättest regulieren können.

Skalierbarkeit, sehr hoch (5/5) Einmal gebaut, scant das Modell jede neue Schadensmeldung ohne proportional steigenden Aufwand. Ob dein Schadenvolumen um 20 % wächst oder du eine neue Sparte integrierst: Der Grenzaufwand ist gering. Die einzige Skalierungsbedingung ist Datenqualität, bei neuen Sparten mit anderen Regulierungsmustern muss das Modell nachtrainiert werden.

Richtwerte, stark abhängig von Schadenvolumen, Spartenstruktur und Qualität der Bestandsdaten.

Was das System konkret macht

Schadenleistungs-Leakage-Erkennung arbeitet in zwei Modi, die du kombinieren oder sequentiell einführen kannst:

Modus 1: Retroaktives Portfolio-Audit

Das System analysiert abgeschlossene Schadensfälle der letzten 3–5 Jahre. Das Machine Learning-Modell gruppiert alle Fälle nach Schadentyp, Sparte, Schadenhöhe, Region, Schadenursache und weiteren Merkmalen. Für jede Gruppe berechnet es einen statistischen Erwartungsbereich für die Regulierungshöhe. Fälle, die deutlich außerhalb dieses Bereichs liegen, werden markiert, mit einem Erklärungswert: „Dieser Haftpflichtfall wurde 43 % über dem Median ähnlicher Fälle reguliert. Mögliche Ursache: kein Gutachter hinzugezogen.”

Gleichzeitig führt ein regelbasierter Layer eine Deckungsprüfung durch: Wurde der korrekte Deckungsumfang auf den Policentyp angewendet? Sind Sublimits eingehalten? Gibt es einen Ausschluss, der nicht berücksichtigt wurde?

Das Ergebnis ist eine priorisierte Liste von Fällen, die Sachbearbeiter oder Innenrevisoren manuell nachprüfen sollten, mit Begründung je Fall.

Modus 2: Echtzeit-Scoring bei Neuschäden

Bei jedem neu eingehenden Schadensfall, zum Zeitpunkt der Ersterfassung (First Notice of Loss, FNOL) oder während der Regulierung, berechnet das Modell einen Leakage-Score. Dieser Score fließt als Hinweis in die Sachbearbeiteroberfläche ein: „Achtung: Ähnliche Fälle wurden im Schnitt mit 4.200 € reguliert. Der vorgeschlagene Betrag liegt bei 7.800 €. Bitte Deckungsklausel §12 Abs. 3 prüfen.”

Ob der Sachbearbeiter den Hinweis akzeptiert oder mit Begründung übergeht, wird protokolliert, das ist die Datenbasis für das Modell-Retraining.

Was das System nicht macht

Es ersetzt keine menschliche Entscheidung. Es blockiert keine Auszahlung automatisch. Und es erkennt keinen Betrug, das ist ein anderes System mit anderen Trainingsdaten und anderen Modellen. Wer beides kombinieren will, betreibt zwei separate Scoring-Layer, die unterschiedliche Flags setzen.

Retroaktives Audit vs. Echtzeit-Scoring, der Unterschied zählt

Das sind keine Varianten desselben Systems, es sind zwei unterschiedliche Investitionsentscheidungen mit unterschiedlichen Laufzeiten und Risikostrukturen.

Die Empfehlung für jeden Versicherer, der neu einsteigt: zuerst das retroaktive Audit. Es erzeugt innerhalb von Monaten belastbare Zahlen, und ist die überzeugendste interne Argumentationshilfe für die Vollimplementierung.

Konkrete Werkzeuge, was wann passt

Kein Weg führt an einer ehrlichen Toolauswahl vorbei: Claims-Leakage-Erkennung ist ein Spezialproblem, und die relevanten Lösungen sind sehr unterschiedlich positioniert.

Shift Technology, wenn du Echtzeit-Leakage-Prävention und Automatisierung kombinieren willst Die am tiefsten spezialisierte Lösung für Claims Leakage und Fraud Detection. Das seit 2024/2025 lancierte Shift Claims kombiniert Leakage-Erkennung, Betrugserkennung und Workflow-Automatisierung in einer agentenbasierten Plattform. AXA Switzerland erzielte damit 3 % niedrigere Schadenkosten, 30 % schnellere Regulierung und eine 60-prozentige Automatisierungsrate. Einschränkung: Nur für Erstversicherer mit Enterprise-Budget und großem Schadenvolumen. Keine öffentliche Preisliste, Vertragsmodell auf Anfrage, typisch ergebnisbasierte Komponenten.

NTT DATA CLIP, wenn du ein strukturiertes Portfolio-Audit für deutsche Versicherungsbestände willst Die Claims Leakage Identification Platform von NTT DATA ist explizit auf den deutschen und europäischen Markt ausgerichtet und bei rund 15 deutschen Versicherern im Einsatz. Das Modell liefert quantitative Leakage-Potenzialschätzungen nach Sparte, eine priorisierte Aktionsliste und Benchmark-Vergleiche gegen die Branche. Sinnvoller Einstieg für mittelgroße Versicherer, die zunächst das Potenzial verstehen wollen, bevor sie in Echtzeit-Integration investieren. Enterprise-Consulting-Preis auf Anfrage. Kontakt über de.nttdata.com.

Celonis, wenn der Schadenbearbeitungsprozess selbst das Problem ist Claims Leakage entsteht oft nicht nur durch schlechte Deckungsanwendung, sondern durch Prozessfehler: Fälle, die zu lange liegen, zu viele Handwechsel haben, oder Schritte überspringen. Celonis Process Mining legt diese Muster offen und identifiziert, wo Regulierungsschritte systematisch abgekürzt oder umgangen werden. Das Tool ist kein Leakage-Detector im engeren Sinne, aber ein wertvolles Diagnosewerkzeug in der Vorbereitungsphase. Einstieg ab ca. 50.000–100.000 Euro.

Dataiku, wenn du ein Custom-ML-Modell intern bauen willst Für Versicherer mit einer eigenen Data-Science-Abteilung ist Dataiku eine Option, um Claims-Leakage-Modelle intern zu entwickeln, auf eigenen Daten, mit voller Kontrolle über Modellarchitektur und Erklärbarkeit. Die Plattform bietet vorgefertigte Pipelines für Insurance Analytics und die notwendige MLOps-Infrastruktur für Monitoring und Retraining. Erfordert 2–4 interne Data Scientists plus Implementierungsunterstützung. Sinnvoll, wenn du Hersteller-Unabhängigkeit und volle Datensouveränität priorisierst.

SAS Fraud Management, wenn du bereits auf SAS-Infrastruktur arbeitest SAS bietet Leakage- und Betrugsmodelle für Versicherer, die bereits in der SAS-Welt zuhause sind. Preislich ab ca. 500.000 Euro/Jahr, sinnvoll nur in Kombination mit anderen SAS-Anwendungen. Keine Stand-alone-Empfehlung für reines Claims Leakage.

Wann welcher Ansatz:

• Retroaktives Audit, erste Potenzialschätzung → NTT DATA CLIP (Kontakt über de.nttdata.com)
• Echtzeit-Prävention + Enterprise-Vollintegration → Shift Technology
• Prozessdiagnose als Vorarbeit → Celonis
• Eigenentwicklung mit interner Data-Science → Dataiku
• Bestehendes SAS-Ökosystem → SAS Fraud Management

Datenschutz und Datenhaltung

Claims-Leakage-Erkennung verarbeitet hochsensible Daten: personenbezogene Daten von Versicherungsnehmern, Gesundheitsdaten in Personenschadenregulierungen, Bankverbindungen, Schadenfotos, ärztliche Gutachten. Das bedeutet: maximale DSGVO-Sensibilität.

DSGVO Art. 22, automatisierte Entscheidungen Wenn das Leakage-Scoring dazu führt, dass eine Auszahlung verzögert oder verweigert wird, ohne dass ein Mensch die Entscheidung trifft, greift DSGVO Art. 22 über automatisierte Einzelentscheidungen mit erheblicher Wirkung. Für die Versicherungsbranche gilt § 37 BDSG als nationale Ausnahmeregel, er erlaubt automatisierte Entscheidungen in der Versicherungsleistungserbringung, sofern die Person das Recht auf menschliche Überprüfung hat. In der Praxis bedeutet das: Keine automatische Markierung darf direkt zu einer Auszahlungssperre führen, immer muss ein menschlicher Sachbearbeiter die finale Entscheidung treffen.

Dieser Abschnitt ist eine fachliche Orientierung, keine Rechts- oder Complianceberatung. Für verbindliche Einschätzungen zu BaFin-Anforderungen, Art. 22 DSGVO oder § 37 BDSG wende dich an einen Fachanwalt für Versicherungsrecht.

BaFin-Explainability-Anforderung Die BaFin hat 2024 explizit betont: KI-Modelle in der Schadenregulierung dürfen nur eingesetzt werden, wenn ihre Entscheidungen erklärbar sind. Ein Black-Box-ML, das Schadensfälle markiert, ohne nachvollziehbare Begründung, entspricht nicht den aufsichtsrechtlichen Anforderungen. Vertraglich musst du mit jedem Anbieter vereinbaren, dass SHAP-Werte (oder gleichwertige Erklärbarkeitsmetriken) je markiertem Fall ausgegeben werden.

Dieser Abschnitt ist eine fachliche Orientierung, keine Rechts- oder Complianceberatung. Für verbindliche Einschätzungen zu BaFin-Anforderungen oder VVG-Pflichten wende dich an einen Fachanwalt für Versicherungsrecht.

Datenhaltung praktisch:

• Shift Technology: EU-Datenhaltung verfügbar; DSGVO-konformes Setup möglich, aber explizit vertraglich einfordern
• NTT DATA CLIP: Deutsche Implementierung; Datenhaltung in Deutschland vertraglich fixierbar
• Dataiku: Kann on-premise oder in deutschen Cloud-Regionen (Azure Germany North, AWS eu-central-1) betrieben werden, maximale Kontrolle
• Celonis: EU-Datenhaltung konfigurierbar; AVV standardmäßig verfügbar

AVV (Auftragsverarbeitungsvertrag) ist bei allen genannten Anbietern Pflicht und muss vor dem Start des Pilotprojekts unterzeichnet sein.

Was es kostet, realistisch gerechnet

Phase 1: Retroaktives Portfolio-Audit (3–6 Monate)

• NTT DATA CLIP-Pilotaudit: Erfahrungsgemäß im Bereich 80.000–250.000 Euro als Consulting-Projekt, abhängig von Datenmenge und Spartenbreite (Schätzwert; auf Anfrage bei NTT DATA)
• Intern: 20–40 Stunden Datenvorbereitung plus Abstimmungsaufwand mit IT und Compliance
• Erwartetes Ergebnis: Quantifiziertes Leakage-Potenzial nach Sparte, die Grundlage für den Business Case der Vollintegration

Phase 2: Echtzeit-Integration (9–18 Monate)

• Shift Technology oder vergleichbare Plattform: Enterprise-Lizenz, keine öffentliche Preisliste. Erfahrungsgemäß sechs- bis siebenstellige Investitionen für Implementierung plus Jahreslizenz. ROI-basierte Vertragsmodelle (Beteiligung am identifizierten Leakage) werden teilweise angeboten.
• Interne Kosten: IT-Ressourcen für CMS-Integration (Guidewire, SAP FS-CM, msg.Insurance), Datenvorbereitung, Testing und Change Management, typisch 2–4 interne FTE über 12 Monate.
• Laufend: Modell-Monitoring, vierteljährliches Retraining, Pflege der Deckungsregel-Bibliothek.

Was du dagegenrechnen kannst Ein Versicherer mit 300 Millionen Euro Schadenvolumen und 8 % Leakage-Quote hat theoretisch 24 Millionen Euro Leakage im Jahr. Wenn das System 30 % davon verhindert oder identifiziert (konservative Annahme): 7,2 Millionen Euro, im ersten Jahr nach Vollbetrieb. Selbst wenn du nur 50 % dieser Einsparung tatsächlich realisierst (weil weiches Leakage nicht vollständig verhindert wird und hartes Leakage nicht immer rückforderbar ist): 3,6 Millionen Euro jährlicher Netto-Benefit ist für die meisten Versicherer eine klare positive Rechnung.

Der entscheidende Schritt: nicht die Vollimplementierung als erstes verkaufen, sondern das Pilot-Audit. Ein Audit für 200.000 Euro, das 2 Millionen Euro Leakage-Potenzial aufzeigt, verkauft sich selbst.

Drei typische Einstiegsfehler

1. Leakage-Erkennung und Betrugserkennung als ein System planen Die Versuchung ist groß: beide Systeme arbeiten mit Schadensdaten, beide markieren Ausreißer. Aber die Trainingsdaten, die Modellarchitektur, die Eskalationswege und die rechtlichen Anforderungen sind fundamental verschieden. Betrugserkennungssysteme sind für die SIU (Special Investigation Unit) optimiert und produzieren rechtsfeste Dokumentation für Strafverfolgung. Leakage-Systeme sind für Sachbearbeiter und Innenrevision optimiert und produzieren Verbesserungshinweise. Wer beide in einem gemeinsamen Modell entwickelt, landet nach 9 Monaten mit einem System, das Betrug mit zu vielen Falsch-Positiven übersieht und Leakage-Hinweise produziert, die vor Gericht nicht verwertbar sind, weil das Training auf gemischten Labels keine saubere Entscheidungsgrenze lernt. Lösung: Zwei separate Scoring-Layer mit getrennten Trainingsdaten, getrennten Schwellenwerten und getrennten Eskalationspfaden, von Projektbeginn an.

2. Starten ohne saubere Datenbasis Claims-Leakage-ML braucht konsistente, vollständig ausgefüllte Schadensdaten über mindestens 3 Jahre. In der Praxis findet man: unterschiedliche Schadenscodes in verschiedenen Jahren (Taxonomy-Änderungen), fehlende Felder in Altfällen, inkonsistente Deckungs-Kennzeichnung, Daten in mehreren System-Generationen. Wer ohne Daten-Audit einsteigt, trainiert ein Modell auf gemischte Qualität, und bekommt schlechte Modell-Performance zurück. Lösung: 4–6 Wochen Daten-Audit und -Bereinigung vor dem Modellbau einplanen.

3. Falsch-Positive ignorieren statt monitoren Das ist der regulatorisch gefährlichste Fehler. Wenn das Leakage-System zu viele legitime Fälle markiert und damit die Regulierungsdauer verlängert, entsteht eine VVG-Problematik: Der Versicherer ist verpflichtet, unstrittigen Schadenersatz unverzüglich zu leisten (§ 14 VVG). Systematische Verzögerungen durch übertriebenes Flagging können als Regulierungserschwernis gewertet werden. Lösung: Eine klare False-Positive-Rate als KPI definieren (erfahrungsgemäß unter 10 % der markierten Fälle sollten sich als unbegründet herausstellen), wöchentlich monitoren, und Modell-Thresholds anpassen.

Dieser Abschnitt ist eine fachliche Orientierung, keine Rechts- oder Complianceberatung. Für verbindliche Einschätzungen zu VVG §14 oder BaFin-Anforderungen bei Regulierungsverzögerungen wende dich an einen Fachanwalt für Versicherungsrecht.

4. Kein Modell-Retraining einplanen Claims Leakage ML ist kein fire-and-forget-System. Reparaturkosten inflationieren, das verändert die Referenzwerte für Kfz-Schäden. Gerichtsentscheidungen zu Personenschäden ändern Benchmark-Beträge. Neue Klauselgenerationen kommen in den Bestand. Ein Modell, das 2024 trainiert wurde und 2026 unverändert läuft, markiert entweder zu viele Fälle (weil die Welt sich verändert hat) oder zu wenige. Quartalsweises Retraining ist das Minimum, und muss als laufende Betriebsaufgabe eingeplant sein, nicht als Einmalaufwand.

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

Die technische Implementierung ist das, was im Projektplan steht. Was nicht im Projektplan steht, ist das Schwierigere.

Sachbearbeiter-Widerstand gegen „automatische Besserwisser” Ein System, das einem erfahrenen Sachbearbeiter sagt, dass seine Regulierung 43 % über dem Median liegt, wird nicht widerstandslos akzeptiert. Die typische Reaktion: „Das war ein komplizierter Fall, das System versteht den Kontext nicht.” Oft hat der Sachbearbeiter sogar recht, der Kontext fehlt tatsächlich. Die Lösung ist nicht technisch, sondern organisatorisch: Erstens muss jeder Flag eine erklärbare Begründung liefern (welche Merkmale haben den Score ausgelöst), nicht nur einen Score. Zweitens muss die Unternehmensführung klar kommunizieren, dass Sachbearbeiter den Flag mit Begründung zurückweisen dürfen und darin ausdrücklich bestärkt werden, das System ist ein Hinweis, kein Urteil.

Die Innenrevision als Verbündeter, nicht als Bremse Leakage-Erkennung stärkt die Innenrevision strukturell, sie bekommt 100 % Abdeckung statt Stichproben. Das ist für viele Revisionsleiter ein echter Gewinn. Nutze das: Binde die Innenrevision früh in die Definition der Leakage-Kategorien ein. Was gilt als Leakage, was als legitime Regulierungsvariation? Diese Frage ist nicht technisch, sie ist inhaltlich, und die Innenrevision hat die Antworten.

Falsche Erwartungen an Rückforderungsquoten Nicht jedes identifizierte harte Leakage ist rückforderbar. Verjährungsfristen nach BGB (§ 195: 3 Jahre) begrenzen das Rückholpotenzial aus alten Portfolios. Manche Überzahlungen sind regulatorisch zwar korrekt gewesen, aber prozessual unglücklich, kein Rückforderungsrecht. Und aggressive Rückforderungen gegenüber Versicherungsnehmern schaffen Reputationsrisiken. Internes Leakage (zu hohe Sachverständigengebühren, ineffiziente Werkstattverhandlungen) ist politisch einfacher zu adressieren als externes.

Dieser Abschnitt ist eine fachliche Orientierung, keine Rechts- oder Complianceberatung. Für verbindliche Einschätzungen zu Verjährungsfristen nach § 195 BGB, Rückforderungsansprüchen gegenüber Versicherungsnehmern oder Haftungsfragen bei ML-gestützter Schadenprüfung wende dich an einen Fachanwalt für Versicherungsrecht.

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände, und was dahintersteckt

„Wir kennen unsere Regulierungsqualität, wir haben erfahrene Sachbearbeiter.” Das stimmt, und die Erfahrung ist wertvoll. Aber auch erfahrene Sachbearbeiter kennen nicht alle 200 Policenvarianten mit allen Klauseln auswendig. Das Problem ist nicht Inkompetenz, sondern Komplexität und Volumen. Ein Sachbearbeiter, der 80 Fälle im Monat bearbeitet, kann nicht bei jedem Fall alle Deckungsklauseln gegen alle historischen Vergleichsfälle prüfen. Das System tut das, schneller und konsistenter, nicht besser im Urteil, aber breiter in der Abdeckung.

„Das macht uns rechtlich angreifbar, wenn wir Schäden re-prüfen.” Das ist ein reales Risiko, aber ein handhabbares. Wenn du externe Versicherungsnehmer auf Basis von ML-Flags zu Rückzahlungen aufforderst, brauchst du rechtlich belastbare Begründungen. Der ML-Flag allein ist keine Grundlage für eine Rückforderung. Die Überprüfung muss durch einen Sachbearbeiter mit sachlicher Begründung erfolgen. Bei internen Leakage-Potenzialen (Werkstattgebühren, Sachverständigenkosten) ist das Risiko deutlich geringer. Lass dich von einem Versicherungsrechtsexperten beraten, welche Szenarien welches Rückforderungsrecht begründen.

Dieser Abschnitt ist eine fachliche Orientierung, keine Rechts- oder Complianceberatung. Für verbindliche Einschätzungen zu Rückforderungsansprüchen, BGB-Verjährung oder Haftungsrisiken bei ML-gestützter Schadenprüfung wende dich an einen Fachanwalt für Versicherungsrecht.

„Wir haben die Daten nicht strukturiert genug.” Das ist der häufigste und ehrlichste Einwand. Viele Versicherer wissen, dass ihre Schadensdaten in mehreren System-Generationen liegen, inkonsistent kodiert sind oder Felder systematisch leer sind. Die gute Nachricht: Das ist lösbar, aber es dauert länger als gedacht. Der Daten-Audit am Anfang ist kein bürokratischer Schritt, sondern der Kern des Projekts. Wer glaubt, er könne den Daten-Audit überspringen und direkt mit dem ML anfangen, wird nach 3 Monaten mit einem Modell dastehen, das auf Datenmüll trainiert wurde.

Woran du merkst, dass das zu dir passt

Du bist gut positioniert für Claims-Leakage-Erkennung, wenn:

• Du verarbeitest mindestens 30.000–50.000 Schadensmeldungen pro Jahr, darunter sind die statistischen Grundlagen für ein ML-Modell zu dünn
• Du hast strukturierte Schadensdaten aus mindestens 3 Jahren in einem einheitlichen System, mehrere System-Generationen oder inkonsistente Kodierung machen den Daten-Aufbereitungsaufwand prohibitiv
• Du hast eine Innenrevision oder ein Schaden-Audit-Team, das heute Stichproben manuell prüft, die brauchen das System und werden es verteidigen
• Deine Schadenquote ist in den letzten 2–3 Jahren gestiegen ohne klaren strukturellen Grund, das ist ein Hinweis, dass Leakage wächst
• Du hast ein modernes CMS (Guidewire, SAP FS-CM, msg.Insurance) und eine IT-Abteilung, die API-Integrationen bauen kann

Drei harte Ausschlusskriterien, wer es noch nicht tun sollte:

1. Unter 30.000 Schadenfälle pro Jahr (Unternehmensgröße): Das statistische Fundament für ein ML-Modell fehlt. Leakage-Analyse für kleine Portfolios funktioniert besser mit regelbasierten Systemen und gezielten manuellen Audits, kein ML erforderlich.

2. Keine konsistente Schadensdaten-Taxonomie über mindestens 3 Jahre (Datenreife): Wenn Schadentypen in verschiedenen Jahren unterschiedlich kodiert wurden, wenn Pflichtfelder systematisch leer sind, oder wenn die Datenmigration aus Legacy-Systemen nie abgeschlossen wurde, wird das Modell auf unzuverlässigen Trainingsdaten aufgebaut. Das Ergebnis: hohe False-Positive-Rate, niedriges Vertrauen der Sachbearbeiter, Projektstop nach 12 Monaten.

3. Kein modernes Claims-Management-System für Echtzeit-Integration (Infrastrukturreife): Wer seine Schäden noch in einer proprietären AS/400-Applikation verwaltet oder mit Excel-gestützten Workflows arbeitet, kann kein Echtzeit-Scoring integrieren. Das retroaktive Audit ist noch möglich (Datenexport als Basis), aber der eigentliche Wert, Prävention in Echtzeit, ist ohne CMS-Integration nicht erreichbar.

Das kannst du heute noch tun

Der schnellste Einstieg ohne großes Commitment: Führe intern ein Mini-Audit durch. Wähle eine Sparte aus (idealerweise Kfz-Haftpflicht, weil die Vergleichbarkeit der Fälle hoch ist) und ziehe die letzten 200–300 abgeschlossenen Fälle. Schau dir die Verteilung der Auszahlungsbeträge an: Wie viel Varianz gibt es? Gibt es Ausreißer, die auf den ersten Blick auffallen?

Das dauert einen halben Tag. Wenn du dabei Fälle findest, bei denen du dich fragst, warum der Betrag so hoch war, dann hast du dein erstes internes Argument für ein systematisches Audit.

Für den strukturierten nächsten Schritt: Nutze den folgenden Prompt, um einen ersten Leakage-Analyse-Rahmen für eine manuelle Stichprobe zu erstellen.

Quellen & Methodik

• NTT DATA CLIP-Brochure: „Weniger Claims Leakage, weniger Schadenkosten” (de.nttdata.com, 2024). Leakage-Potenziale von 6–12 % (Kfz/Haftpflicht/Unfall), 7–11 % (Personenschäden), 10–18 % (Hausrat); ca. 15 deutsche Versicherer als Nutzer; 50–80 % schnellere Closed-Files-Review.
• Shift Technology, AXA Switzerland Case Study (shift-technology.com, 2025). 3 % niedrigere Schadenkosten, 30 % schnellere Regulierung, 60 % Automatisierungsrate, über 99 % Bewertungsgenauigkeit. AXA-weite Partnerschaft in 15 Ländern, über 1 Million analysierte Schäden, €12M+ Betrug gestoppt.
• VCA Software, Understanding Claims Leakage (vcasoftware.com, 2024). Branchenweite Leakage-Quote 5–10 % der Schadenaufwendungen; Beispiel Midsize-Versicherer: 3,2 Mio. USD jährliches Leakage.
• BaFin-Fachartikel „KI bei Banken und Versicherern: Automatisch fair?” (bafin.de, August 2024). KI-Modelle in der Schadenregulierung nur zulässig, wenn Erklärbarkeit gewährleistet; Diskriminierungsrisiken bei automatisierten Prozessen.
• DSGVO Art. 22 und § 37 BDSG: Automatisierte Einzelentscheidungen in der Versicherungsleistungserbringung. BGH-Urteil vom 27.03.2025 (SCHUFA): Recht auf Erklärung der wesentlichen Score-Faktoren bestätigt.
• Hard/Soft Leakage Taxonomie: Workers’ Compensation Claims Leakage-Definitionen (wcabdefense.com und amaxx.com, Praxisberichte aus der Regulierung).
• Implementierungskosten: Schätzwerte aus Branchenpraxis und NTT DATA-Projektbeispielen; keine verifizierten Listenpreise verfügbar, Enterprise-Konditionen auf Anfrage.

Du willst wissen, ob dein Schadenportfolio das statistische Volumen für ein ML-Modell mitbringt, und welche Sparte der sinnvollste Einstieg wäre? Meld dich für ein kurzes Gespräch.