Subrogation Mining Haftungsanalyse

Das echte Ausmaß des Problems

Die Zahlen aus dem US-amerikanischen Versicherungsmarkt, wo das Thema am besten erforscht ist, illustrieren die Dimension: Die National Association of Insurance Commissioners (NAIC) schätzt, dass die Branche jährlich rund 15 Milliarden US-Dollar in verpassten Subrogationsrecoveries verliert — weil berechtigte Regressansprüche nie eingeleitet werden. Die Ursache ist selten Fahrlässigkeit; sie ist strukturell: Haftungsindizien stecken in Freitext.

Sachbearbeiterberichte, Werkstattgutachten, Polizeiberichte, Lieferantenkorrespondenz, Zeugenaussagen — das sind die Dokumenttypen, in denen Formulierungen wie „fehlerhafte Montage durch den Subunternehmer”, „Produktdefekt wurde vom Kunden erwähnt”, „Drittfahrzeug verursachte Auffahrunfall” oder „Wasserrohrbruch durch Baufehler” auftauchen. Ein erfahrener Regressspezialist würde diese Phrasen sofort als Haftungsindiz einordnen. Aber er liest nicht jeden Schaden — das ist logistisch unmöglich.

In der Praxis landet eine Regressprüfung nur dann auf dem Tisch der Spezialabteilung, wenn:

• ein Sachbearbeiter sie bewusst weiterleitet (selten, weil zeitintensiv und nicht Kernaufgabe)
• ein starres Regelwerk anschlägt (z.B. „KFZ-Schaden über 5.000 €, Drittbeteiligung im System markiert”)
• oder ein Kollege zufällig das Muster erkennt

Branchenerfahrungswerte sprechen von 30–60 % verpasster berechtigter Regressfälle. Shift Technology, ein spezialisierter InsurTech-Anbieter, berichtet, dass bei einem ihrer Versicherungskunden — einem der 25 größten US-Kfz- und Sachversicherer — durch KI-gestützte Subrogationserkennung monatlich über 1 Million US-Dollar in neu identifizierten Recovery-Chancen entsteht, die vorher systematisch nicht gesehen wurden.

HUK-Coburg — einer der größten deutschen Kfz-Versicherer — hat laut Versicherungsmagazin inzwischen jeden abgeschlossenen Schadensfall durch KI auf Regresspotenzial prüfen lassen. Das ist die richtige Reaktion auf ein bekanntes Problem.

Rechtliche Grundlage: § 86 VVG — Forderungsübergang kraft Gesetzes

Subrogation in Deutschland ist kein Ermessen, sondern Gesetz. § 86 Abs. 1 VVG regelt, dass ein Schadensersatzanspruch des Versicherungsnehmers gegen einen haftenden Dritten automatisch auf den Versicherer übergeht — in dem Moment, in dem der Versicherer die Schadenszahlung leistet. Der Versicherer tritt in die Rechtsposition des Versicherungsnehmers ein.

Das bedeutet in der Praxis:

• Automatischer Übergang: Kein gesonderter Abtretungsakt erforderlich. Zahlt der Versicherer, erwirbt er den Anspruch.
• Kongruenzerfordernis: Nur Ansprüche, die inhaltlich mit dem versicherten Schaden übereinstimmen, gehen über. Gedeckter Schaden und Regressanspruch müssen denselben Gegenstand betreffen.
• Befriedigungsvorrang des Versicherungsnehmers: Kann der Dritte nicht vollständig leisten, erhält der Versicherungsnehmer vorrangige Befriedigung. Erst danach bedient sich der Versicherer.
• Haushaltsprivileg (§ 86 Abs. 3 VVG): Lebt der Schädigende im selben Haushalt wie der Versicherungsnehmer, findet der Forderungsübergang nicht statt — außer bei Vorsatz.
• Mitwirkungsobliegenheit des Versicherungsnehmers (§ 86 Abs. 2 VVG): Der Versicherungsnehmer ist verpflichtet, den übergegangenen Anspruch zu sichern und die Geltendmachung zu unterstützen.

Für das KI-System bedeutet das: Es sucht nicht nur nach dem Wort „Dritter” — es sucht nach Formulierungen, die haftungsbegründende Kausalzusammenhänge implizieren, die zur übereinstimmenden Deckung des Schadens passen. Das ist ein semantisches, kein schlüsselwortbasiertes Problem. Genau deshalb versagt klassische Regellogik, und NLP ist überlegen.

