Automatische Vollständigkeitsprüfung eingereichter Unterlagen

Das echte Ausmaß des Problems

Frag zehn Sachbearbeiterinnen und Sachbearbeiter in einer mittelständischen Versicherungsgesellschaft, wie viel ihrer täglichen Arbeitszeit sie mit Vollständigkeitsprüfung und Nachforderungen verbringen — und du wirst Antworten zwischen 30 und 50 Prozent hören. Das ist keine Ineffizienz, die sich mit mehr Disziplin lösen lässt. Es ist ein strukturelles Problem: Einreichende (Versicherungsnehmer, Makler, Anwälte, Werkstätten) kennen die internen Checklisten des Versicherers nicht vollständig, wechseln zwischen Produktlinien, machen Flüchtigkeitsfehler.

Zahlen aus Branchenberichten und Praxiserfahrungen zeigen konsistent: 30 bis 40 Prozent aller eingehenden Schadensmeldungen und Neuantragsunterlagen sind beim ersten Eingang unvollständig — fehlende Dokumente, falsche Versionen, nicht unterschriebene Formulare, fehlende Pflichtanhänge.

Jede Nachforderungsrunde kostet real:

• Bearbeitungszeit intern: 15–30 Minuten je Nachforderung (E-Mail verfassen, verfolgen, eingehende Unterlagen neu bewerten)
• Wartezeit extern: 3–7 Werktage, bis der Einreichende reagiert
• Regulierungsverzögerung: Bei Schadensfällen mit gesetzlichen Fristen (§ 14 VVG: 30 Tage Entscheidungspflicht) werden Puffer verbraucht, die für die inhaltliche Prüfung fehlen
• Kundenzufriedenheit: Mehrfache Nachforderungen sind einer der häufigsten Beschwerdegründe bei Versicherungsombudsleuten

Bei einem mittelständischen Versicherer mit 150 Eingängen täglich und einer Nachforderungsquote von 35 Prozent: Das sind täglich 52 Nachforderungsvorgänge — jeder mit mindestens zwei Bearbeitungsschleifen. Auf das Jahr hochgerechnet ergeben sich über 25.000 Nachforderungsvorgänge, die intern Zeit kosten und extern die Regulierungsdauer verlängern.

Das Hinterhältige: Das Problem ist für viele Versicherer unsichtbar, weil es im laufenden Betrieb versinkt. Es gibt keine eigene Kostenstelle “Nachforderungen”. Die Kosten tauchen als Sachbearbeitungszeit auf — und die hat nun mal jemand, der eingestellt ist.

Mit vs. ohne KI — ein ehrlicher Vergleich

¹ Erfahrungswerte aus IDP-Projekten bei mittelständischen Versicherern; keine repräsentative Studie, aber konsistente Beobachtungen über mehrere Implementierungen. Wert abhängig von Qualität der Checklisten und Abdeckungstiefe der Dokumenttypen.

Die Vollständigkeitsquote steigt nicht auf 100 Prozent — Einreichende machen weiterhin Fehler, und manche Dokumente sind schlicht schwer zu beschaffen. Aber der Unterschied zwischen “Sachbearbeiter prüft jeden Fall” und “KI filtert vorab” liegt darin, wann man anfängt: Mit KI beginnt die inhaltliche Arbeit sofort, wenn ein Fall vollständig ist — nicht erst nach zwei Nachforderungsrunden.

Einschätzung auf einen Blick

Zeitersparnis — hoch (4/5) Jede eliminierte Nachforderungsrunde spart intern 15–30 Minuten Bearbeitungszeit plus 3–7 Tage Wartezeit im externen Zyklus. Bei einem Versicherer mit 50+ Nachforderungsvorgängen täglich sind das bis zu 25 Stunden täglich, die umgeleitet werden — von reaktiver Nachverfolgung zu produktiver Sachbearbeitung. Nicht ganz die Höchstwertung, weil der Effekt sich auf den Eingangskanal beschränkt; die inhaltliche Schadensprüfung selbst wird davon nicht schneller.

Kosteneinsparung — mittel (3/5) Die Kosten verschieben sich von Nachforderungsstunden (indirekt messbar) hin zu mehr vollständigen Fällen pro Sachbearbeiter-Tag. Dazu kommen vermiedene SLA-Pönalen und bessere Fristen-Compliance nach § 14 VVG. Direkter als bei reinen KI-Analysetools (wo der Nutzen noch schwerer zu isolieren ist), aber schwächer als bei den Hochautomatisierungs-Use-Cases im Schaden (wo Regulierungsvolumen direkt messbar ist).

