Automatisierte Schadentriage in der Versicherung mit Kontrolle der False Positives

Die automatisierte Schadentriage funktioniert, wenn man sie in zwei Probleme aufteilt und getrennt löst: die Fakten mit bekannter Konfidenz aus den Schadenunterlagen ziehen, dann den zusammengesetzten Schaden auf Risiko bewerten und routen. Schnelle, risikoarme Schäden laufen dunkel durch. Alles, worüber sich der Extraktor unsicher ist oder was das Betrugsmodell markiert, geht mit angehängten Belegen an einen Sachbearbeiter. Der Audit-Trail hält beides fest.

Der größte Teil der Kosten in der Schadenbearbeitung ist nicht die Entscheidung. Es ist der Weg bis zu dem Punkt, an dem eine Entscheidung getroffen werden kann. Eine Schadenmeldung trifft als Telefonprotokoll ein, als PDF, als Satz von Fotos, als Reparaturkostenvoranschlag, manchmal als Polizeibericht. Jemand liest alles, überträgt das Schadendatum und die Vertragsnummer ins Schadensystem, prüft, ob der Versicherungsschutz in Kraft war, sucht nach den offensichtlichen Anzeichen eines inszenierten Schadens und entscheidet erst dann, ob dieser Fall eine Zwei-Minuten-Freigabe oder eine zweiwöchige Ermittlung ist. Das Lesen und das Übertragen fressen die Zeit. Das Urteil sind die letzten fünf Minuten.

Genau dorthin gehört die Automatisierung, und genau dort richtet sie auch Schaden an, wenn man schludert. Ein Modell, das einen Schaden gut zusammenfasst, aber das Schadendatum aus der falschen Zeile liest, gibt im Straight-Through etwas frei, das nie gedeckt war. Das Versagen ist leise. Niemand sieht einen falschen Satz; man sieht einen bezahlten Schaden.

Extraktion zuerst, und Konfidenz als erstklassiges Output behandeln

Die Triage kann nicht besser sein als die Felder, auf denen sie läuft. Deshalb ist das erste System, das man baut, eine Dokumentenextraktionsschicht, die die strukturierten Fakten zurückgibt, die eine Schadenentscheidung braucht: Vertragsnummer, versicherte Person, Schadendatum und -uhrzeit, Schadenursache, geforderter Betrag, Einzelposten des Kostenvoranschlags, Dritte, referenzierte Vorschäden. Jeder dieser Werte kommt mit einer Konfidenz zurück und mit einem Verweis darauf, wo im Quelldokument er gefunden wurde.

Die Konfidenz ist keine Dekoration. Sie entscheidet darüber, ob der Schaden überhaupt für die Dunkelverarbeitung (Straight-Through Processing) infrage kommt. Ein Schaden, bei dem das Schadendatum sauber aus einem getippten Formular gelesen wurde, ist ein anderes Objekt als einer, bei dem es aus einem verschwommenen Foto einer handschriftlichen Notiz abgeleitet wurde, selbst wenn beide auf demselben Datum landen.

Was wir in diese Schicht einbauen:

• Entity Resolution gegen den Vertragsbestand, sodass die extrahierte versicherte Person und der Vertrag tatsächlich zu einem aktiven Vertrag mit am Schadendatum in Kraft befindlichem Versicherungsschutz passen. Ein Schaden, der keinem Vertrag zugeordnet werden kann, läuft nie dunkel durch.
• Konfidenz auf Feldebene mit Source Lineage. Jeder extrahierte Wert verweist auf die Seite und den Textabschnitt, aus dem er stammt, sodass ein Sachbearbeiter ihn mit einem Klick prüfen und ein Prüfer ihn später rekonstruieren kann.
• Strukturiertes Output, das ein nachgelagertes System konsumieren kann, ohne dass ein Modell erneut Freitext liest. Der Extraktor liefert typisierte Felder gegen ein Schema, mit Validierung auf Formate, Wertebereiche und feldübergreifende Konsistenz, zum Beispiel eine Reparatursumme, die gleich der Summe ihrer Einzelposten sein muss.
• Ein Held-out-Eval-Set aus echten Schäden mit menschlich geprüften Feldern, bewertet auf Genauigkeit auf Feldebene, nicht auf Dokument-Bauchgefühl. Das sagt einem, welchen Feldern man unbeaufsichtigt trauen kann und welche immer einen Menschen brauchen.