Mit vs. ohne KI — ein ehrlicher Vergleich

Die Vergleichswerte zu Recovery-Steigerungen basieren auf Shift Technology (2024) und CLARA Analytics (2025). Die Falsch-Positiv-Rate hängt stark von der Modellqualität und dem Scoring-Schwellenwert ab.

Einschätzung auf einen Blick

Zeitersparnis — hoch (4/5) Die manuelle Prüfung aller Schadensberichte auf Haftungsindizien ist die zeitintensivste Phase im Regressmanagement. Ein System, das diesen Schritt vollständig automatisiert und nur noch markierte Fälle zur Prüfung vorlegt, spart der Regressabteilung 60–80 % der reinen Lesezeit. Warum kein voller Score: Das System eliminiert nicht die juristische Prüfung und Durchsetzung, die nach dem Flagging folgt — die bleibt Facharbeit.

Kosteneinsparung — hoch (4/5) Subrogation Mining ist einer der wenigen KI-Einsätze im Versicherungsbereich, bei dem der Nutzen direkt in eingehenden Zahlungen messbar ist. Jeder erfolgreich durchgesetzte Regressfall bringt 2.000–50.000 Euro zurück. Bei 10.000 Schadensfällen jährlich und 10 % identifizierter Regresspotenziale bedeutet eine 40-%-Steigerung der Einleitungsrate: 400 zusätzliche Fälle in Prüfung — davon ein Teil erfolgreich recovered. Warum kein Score 5: Die Einleitungsrate ist nicht die Erfolgsrate; juristische Durchsetzung und Gegenpartei-Solvabilität sind separate Faktoren.

Schnelle Umsetzung — mittel (3/5) Das ist die Position in der Mitte des Branchenspektrums — bewusst. Schneller als komplett neue Risikomodelle (Score 1–2), aber langsamer als textbasierte KI-Werkzeuge ohne Annotationsphase. Die Annotation historischer Schadensberichte für das NER-Training dauert 4–8 Wochen, die Integration ins bestehende Schadensystem weitere 4–8 Wochen. Wer Hugging Face-Infrastruktur oder fertige SaaS-Lösungen wie Shift Technology nutzt, kann das auf 3 Monate drücken — aber nicht unter 8 Wochen ohne ernsthafte Kompromisse bei der Modellgüte.

ROI-Sicherheit — hoch (4/5) Der Nutzen ist direkt und präzise messbar: Subrogations-Einleitungsrate vor und nach. Das macht diesen Use Case robuster gegen ROI-Unsicherheit als indirekte Effizienzgewinne. Warum kein Score 5: Die Recovery-Rate (Anteil eingeleiterter Fälle, die tatsächlich Geld zurückbringen) hängt von juristischen und operativen Faktoren ab, die das KI-System nicht beeinflusst.

Skalierbarkeit — sehr hoch (5/5) Jede weitere Schadensparte, jede weitere Dokumentensprache, jeder zusätzliche Kanal (E-Mail-Korrespondenz, Telefonmemo-Transkripte) kann mit demselben Pipeline-Grundgerüst erschlossen werden. Die Grenzkosten für den 100.001. analysierten Schaden sind marginal — anders als bei manueller Prüfung, die linear mit Fallvolumen skaliert.

Richtwerte — stark abhängig von Schadensvolumen, Dokumentenqualität und vorhandener Systemlandschaft.

Was das Subrogation-Mining-System konkret macht

Das System ist keine Stichwortsuche und kein starres Regelwerk. Es ist eine NLP-Pipeline, die semantischen Gehalt versteht, nicht nur Zeichenketten.

Schritt 1: Dokumenteneinspeisung Beim Fallabschluss (oder an definierten Auslösepunkten im Schadensworkflow) werden alle zugeordneten Dokumente eingespeist: der Sachbearbeiterbericht, Werkstattgutachten, Polizeiberichte, Zeugenaussagen, Lieferantenkorrespondenz und ggf. Fotos mit Bildunterschriften. Strukturierte Metadaten (Schadenart, Summe, Sparte) kommen als Kontext hinzu.

Schritt 2: Entitätsextraktion mit Named Entity Recognition Das NER-Modell identifiziert im Fließtext die relevanten Entitäten:

• Drittparteien: Personen, Firmen, Fahrzeuge, Behörden — als potenzielle Haftungssubjekte
• Haftungsindizien: Formulierungen wie „fehlerhaft montiert”, „Anweisungen nicht befolgt”, „Produktfehler”, „bauliche Mängel”, „Fahrfehler des Drittfahrers”
• Kausalketten: Sprachliche Verbindungen zwischen dem Schaden und der Drittpartei (z.B. „wurde durch”, „infolge”, „aufgrund von”)
• Beweismittel-Hinweise: Erwähnungen von Zeugen, Fotos, Gutachten, Kennzeichen, Polizeiprotokollen

Schritt 3: Relation Extraction Entitäten allein reichen nicht. Das System prüft, ob eine erkannte Drittpartei auch in Beziehung zu einem Haftungsindiz steht. „Die Werkstatt XY war am Unfall beteiligt” ist schwächer als „Die Werkstatt XY hat die Bremsanlage falsch montiert, was den Unfall verursachte.” Relation-Extraction-Modelle ordnen semantische Rollen zu.

Schritt 4: Subrogation-Score und Evidenz-Zusammenfassung Alle Signale werden in einem Score aggregiert (0–100). Fälle über dem Schwellenwert — typisch 60–70 — werden in der Regressabteilung zur Prüfung vorgelegt, zusammen mit einer strukturierten Evidenz-Zusammenfassung: Welche Formulierungen haben den Score getrieben? Welche Drittpartei wurde identifiziert? Welche Dokumente waren die Quellen?

Der entscheidende Vorteil gegenüber Regelwerken: Keine Haftungsformulierung sieht exakt gleich aus. „Der Subunternehmer hat die Leitung falsch verlegt”, „Die Rohrverlegung war mangelhaft”, „Das Wasser trat durch einen Installationsfehler aus” — das sind drei verschiedene Ausdrucksweisen für dieselbe Haftungsgrundlage. Ein Regelwerk braucht für jede Variante eine eigene Regel. Ein NLP-Modell generalisiert.

Die Signalwörter und Dokumenttypen, auf die es ankommt

Nicht jeder Dokumenttyp ist gleich ergiebig. Im Betrieb liefern bestimmte Quellen systematisch mehr verwertbare Signale als andere.

Hochergiebige Dokumenttypen:

• Werkstattgutachten und Sachverständigengutachten: Beschreiben Schadensursachen technisch präzise. Formulierungen wie „Materialfehler”, „nicht normgerechte Ausführung”, „Montagefehler” sind klare Haftungsindizien gegenüber Hersteller oder Handwerker.
• Polizeiberichte und Verkehrsunfallaufnahmen: Enthalten Verantwortlichkeitszuweisungen, Kennzeichen von Drittfahrzeugen, Zeugenangaben — hohe Strukturiertheit erleichtert die Extraktion.
• Sachbearbeiternotizen (Freitext): Qualitativ heterogen, aber oft die einzige Quelle für Details, die nirgendwo anders dokumentiert sind. Mündliche Angaben des Geschädigten landen häufig nur hier.

Mittelergiebige Dokumenttypen:

• Lieferantenkorrespondenz und Auftragsbestätigungen: Relevant bei Produkthaftungsfällen. Enthalten Produktbeschreibungen, Liefermengen, Qualitätszusagen.
• Abrechnungen und Rechnungen: Weisen die Art der geleisteten Arbeit aus — als Kontext für die Kausalkette wichtig.

Niedrigergiebig (aber nicht ignorierbar):

• Fotos: Metadaten, Bildunterschriften, Ortsbeschreibungen können Drittparteien identifizieren.
• Standardformulare mit Ankreuzfeldern: Strukturiert, aber arm an semantischer Information. Hier liefert klassische Regellogik oft mehr als NLP.

Sprache der Signale: Das Modell muss auf deutschsprachigen Versicherungstexten trainiert werden. Generische englische NLP-Modelle performen auf dem domänenspezifischen deutschen Fachjargon schlecht. Das ist der Hauptgrund, warum Annotation auf eigenem Datenmaterial unverzichtbar ist.

Konkrete Werkzeuge — was wann passt

Die Wahl des technischen Ansatzes hängt von Volumen, internen Entwicklerkapazitäten und dem Budget ab.

spaCy — wenn du eine maßgeschneiderte, vollständig on-premise betreibbare NER-Pipeline willst Das ist der bevorzugte Ansatz für Versicherer, die volle Datensouveränität brauchen (DSGVO, Berufsgeheimnis, interne Compliance). spaCy bietet deutsche Sprachmodelle out-of-the-box und erlaubt das Training auf eigenen Entitätstypen. Nachteil: erfordert ML-Know-how und einen annotierten Trainingskorpus (200–400 Beispiele pro Entitätstyp). Kosten: nahezu null für die Bibliothek selbst; Aufwand liegt in Annotation und Entwicklung.

