KI-Vertragsprüfung in der Versicherung: 2-Wochen-Pilot mit LangChain

Das Problem: Manuelle Vertragsprüfung in der Versicherung

Versicherungsunternehmen mit 201 bis 500 Mitarbeitern stehen vor einem spezifischen Problem: Die manuelle Datenerfassung aus Verträgen und Policen bindet Compliance-Teams, während die Dokumentenlaufzeit unter Druck steht. In Deutschland ist die DSGVO (Art. 5, 6) strenger als in anderen Märkten, was bedeutet, dass personenbezogene Daten nicht einfach an US-Cloud-LLMs gesendet werden dürfen. Gleichzeitig fehlt es an Skalierbarkeit: Ein Compliance-Experte braucht im Schnitt 45 Minuten für die Vorprüfung eines Standardvertrags, während ein automatisierter Prozess diese Zeit auf unter 5 Minuten senken kann. Der Kern des Problems ist nicht die KI-Technologie selbst, sondern die Integration in bestehende Workflows ohne den Austausch von CRM, ERP oder Helpdesk-Systemen. Ein isolierter Pilot, der nicht in den täglichen Betrieb eingebettet ist, liefert keine messbaren Ergebnisse. Die Lösung liegt in einem zweiwöchigen Integration Sprint, der einen Conversational Agent aufsetzt, der über Slack oder Microsoft Teams mit den Mitarbeitern interagiert, Dokumente über ein RAG-System prüft und die manuelle Datenerfassung ersetzt.

Voraussetzungen für den zweiwöchigen Sprint

Bevor der Sprint startet, müssen folgende Voraussetzungen erfüllt sein:

• Zugang zu den Quelldokumenten: Die Verträge und Policen müssen in einem zentralen Repository (SharePoint, S3, oder lokales NAS) liegen. Gescannte PDFs ohne OCR sind nicht geeignet; die Dokumente müssen textbasiert sein.
• API-Zugänge: Sie benötigen Read-Only-Zugänge zu Ihrem CRM (z. B. Salesforce, HubSpot) und ERP (z. B. SAP, Microsoft Dynamics) über REST-APIs. Diese werden für die Kontextanreicherung des RAG-Systems benötigt.
• Chat-Kanal-Integration: Ein Bot-Token für Slack oder Microsoft Teams, der in den relevanten Compliance-Channel eingebunden werden kann.
• Datenklassifizierung: Eine klare Definition, welche Daten als personenbezogen gelten. Für diese Daten muss ein On-Premise-Modell (z. B. Llama 3 auf eigener Hardware) oder ein EU-Hosting-Dienstleister mit Standardvertragsklauseln (Art. 46 DSGVO) vorbereitet sein.
• Baseline-Messung: Sie müssen die aktuelle Zykluszeit und Fehlerquote für die Vertragsprüfung dokumentieren. Ohne diese Baseline können Sie den Erfolg des Piloten nicht messen.

Schritte zur Implementierung des Conversational Agents

1. Prozess-Audit und Scope-Definition: Identifizieren Sie den spezifischen Vertrags-Typ, der im Piloten abgedeckt wird (z. B. B2B-Versicherungsverträge). Definieren Sie die 5-10 Felder, die extrahiert werden müssen (z. B. Versicherungsnehmer, Laufzeit, Prämie). Dokumentieren Sie die Freigabekriterien: Welche Felder müssen ein Mensch prüfen? Dies wird in einem 2-stündigen Workshop mit Compliance und IT festgelegt.

2. RAG-Infrastruktur aufsetzen: Laden Sie die relevanten Dokumente in einen Vektor-Datenbank (z. B. Pinecone oder Weaviate) ein. Verwenden Sie langchain.vectorstores für die Indexierung. Für die Embedding-Modellierung nutzen Sie ein DSGVO-konformes Modell (z. B. all-MiniLM-L6-v2 lokal oder ein EU-gehostetes API). Testen Sie die Retrieval-Genauigkeit mit 20 Stichproben aus dem Dokumentenbestand.

3. LangGraph-Workflow konfigurieren: Definieren Sie den Zustandsautomaten in langgraph.graph. Die Nodes sind: extract (Extraktion der Felder), validate (Prüfung der Plausibilität), human_approval (Pause für die Freigabe), und update_crm (Schreiben der Daten ins CRM). Verwenden Sie StateGraph mit einem MessageHistory-State, um den Kontext im Chat-Kanal zu erhalten.

4. Conversational Agent für Slack/Teams implementieren: Verwenden Sie das slack-bolt oder botframework-Framework. Der Agent antwortet auf den Befehl /review <dateiname>. Er lädt das Dokument, führt die RAG-Abfrage durch und postet die extrahierten Felder als Markdown-Message in den Channel. Die Latenz sollte unter 3 Sekunden liegen; bei Cloud-LLMs muss die Anfrage asynchron abgewickelt werden.

