160.000 Dokumente im Jahr: Wie die DMB Rechtsschutz ihren Posteingang in acht Monaten automatisiert hat

Viele IDP-Projekte in der Versicherungsbranche laufen gut an und versanden still. Der Pilot zeigt beeindruckende Erkennungsraten, die Präsentation überzeugt den Lenkungsausschuss, das Budget wird freigegeben. Doch dann wird aus dem Proof of Concept kein belastbares Produktivsystem, weil die eigentliche Herausforderung nicht in der KI-Technologie liegt, sondern in allem, was drumherum passieren muss.

Das ist kein Randproblem. Versicherungen gehören zu den dokumentenintensivsten Branchen: Schadensbearbeitung, Änderungsmanagement, juristische Korrespondenz, Policeneingang. Täglich entstehen hochvolumige, strukturell ähnliche Dokumentenströme. Wer diese Prozesse mit IDP automatisiert, hat einen echten Effizienzhebel. Wer es falsch angeht, hat einen teuren Parallelprozess.

Was IDP heute kann und was Versicherer oft falsch erwarten

Moderne IDP-Lösungen erkennen nicht nur Dokumententypen, sie extrahieren strukturierte Daten: Vertragsnummern, Schadennummern, Fristen, Absender. Klassifikation und Extraktion laufen ohne manuellen Eingriff, die Übergabe in den nachgelagerten Workflow erfolgt automatisch. Dunkelverarbeitungsquoten von 70, 80 oder mehr Prozent sind realistisch: für Eingangspost, Standardkorrespondenz und strukturierte Dokumententypen, bei denen der Prozess sauber definiert ist.

Die falsche Erwartung, die in vielen Projekten Probleme erzeugt: dass IDP ein in sich geschlossenes System ist, das man einschaltet und das dann läuft. In der Praxis ist IDP eine Prozesskomponente. Sie erzeugt Mehrwert nur dort, wo sie nahtlos mit dem bestehenden Dokumentenmanagementsystem und der Workflow-Steuerung zusammenhängt. Systeme, die klassifizieren und extrahieren, aber nicht übergeben oder validieren, schaffen Mehraufwand statt Entlastung. Das Problem liegt in diesen Fällen nicht am Modell, sondern an der Architektur.

LLMs oder ML-Modelle: Die Architekturfrage, die vor dem Piloten beantwortet sein muss

Die Diskussion, welche KI-Technologie für Dokumentenprozesse sinnvoll ist, hat sich in den vergangenen zwei Jahren verschoben. Large Language Models sind zugänglich, beeindruckend und inzwischen in fast jedem Produkt-Pitch. Aber in hochvolumigen, regulierten Kernprozessen sind sie nicht die Standardantwort.

LLMs sind generative Systeme: Sie produzieren Antworten, lesen keine Werte reproduzierbar aus. Wer Dunkelverarbeitungsquoten in der Schadensbearbeitung oder im Antragseingang verantworten muss, braucht Ergebnisse, die sich erklären und auditieren lassen. DORA fordert keine formale Konformität auf dem Papier, sondern operative Resilienz und dazu gehört, dass Entscheidungsprozesse tatsächlich nachvollziehbar sind, nicht nur protokolliert. Selbst trainierte Machine-Learning-Modelle, auf spezifische Dokumententypen ausgelegt, liefern genau das: bei identischem Input identischen Output, mit kalibrierbaren Konfidenzwerten als Grundlage revisionssicherer Protokolle.

LLMs kommen dort sinnvoll zum Einsatz, wo semantische Einordnung gefragt ist oder wo Ergebnisse ohnehin manuell geprüft werden: Zusammenfassungen, Sentiment-Analyse, komplexe juristische Schreiben ohne klare Feldstruktur. Die Frage, welches Modell für welchen Use Case eingesetzt wird, ist keine technische Detailfrage, sondern eine Architekturentscheidung. Wer einen Anbieter evaluiert, sollte sie deshalb vor der Pilotphase stellen und die Antwort in die Systemarchitektur einbauen, nicht erst nach dem Go-live.

Wie das in der Praxis aussieht: DMB Rechtsschutz-Versicherung AG

Die DMB Rechtsschutz-Versicherung AG hat einen dieser Prozesse 2025 grundlegend neu aufgestellt. Die Versicherung betreut mit 63 Mitarbeitenden über 140.000 Versicherungsverträge; jährlich laufen rund 160.000 Dokumente ein. d.velop documents war als DMS bereits im Einsatz. Das Problem lag im vorgelagerten Posteingang: Dokumente ohne erkennbare Vertrags- oder Schadennummer landeten manuell bei der internen Posteingangsstelle und das meist mit Zeitverzug, Fehlerrisiko und gebundener Sachbearbeiterkapazität.