Schnelle Umsetzung — mittel (3/5) Der technische Teil (Dokumentenklassifikation + LLM-Vollständigkeitscheck) ist verhältnismäßig schnell — in 6–8 Wochen pilotfähig. Die eigentliche Arbeit liegt davor: Für jeden Dokumenttyp muss eine präzise Checkliste existieren. Wer diese nicht hat, muss sie erst erarbeiten. Realistisch sind 8–12 Wochen bis zum produktiven Einsatz für 3–5 Dokumenttypen. Das ist machbar, aber kein Wochenend-Projekt. Kein 5, weil die Checklistenarbeit unterschätzt wird.

ROI-Sicherheit — hoch (4/5) Vollständigkeitsquote beim Eingang lässt sich vor und nach der Einführung direkt messen — im Gegensatz zu vielen anderen KI-Anwendungsfällen, wo der Nutzen schwer zu isolieren ist. Zähle Nachforderungsmails vor dem Projekt, nach drei Monaten nochmals: Der Rückgang ist greifbar. Das macht diesen Use Case für Budgetverantwortliche attraktiv. Kein 5, weil der Nutzen an Checklistenqualität hängt — bei schlechten Checklisten keine messbare Verbesserung.

Skalierbarkeit — hoch (4/5) Die Grundlogik (“prüfe Dokument X gegen Checkliste Y”) ist für jeden weiteren Dokumenttyp und jede Produktlinie wiederverwendbar. Einmal aufgebaut, skaliert das System auf neue Dokumentklassen ohne proportionalen Mehraufwand. Kein 5, weil die Checklistenpflege bei Produktänderungen aktive Wartungsarbeit erfordert — sie pflegt sich nicht von selbst.

Richtwerte — stark abhängig von vorhandener Checklistenstruktur, Dokumentenvolumen und Integrationstiefe ins Kernsystem.

Was das System konkret macht

Der technische Kern ist weniger komplex als man vermuten würde: Es ist Dokumentenklassifikation plus Regelprüfung — und LLM-gestützt läuft beides zuverlässig.

Schritt 1 — Dokumenteneingang erkennen.
Das System empfängt ein PDF, ein E-Mail-Anhang-Paket oder einen Portal-Upload. Ein Klassifikationsmodell bestimmt: Was ist das für ein Dokument? Schadensmeldung KFZ, Neuantrag Hausrat, ärztliches Attest, Gutachten Sachverständiger, Vollmacht Makler? Für jeden Typ gilt eine andere Checkliste.

Schritt 2 — Vollständigkeit prüfen.
Das NLP-Modell extrahiert die relevanten Felder aus dem erkannten Dokumenttyp und gleicht sie gegen die Pflichtcheckliste ab: Ist die Policenummer vorhanden und gültig? Ist das Schadendatum ausgefüllt? Ist das richtige Gutachten-Formular angehängt? Wenn ein Vorgang aus mehreren Dokumenten bestehen soll (z. B. Schadenformular + Fotodokumentation + Reparaturkostenvoranschlag), prüft das System auch die Vollständigkeit des Pakets.

Schritt 3 — Entscheiden und handeln.
Vollständig: Der Vorgang wird direkt in die Sachbearbeitungs-Warteschlange eingestellt — ohne manuelle Eingangsprüfung.
Unvollständig: Das System generiert automatisch eine Nachforderungs-E-Mail, die konkret benennt, was fehlt (“Bitte laden Sie das ausgefüllte Formular KS-3 hoch, das Reparaturgutachten fehlt in Ihrer Einreichung”). Die E-Mail geht an den Einreichenden, der Fall kommt in die Warteschleife.

Was das System nicht tut:
Es prüft keine inhaltliche Korrektheit. Das Gutachten kann sachlich falsch sein — das System erkennt nur, ob es vorhanden ist. Es ersetzt keine fachliche Schadensbewertung. Wer das verwechselt, bekommt ein System, das formal vollständige, aber inhaltlich fragwürdige Fälle ohne Warnung in die Bearbeitung gibt.

Welche Dokumenttypen haben die höchste Fehlerrate

Nicht alle Dokumenttypen sind gleich fehleranfällig. Aus Praxisberichten und Sachbearbeiter-Interviews ergibt sich regelmäßig dieselbe Rangfolge der problematischsten Kategorien:

Arztberichte und Gutachten (Private Kranken- und BU-Versicherung): Hohe Varianz in Format und Vollständigkeit je nach Arztpraxis. Fehlendes Datum, unleserliche Diagnosefelder, falsche Formularversion. Fehlerquote erfahrungsgemäß bei 45–55 %.

KFZ-Neuanträge mit Sonderausstattung: Fahrzeugidentifikationsnummer korrekt vorhanden, aber die Pflichtdokumentation für gemeldete Extras fehlt. Besonders häufig bei Flottenverträgen, wo Fahrzeuge nachträglich gemeldet werden.

Schadensmeldungen mit Drittbeteiligung: Wenn Unfallgegner, eigene Versicherung und Werkstatt jeweils Dokumente einreichen, ist die Kombination selten vollständig im ersten Anlauf. Koordination zwischen Parteien führt zu fragmentierten Einreichungen.

Makler-Einreichungen über externe Portale: Makler arbeiten mit verschiedenen Portalsystemen und kennen die internen Checklisten nicht immer vollständig. Hohe Varianz zwischen Maklerunternehmen.

Wichtig für den Systemaufbau: Die KI braucht für die fehleranfälligsten Dokumenttypen die präzisesten Checklisten. Beginne nicht mit den einfachen Typen, die ohnehin meist vollständig sind — beginne mit denen, die die meisten Nachforderungen verursachen.

Rechtliche Implikationen: Wenn “vollständig akzeptiert” ein Fehler war

Die Vollständigkeitsprüfung hat eine Seite, die in Technikdiskussionen regelmäßig übersehen wird: Wenn das System einen Vorgang fälschlich als vollständig einstuft und in die Sachbearbeitung gibt, können Konsequenzen entstehen.

§ 14 VVG (Versicherungsvertragsgesetz): Die Versicherung hat 30 Tage ab Vorlage “der für die Leistungspflicht notwendigen Unterlagen” Zeit zur Entscheidung. Stuft das System einen Vorgang als vollständig ein, startet die Uhr. Stellt der Sachbearbeiter später fest, dass Unterlagen fehlen, ist nachfragender Zeitaufwand intern entstanden — und die Frist läuft.

Auditierbarkeit für BaFin: BaFin-regulierte Betriebe müssen nachweisen können, wie Entscheidungen getroffen wurden. Ein System, das Vollständigkeitsentscheidungen trifft, muss protokollieren, was es geprüft hat und wie es zu “vollständig” gekommen ist. EU AI Act-Klassifizierung: Automatisierte Vollständigkeitsprüfung ist kein Hochrisikosystem im Sinne von Annex III des AI Acts — aber Protokollierungspflichten aus dem BaFin-Rundschreiben 10/2017 (BA) gelten trotzdem.

Makler-Haftung und Weiterleitung: Wenn ein Makler Unterlagen einreicht, die das System als vollständig durchwinkt, aber aus inhaltlichen Gründen zur Ablehnung führen, kann es zu Streit über die Frage kommen, ab wann die Uhr lief. Klare Kommunikation im Eingangs-Acknowledgement (“Vollständigkeit formal bestätigt — inhaltliche Prüfung folgt”) ist keine Formalie, sondern Haftungsschutz.

Fazit: Das System sollte immer mit dem Hinweis kommunizieren, dass die formale Vollständigkeit nicht die inhaltliche Korrektheit ersetzt. In der Nachforderungs-E-Mail wie im Eingangsacknowledgement.

Konkrete Werkzeuge — was wann passt

Es gibt sehr unterschiedliche Wege, eine KI-Vollständigkeitsprüfung umzusetzen. Die Wahl hängt von Volumen, Integrationstiefe und internen IT-Ressourcen ab.

Konfuzio — wenn deutsches Hosting Pflicht ist
Helm & Nagel GmbH aus Berlin, entwickelt explizit für Versicherungen und Banken mit DSGVO-Anforderungen. On-Premises-Betrieb möglich, keine Daten verlassen das Rechenzentrum. Low-Code-Konfiguration von Dokumenttypen und Vollständigkeitschecklisten ohne tiefes IT-Know-how. Sinnvoll für Versicherer mit Datenschutz-Anforderungen, die den US-Cloud-Anbieter ausschließen müssen. Preis auf Anfrage; gilt als mittelstandsfreundlich im Vergleich zu Enterprise-Plattformen.

