Eingangsbearbeitung gewerblicher Versicherungsanfragen für das Underwriting (Maklerunterlagen, SOV, Schadenverläufe)

Gewerbliche Underwriter erhalten weit mehr Makleranfragen, als sie kalkulieren können, und jede kommt als unstrukturiertes Paket: eine E-Mail, ein paar Formulare, eine Tabelle mit Standorten und mehrere Schadenverläufe in unterschiedlichen Layouts. Die KI stellt das Paket zusammen, ordnet Spalten semantisch zu, extrahiert und gleicht die Fakten ab, markiert Fehlendes, prüft die Zeichnungsbereitschaft und übergibt dem Underwriter einen sauberen Fall. Der Underwriter entscheidet; die Maschine übernimmt Dateneingabe und erste Triage.

Problem & Nutzen

• Heute: Underwriting-Assistenten erfassen Daten aus E-Mails und Anhängen erneut in der Arbeitsumgebung, fragen bei Maklern fehlende Unterlagen nach und sortieren nach Bauchgefühl. Zeichenbares Geschäft konkurriert mit Anfragen außerhalb der Zeichnungsbereitschaft um dieselbe knappe Zeit der Underwriter; langsame Antworten verlieren gegen schnellere Versicherer.
• KI-Nutzen: schnellere erste Antwort an Makler, mehr triagierte Anfragen je Underwriter, einheitliche Erfassung der Daten, die in die Preisfindung einfließen, und ein Prüfpfad, der jeden Wert mit seiner Quellseite verknüpft.
• Nutzenangaben: Von Anbietern berichtete Ergebnisse (Zeitersparnis, Verbesserung der Abschlussquote) gibt es, sie wurden für diese Datei aber nicht unabhängig geprüft; messen Sie Ihre eigene Ausgangslage (siehe Kennzahlen), statt sich auf sie zu verlassen.

Varianten

• Sach / SOV-lastig: Hunderte oder Tausende Standorte, COPE-Daten (Construction, Occupancy, Protection, Exposure), Geokodierung und Aufbereitung für Naturgefahrenmodelle.
• Haftpflicht, Cyber, Transport, D&O: Fragebögen und Finanzdaten statt SOVs.
• MGA / delegierte Zeichnungsvollmacht: Eingangsbearbeitung beim Coverholder, Abstimmung der Bordereaux.
• Rückversicherung: Datenlieferungen der Zedenten und Vertragsslips, ähnliche Normalisierung.
• Maklerseite: Makler nutzen dieselbe Technik, um vorab saubere Anfragen zusammenzustellen.
• Private Nutzung: keine; Privatkundengeschäft ist DOC-003 / auf der Schadenseite AGENT-014.

So funktioniert es

1. Makler-E-Mail / Portal / API
2. Paketaufbau (Anhänge trennen, klassifizieren und verknüpfen; Kontext des E-Mail-Verlaufs)
3. Parsing (OCR, Layout, Tabellenerkennung; Excel über einen strukturbewussten Leser)
4. semantische Feldzuordnung (SOV-Spalten
5. Zielschema; Schadenverlaufstabellen
6. Schadendatensätze)
7. Extraktion + dokumentenübergreifender Abgleich (Konflikte, Duplikate, Währung, Zeiträume)
8. Anreicherung (Geokodierung, Gefahren-/Peril-Daten, Unternehmensregister, Vorschadendaten)
9. Lückenprüfung & Entwurf der Nachfrage an den Makler
10. Triage nach Appetite / Zulässigkeit anhand der Richtlinien
11. Fallanlage in der Arbeitsumgebung / Policenverwaltung; Prüfung und Entscheidung durch den Underwriter

• Semantische Zuordnung: Ein LLM schlägt die Zuordnung beliebiger Tabellenüberschriften zum Schema vor (und die Normalisierung von Einheiten/Währungen); deterministischer Code wendet sie an und validiert Summen.
• Große Tabellen: Geben Sie nie 5.000 SOV-Zeilen in einen Prompt; nutzen Sie das Modell, um eine Zuordnung zu schreiben oder zu wählen, und führen Sie sie dann im Code aus. Prüfen Sie die Versicherungssummen gegen die angegebene Gesamtsumme.
• Triage: Regeln plus LLM-Schlussfolgerung über die Appetite-Dokumente; jedes Urteil nennt die herangezogene Klausel.
• Mensch-in-der-Schleife (Human-in-the-Loop): Der Underwriter bestätigt die extrahierten Schlüsselfelder, übernimmt oder ändert die Triage und verantwortet Angebot, Ablehnung und Weiterleitung. Ablehnungen werden nie allein von der KI versendet.

Datenaufbereitung