Auf Empfehlung aus dem d.velop-Netzwerk kam Buildsimple ins Projekt, eine auf Versicherungen spezialisierte IDP-Plattform. Der technische Ansatz: ein Foundation Model mit vortrainiertem Sprach- und Strukturverständnis, das individuelle Modelle ab etwa 20 Beispieldokumenten pro Klasse ermöglicht. Klassische Verfahren brauchen typischerweise mehrere tausend. Im konkreten Projekt der DMB Rechtsschutz wurden für jede der über 70 Klassen rund 100 Beispieldokumente verwendet, bedingt durch die Komplexität der Dokumentenlandschaft und Mehrfachzuordnungen.

Start war Januar 2025. Nach acht Monaten lief das System produktiv: über 70 Dokumentenklassen klassifiziert, Vertrags-, Schaden- und Vermittlernummern extrahiert, Trefferquoten von über 90 Prozent sowohl bei Klassifikation als auch Fachdaten-Extraktion. Buildsimple wurde vollständig in die bestehende d.velop-Infrastruktur eingebettet, ohne Parallelsystem oder manuelle Übergaben. Produktive Daten werden nicht dauerhaft gespeichert; Trainingsdaten werden anonymisiert, personenbezogene Informationen entfernt. Welches Modell künftig zum Einsatz kommt, bleibt damit eine offene Architekturfrage: kein Anbieter-Lock-in.

Das Projekt funktioniert nicht, weil die KI besonders gut ist. Es funktioniert, weil die Integration konsequent mitgedacht und die Architekturentscheidungen vor dem Piloten getroffen wurden, nicht danach. IDP als vorgelagerter Filter, der strukturierte Daten an ein bestehendes DMS und Workflow-System übergibt, ist ein anderes Projekt als IDP als isoliertes Erkennungswerkzeug zu betrachten. Wer das unterscheidet, bevor er einen Anbieter mandatiert, spart sich den typischen Projektknick nach dem Go-live.

Was aus diesem Projekt für andere Versicherer relevant ist

Der größte Hebel entsteht nicht durch bessere KI-Modelle, sondern durch bessere Integration. KI-Lösungen als vorgelagerte Filter, die klassifizieren und extrahieren, aber nicht nahtlos an das DMS übergeben, schaffen lediglich einen zusätzlichen manuellen Schritt. Wer die Integration als nachgelagerte Aufgabe betrachtet, verliert den größten Teil des Projektnutzens und wer die Architekturfrage erst nach dem Go-live klärt, zahlt einen hohen Preis für etwas, das vorher lösbar gewesen wäre.

Außerdem sind kalibrierte Konfidenzwerte und eine kontrollierte Hochlaufphase mit menschlicher Nachprüfung keine optionalen Features. Sie sind der Mechanismus, der aus einem gut aussehenden Modell ein belastbares Produktivsystem macht. Autonomie wächst kontrolliert: Der Mensch entscheidet, welche Prozesse er delegiert, und das System signalisiert, wann Eingreifen nötig ist. Versicherer, die das überspringen wollen, weil der Pilot stark war, riskieren genau den stillen Misserfolg, der KI-Projekte in vielen Häusern in Erklärungsnot gebracht hat.

Wer heute IDP-Lösungen einführt, sollte Wechselbarkeit von Anfang an als Architekturprinzip einbauen. Welches Modell, welcher Anbieter, welches Betriebsmodell, das sind keine einmaligen Entscheidungen, sondern Parameter, die sich in einem sich schnell verändernden Markt verschieben werden. Digitale Souveränität beginnt nicht bei der Cloud-Wahl, sondern bei der Frage, ob die eigene IT-Architektur diese Entscheidung in zwei Jahren noch offen lässt.

IDP im Posteingang ist kein Zukunftsprojekt mehr. Die Technologie ist ausgereift, die Einstiegshürden für das Training sind in den vergangenen zwei Jahren erheblich gesunken. Was viele Versicherer aufhält, ist nicht die Technologie, sondern die Unterschätzung dessen, was drumherum gebaut werden muss: Integration, Governance, nachvollziehbare Prozesse, Wechselbarkeit. Wer das ernst nimmt, hat ein Projekt, das auch nach dem Go-live noch erfolgreich ist.