ABBYY FlexiCapture — wenn Volumen und Dokumentenvielfalt Enterprise-Level haben
Marktführende OCR-Qualität, auch bei handschriftlichen Formularen und schlechter Scan-Qualität. On-Premises oder Azure-Cloud (EU-Region). Für Versicherer, die täglich hunderte bis tausende Dokumente in verschiedenen Formaten verarbeiten. Implementierung: 3–6 Monate, Einrichtungskosten ab mehreren zehntausend Euro. Nicht für KMU geeignet.

Docsumo — wenn entwicklergestützte Integration gewünscht
US-Anbieter, gute API, hohe Extraktionsgenauigkeit. Vollständige 8-stufige Dokumentenpipeline inklusive Ausnahme-Workflow. Achtung: Datenverarbeitung auf US-Servern, kein EU-Hosting bestätigt. Für DSGVO-sensible Versicherungsunterlagen kritisch prüfen — DPA-Abschluss vor Einsatz notwendig. Preise ab ca. 500–1.500 USD/Monat.

Mindee — wenn das Inhouse-Team die API selbst integriert
Französisches Unternehmen, EU-Hosting (AWS Irland), DSGVO-konform. Saubere REST-API, granulare Confidence-Scores, trainierbare Custom-Modelle. Kein fertiges Interface für Sachbearbeiter — reine API, Workflow-Logik muss selbst gebaut werden. Ab 44 EUR/Monat für 500 Seiten. Ideal für Versicherer mit eigenem Entwicklungsteam.

LLM-basierter Ansatz mit ChatGPT oder Claude + Make.com / n8n
Für Versicherer mit weniger als 50 Eingängen täglich oder als schneller Proof-of-Concept: Ein strukturierter Prompt beschreibt die Vollständigkeitscheckliste, das eingehende Dokument wird als Text übergeben, das Modell gibt aus: “vollständig / unvollständig — fehlend: [X, Y]”. Make.com oder n8n orchestrieren den Workflow (E-Mail-Eingang → Text-Extraktion → LLM-Prüfung → Nachforderungs-E-Mail). Keine Investition in spezialisierte IDP-Plattform. Einschränkung: Kein EU-Hosting bei ChatGPT/Claude Standard; für DSGVO-konforme Variante Claude über AWS Bedrock (Frankfurt) nutzen. Sehr gut als Pilotprojekt, bevor man in Enterprise-Software investiert.

Zusammenfassung: Wann welcher Ansatz

• Deutsches Hosting, Low-Code, Versicherungsfokus → Konfuzio
• Enterprise-Volumen, maximale OCR-Qualität, On-Premises → ABBYY FlexiCapture
• Entwicklungsteam vorhanden, DSGVO, API-Integration → Mindee
• US-Hosting akzeptabel, umfangreiche Pipeline → Docsumo
• Kleines Volumen oder Pilottest → LLM + Make.com / n8n

Datenschutz und Datenhaltung

Versicherungsunterlagen enthalten fast immer personenbezogene Daten: Schadenbeschreibungen mit Personenangaben, Gesundheitsdaten bei Kranken- und BU-Versicherungen, Kfz-Daten mit Kennzeichen, Anschriften, Policenummern. Das ist DSGVO-Pflichtgebiet — und im Versicherungsbereich mit zusätzlichen branchenspezifischen Anforderungen verbunden.

DSGVO-Grundregel für alle Tools: Sobald ein externes System Versicherungsunterlagen verarbeitet, ist ein Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO Pflicht. Das gilt für jeden Cloud-Anbieter — auch wenn der im EU-Raum hostet. AVV anfordern, unterzeichnen, aufbewahren.

Besonderheit Gesundheitsdaten: Arztberichte, Diagnosen, BU-Leistungsfälle enthalten Daten nach Art. 9 DSGVO (besondere Kategorien). Diese erfordern höhere technisch-organisatorische Maßnahmen und ggf. eine Datenschutz-Folgenabschätzung (Art. 35 DSGVO) vor dem KI-Einsatz.

EU AI Act und Versicherung: Vollständigkeitsprüfung fällt nicht unter die Hochrisikosysteme nach Annex III des AI Acts — sie ist kein System, das Leistungsansprüche bewertet, sondern nur Formales prüft. Aber: Im Kontext einer vollständigen Schadenbearbeitungskette, die KI nutzt, sollte die Dokumentation der KI-Entscheidungslogik aus BaFin-Compliance-Gründen trotzdem vorhanden sein.

Praktische Empfehlung nach Tool:

• Konfuzio: On-Premises-Option eliminiert externe Datenweitergabe vollständig — datenschutzrechtlich der sauberste Weg
• ABBYY FlexiCapture: Cloud über Azure EU-Region (West Europe) mit ABBYY-AVV — prüfpflichtig, aber machbar
• Mindee: EU-Hosting (AWS Irland), AVV erhältlich — für die meisten Versicherungstypen ausreichend
• Docsumo: US-Hosting, kein EU-Standort bestätigt — für Gesundheitsdaten und BU-Unterlagen problematisch; explizit klären
• LLM via Claude.ai / ChatGPT: US-Hosting, keine dedizierte EU-Region im Consumer-Plan. Für produktiven Betrieb: Claude über AWS Bedrock Frankfurt oder ChatGPT Enterprise mit EU-AVV nutzen

Checklisten aufbauen — der unterschätzte Kern

Hier ist die unbequeme Wahrheit: Das KI-System ist so gut wie seine Checklisten. Kein Algorithmus kann entscheiden, dass zu einer Kfz-Haftpflicht-Schadensmeldung ein Polizeibericht gehört, wenn du dem System nicht gesagt hast, dass das eine Anforderung ist.

Die Checklistenarbeit ist oft das, was Projekte verzögert — und das, was den größten Mehrwert schafft. Weil sie eine Bestandsaufnahme erzwingt, die viele Versicherer nie gemacht haben:

• Welche Dokumenttypen gibt es überhaupt, und für welche gilt welche Checkliste?
• Welche Pflichtfelder und Pflichtanhänge sind pro Schadensklasse wirklich verpflichtend — und welche sind nur “wünschenswert”?
• Was gilt als “ausreichendes Gutachten” bei Kfz-Totalschaden versus Bagatellschaden?
• Unterscheiden sich die Anforderungen nach Einreicher (Versicherungsnehmer direkt vs. Makler vs. Anwalt vs. Werkstatt)?

Diese Arbeit macht kein Tool automatisch. Sie erfordert Sachbearbeiterinnen und Sachbearbeiter, die ihre Fälle kennen — und Produktverantwortliche, die entscheiden, was Pflicht ist und was nicht. Erfahrungsgemäß dauert allein dieser Workshop-Prozess für drei bis fünf Dokumenttypen vier bis sechs Wochen.

Konkreter Startpunkt: Exportiere die letzten 200 Nachforderungs-E-Mails aus deinem Postausgang und kategorisiere, was angefordert wurde. Das sind deine empirischen Checklisten-Lücken — direkt aus dem laufenden Betrieb, ohne Workshop.

Was es kostet — realistisch gerechnet

Einmalige Einrichtungskosten

• Checklistenworkshops intern (3–5 Dokumenttypen): 3–6 Wochen Aufwand von 1–2 erfahrenen Sachbearbeiterinnen/Sachbearbeitern
• Tool-Einrichtung und Integration ins Dokumenteneingang: externe Begleitung 5.000–25.000 EUR je nach Ansatz und Integrationstiefe
• Enterprise-IDP-Lösung (Konfuzio, ABBYY): Projekt typisch ab 20.000–50.000 EUR, inkl. Implementierungspartner
• LLM + Workflow-Tool (Make.com/n8n): eher 2.000–8.000 EUR für Einrichtung und API-Integration

Laufende Kosten (monatlich)

• Konfuzio: Auf Anfrage (Lizenz); kein Pay-per-Page-Modell bekannt
• ABBYY FlexiCapture: Enterprise-Lizenz, auf Anfrage; typisch mehrere tausend EUR/Jahr für Wartung
• Docsumo: ca. 500–1.500 USD/Monat bei mittlerem Volumen
• Mindee: 44–584 EUR/Monat je nach Seitenvolumen
• LLM-API (Claude/ChatGPT): 0,003–0,01 USD pro 1.000 Token; bei 150 Dokumenten täglich ca. 50–200 EUR/Monat

Was du dagegenrechnen kannst
Eine Sachbearbeiterin prüft täglich 40 Eingänge manuell auf Vollständigkeit: 4 Minuten je Fall = 160 Minuten = 2,7 Stunden täglich. Bruttostundensatz 30–45 EUR: das sind 80–120 EUR täglich nur für die Eingangsprüfung — ohne die Nachforderungsrunden. 22 Arbeitstage: 1.760–2.640 EUR pro Monat, eine Vollzeitkraft.

Bei einem Versicherer mit fünf Sachbearbeiterinnen in der Eingangsprüfung: 8.800–13.200 EUR Personalkosten monatlich für den Vollständigkeits-Check allein. Ein System, das 80 % davon übernimmt, amortisiert sich im mittleren Einrichtungsaufwand in vier bis acht Monaten — konservativ gerechnet.