Benötigte Daten: Makler-E-Mails und Anhänge, Anträge und Fragebögen, Wertaufstellungen (SOV) in Excel, Schadenverläufe, Jahresabschlüsse, Besichtigungsberichte sowie die Zeichnungsrichtlinien des Versicherers, Appetite-Regeln und historische Angebote. Sie liegen in gemeinsamen Underwriting-Postfächern, im Policenverwaltungssystem, in einem DMS und auf Dateiablagen; manche kommen als Scans.

Typische Lücken: Jeder Makler nutzt ein anderes Layout, Tabellen mit verbundenen Zellen und versteckten Blättern, gescannte Schadenverläufe, doppelte Anfragen und Verlängerungen vermischt mit Neugeschäft, fehlende Ergebnislabels (gezeichnet, abgelehnt, verloren) und Zeichnungsregeln, die nur implizit vorliegen.

Schritte der Aufbereitung: das Postfach anbinden und historische Anfragen exportieren (PREP-005, PREP-007); mit den Underwritern das Datenmodell einer Anfrage definieren (PREP-019, PREP-012); typische SOV-Vorlagen in saubere Tabellen umbauen (PREP-011); gescannte Schadenverläufe digitalisieren (PREP-006); Ergebnisse aus dem Policensystem als Labels gewinnen (PREP-020); die Zeichnungsrichtlinien in einer für Retrieval geeigneten Form niederschreiben (PREP-014); ein Evaluationsset aus 100 bis 200 geprüften Anfragen aufbauen (PREP-018) und Testdaten pseudonymisieren (PREP-022). Bausteine für die Extraktion liefert DOC-014.

Die Datenaufbereitung macht einen mittleren Anteil aus, etwa 25 bis 35 Prozent. Siehe GUIDE-003.

Umsetzungswege

Welcher Weg für wen

• enterprise: Weg B, weil die Eingangsbearbeitung im Underwriting für die Wettbewerbsfähigkeit des Versicherers zentral ist, in die eigenen Policenverwaltungs- und Tarifierungssysteme sowie Appetite-Regeln passen muss und die Mengen eine eigene Pipeline rechtfertigen; Weg A passt zu Versicherern, bei denen bereits ein Anbieter in ihrem Stack verankert ist.
• developer: Weg B, weil Insurtech-Anbieter und Integratoren Pipelines zur Anfrageerfassung auf in der EU gehosteten APIs bauen und an die Systeme der Versicherer anbinden.

Weg A — Kaufen (Standardsoftware)

• Spezialisierte Anbieter für Anfrageerfassung / Underwriting-KI: Cytora (UK; 2025 von Applied Systems übernommen, Produktstatus prüfen), Sixfold, FurtherAI, IntellectAI (in der Recherche genannt); außerdem Kalepa und Federato (Underwriting-Plattformen mit Datenaufnahme). Prüfen: EU-/UK-Datenhaltung, ACORD-Unterstützung, SOV-Verarbeitung in großem Maßstab, Quellenangaben, Konnektor zu Ihrem Policensystem, ob Daten für das Training von Anbietermodellen verwendet werden.
• Kernsystem-Suiten: Guidewire, Duck Creek und Insurity ergänzen die Policenverwaltung um Eingangs- und Dokumentenfunktionen; am stärksten, wenn Sie sie bereits betreiben.
• Generische IDP-Engines (ABBYY, Hyperscience, Rossum, Indico) eignen sich für Formulare und Schadenverläufe, bieten aber SOV-Zuordnung und Appetite-Logik nicht von Haus aus.
• Wählen Sie A, wenn: Sie innerhalb weniger Monate Nutzen wollen und Ihr Policensystem eine Integration bietet.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Parsing: Azure AI Document Intelligence (EU-Regionen), Google Document AI (EU-Standort), AWS Textract, Mistral OCR (EU-Anbieter).
• Schlussfolgerung/Extraktion: multimodale Spitzen-LLMs mit strukturierten Ausgaben über Endpunkte in EU-Regionen (Azure OpenAI, Vertex AI, Bedrock, Mistral). Nutzen Sie schemabeschränkte Ausgaben und Quellenangaben je Feld.
• Orchestrierung: Agenten-Framework oder Workflow-Engine (n8n, Camunda, Temporal), Excel-Verarbeitung in Python (pandas/openpyxl), gesteuert durch vom LLM erzeugte Zuordnungen.
• Wählen Sie B, wenn: Sie eigene Appetite-Logik oder tiefe Integration brauchen und ein Plattformteam haben.

Weg C — Selbst betreiben (Open Source)

