Dokumenten-Triage für Versicherungen. Klassifikation, Feldextraktion und regelbasierte Eskalation an eine menschliche Prüfung.
Live-Demo: https://posteingang-ki.streamlit.app
Versicherungsunternehmen erhalten täglich hunderte unstrukturierte Nachrichten über E-Mail, eingescannte Briefe und Portale. Jede Nachricht muss in der Theorie von einer Person gelesen, eingeordnet und an die zuständige Stelle weitergeleitet werden, bevor die eigentliche Bearbeitung überhaupt beginnt.
Diese Demo zeigt, wie sich der Schritt der Einordnung teilweise automatisieren lässt, ohne die Kontrolle über Grenzfälle abzugeben.
Der Testsatz umfasst 30 synthetische Versicherungsdokumente. Jedes durchläuft vier Schritte:
- Klassifikation in eine von fünf Kategorien, mit Dringlichkeit, Konfidenz und Begründung
- Feldextraktion nur bei Schadenmeldungen: Schadennummer, Name, Datum, Betrag
- Eskalationsprüfung durch reine Python-Regeln, ohne Modellbeteiligung
- Anzeige in zwei Tabs, getrennt nach automatisch verarbeitet und zur Prüfung
Ergebnis im aktuellen Durchlauf: 20 von 30 Dokumenten automatisch, 10 zur Prüfung. Automatisierungsquote 67 Prozent.
Fehlende Angaben werden sichtbar als fehlt ausgewiesen statt stillschweigend ergänzt. Jeder
eskalierte Fall trägt den Grund direkt in der Überschrift, damit ein Prüfer nicht jedes
Dokument neu lesen muss.
Der Rechner in der Seitenleiste multipliziert die gemessene Automatisierungsquote mit Annahmen, die der Nutzer selbst einstellt.
Bei 200 Dokumenten pro Tag, 6 Minuten manueller Bearbeitung und 65 Euro Vollkosten pro Stunde:
| Ersparnis pro Monat | 18.200 EUR |
| Ersparnis pro Jahr | 218.400 EUR |
Was in dieser Zahl nicht enthalten ist: Betriebskosten, Einführungsaufwand und der Prüfaufwand für die verbleibenden 33 Prozent. Es handelt sich um die Bruttoersparnis auf der automatisierten Menge.
Modellkosten: Ein kompletter Durchlauf über 30 Dokumente kostet rund 0,05 USD, also etwa 0,18 Cent pro Dokument. Bei 200 Dokumenten täglich entspricht das ungefähr 130 Euro im Jahr. Der Tokenverbrauch wird pro Lauf in der Oberfläche protokolliert.
CSV-Upload
↓
Klassifikationsaufruf (pydantic-Schema, strukturierte Ausgabe)
↓
Extraktionsaufruf (nur bei Schadenmeldungen, zweites Schema)
↓
Eskalationsprüfung (reine Python-Regeln, kein Modell)
↓
Dashboard mit zwei Tabs + ROI-Rechner
Beide Modellaufrufe nutzen strukturierte Ausgaben mit pydantic-Schemata. Die Antwort wird während der Erzeugung an das Schema gebunden, es wird kein Freitext nachträglich zerlegt.
Der zweite Aufruf läuft bewusst nur bei Schadenmeldungen. Bei 30 Dokumenten sind das acht zusätzliche Aufrufe statt 30, eine Kostenentscheidung mit direktem Effekt.
Bewusst regelbasiert statt modellgeschätzt. Die Schwellenwerte stehen als Konstanten in
eskalation.py und sind ohne Codeverständnis änderbar.
Ein Dokument geht an eine menschliche Prüfung, wenn mindestens eine Bedingung zutrifft:
| Regel | Bedingung |
|---|---|
| Konfidenz | unter 0,7 |
| Kategorie | "Sonstiges" |
| Schadenmeldung | Schadendatum fehlt |
| Kündigung | Vertragsnummer und Name fehlen beide |
| Technischer Fehler | Modellaufruf gescheitert |
Warum Regeln und nicht das Modell: Grenzentscheidungen bestimmen, ob ein Mensch eingreift. Diese Entscheidung muss begründbar, über Zeit konstant und vom Fachbereich änderbar sein. Eine Regel liefert für dieselbe Eingabe immer dasselbe Ergebnis und lässt sich ohne einen einzigen API-Aufruf testen. Das Modell liefert das Urteil über den Inhalt, die Regel trifft die Entscheidung über den Prozess.
Woher die Regeln ihre Information beziehen: Die Datumsprüfung bei Schadenmeldungen liest das Ergebnis des Extraktionsaufrufs, der nur für diese Kategorie läuft. Die Prüfung des Vertragsbezugs bei Kündigungen liest die Liste fehlender Angaben aus dem Klassifikationsaufruf, weil es für Kündigungen keinen eigenen Extraktionsschritt gibt.
Die Extraktion ist die verlässlichere Quelle, weil sie gegen ein festes Schema und einen präzisen Prompt arbeitet. Ein eigener Extraktionsschritt für Kündigungen mit den Feldern Vertragsnummer und Beendigungsdatum wäre der nächste Ausbauschritt.
Warum die Regeln kategoriespezifisch sind: Eine Beschwerde über eine lange Bearbeitungszeit ist auch ohne Schadennummer vollständig bearbeitbar. Eine Kündigung ohne jeden Vertragsbezug ist es nicht. Der Maßstab ist Zuordenbarkeit, nicht Vollständigkeit.
Zu den 30 Testdokumenten existiert eine manuell erstellte Referenzklassifikation
(data/referenz.md) mit Soll-Kategorie und Soll-Feldwerten. Sie wird nicht in die App geladen
und dient dem Abgleich der Modellergebnisse.
Fünf der 30 Dokumente sind bewusst uneindeutig konstruiert und bilden den Eskalationstest.
Gefundene Fehlerklassen und ihre Korrektur:
- Die Konfidenz lag ohne Kalibrierungsanweisung durchgängig bei 0,85 und höher, auch bei eindeutig uneindeutigen Texten. Nach Präzisierung im System-Prompt trennt sie zwischen 0,65 und 0,95.
- Das Modell übernahm eine im Text genannte Vertragsnummer als Schadennummer. Formal korrekt aussehend, fachlich falsch, und dadurch gefährlicher als ein leeres Feld. Behoben über eine explizite Abgrenzung im Extraktions-Prompt.
- Bei Erstmeldungen wurde der genannte Anschaffungswert als Schadenhöhe interpretiert. Ebenfalls im Prompt abgegrenzt.
Der Erfolg einer Automatisierung sollte danach bewertet werden, wie viel Arbeit danach immer noch von einem Menschen übernommen werden muss.
Meine erste Regelvariante hätte 22 von 30 Dokumenten an eine menschliche Prüfung geschickt, weil das Modell bei fast jedem Dokument irgendeine fehlende Angabe meldet. Die Quote wäre auf 27 Prozent gefallen und der wirtschaftliche Nutzen damit hinfällig, obwohl die Klassifikation selbst korrekt war. Erst die Eingrenzung auf kategoriespezifische Pflichtfelder hat aus einer technisch funktionierenden Lösung eine wirtschaftlich sinnvolle gemacht.
- Der Testsatz ist zu klein für eine belastbare Schwellenwertfestlegung. 0,7 wurde an 30 Dokumenten bestimmt. Produktiv gehörte dieser Wert an mehreren hundert Fällen kalibriert.
- Von fünf bewusst uneindeutigen Dokumenten fangen die Regeln drei. Ein Fall erhält Konfidenz 0,85 bei inhaltlich strittigem Sachverhalt und läuft automatisch durch.
- Die Konfidenzwerte sind grob gerastert. Das Modell nutzt wenige Stufen statt einer feinen Skala, was die Steuerbarkeit über den Schwellenwert begrenzt.
- Grenzfälle streuen zwischen Durchläufen. Eindeutige Dokumente werden reproduzierbar eingeordnet, uneindeutige nicht. Das ist der Grund, warum sie zu einem Menschen gehören.
- Es findet keine Speicherung statt. Die Prüf-Buttons demonstrieren den Ablauf, ohne Entscheidungen festzuhalten.
- Die Demo läuft auf einem persönlichen API-Schlüssel ohne Zugriffsbeschränkung. Ein Produktivsystem bräuchte Authentifizierung, Nutzungsbegrenzung pro Anwender und Kostenüberwachung.
- Speicherung der Prüfentscheidungen als Grundlage für einen Evaluierungssatz
- Prompt Caching für den identischen Systemteil, relevant ab höherem Volumen
- Sparten- und kundenspezifische Prompts
- E-Mail-Anbindung statt CSV-Upload
- Ausbau strukturierter Eingabekanäle, damit weniger Volumen überhaupt im unstrukturierten Posteingang landet
- DSGVO-Prüfung mit dem Datenschutzbeauftragten: Verarbeitungsort, Auftragsverarbeitungsvertrag, Ausschluss der Trainingsnutzung
Ausschließlich synthetische, selbst erstellte Beispieldokumente. Keine echten Personen- oder Unternehmensdaten, keine Arbeitgeberdaten.
Python 3.13 · Streamlit · pandas · pydantic · Anthropic SDK (Claude Haiku 4.5)
python -m venv .venv
.venv\Scripts\activate
pip install -r requirements.txtDanach .streamlit/secrets.toml.example nach .streamlit/secrets.toml kopieren und einen
eigenen API-Schlüssel eintragen.
streamlit run app.py