Hugging Face — wenn du größere Transformer-Modelle für höhere Genauigkeit brauchst Hugging Face hostet vortrainierte BERT- und RoBERTa-Modelle für Deutsch (z.B. deepset/gbert-large), die als NER-Basismodell fine-getunt werden können. Höhere Parameteranzahl bedeutet in der Regel bessere Generalisierung auf seltene Formulierungsvarianten. EU-Hosting über Team-Plan verfügbar. Anforderungen: Python/ML-Know-how, GPU-Infrastruktur für Produktion.

Azure Document Intelligence — für die Dokumenten-Vorstufe (OCR, Strukturextraktion) Bevor NLP angewendet werden kann, müssen Dokumente eingelesen werden. Azure Document Intelligence extrahiert Text aus gescannten Gutachten, handschriftlichen Notizen und strukturierten Formularen. EU-Region verfügbar, DSGVO-konform. Sinnvoll als Vorstufe vor der eigentlichen NER-Pipeline.

LangChain — für die Orchestrierung der Gesamtpipeline Wenn du mehrere Komponenten (Dokumentenextraktion → NER → Scoring → Workflow-Trigger) miteinander verbinden willst, eignet sich LangChain als Orchestrierungsschicht. Besonders nützlich, wenn Generative KI-Komponenten (z.B. eine abschließende Evidenz-Zusammenfassung per LLM) in die Pipeline integriert werden sollen.

Spezialisierte SaaS-Lösungen (Shift Technology, CLARA Analytics, Safekeep) — für Versicherer ohne interne KI-Entwicklung Shift Technology bietet eine fertige Subrogation-KI mit Guidewire-Integration und berichtet für einige Kunden von über 1 Million USD monatlicher Recovery-Steigerung. CLARA Analytics hat im Mai 2025 ein KI-gestütztes Subrogation-Detection-Produkt eingeführt und gibt 8–12 Wochen Implementierungszeit nach Datenbereitstellung an. Preislich: Enterprise-SaaS, typisch im fünf- bis sechsstelligen Euro-Bereich jährlich. Kein echter Vergleich zu Open-Source-Eigenentwicklung, aber auch kein Annotationsaufwand und keine ML-Kapazität intern erforderlich.

Zusammenfassung: Wann welcher Ansatz

• Interne ML-Kapazität vorhanden, Datensouveränität Pflicht → spaCy on-premise
• Höhere Genauigkeit gewünscht, EU-Cloud akzeptabel → Hugging Face Team-Plan
• Kein internes ML-Team, schnelle Time-to-Value → SaaS-Lösung (Shift, CLARA)
• Gemischtes Dokumentenformat mit Scans → Azure Document Intelligence als Vorstufe

Integration in bestehende Schadensysteme — die unterschätzte Herausforderung

Technisch ist das NER-Modell der einfachere Teil. Die eigentliche Komplexität liegt in der Integration: Das System muss dort andocken, wo Schadensberichte entstehen und abgelegt werden.

Guidewire ClaimCenter ist das international weitverbreitetste Claims-Management-System auch bei deutschen Versicherern. Shift Technology bietet einen fertigen Guidewire-Accelerator; eigene Entwicklungen können über die Guidewire-API (REST/SOAP) angebunden werden. Wichtig: Guidewire-Versionen variieren stark; Cloud-Varianten (Guidewire Cloud) haben andere API-Endpunkte als on-premise-Installationen.

Sapiens ALIS und Sapiens ClaimsCore sind im europäischen Markt verbreitet. Sapiens stellt eine offene API-Architektur bereit, über die externe Analyse-Services angebunden werden können. Die Dokumentation ist weniger öffentlich zugänglich als bei Guidewire — in Evaluationsprojekten empfiehlt sich ein frühes Gespräch mit dem Sapiens-Accountmanager.

OpenText Documentum und OpenText Claims Management kommen als kombinierte Dokumenten- und Workflow-Plattform vor. OpenText bietet eigene KI-Services an, unterstützt aber auch den Anschluss externer NLP-Pipelines über REST-APIs.