• Parsing: Docling, MinerU, PaddleOCR; Excel über pandas/openpyxl.
• Modelle: Open-Weight-LLMs und -VLMs der Klasse 30–120B (z. B. Qwen-, Mistral-, gpt-oss-Familien) auf vLLM; strikte JSON-Dekodierung. Nötig, wenn Anfragen sensible Kundendaten enthalten und Richtlinien die Cloud verbieten.
• Hardware: HW3 für verlässliche Schlussfolgerung auf Paketebene; HW2 genügt nur für die Extraktion von Formularen/Schadenverläufen.
• Aufwand: Schemazuordnung, Evaluationsset und Konnektoren bauen Sie selbst.

Weg D — Eigenes Training

Anfangs selten lohnend. Feintunen Sie einen kleinen Extraktor für Ihre mengenstärksten Schadenverlaufsformate oder Ihr internes SOV-Schema, sobald Sie einige Tausend von Underwritern korrigierte Fälle haben; das Korrekturprotokoll aus der Prüfung sind die Trainingsdaten. Die Appetite-Triage lässt sich besser mit Retrieval plus Regeln lösen.

Stand der Technik (2026)

• Agentische Pipelines, die ein Paket aufteilen, Dokumente an spezialisierte Extraktoren leiten und Konflikte zwischen Dokumenten abgleichen, sind die übliche Produktarchitektur; Oberflächen für Underwriter zeigen jeden Wert neben seinem Quellausschnitt.
• Der Schwerpunkt der Anbieter hat sich von der Extraktionsgenauigkeit zur Entscheidungsunterstützung verlagert: Zusammenfassungen, Appetite- Prüfungen und die nächstbeste Frage an den Makler.
• Grenzen: Schadenverläufe unterscheiden sich stark (mehrspaltige Tabellen, über Seiten geteilte Schäden, Unterschiede bei Währung und Bewertungsstichtag); SOVs haben verbundene Zellen, versteckte Blätter und uneinheitliche Einheiten; gescannte Dokumente und handschriftliche Notizen verschlechtern die Genauigkeit; LLMs füllen Lücken unter Umständen plausibel auf. Gegenmaßnahmen: rechnerische Gegenprüfungen, verpflichtende Quellenangaben und eine Option „nicht gefunden“.
• Öffentliche Benchmarks für genau diese Aufgabe sind selten; bauen Sie aus früheren Anfragen ein eigenes gelabeltes Testset.

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack (ocr-docparse + vlm + llm-general): DOC-003 (Formulare), DOC-008 (Klassifikation in der Poststelle und Weiterleitung des Makler-Posteingangs), DOC-014 (Tabellenextraktion), DOC-012 (Jahresabschlüsse für Unternehmensrisiken), DOC-016 (Regelprüfungen gegen Richtlinien).
• Nachgelagert: PRED-010 (Tarifierungs- und Underwriting-Modelle nutzen die strukturierten Daten), ANOM-003 (Betrugssignale), PRED-037 (Schäden und Reservierung), AGENT-014 (Schadenseite; gleicher Dokumenten-Stack).
• Wissen: Retrieval im Stil von KNOW-001 über Zeichnungsrichtlinien und Handbücher.
• Hardware: Ein HW3-GPU-Server kann Eingangsbearbeitung, Poststelle und Dokumentenlasten der Schadenbearbeitung bedienen.

Aufwand, Kosten & Kennzahlen

• Weg A: 2–6 Monate einschließlich Anbindung an die Arbeitsumgebung und Konfiguration der Appetite-Regeln; Lizenz je Anfrage oder je Plattform.
• Weg B: 4–9 Monate; Kosten sind Modellaufrufe je Paket plus Plattform-Engineering.
• Weg C: 6–12 Monate; GPU-Server plus MLOps.
• Kennzahlen: Zeit vom Eingang bis zur ersten Antwort an den Makler, Anteil automatisch triagierter Anfragen, Genauigkeit auf Feldebene bei SOV-/Schadenverlaufsdaten gegenüber einem Referenzset, Angebots- und Abschlussquote, Underwriter- Stunden je gezeichneter Police, Anteil der Fälle mit Nachfrage beim Makler, Nacharbeitsquote.

Menschen & Veränderung

Beziehen Sie zuerst die Geschäftsleitung und die Leitung des Underwritings ein, denn Appetite- und Weiterleitungsregeln liegen bei ihnen. Holen Sie Underwriter und Underwriting-Assistenten von Anfang an als Mitgestalter hinzu; ergänzen Sie IT und IT-Sicherheit für den Postfachzugriff und die Integration sowie die Datenschutzbeauftragte bzw. den Datenschutzbeauftragten für Rechtsgrundlage und AVV, weil Anfragen personenbezogene Daten der Versicherten und teils Gesundheits- oder Schadendaten enthalten (GUIDE-005). Makler sind als Partner betroffen; teilen Sie ihnen mit, wie Anfragen verarbeitet werden und welches Format hilft.

