Vom PDF zur Entscheidung: Wie ein KI-Copilot das Underwriting verändert

Der Morgen im Underwriting

Stellen wir uns einen Montagmorgen in einem Industrieversicherer vor. Im Postfach liegen drei neue Submissions von Maklern. Jede besteht aus fünf bis zehn PDFs: Statement of Values, Schadenhistorien der letzten fünf Jahre, Lagepläne, Brandschutzkonzepte, eine Cover Note des Maklers. Zusammen: 150 bis 300 Seiten. Pro Vorgang.

Die Aufgabe: aus diesem Dokumentenstapel eine saubere Risikoeinschätzung destillieren, gegen interne Richtlinien prüfen und eine Entscheidungsempfehlung formulieren. Realistisch zwei bis vier Stunden pro Submission — bevor überhaupt mit der eigentlichen Preisfindung begonnen wird.

Das ist kein Bug in einem einzelnen Versicherer, das ist der Standard. Und es ist der Moment, an dem KI tatsächlich etwas Sinnvolles beitragen kann — nicht indem sie die Entscheidung trifft, sondern indem sie die Vorarbeit erledigt.

Was der Copilot macht

Der Underwriting Submission Copilot nimmt diese PDFs entgegen und verwandelt sie in vier aufeinander aufbauende Artefakte:

1. Strukturierte Ingestion. PDFs werden geparst, nach Dokumententyp klassifiziert (SOV, Loss Run, Broker Note, etc.), in semantisch sinnvolle Abschnitte zerlegt und als Vektorembeddings in einer pgvector-Datenbank abgelegt. Aus einem Stapel PDFs wird so ein durchsuchbarer Wissenskorpus.

2. Belegbasierte Risiko-Zusammenfassung. Für jede Risikokategorie — Sachrisiken, Haftpflicht, Umwelt, Finanziell — werden gezielte Retrieval-Queries gegen den Korpus gestellt und die Ergebnisse vom LLM zu einer Zusammenfassung verdichtet. Jeder Satz trägt eine Quellenangabe: Dokumentname plus Seitenzahl. Keine Halluzinationen, keine Copy-Paste-Zitate — direkte Rückverfolgbarkeit.

3. Automatisierte Compliance-Prüfung. Interne Underwriting-Richtlinien werden Regel für Regel gegen die Submission geprüft. Jede Regel bekommt ein Ampelergebnis (erfüllt / unklar / nicht erfüllt), eine Begründung und wiederum Quellenangaben. Kein Regelwerk wird „aus Versehen“ übersprungen, kein Checklist-Punkt vergessen.

4. Interaktiver Dokumenten-Chat. Für alles, was über die vorberechneten Summaries hinausgeht, gibt es einen Q&A-Modus über den gesamten Submission-Korpus. Antworten mit nummerierten Quellenverweisen, Chatverlauf pro Submission gespeichert, Daumen-hoch-/runter-Feedback auf jeder Antwort.

Das Ergebnis: ein Underwriter, der mit einer strukturierten Aktennotiz und konkreten Rückfragen in die Entscheidung geht — statt mit einem Stapel PDFs und einem Marker.

Drei Entscheidungen, die das Projekt geprägt haben

Ein Projekt dieser Art lässt sich auf hundert Arten bauen. Drei Entscheidungen haben den größten Unterschied gemacht.

RAG ohne Framework. Der naheliegende Weg wäre LangChain oder LlamaIndex gewesen — in drei Tagen hätte man einen funktionierenden Prototyp. Ich habe mich bewusst dagegen entschieden. Frameworks dieser Art refaktorieren sich etwa alle sechs Monate grundlegend; jede Abhängigkeit von ihren Abstraktionen bedeutet wiederkehrende Migrationsarbeit. Wichtiger noch: in einer regulierten Domäne muss jeder Schritt — Retrieval, Prompt-Konstruktion, Citation-Mapping — inspizierbar sein. Frameworks verstecken genau diese Schichten hinter ihrer API.