Die Regel, an der wir festhalten: Ein Schaden kommt nur dann für die automatische Bearbeitung infrage, wenn jedes für die Auszahlung relevante Feld seine Konfidenzschwelle überschritten und den Abgleich mit den Vertragsdaten bestanden hat. Ein einziges Feld mit niedriger Konfidenz auf einem tragenden Wert, und der Schaden wird an einen Menschen geleitet.

Auf Risiko scoren, ein False-Positive-Budget einhalten

Mit sauberen Feldern ist das zweite Problem das Routing. Jeder Schaden bekommt zwei Dinge: ein Komplexitätssignal, das vorhersagt, wie viel Arbeit er braucht, und ein Betrugssignal, das vorhersagt, ob er eine Ermittlung rechtfertigt. Beide fließen in dieselbe Routing-Entscheidung ein, aber man behandelt sie sehr unterschiedlich.

Das Betrugssignal ist der Ort, an dem False Positives echte Menschen Geld kosten. Ist das Modell zu aggressiv, werden legitime Anspruchsteller mit verzögerten Schäden konfrontiert, an die Sonderermittlung geschickt und nach Unterlagen gefragt, die sie nie hätten brauchen sollen. Der Betrugs-Score priorisiert und routet also. Er lehnt nicht ab. Ein hoher Score schickt den Schaden mit nach Rang geordneten Gründen an einen Ermittler; er schließt einen Schaden nie von selbst.

Konkret sieht das Design so aus:

• Den Betrugs-Score in Stufen aufteilen: Straight-Through, Standard-Sachbearbeiter, verschärfte Prüfung, Ermittlung. Jede Stufe hat ein False-Positive-Budget, das man festlegt und misst, den Anteil der hochgestuften Schäden, die sich als legitim herausstellen.
• Suppression gegen bestätigte Outcomes backtesten, nicht gegen die Ahnungen der Sachbearbeiter. Die Straight-Through-Stufe existiert nur, wenn ihre gemessene Miss-Rate gegen bestätigte Betrugs-Labels auf einem Point-in-Time-Eval-Set unter der Zahl bleibt, die Ihre Schaden- und Compliance-Verantwortlichen abgezeichnet haben.
• Features zum Zeitpunkt der Schadenmeldung (First Notice of Loss) aufbauen. Reserveänderungen, Sachbearbeiter-Notizen und Dispositionen passieren alle nach der Triage; sie zu verwenden ist Lookahead, und ein darauf trainiertes Modell wirkt im Backtest brillant und fällt in der Produktion auseinander.
• Drift überwachen. Schadenmuster verschieben sich mit Wetter, Betrugsringen und Änderungen im Vertragsbestand, also ist die False-Positive-Rate pro Stufe eine Live-Metrik mit Alert, keine Folie vom Launch-Tag.

Weil ein verzögerter oder bestrittener Schaden Pflichten zur fairen Behandlung mit sich bringen kann, wird der Betrugs-Score vor dem Ausrollen auf einem Held-out-Set auf Disparate Impact über geschützte Gruppen hinweg getestet und turnusmäßig neu getestet. Wenn eine Stufe eine Gruppe ohne vertretbaren Grund häufiger in die Ermittlung schiebt, ist das ein Befund, den man behebt, keine Fußnote.

Was der Sachbearbeiter sieht

Automatisierung, die ihre Begründung verbirgt, macht Sachbearbeiter langsamer, denn jetzt müssen sie die Maschine erst reverse-engineeren, bevor sie ihr trauen können. Deshalb produziert die Triage einen aufbereiteten Schaden statt eines nackten Urteils.

Ein Sachbearbeiter, der einen gerouteten Schaden öffnet, sieht die extrahierten Felder mit ihrer Konfidenz und einem Link zum Quellabschnitt, den Vertragsabgleich und die Deckungsprüfung, die Komplexitäts- und Betrugsstufen mit den wichtigsten beitragenden Gründen sowie eine Markierung an allem, was Validierung oder Abgleich nicht bestanden hat. Er kann alles davon überschreiben, und das Override wird als Label erfasst, das in den nächsten Eval-Zyklus einfließt.

Die Straight-Through-Schäden erzeugen denselben Datensatz. Ein automatisch freigegebener Schaden hat die vollständige Extraktion, den Score, das Abgleichergebnis und die Vertragsprüfung gespeichert, sodass ein Stichproben-Prüfer oder ein externer Auditor jede Entscheidung ziehen und exakt sehen kann, was das System im Moment des Handelns wusste. Die Dunkelverarbeitung ist nur dann vertretbar, wenn jede automatische Entscheidung genauso rekonstruierbar ist wie eine manuelle.