ROI-Messung: Exportiere die Nachforderungsquote aus deinem Schadenmanagementsystem heute. Drei Monate nach Einführung nochmals. Die Differenz ist dein messbarer Effekt.

Typische Einstiegsfehler

1. Die Checklisten aus dem Gedächtnis schreiben statt aus dem Datenmaterial.
Der Reflex: Einige erfahrene Sachbearbeiterinnen und Sachbearbeiter sitzen in einem Raum und listen auf, was “normalerweise” gebraucht wird. Das Ergebnis ist meistens unvollständig — weil Ausnahmen und Sonderfälle im Gedächtnis verschwinden, und weil sich jeder auf jemand anderen verlässt. Besser: Daten zuerst. Letzte 200 Nachforderungs-E-Mails auswerten. Das ist die echte Checkliste, nicht die erinnerte.

2. Das System auf zu viele Dokumenttypen gleichzeitig ausdehnen.
Wer versucht, sofort alle 18 Dokumenttypen eines Versicherers zu erfassen, endet mit 18 halbfertigen Checklisten und einem System, das überall unzuverlässig ist. Drei Dokumenttypen, sauber konfiguriert, messbar verbessert — das ist besser als ein Vollausbau, der sechs Monate braucht und niemanden begeistert. Die anderen 15 kommen danach.

3. Keine Eskalationslogik für unbekannte Dokumenttypen.
Wenn ein Einreicher ein Dokument sendet, das das System nicht kennt (neues Formular, fremdsprachiges Gutachten, unerwartetes Dateiformat), muss das System nicht raten. Es muss eskalieren — und den Fall an einen Menschen weitergeben mit dem Hinweis “Dokumenttyp nicht erkannt”. Fehlt diese Logik, werden unbekannte Dokumente entweder stillschweigend als “unvollständig” abgewiesen oder als “vollständig” durchgelassen. Beides ist falsch.

4. Die Checklisten als einmalige Aufgabe behandeln.
Das ist der gefährlichste Fehler — weil er still passiert.

Produktlinien ändern sich. Formularversionen werden aktualisiert. Neue Pflichtdokumente durch regulatorische Änderungen kommen hinzu. Ein Vollständigkeitssystem, das im Januar konfiguriert und im Dezember nicht aktualisiert wurde, fordert mit hoher Wahrscheinlichkeit falsche Dokumente nach — oder übersieht neue Pflichtfelder. Wer Checklisten nicht als lebendiges Artefakt behandelt, das jemand besitzt und pflegt, hat ein System, das täglich ein bisschen unzuverlässiger wird.

Lösung: Für jeden Dokumenttyp eine namentliche Verantwortungsperson benennen. Mit einem expliziten Trigger-System: Wann wird die Checkliste geprüft? Bei jeder Produktänderung, bei jedem regulatorischen Update, mindestens jährlich. Das ist keine IT-Aufgabe — das ist Fachbereichsaufgabe.

Was mit der Einführung wirklich passiert — und was nicht

Die größte Überraschung in der Einführungsphase ist meistens nicht die Technik. Es sind die Reaktionen der Sachbearbeiterinnen und Sachbearbeiter.

Widerstandsmuster 1: “Das System versteht unsere Ausnahmen nicht.”
Stimmt — am Anfang. Kein System deckt von Anfang an 100 Prozent der Fälle korrekt ab. Die erste Reaktion von Teams ist oft: Ein Sonderfall wird falsch behandelt, und das wird als Beleg dafür gewertet, dass das System “grundsätzlich nicht funktioniert”. Was hilft: Klare Vorab-Kommunikation, dass das System auf die häufigsten 80–90 Prozent der Fälle ausgerichtet ist — seltene Ausnahmen bleiben manuell, das ist kein Fehler. Und ein Feedback-Kanal, über den Ausnahmen gemeldet und in die Checklisten aufgenommen werden können.

Widerstandsmuster 2: Erfahrene Sachbearbeiterinnen und Sachbearbeiter fühlen sich übergangen.
Die Kollegin, die seit zwölf Jahren weiß, welche Unterlagen eine Kfz-Teilkasko-Meldung vollständig machen, hat dieses Wissen als Erfahrungsschatz — und ein System, das das jetzt “automatisch” kann, kann sich bedrohlich anfühlen. Was hilft: Dieses Wissen explizit einbinden. Wer die Checklisten mitgestaltet hat, verteidigt das System. Und das ehrliche Versprechen: Die Sachbearbeiterin prüft weiterhin die inhaltlich schwierigen Fälle — das System nimmt ihr die stupide Eingangskontrolle ab.