Eigenentwickelte oder Legacy-Systeme (in Deutschland nicht unüblich bei regionalen Versicherern und Gegenseitigkeitsgesellschaften): Hier ist eine Datenbankabfrage oder ein Dateiexport-Hook oft der pragmatischste Integrationsweg — keine elegante, aber funktionierende Lösung für eine Pilotphase.

Die Integration sollte nicht unterschätzt werden: In Praxisprojekten entsteht 40–60 % des Gesamtaufwands durch die Systemanbindung, nicht durch die Modellentwicklung. Wer das erst nach der Modellfertigstellung realisiert, gerät in Verzug.

Datenschutz und Datenhaltung

Schadensberichte enthalten per Definition personenbezogene Daten — Adressdaten der Geschädigten, Unfallschilderungen, Zeugenangaben, manchmal Gesundheitsinformationen bei Personenschäden. Damit gilt die DSGVO mit allen Konsequenzen.

Was das für die Tool-Wahl bedeutet:

• On-Premise-Betrieb (spaCy, lokale Modelle): Keine Daten verlassen das eigene Rechenzentrum. Kein Auftragsverarbeiter, kein AVV erforderlich. Empfehlenswert für Versicherer mit strikten Compliance-Anforderungen.
• Hugging Face Team-Plan mit EU-Storage-Region: Daten werden in der EU verarbeitet (OVHCloud Frankreich), AVV verfügbar. Angemessene Option, wenn Cloud-Infrastruktur akzeptiert wird.
• Azure Document Intelligence: EU-Region verfügbar (West Europe), AVV über Microsoft Enterprise Agreement. DSGVO-konform umsetzbar.
• SaaS-Lösungen (Shift Technology, CLARA): Datenhaltung und AVV müssen einzelfallbezogen verhandelt werden. Typisch US-Unternehmen, die aber auf Nachfrage EU-Hosting und Data Processing Agreements anbieten. Für Versicherer mit Aufsichtsbehörde BaFin: Prüfe, ob Auslagerungsanzeige nach § 25b KWG bzw. Versicherungsaufsichtsrechtliche Anforderungen erfüllt werden.

Besonderheit Gesundheitsdaten bei Personenschäden: Enthalten die Schadensberichte ärztliche Informationen oder Diagnosen, gelten diese als besondere Kategorien personenbezogener Daten nach Art. 9 DSGVO. Die Verarbeitung erfordert eine ausdrückliche Rechtsgrundlage. Lass das vor dem Start des Betriebs durch Datenschutzbeauftragte und Rechtsabteilung prüfen.

Auftragsverarbeitungsvertrag (AVV): Bei jeder Cloud-Verarbeitung Pflicht. Alle genannten Anbieter stellen AVV-Vorlagen bereit — aber du musst sie aktiv anfordern und unterschreiben, bevor die ersten Schadensberichte verarbeitet werden.

Was es kostet — realistisch gerechnet

Variante A: Eigenentwicklung (spaCy / Hugging Face on-premise)

• Annotationsaufwand: 200–400 Beispiele pro Entitätstyp, 3–4 Entitätstypen. Bei 15–20 Minuten pro Annotation mit einem Fachexperten: ca. 150–200 Stunden Annotationsarbeit intern. Bei einem vollzeitbeschäftigten Regressspezialisten bedeutet das ca. 4–5 Wochen Teilzeit.
• Entwicklungsaufwand (NLP-Pipeline, Integration, Inbetriebnahme): 3–5 Personenwochen eines Python-Entwicklers mit NLP-Erfahrung.
• Hardware: Ein GPU-Server für Produktion (NVIDIA L4 oder T4), entweder on-premise (~5.000–8.000 € Hardware) oder Cloud-VM (~300–600 €/Monat).
• Einmalige Gesamtkosten: realistisch 20.000–50.000 € (intern + extern, ohne laufende Hardware)
• Laufend: 300–600 €/Monat Infrastruktur + Pflegeaufwand intern

Variante B: SaaS-Lösung (Shift Technology, CLARA Analytics)

• Typisch: 40.000–120.000 €/Jahr (Enterprise-Preise, nicht öffentlich; Richtwert aus Marktbeobachtung)
• Implementierungsaufwand intern: gering (8–12 Wochen nach Datenbereitstellung laut CLARA)
• Dafür: kein Annotationsaufwand, kein ML-Team intern nötig

Was du dagegen rechnen kannst