Betriebsrat: abhängig vom Einzelfall. Die Automatisierung der Eingangsbearbeitung überwacht als solche keine Beschäftigten, doch Protokolle, Produktivitätszahlen je Underwriter oder Triage-Statistiken nach Person fielen unter §87 Abs. 1 Nr. 6 BetrVG (die objektive Eignung genügt). Informieren Sie ihn nach §90 Abs. 1 Nr. 3, da sich Arbeitsabläufe ändern, und vereinbaren Sie, dass die Daten nicht zur individuellen Leistungskontrolle genutzt werden (GUIDE-004).

KI-Kompetenz: Art. 4 der KI-Verordnung (AI Act) verlangt Maßnahmen zur Förderung der KI-Kompetenz (GUIDE-006). Schulen Sie Underwriter darin, Extraktionen mit Quellenangaben zu lesen und typische Fehler zu erkennen. Führen Sie einen Pilot mit einer Sparte und einer kleinen Gruppe durch, im Schattenbetrieb neben der manuellen Erfassung, und entscheiden Sie über Go/No-Go anhand von Genauigkeit und Durchlaufzeit (GUIDE-009). Typische Sorgen sind der Verlust des Urteilsvermögens im Underwriting und die faire Behandlung von Antragstellern. Begegnen Sie ihnen, indem Zeichnungsentscheidung, Tarifierung und Ablehnung bei Menschen bleiben und indem Sie regelmäßig Stichproben auf Verzerrungen ziehen (GUIDE-008).

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): Die Eingangsbearbeitung im Gewerbegeschäft für Geschäftskunden fällt in der Regel nicht unter Annex III. Annex III Nr. 5(c) betrifft Risikobewertung und Preisbildung für natürliche Personen in der Lebens- und Krankenversicherung, daher müssen solche Sparten oder Einzelunternehmer- und stark personenbezogene Fälle, die in eine individuelle Risikobewertung einfließen, gesondert beurteilt werden (Einstufung: hier minimal; abhängig vom Einzelfall, wenn Einzelpersonen bewertet werden). Die KI-Kompetenz (Art. 4) gilt.
• DSGVO: Schadenverläufe und Anträge können personenbezogene Daten enthalten (Geschädigte, Eigentümer, Fahrer, Gesundheitsangaben in Arbeitsunfall- und Unfallsparten). Auftragsverarbeitungsverträge, EU-Hosting, Aufbewahrungsfristen und kein Training des Anbieters mit Ihren Daten.
• Branche: Governance nach Solvency II, Erwartungen der EIOPA an KI-Governance und Erklärbarkeit, DORA für das IKT-Drittparteirisiko (Anbieterregister, Ausstiegspläne), deutsche Anforderungen nach VAG/BaFin (MaRisk VA).
• Risiken: erfundene Werte, die in die Tarifierung gelangen, Prompt Injection über E-Mail-Anhänge, Vertraulichkeit der Maklerdaten. Gegenmaßnahmen: Quellenangaben, Validierungsregeln, Sandboxing von Anhängen und Freigabe durch den Underwriter.

Erste Schritte

1. Sammeln Sie 200–300 historische Anfragen (auch schlechte) und labeln Sie die Schlüsselfelder; das ist Ihr Testset.
2. Legen Sie das Zielschema (SOV, Schadenhistorie, Antragsteller) und die Appetite-Regeln schriftlich fest.
3. Lassen Sie 2–3 Anbieter (Weg A) oder einen Prototyp (Weg B) auf dem Testset laufen; vergleichen Sie Feldgenauigkeit und Zeitersparnis.
4. Pilotieren Sie mit einer Sparte und einigen Underwritern; protokollieren Sie jede Korrektur.
5. Ergänzen Sie den Entwurf der Maklernachfrage und die Anbindung an die Arbeitsumgebung, sobald die Genauigkeit stabil ist.

Quellen

Hinweis: Beim Verfassen dieser Datei war keine Live-Webrecherche möglich (Werkzeugbudget erschöpft); die Links unten sind Primärreferenzseiten, die aus dem Hintergrundwissen benannt wurden, und müssen erneut geprüft werden. 1. Regulation (EU) 2024/1689 (AI Act), Annex III 5(c) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj 2. Regulation (EU) 2016/679 (GDPR) — https://eur-lex.europa.eu/eli/reg/2016/679/oj 3. Regulation (EU) 2022/2554 (DORA) — https://eur-lex.europa.eu/eli/reg/2022/2554/oj 4. ACORD standards and forms — https://www.acord.org 5. Docling project — https://github.com/docling-project/docling 6. Microsoft — Azure AI Document Intelligence — https://learn.microsoft.com/azure/ai-services/document-intelligence/ 7. EIOPA — Artificial intelligence — https://www.eiopa.europa.eu 8. Vendor sites (Cytora, Sixfold, FurtherAI) — https://www.cytora.com , https://www.sixfold.ai , https://www.furtherai.com