5. Human-in-the-Loop-Integration: Implementieren Sie den human_approval-Node so, dass der Agent eine Interaktive-Message mit Buttons (‘Freigeben’, ‘Ablehnen’, ‘Korrigieren’) sendet. Die Freigabe wird im CRM als Status ‘Approved’ markiert. Ohne diese Freigabe wird kein Datenpunkt in das ERP geschrieben. Dies erfüllt die Anforderung der DSGVO, dass automatisierte Entscheidungen überprüfbar sein müssen.

6. Baseline-Vergleich und Messung: Führen Sie 50 Testverträge durch. Messen Sie die Zeit von der Dokumentenübergabe bis zur Freigabe. Vergleichen Sie die Fehlerquote (z. B. falsche Prämien-Eingabe) mit der manuellen Baseline. Dokumentieren Sie die Ergebnisse in einem kurzen Report, der als Grundlage für den Rollout dient.

Häufige Stolperfallen und wie Sie sie erkennen

• OCR-Fehler bei gescannten PDFs: Wenn die Quelldokumente gescannte Bilder sind, ohne vorherige OCR-Bearbeitung, wird die Extraktionsrate unter 70 % fallen. Erkennen Sie dies im Schritt 2, wenn die Retrieval-Genauigkeit bei den Stichproben niedrig ist. Lösung: Vorverarbeitung mit Tesseract oder einem kommerziellen OCR-Dienst, bevor die Dokumente in den Vektor-Index geladen werden.
• API-Rate-Limits im CRM: Wenn der Agent zu viele parallele Anfragen an das CRM sendet, werden diese abgelehnt. Erkennen Sie dies an HTTP-429-Fehlern in den Logs. Lösung: Implementieren Sie einen Rate-Limiter in LangChain (z. B. tenacity mit Exponential Backoff) und begrenzen Sie die parallelen Anfragen auf 5 pro Minute.
• Halluzinationen bei fehlenden Daten: Wenn ein Feld im Dokument nicht vorhanden ist, erfindet das LLM manchmal einen Wert. Erkennen Sie dies, wenn die validate-Node-Prüfung eine Inkonsistenz meldet. Lösung: Konfigurieren Sie das Prompt so, dass das Modell ‘Nicht gefunden’ zurückgibt, wenn ein Feld fehlt, und erzwingen Sie dies durch eine structured_output-Konfiguration in LangChain.
• Latenz im Chat-Kanal: Wenn die Antwortzeit über 10 Sekunden liegt, wird der Agent von den Nutzern als unzuverlässig empfunden. Erkennen Sie dies durch User-Feedback oder durch Messung der API-Latenz. Lösung: Verwenden Sie ein kleineres, schnelleres Modell für die Extraktion (z. B. Llama 3 8B) und ein größeres Modell nur für die semantische Prüfung, oder nutzen Sie Caching für häufige Abfragen.
• Fehlende Freigabe-Logik: Wenn der human_approval-Node nicht korrekt pausiert, wird der Prozess fortgesetzt, ohne dass ein Mensch zugestimmt hat. Erkennen Sie dies, wenn Daten im CRM aktualisiert werden, obwohl keine Button-Interaktion stattfand. Lösung: Testen Sie den Workflow explizit mit einem ‘Timeout’-Szenario, bei dem keine Freigabe erfolgt, und stellen Sie sicher, dass der Prozess in einem ‘Pending’-Status bleibt.

Nächste Schritte nach dem Piloten

Der zweiwöchige Sprint liefert einen funktionierenden Piloten, der die manuelle Datenerfassung für einen spezifischen Vertrags-Typ ersetzt. Die gemessenen Baseline-Werte zeigen, ob die Zykluszeit und Fehlerquote signifikant verbessert wurden. Der nächste logische Schritt ist die Ausweitung auf weitere Vertrags-Typen und die Integration in den gesamten Compliance-Prozess. Dabei sollten Sie die Modell-Agnostizität nutzen: Wenn die Cloud-LLMs für bestimmte Daten zu langsam oder zu teuer sind, können Sie auf On-Premise-Modelle umstellen, ohne die Architektur zu ändern. Die Architektur ist so gestaltet, dass sie in bestehende Systeme integriert wird, nicht sie ersetzt. Das bedeutet, dass Ihr CRM, ERP und Helpdesk weiterhin die zentrale Rolle spielen, während der KI-Agent als Beschleuniger fungiert. Für den Rollout sollten Sie ein Change-Management-Programm aufsetzen, das die Compliance-Teams schult und die Akzeptanz des neuen Workflows fördert. Die Messung der Ergebnisse sollte kontinuierlich erfolgen, um sicherzustellen, dass die Qualität der Extraktion und die Nutzerzufriedenheit auf einem hohen Niveau bleiben.