Was meistens nicht passiert: Dass Sachbearbeiterinnen und Sachbearbeiter sofort aufhören, die Vollständigkeit selbst im Blick zu haben. In der Praxis kontrollieren gute Sachbearbeiterinnen die ersten Wochen parallel — und das ist gut. Doppelte Kontrolle zu Beginn ist kein Zeichen von Misstrauen, sondern von Qualitätsbewusstsein. Das Vertrauen in das System wächst dann aus der gelebten Erfahrung.

Was konkret hilft:

• Vor dem Launch je Dokumenttyp-Cluster eine Pilotgruppe bilden — zwei bis drei Sachbearbeiterinnen, die das System unter realen Bedingungen testen, bevor es für alle ausgerollt wird
• Eine monatliche Feedback-Runde für die ersten drei Monate: Was hat das System richtig gemacht? Was hat gefehlt? Was war eine ungerechtfertigte Nachforderung? Das sind Daten für Checklisten-Updates
• KPIs kommunizieren: “Nachforderungsquote gesunken von 38 auf 12 Prozent in Monat 3” — Zahlen machen abstrakte Systeme greifbar

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände — und was dahintersteckt

“Unsere Fälle sind zu individuell für eine Checkliste.”
Das Gegenteil ist die Praxis: Die häufigsten Fehler in Nachforderungen sind fast immer dieselben — fehlendes Pflichtformular, falsches Datum, fehlender Anhang. Das sind keine individuellen Fälle, das sind Musterfehler. Die Individualität eines Schadenfalls liegt im Inhalt — nicht in der formalen Vollständigkeit. Wer das verwechselt, lehnt das Richtige aus dem falschen Grund ab.

“Wir haben das schon im System, das merkt man doch sofort.”
In der Praxis: nein. Die meisten Einreichungsportale prüfen, ob ein Feld ausgefüllt wurde — aber nicht, ob der Inhalt plausibel ist, ob die richtige Formularversion verwendet wurde, oder ob das angehängte PDF tatsächlich das erwartete Dokument enthält. Das sind verschiedene Qualitätsstufen. Die Verwechslung dieser Stufen führt dazu, dass “formal ausgefüllt” für “vollständig” gehalten wird — bis der Sachbearbeiter es öffnet.

“Was, wenn das System eine falsche Nachforderung schickt?”
Das wird passieren, besonders in den ersten Wochen. Eine falsche Nachforderung ist unangenehm, aber nicht katastrophal — der Einreichende antwortet und stellt klar, dass das Dokument vorhanden ist. Das System lernt aus dem Feedback. Das Verhältnis aus falsch-positiven Nachforderungen (KI fordert etwas nach, was vorhanden war) zu vermiedenen manuellen Prüfungsrunden entscheidet darüber, ob sich der Ansatz lohnt. In der Praxis überwiegen die vermiedenen Prüfungsrunden deutlich die falsch-positiven Nachforderungen — sofern die Checklisten sauber konfiguriert sind.

Woran du merkst, dass das zu dir passt

• Dein Team verbringt täglich mehr als zwei Stunden mit Eingangsprüfung — nicht mit inhaltlicher Sachbearbeitung, sondern mit der Frage: Ist alles da?
• Deine Nachforderungsquote liegt über 25 Prozent — gemessen an Fällen, die nach dem ersten Eingang noch einmal angeschrieben werden mussten
• Du empfängst Unterlagen über mindestens drei Kanäle (E-Mail, Portal, Post-Scan) und die Prüfung ist nicht automatisiert
• § 14 VVG-Fristen werden regelmäßig durch Nachforderungsrunden strapaziert — nicht weil Fälle komplex sind, sondern weil Dokumente fehlen
• Du hast mindestens drei Dokumenttypen, die häufig unvollständig ankommen, und für jeden gibt es eine implizite Checkliste im Kopf der erfahrenen Sachbearbeiterinnen und Sachbearbeiter

Wann es sich noch nicht lohnt — drei harte Ausschlusskriterien:

1. Unter ca. 30 Eingängen täglich. Bei kleinerem Volumen amortisiert sich der Einrichtungsaufwand nicht — die Einrichtungskosten übersteigen die erzielbaren Einsparungen mehrfach. Manuelle Eingangsprüfung ist schneller und günstiger.