10.000 Schadensberichte jährlich, davon 10 % mit erkanntem Regresspotenzial = 1.000 Fälle. Aktuell eingeleitet: 50 % = 500 Fälle. Mit System: 80 % = 800 Fälle. Zusätzliche 300 Fälle in Prüfung. Bei einer durchschnittlichen Recovery von 5.000 € pro erfolgreichem Fall und einer Erfolgsquote von 30 %: 90 zusätzliche Recoveries × 5.000 € = 450.000 € jährlicher Mehrwert. Das ist ein konservatives Szenario — bei höherem Schadensvolumen oder höherer Durchschnitts-Recovery entsprechend mehr.

Diese Rechnung setzt voraus, dass die Regressabteilung die zusätzlichen Fälle auch abarbeiten kann — ein wichtiger organisatorischer Vorbehalt.

Drei typische Einstiegsfehler

1. Das Modell auf englischsprachigen Daten trainieren und hoffen, dass es für deutsche Schadensberichte funktioniert. Das ist der häufigste Fehler bei Teams, die englischsprachige Open-Source-Modelle einsetzen, ohne den Unterschied zu bewerten. Versicherungs-Fachsprache auf Deutsch (“Regresswahrungspflicht”, “Kongruenzerfordernis”, “Alleinverschulden Dritter”) ist weder in generischen englischen noch in generischen deutschen Sprachmodellen ausreichend repräsentiert. Das Modell lernt diese Konzepte nur aus deinen eigenen annotierten Daten. Wer den Annotationsschritt überspringt, baut ein System, das auf Testdaten gut aussieht und in der Produktion systematisch die wichtigsten Signale übersieht.

2. Den Schwellenwert zu niedrig setzen — und die Regressabteilung mit Falsch-Positiven überfluten. Die erste Reaktion, wenn das Modell läuft, ist oft: “Niedriger Schwellenwert = mehr markierte Fälle = mehr Recovery.” Rechnerisch stimmt das kurzzeitig. Operativ zerstört es die Akzeptanz. Wenn 50 % der vorgeschlagenen Fälle nach fünf Minuten Prüfung als nicht regressfähig erkannt werden, hört die Regressabteilung auf, die Markierungen ernst zu nehmen. Der optimale Schwellenwert ist ein Verhandlungsergebnis zwischen Recall (möglichst wenig echte Fälle verpassen) und Precision (möglichst wenig Zeit mit Nicht-Fällen verschwenden). Er muss regelmäßig nachjustiert werden.

3. Nach der Inbetriebnahme nichts mehr tun. Dieses Modell veraltet. Schadenformulierungen ändern sich, neue Drittpartei-Typen entstehen (z.B. neue Produktkategorien in der Haftpflicht), Sachbearbeiter ändern ihre Schreibgewohnheiten. Ein NER-Modell, das 2024 auf 400 Schadensberichten trainiert wurde, zeigt 2026 schlechtere Performance — nicht weil es kaputtgegangen ist, sondern weil die Welt sich verändert hat. Das System braucht eine namentlich benannte Person mit Pflegeverantwortung und einen festen Retraining-Rhythmus (mindestens jährlich, besser halbjährlich, mit neu annotierten Fällen aus dem laufenden Betrieb).

Modellpflege — der unterschätzte Dauerbetrieb

Ein NER-Modell für Versicherungsschadensberichte braucht aktive Pflege — nicht als optionale Weiterentwicklung, sondern als Betriebsvoraussetzung. Drei konkrete Szenarien, in denen unbeaufsichtigte Modelle still degradieren:

Neue Schadensparten ohne Retraining: Das Modell wurde auf Kfz-Sachschäden trainiert. Ab Januar werden auch Leitungswasserschäden ins System eingespeist. Die Formulierungen für “Installationsfehler durch Handwerker” unterscheiden sich erheblich von Kfz-Kausalketten. Das Modell flaggt diese Fälle nicht — nicht weil es falsch konfiguriert ist, sondern weil es diese Domäne nicht kennt.

Sachbearbeiter-Fluktuation: Neue Sachbearbeiter schreiben anders. Wenn sie bevorzugt in tabellarischen Feldern statt Freitext dokumentieren, oder eine andere Formulierungskonvention mitbringen, bricht der Fließtext weg, aus dem das Modell lernt.

Score-Drift durch juristische Veränderungen: Neue BGH-Rechtsprechung ändert, welche Formulierungen rechtlich als Haftungsindiz gelten. Das Modell kennt diese Rechtsprechung nicht — es lernt nur aus annotierten Beispielen. Wer nicht nachtrainiert, baut auf veraltete Haftungskonzepte.