Die eigene Pipeline ist schlanker, stabiler und vollständig observable. Das Chunking ist auf insurance-spezifische Dokumentstrukturen getunt: nur an nummerierten Überschriften splitten, kleine Abschnitte bis zu einer Zielgröße von ~800 Tokens zusammenführen. Das wäre mit einem generischen RecursiveCharacterTextSplitter nicht zu erreichen gewesen.

Zitate als First-Class-Citizens. Jede LLM-Ausgabe im System referenziert Quellen über Nummern wie [1], [2], die beim Parsen automatisch auf SourceReference-Objekte zurückgemappt werden. Diese Referenzen tragen Dokumentname, Seitenzahl und Chunk-ID — sie überleben den gesamten Weg vom Retriever bis zur UI, ohne unterwegs in einem metadata-Feld zu verschwinden. In einem generischen Framework wäre das eine Konvention; hier ist es erzwungene Datenstruktur.

Zweistufige Qualitätssicherung. Das vielleicht wichtigste Element, und der Punkt, an dem sich das Projekt von typischen RAG-Demos absetzt. Ebene 1: Code-Assertions laufen auf jeder Ausgabe — prüfen, ob Zitate vorhanden sind, ob die Struktur stimmt, ob leere Abschnitte ausgegeben werden. Null LLM-Kosten, sofortiges Feedback auf Regressionen. Ebene 2: LLM-as-Judge — ein zweites Modell bewertet binär, ob die Antwort die Frage treu, vollständig und korrekt zitiert beantwortet. Im Zweifel wird konservativ auf FAIL entschieden.

Über ein Dashboard sind Passraten, Token-Kosten, Latenzen und Nutzer-Feedback pro Query-Typ einsehbar. Wer das System in Produktion nehmen möchte, hat damit die Messinstrumente, die KI-Projekte sonst nachträglich und mühsam aufbauen müssen.

Was ich dabei gelernt habe

Drei Punkte haben sich als tragfähig erwiesen — über dieses Projekt hinaus.

Domäne schlägt Framework. Je enger der Anwendungsfall, desto weniger helfen generische Abstraktionen. Insurance-PDFs haben Strukturen, die sich aus zehn Zeilen domain-spezifischem Code besser erfassen lassen als aus hundert Zeilen Framework-Konfiguration.

Evaluation ist nicht optional. Ein RAG-System ohne Qualitätsmessung ist eine Demo, kein Produkt. Die zweistufige Evaluation war nicht der letzte Schritt, sondern die Grundlage — ohne sie hätte ich beim Tuning des Chunkings oder der Retrieval-Parameter im Blindflug gearbeitet.

Zitate sind das Fundament, nicht die Verzierung. In einer Domäne mit Audit- und Compliance-Anforderungen entscheidet die Nachvollziehbarkeit darüber, ob ein System überhaupt genutzt werden darf. Citation-Tracking von Anfang an einzubauen ist um ein Vielfaches leichter, als es nachträglich einzuziehen.

Woher das Projekt kommt — und wohin es geht

Das Projekt ist als eigenständiges Arbeitsergebnis entstanden, außerhalb eines konkreten Kundenmandats. Es ist bewusst öffentlich zugänglich als Referenzarchitektur: für alle, die eine produktionsreife RAG-Pipeline für regulierte Domänen suchen, als Diskussionsgrundlage über Architekturentscheidungen oder als Ausgangspunkt für gemeinsame Projekte.

Auf der Roadmap stehen hybrides Retrieval (semantisch plus Schlüsselwort-Suche mit Re-Ranking), Unterstützung weiterer Modelle (Anthropic Claude, lokale Modelle via Ollama) und ein Golden-Dataset zur systematischen Messung der Retrieval-Qualität.

Über Rückmeldung, Kollaborationen oder konkrete Anwendungsszenarien freue ich mich jederzeit.