2. Keine dokumentierten Checklisten vorhanden und keine Ressourcen, sie zu erarbeiten. Das System prüft gegen Checklisten, die du definierst. Wer keine Zeit hat, diese zu erarbeiten (realistisch: zwei bis sechs Wochen Aufwand für fünf Dokumenttypen), sollte nicht anfangen. Das Ergebnis wäre ein System, das keine zuverlässige Prüfung leistet.

3. Dokumenteingang zu heterogen ohne klares Klassifikationsschema. Wenn Dokumente in freier Form eintreffen (jeder Einreichende schickt, was er für richtig hält, in wechselnden Formaten und Sprachen), ohne dass eine Klassifikation möglich ist, braucht man zuerst eine Standardisierung des Eingangskanals — nicht eine KI. Die KI kommt nach der Ordnung, nicht davor.

Das kannst du heute noch tun

Öffne dein E-Mail-Programm und filtere alle ausgehenden E-Mails der letzten drei Monate mit dem Betreff-Wort “Nachforderung” (oder dem Muster, das dein Team tatsächlich verwendet). Zähle: Wie viele pro Woche? Welche Formulierungen tauchen immer wieder auf? Was wurde am häufigsten nachgefordert?

Das dauert 30–60 Minuten und gibt dir mehr Klarheit über dein tatsächliches Nachforderungsprofil als jede Systemdokumentation. Und es ist die Grundlage für deine ersten Checklisten — ohne Workshop, ohne Tool, ohne Investition.

Wenn du danach sehen willst, wie eine automatisierte Vollständigkeitsprüfung konkret aussieht, kannst du diesen Prompt als einfachen Pilottest nutzen — heute, ohne Systemintegration:

Quellen & Methodik

• Pexon Consulting, pexon-consulting.de (2025): Praxisbericht zu KI-Dokumentenanalyse und Schadensprüfung in der Versicherungsbranche. Genannte Werte: 70 % Zeitersparnis bei Schadensprüfung, 30 % schnellere Regulierung, Pilotprojekt in 6 Wochen, Enterprise-Paket ab 52.000 EUR. Anbieterseitige Angabe — nicht unabhängig verifiziert. Einordnung: Anhaltspunkt, kein Benchmark.
• SDA.se, “KI zur Dokumentenprüfung in Versicherungen” (2025): Fallstudie Zurich North America (Dezember 2025): Einsatz von Convr AI für ACORD-Formulare und Loss-Run-Berichte im Commercial P&C Underwriting. Ziel: Underwriter von Routinedokumentation entlasten. Außerdem: Identifikation der Kernfehler bei KI-Modellen ohne annotierte Trainingsdaten (“Das Modell funktioniert auf Papier und versagt in der Praxis”).
• Hunton Insurance Recovery Blog (2024): Klage UnitedHealth/nH Predict — Gerichtsbeschluss zur Offenlegung interner KI-Dokumentation bei algorithmischen Ablehnungsentscheidungen. Hintergrundfallstudie zur Haftungsfrage bei fehlerhafter KI-Klassifikation in der Versicherungsbranche (nicht direkt Vollständigkeitsprüfung, aber strukturell verwandt).
• § 14 VVG (Versicherungsvertragsgesetz): Gesetzlich vorgeschriebene 30-Tage-Frist ab Vorlage der notwendigen Unterlagen zur Leistungsentscheidung.
• EU AI Act, Annex III (2024): Klassifikation von KI-Hochrisikosystemen; formale Vollständigkeitsprüfung ist nicht erfasst, inhaltliche Leistungsbeurteilungssysteme hingegen schon.
• BaFin-Rundschreiben 10/2017 (BA): Anforderungen an Aufbau-/Ablauforganisation bei algorithmischen Entscheidungsunterstützungssystemen im regulierten Finanzdienstleistungsbereich.
• Erfahrungswerte aus Praxisprojekten: Mehrfach beobachtete Vollständigkeitsquoten (60–70 % ohne, 85–92 % mit Vollständigkeitsprüfung), Nachforderungsquoten und Prozesszeiten aus Projekten mit mittelständischen Versicherern. Keine repräsentative Studie — konsistente Beobachtungen aus mehreren Implementierungen.

Du willst wissen, ob euer Nachforderungsvolumen groß genug für eine Automatisierung ist und welcher Ansatz zu eurer Systemlandschaft passt? Meld dich — das lässt sich in einem kurzen Gespräch klären.