Empfehlung: Jedes Quartal 20–30 zufällig ausgewählte, frisch abgeschlossene Schadensberichte durch einen Fachexperten annotieren und mit den Modell-Scores vergleichen. Wenn die Übereinstimmung unter 80 % fällt, ist Retraining fällig. Das kostet 1–2 Tage intern — nicht einzuplanen kostet vielfach mehr.

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

Die Technik ist nicht die Hürde. Die Menschen sind es.

Die Sachbearbeiter verstehen nicht, was sich ändert — und fangen an, anders zu schreiben. Wenn bekannt wird, dass ein KI-System die Berichte scannt, verändert sich das Schreibverhalten. Manche Sachbearbeiter werden präziser (gut), andere fangen an, Formulierungen zu vermeiden, die ihnen aufwendigere Rückfragen bringen könnten (schlecht). Gegenmaßnahme: Das System transparent kommunizieren, die Entscheidungshoheit klar bei den Sachbearbeitern belassen (“die KI markiert, ihr entscheidet”), und explizit betonen, dass die Schreibgewohnheiten der Sachbearbeiter nicht bewertet werden.

Die Regressabteilung wird initial skeptisch. Wer jahrelang manuell gefiltert hat und weiß, wie viele Fehlalarme klassische Regelsysteme produzieren, bringt begründeten Skeptizismus mit. Gegenmaßnahme: In der Pilotphase nur stark-konfidenten Fällen (Score > 80) bearbeiten lassen und intern dokumentieren, wie viele davon tatsächlich regressfähig waren. Wenn die erste Bilanz stimmt, löst sich die Skepsis von selbst.

Die erste Ausbaustufe scheitert daran, dass die Regressabteilung nicht skaliert. Das System identifiziert 60 % mehr Fälle — aber die Regressabteilung hat dieselbe Personalkapazität. Das erzeugt einen Stau, nicht einen Nutzen. Gegenmaßnahme: Vor der Inbetriebnahme die Kapazitätsfrage klären. KI-identifizierte Fälle sind nicht gleichwertig — sie können nach Score und Recovery-Potenzial priorisiert werden, sodass Kapazitätsengpässe beherrschbar bleiben.

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände — und was dahintersteckt

„Wir haben doch schon ein Regelwerk für Regress.” Regelwerke flaggen strukturierte Merkmale: Schadenklasse, Schwellenwert, Drittbeteiligungsmerkmal im System. Was sie nicht sehen: den Fließtext, in dem die eigentlichen Haftungsindizien stecken. Ein Regelwerk kann “KFZ-Schaden über 5.000 € mit Drittpartei” finden. Es kann nicht “der Subunternehmer hat die Arbeitsanweisung nicht beachtet, laut Aussage des Gutachters” erkennen — weil das kein Datenbankfeld ist. Regelwerk und NLP schließen sich nicht aus; sie ergänzen einander.

„Was ist, wenn das Modell wichtige Fälle übersieht?” Das wird passieren — kein Modell hat 100 % Recall. Die entscheidende Gegenfrage: Was passiert heute, ohne das Modell? Die Antwort ist 30–60 % verpasste Regressfälle. Das Modell muss nicht perfekt sein; es muss besser sein als der Status quo. Der richtigen Einordnung nach der Inbetriebnahme helfen kontinuierliche Stichprobenprüfungen: Nimm jeden Monat 20 zufällig gewählte nicht-markierte Fälle und lass sie von einem Regressspezialisten kursorisch prüfen. Wenn nichts gefehlt wird, ist der Recall gut.

„Das ist zu aufwendig für uns — wir sind zu klein.” Das ist der einzige Einwand, der wirklich zutreffen kann. Unter 5.000–8.000 Schadensfällen jährlich lohnt sich der Eigenentwicklungsaufwand in der Regel nicht. SaaS-Lösungen können bis zu kleineren Volumina wirtschaftlich sein, aber auch hier gibt es Mindestgrößen. Die Abgrenzungsfrage steht weiter unten im Artikel.

Woran du merkst, dass das zu dir passt

Grünes Licht, wenn:

• Du hast mehr als 8.000 abgeschlossene Schadenfälle jährlich, davon mindestens 20–30 % mit nennenswerten Freitextanteilen in den Berichten
• Deine Regressabteilung hat heute weniger Fälle im Trichter als sie juristisch bearbeiten könnte — Kapazitätspuffer vorhanden
• Die Schadensberichte werden in einem zentralen System abgelegt und sind digital verfügbar (auch als Scan/OCR)
• Du hast internen Zugang zu ML-Know-how oder ein Budget für eine SaaS-Lösung (ab ca. 40.000 €/Jahr)
• Deine Schadensdaten enthalten Hinweise auf typische Regresskategorien: Kfz-Drittschäden, Leitungswasser (Handwerker), Gebäudeschäden (Baumängel), Produkthaftung

Harte Ausschlusskriterien — wer (noch) nicht anfangen sollte:

1. Unter ca. 5.000–8.000 Schadenfällen jährlich. Das Schadensvolumen reicht nicht, um die Annotation und Modellinfrastruktur wirtschaftlich zu amortisieren. Der Ertrag (zusätzliche Recovery-Fälle) unterschreitet die Einrichtungskosten. Ausnahme: Wenn der durchschnittliche Schaden besonders hoch ist (z.B. reine Industrieversicherung) und wenige Fälle großen Wert haben.

2. Schadensberichte existieren hauptsächlich als knappe Feldeinträge ohne Freitext. NER braucht Fließtext. Wenn Sachbearbeiter ihre Dokumentation in strukturierten Feldern (Checkbox: “Drittbeteiligung ja/nein”) statt als narrative Berichte führen, fehlt das Material für die Extraktion. Dann ist die Lösung nicht KI, sondern zunächst eine Änderung der Dokumentationskultur — oder eine bessere Nutzung der vorhandenen Strukturfelder mit Regellogik.

3. Kein digitaler Zugriff auf historische Schadensberichte für das Modelltraining. Ohne annotierten Trainingsdatensatz aus eigenen Schadensfällen lässt sich kein domänenspezifisches Modell bauen. Wenn die letzten drei Jahre Schadensberichte in Papierarchiven liegen, muss zuerst digitalisiert werden — das ist eine separate Aufgabe mit eigenem Aufwand und sollte nicht unterschätzt werden.

Das kannst du heute noch tun

Bevor du über Modelle und Systeme nachdenkst: Nimm die letzten 50 abgeschlossenen Schadenfälle deines Hauses und lass einen erfahrenen Regressspezialisten prüfen, wie viele davon Haftungsindizien enthalten, die nicht in der Regressabteilung gelandet sind. Diese Zahl ist dein Ausgangspunkt — und oft das überzeugendste Argument für das Management.

Parallel kannst du mit dem folgenden Prompt erste Eindrücke gewinnen, wie gut ein vorhandenes LLM Haftungsindizien aus deutschsprachigen Schadenstexten extrahiert:

Quellen & Methodik

• 15 Milliarden USD jährlich verpasste Subrogations-Recoveries: National Association of Insurance Commissioners (NAIC), zitiert durch CLARA Analytics, „CLARA Analytics Unveils AI-Driven Subrogation Detection” (BusinessWire, Mai 2025, businesswire.com)
• Monatliche Recovery-Steigerung $1M+: Shift Technology, Case Study „Top 25 US Auto and Property Insurer” (shift-technology.com, 2024)
• HUK-Coburg: KI prüft jeden abgeschlossenen Schadensfall auf Regress: Versicherungsmagazin Deutschland, „Schadenregulierung: Ohne KI geht es nicht” (versicherungsmagazin.de)
• 8–12 Wochen Implementierungszeit (SaaS): CLARA Analytics, Produktbeschreibung (2025)
• § 86 VVG Forderungsübergang: Versicherungsvertragsgesetz in der aktuell gültigen Fassung (gesetze-im-internet.de)
• 30–60 % verpasste Regressfälle: Brancheneinschätzung basierend auf NASP (National Association of Subrogation Professionals) und Praxisberichten aus Versicherungsmagazin (Werte konsistent zitiert in mehreren unabhängigen Quellen, 2023–2025)
• Implementierungskosten Eigenentwicklung: Erfahrungswerte aus NLP-Projekten bei deutschen Versicherern (anonymisiert, eigene Einschätzung basierend auf Projektdokumentation, Stand Mai 2026)
• F1-Scores für domänenspezifisches NER: Eigene Evaluation auf vergleichbaren Versicherungstextdaten; Vergleichswerte aus BERT-Fine-Tuning-Literatur für deutschsprachige Domänentexte

Willst du einschätzen, wie viele Regressfälle in eurem aktuellen Bestand bisher nicht erkannt wurden — und was das bedeutet? Meld dich für ein kurzes Gespräch.