Automatisierte Policenverwaltung und Vertragspflege

Das echte Ausmaß des Problems

Der deutsche Versicherungsmarkt umfasste laut GDV zum Ende des Geschäftsjahres 2024 allein im Lebensversicherungsbereich 80,3 Millionen aktive Verträge — ein Rückgang von 1,4 Prozent gegenüber dem Vorjahr. Im Sachversicherungsbestand kommen nochmals mehrere hundert Millionen Policen hinzu.

Für Makler und Mehrfachagenten bedeutet das: Selbst ein mittelgroßes Unternehmen mit 5.000 bis 20.000 Policen im Bestand hat einen Verwaltungsaufwand, der bei konventioneller Bearbeitung zwei bis vier Vollzeitstellen bindet — ausschließlich für Datenpflege, Fristüberwachung und Kommunikationsvorbereitung, noch bevor ein einziger Beratungsfall ansteht.

Die konkreten Schwachstellen im Bestandsalltag:

• Ablaufende Fristdaten: Kündigungsfristen, Verlängerungsoptionen und Meldepflichten bei Schadenereignissen müssen manuell überwacht werden. In Beständen mit hunderten Policen je Betreuer ist systematisches Monitoring ohne Automatisierung nicht realistisch.
• Veraltete Versicherungssummen: Sachversicherungssummen (Hausrat, Gebäude, Gewerbe) müssen regelmäßig an Kostensteigerungen oder Bestandsveränderungen angepasst werden. Unterversicherung kostet den Kunden im Schadenfall — und kostet den Makler das Vertrauen.
• AVB-Konditionsvergleiche: Wenn ein Versicherer seine Allgemeinen Versicherungsbedingungen ändert, muss der Makler beurteilen, ob die bestehende Police noch passt oder nachgebessert werden muss. Pro Vergleich können mehrere Stunden anfallen — manuell.
• Datenlücken aus der Systemhistorie: Bestandsdaten, die über Jahre von mehreren Personen eingepflegt wurden, enthalten Lücken, Widersprüche und veraltete Adressdaten. Diese Lücken sieht niemand — bis ein Schadenfall oder eine Kündigung den Fehler sichtbar macht.

Laut McKinsey können Versicherungsunternehmen durch den Einsatz von KI in der Policenverwaltung die Onboarding- und Bearbeitungskosten im Policy Administration-Bereich um 20 bis 40 Prozent senken — unter der Voraussetzung, dass die zugrundeliegenden Daten sauber strukturiert sind.

Mit vs. ohne KI — ein ehrlicher Vergleich

Der zentrale Unterschied liegt nicht in der Geschwindigkeit, sondern in der Vollständigkeit. Ein Betreuender kann 30 Policen täglich manuell prüfen. Ein KI-Monitoring-System prüft 30.000 — und liefert morgens eine priorisierte Liste mit genau den Fällen, die heute Handlung erfordern.

Einschätzung auf einen Blick

Zeitersparnis — mittel (3/5) Tägliche Bestandschecks und manuelle Fristüberwachung fallen weg — das spart je nach Bestandsgröße ein bis drei Stunden täglich je Bestandsbetreuer. Das ist real, aber verglichen mit Use Cases wie der automatisierten Schadensmeldungsverarbeitung, die Triage-Aufwand von Minuten auf Sekunden reduziert, ist die Zeitersparnis hier gleichmäßiger über den Tag verteilt und weniger dramatisch sichtbar. Der Effekt zeigt sich vor allem in Peaks: wenn Fristenläufe zusammenfallen oder eine AVB-Konditionsänderung gleich fünfzig Policen betrifft.

Kosteneinsparung — mittel (3/5) Die direkten Kostenersparnisse sind schwer zu isolieren: Gesparte Bearbeitungszeit hat einen klaren Wert, aber der eigentliche Hebel liegt in verhinderten Vertragsverlusten — und die sind per definitionem nicht sichtbar, wenn alles funktioniert. Branchen-Benchmarks zeigen 30–50 Prozent Einsparung bei Policenverwaltungskosten im Vergleich zu rein manuellen Prozessen. Ein Makler, der durch proaktives Monitoring zehn Vertragsabgänge pro Jahr verhindert, erzielt im Bestandsprämienvolumen einen deutlich messbaren Effekt — aber diese Kalkulation erfordert ehrliche Annahmen über tatsächliche Verlustquoten.

Schnelle Umsetzung — niedrig (2/5) Das ist der ehrlichste Score in diesem Profil. Ein nützlicher Pilot erfordert Zugriff auf strukturierte Bestandsdaten aus dem vorhandenen CRM oder Bestandssystem — und genau das ist in vielen Maklerunternehmen nicht ohne Integration-Aufwand möglich. Einfache Fristalarme auf Basis einer sauberen Excel-Liste gehen schneller, aber das volle Monitoring mit AVB-Vergleich und priorisierten Handlungslisten braucht sechs bis zehn Wochen. Verglichen mit schnell umsetzbaren Use Cases wie der KI-Vertriebsunterstützung liegt die Policenverwaltung bei Integrationstiefe und Vorlaufzeit deutlich höher.

ROI-Sicherheit — mittel (3/5) Der Nutzen ist real, aber die Zuweisung ist schwierig. Wie viele Vertragsabgänge wurden tatsächlich durch das Monitoring verhindert? Wie viele AVB-Abweichungen hätte niemand entdeckt, bis ein Schadenfall die Lücke sichtbar gemacht hätte? Beides lässt sich kalkulieren, aber nicht sauber nachweisen. Wer eine klare Erfolgsmessung einrichten will, braucht eine Baseline aus den zwölf Monaten vor der Einführung — Verlustquote, manuelle Bearbeitungszeit, Eskalationsrate — um danach vergleichen zu können.

Skalierbarkeit — sehr hoch (5/5) Das ist der klare Stärkebereich. Ein Monitoring-System, das täglich 5.000 Policen auf ablaufende Fristen, Datenlücken und Versicherungssummen prüft, prüft 50.000 mit identischem Aufwand. Kein zusätzliches Personal, keine umgewerteten Kapazitäten — die Stückkosten je Police sinken mit wachsendem Bestand gegen null. Für Makler in der Wachstumsphase oder bei einer Bestandsübernahme ist das der entscheidende Vorteil.

Richtwerte — stark abhängig von Bestandsgröße, Systemlandschaft und Datenqualität im vorhandenen Bestandssystem.

Was das Monitoring-System konkret macht

Der technische Kern ist ein regelbasiertes Monitoring, das auf strukturierten Bestandsdaten aufsetzt — ergänzt durch NLP- und LLM-Schichten für Aufgaben, bei denen reine Regellogik nicht ausreicht.

Schritt 1 — Datenzugriff und täglicher Scan Das System liest täglich die Bestandsdaten aus dem CRM oder dem Bestandssystem (Guidewire, Duck Creek, SAP FS-PM, assfinet, NAFI oder ein hausintern entwickeltes System) und prüft jeden Vertrag gegen einen Regelsatz:

• Läuft die Kündigungsfrist innerhalb von 60/30/14/7 Tagen ab?
• Liegt die hinterlegte Versicherungssumme unter dem aktuellen Marktwert (z.B. Wohngebäude-Index)?
• Fehlen Pflichtfelder wie Bankverbindung, aktuelle Adresse oder Unterschriftsdatum?
• Hat sich der zugeordnete Betreuer geändert und wurde die Police nicht neu zugewiesen?

Schritt 2 — Priorisierung und Handlungsliste Die Treffer werden nach Dringlichkeit und Auswirkung sortiert. Ablaufende Fristen mit hoher Prämie stehen oben. Datenlücken bei inaktiven Policen ohne Betreuungsrelevanz kommen nach hinten. Betreuer bekommen morgens eine Liste mit priorisierten Aktionen — nicht einen unsortierten Rohdump aller Auffälligkeiten.

Schritt 3 — Kommunikationsvorbereitung Für Standardfälle (Verlängerungsangebot vorbereiten, Adressänderung anfragen) erzeugt das System einen Entwurf für die Kundenkommunikation. Die Betreuenden prüfen, passen bei Bedarf an und senden ab — aber sie schreiben nicht mehr bei null.

Schritt 4 — AVB-Vergleich (optionale LLM-Erweiterung) Wenn ein Versicherer seine Versicherungsbedingungen aktualisiert, lädt das System die neue AVB-Version, vergleicht sie mit der zum Vertragsabschluss gültigen und fasst die relevanten Unterschiede zusammen: Welche Klauseln wurden verschärft? Welche Leistungen entfallen? Der Betreuer erhält eine strukturierte Zusammenfassung, keine 40-seitige Textdatei.

Was das System nicht entscheidet: Ob ein Vertrag angepasst, umgedeckt oder gekündigt werden soll. Das bleibt die Aufgabe des Betreuers — und das ist auch regulatorisch so vorgeschrieben.

Die Systemlandschaft im Versicherungsbestand

Bevor du ein Monitoring-System planst, musst du wissen, auf welche Bestandsdaten du zugreifst — und in welcher Qualität sie vorliegen. Die Systemlandschaft in deutschen Maklerunternehmen und Versicherern ist ausgesprochen heterogen.

Internationale Kernsysteme (Konzerne und große Regionale)

• Guidewire PolicyCenter — Marktstandard für Schaden/Unfall-Versicherer mit strukturierten Daten und REST-API. AI-Integration ist in den aktuellen Niseko/Mammoth-Releases direkt eingebaut. Implementierung dauert 12–24 Monate, Betrieb ist komplex.
• Duck Creek Policy — Microsoft-Azure-basiert, etwas schneller zu integrieren (9–18 Monate), stark bei US-Marktteilnehmern. Gute API-Zugänglichkeit.
• SAP FS-PM (Financial Services Policy Management) — Verbreitet bei größeren deutschen Versicherern mit SAP-Kernlandschaft. Enge Integration in SAP-Ökosystem; Daten sind strukturiert, aber API-Zugriff erfordert SAP-Entwicklungsressourcen.

Deutschsprachige Spezialanbieter (Mittelstand und Makler)

• assfinet und NAFI — Verbreitete Maklerverwaltungssoftware in Deutschland. Bestandsdaten sind strukturiert, aber oft im proprietären Format. Datenbankzugriff über ODBC oder Exportschnittstellen möglich; REST-APIs sind in neueren Versionen verfügbar.
• msg.Life Sierra und Keylane — Lebens- und Krankenversicherungs-Kernsysteme, stark in der D-A-CH-Region. Historisch eng gekoppelt, zunehmend API-fähig.

Interne Legacy-Systeme Viele mittelgroße Maklerunternehmen haben über Jahrzehnte eigene Access-Datenbanken, Excel-Makrolösungen oder frühe Eigenentwicklungen im Einsatz. Diese Systeme haben keine API. Datenzugriff erfolgt über tägliche CSV-Exports oder direkte Datenbankabfragen. Ein Monitoring-System muss mit diesen Exporten arbeiten — was die Datenqualitätsprüfung zu einem echten Projekt macht.

Praktische Konsequenz: Bevor du ein Monitoring-System aufsetzt, muss klar sein, auf welche Datenquelle du zugreifst, in welchem Format die Daten vorliegen und wer für die Konsistenz der Daten verantwortlich ist. Bei Legacy-Systemen ist die erste Projektphase fast immer eine Datenbereinigung — keine KI.

Was BaFin erlaubt — und was nicht

Ein häufiges Missverständnis in der Praxis: Die Grenze zwischen erlaubter Automatisierung und regulierungspflichtiger Entscheidungsunterstützung ist in der Policenverwaltung wichtiger als in fast jedem anderen Versicherungs-Use-Case.

Was automatisiert werden darf — ohne besondere BaFin-Auflagen:

• Fristüberwachung und automatische Erinnerungsauslösung
• Datenvollständigkeitsprüfungen und Lückenidentifikation
• Generierung von Kommunikationsentwürfen, die ein Mensch prüft und freigibt
• Strukturierter Vergleich von Versicherungsbedingungen (Zusammenfassung, nicht Empfehlung)
• Reporting-Automatisierung für interne Controlling-Zwecke

Was regulatorisch anspruchsvoll wird — BaFin MaGo (Rundschreiben 09/2025 VA) und VAG §25a:

• Automatisierte Vertragsänderungen ohne menschliche Prüfung (Anpassung der Versicherungssumme, Deckungsänderungen) — hier gilt: Das System bereitet vor, ein Mensch genehmigt.
• KI-gestützte Empfehlungen für Umdeckung oder Produktwechsel — das berührt die Beratungspflicht nach IDD und muss dokumentiert sein.
• Scoring-Systeme, die Kunden nach Abgangswahrscheinlichkeit priorisieren — das ist Risikobewertung und fällt unter den EU AI Act als Hochrisiko-KI, wenn die Entscheidungsgrundlage diskriminierungsrelevant ist.

Die BaFin verlangt in automatisierten Geschäftsabläufen (§25a VAG, konkretisiert durch MaGo 2025) Nachvollziehbarkeit, Qualitätssicherung und regelmäßige unabhängige Bewertung der automatisierten Prozesse. Das bedeutet in der Praxis: Jede automatisierte Aktion muss protokolliert werden, und es muss ein Mensch benannt sein, der für die Qualität des Systems verantwortlich ist.

Die gute Nachricht: Reines Monitoring — alerting ohne automatische Vertragsveränderung — fällt nicht in die Hochrisiko-Kategorie des EU AI Acts. Du kannst ein vollständiges Fristmonitoring- und Datenpflegesystem aufbauen, ohne BaFin-Genehmigungsverfahren durchlaufen zu müssen.

AVB-Änderungen tracken: Die unterschätzte Pflicht

Makler haben nach höchstrichterlicher Rechtsprechung und IDD-Umsetzung eine laufende Betreuungspflicht: Wenn ein Versicherer die Allgemeinen Versicherungsbedingungen ändert und die bestehende Police dem Kunden dadurch nicht mehr dieselben Leistungen bietet, muss der Makler informieren — unaufgefordert.

In der Praxis werden AVB-Konditionsänderungen von den Versicherern per Post oder digitaler Mitteilung kommuniziert. Ein Betreuungsbüro mit dreißig Versicherungspartnern und mehreren Tausend Policen kann diese Informationen kaum systematisch verfolgen.

KI kann hier konkret helfen:

1. Automatisches Einlesen neuer AVB-Versionen — sobald ein Versicherer eine neue Bedingungsgeneration veröffentlicht, wird das Dokument eingelesen und mit der bisher gespeicherten Version verglichen.
2. Strukturierter Differenzbericht — das System identifiziert geänderte Klauseln und kategorisiert sie: Leistungsverbesserung, Leistungseinschränkung, formale Redaktion ohne inhaltliche Änderung.
3. Betroffene Policen ermitteln — Welche Kunden halten eine Police nach diesem Bedingungswerk? Sie erhalten einen Handlungshinweis in der täglichen Prioritätsliste.

Der Convista-Vergleich: Das Beratungsunternehmen Convista Consulting AG hat für den Assekuradeur Konzept & Marketing ein KI-Modell für genau diesen Zweck implementiert — den automatisierten Vergleich von Versicherungsdokumenten und die strukturierte Identifikation von Abweichungen. Das Ergebnis: manuelle Aufwände erheblich reduziert, ausgebaut auf mehrere Versicherungssparten. Konkrete Prozentsätze wurden nicht veröffentlicht, aber die Ausweitung auf zusätzliche Sparten ist das aussagekräftigste Signal für tatsächlichen Mehrwert.

Wichtige Einschränkung: Das System identifiziert Änderungen und flaggt betroffene Policen. Die Bewertung — ob die Änderung einen Produktwechsel erfordert, und welches Alternativprodukt für den Kunden das richtige ist — bleibt beim Makler. Das ist keine KI-Aufgabe, das ist die Beratungsleistung.

OCR-Fallstricke bei digitalisierten Altdaten

Wer einen Versicherungsbestand digitalisiert oder übernimmt, steht vor einem spezifischen Problem: Ein erheblicher Teil der Altpolicen liegt nicht als strukturierte Daten vor, sondern als eingescannte PDFs — oft von Verträgen, die vor 20 Jahren ausgedruckt und abgeheftet wurden.

OCR-Erkennung auf diesen Dokumenten ist deutlich anspruchsvoller als auf modernen digitalen Dokumenten. Was in der Praxis zu Problemen führt:

• Schlechte Scanqualität: Viele Scans aus dem Archiv wurden mit 200 dpi oder weniger erstellt. Für Automatisierung brauchst du mindestens 300 dpi, besser 400. Nachträgliches Upscaling hilft nur bedingt.
• Tabellenformate: Ältere Versicherungspolicen verwenden Layouttabellen für Deckungsbausteine und Prämien. Diese werden von Standard-OCR-Systemen oft als Fließtext ohne Strukturerkennung ausgegeben — Werte landen in falschen Feldern.
• Handgeschriebene Eintragungen: Nachträge und Korrekturen wurden oft handschriftlich in gedruckte Formulare eingetragen. Die Erkennungsqualität für Handschrift liegt auch bei den besten Systemen bei 70–85 Prozent — nicht ausreichend für kritische Vertragsdaten ohne manuellen Review.
• Mehrsprachige Dokumente: Bei Bestandsübertragungen von Versicherern aus dem DACH-Raum oder Expats-Policen kommen Dokumente in Deutsch und Französisch oder Deutsch und Englisch vor. Nicht alle OCR-Systeme erkennen Sprachmischung zuverlässig.

Azure Document Intelligence und ABBYY FlexiCapture sind die stärksten verfügbaren Systeme für strukturierte Dokumentenextraktion — aber beide brauchen ein angepasstes Modell, das auf deine spezifischen Policentypen trainiert wurde. Plan mindestens vier bis sechs Wochen für Trainings- und Validierungsarbeit ein, bevor OCR-Ergebnisse direkt in das Bestandssystem übernommen werden.

Praxisempfehlung: Starte nicht mit den ältesten Altdaten. Beginne mit den aktuellen Jahrgängen (2015 und jünger), die oft schon digital vorliegen oder auf hochwertigeren Scans basieren. Erst wenn das OCR-Modell auf diesen Dokumenten zuverlässig funktioniert, öffne das Projekt für ältere Bestände.

Konkrete Werkzeuge — was wann passt

Die Auswahl hängt stark davon ab, ob du einfache Fristalarme oder ein vollständiges Monitoring-System mit AVB-Vergleich und Kommunikationsvorbereitung aufbauen willst.

Make.com — wenn du schnell einen Piloten testen willst Für einen ersten Monitoring-Piloten auf Basis exportierter Bestandsdaten (CSV oder Excel) ist Make.com die pragmatische Wahl. Du baust einen Workflow, der täglich eine Datei einliest, gegen Fristregeln prüft und eine E-Mail oder Teams-Nachricht mit der Trefferliste erzeugt. Keine Entwicklerressourcen notwendig, EU-Hosting verfügbar, kostenloser Einstieg bis 1.000 Operationen/Monat. Einschränkung: Für hochvolumige Bestände (50.000+ Policen täglich) ist Make.com zu langsam; hier braucht man eine Datenbankintegration.

n8n — wenn Datensouveränität und technische Tiefe gefragt sind n8n ist die stärkere Wahl für Maklerunternehmen, die ihre Bestandsdaten nicht in eine externe Cloud-Plattform schicken wollen. Self-Hosting auf eigener Infrastruktur, vollständige DSGVO-Kontrolle. n8n kann direkt auf Datenbankebene mit assfinet- oder NAFI-Datenbanken kommunizieren, komplexe Regellogik umsetzen und LLM-Aufrufe für AVB-Vergleiche einbetten. Technisches Setup erforderlich — entweder eigene IT oder externer Dienstleister.

Microsoft Power Automate — wenn ihr bereits Microsoft 365 nutzt Für Maklerunternehmen, die SharePoint und Microsoft Dynamics 365 als CRM nutzen, ist Power Automate die naheliegende Wahl. Direkte Integration ohne zusätzliche Middleware, EU-Datenhaltung, Low-Code-Konfiguration. Einschränkung: Wenn dein Bestandssystem nicht im Microsoft-Ökosystem ist, brauchst du Konnektoren oder Dateiexporte als Brücke.

Azure Document Intelligence — für OCR auf Altbeständen Wenn du Altpolicen aus gescannten Archivdokumenten in strukturierte Daten überführen musst, ist Azure Document Intelligence der empfohlene Einstieg für technische Teams. Custom-Modell-Training auf deine Policentypen in fünf bis zehn Beispieldokumenten möglich, EU-Region verfügbar. Pay-per-use: ab ca. 1,50 USD pro 1.000 Seiten für Standard-Erkennung, ca. 10 USD/1.000 Seiten für Custom-Modelle. Für das erste Proof-of-Concept: 500 kostenlose Seiten/Monat im Free-Tier.

ABBYY FlexiCapture — für komplexe Enterprise-OCR-Projekte Wenn du täglich Hunderte von Policen aus Archiven einliest und On-Premises-Betrieb brauchst, ist ABBYY FlexiCapture die etablierte Enterprise-Option. Höchste Erkennungsqualität auch bei degradierten Dokumenten, DSGVO-konformer On-Premises-Betrieb, Deutsch als Muttersprache. Nur auf Anfrage verfügbar, Einstieg ab mehreren Tausend Euro/Jahr — für KMU mit einem kleinen Altbestand kein verhältnismäßiger Aufwand.

Zusammenfassung: Wann welcher Ansatz

• Pilot mit exportierten Bestandsdaten, kein Code → Make.com
• Vollständige Bestandsintegration, DSGVO-konform, technisches Team → n8n
• Microsoft-365-Umgebung bereits vorhanden → Power Automate
• OCR auf Altpolizzen, Cloud, EU-Hosting → Azure Document Intelligence
• Enterprise-OCR mit On-Premises-Anforderung → ABBYY FlexiCapture

Datenschutz und Datenhaltung

Policendaten enthalten personenbezogene Daten nach Art. 4 DSGVO: Name, Adresse, Geburtsdatum, Bankverbindung, gesundheitsrelevante Informationen in der Kranken- und Lebensversicherung, Schadenshistorie. Das hat konkrete Auswirkungen auf jeden Schritt der Systemarchitektur.

Auftragsverarbeitungsvertrag (AVV) ist Pflicht: Sobald ein externes Tool (Make.com, Azure, n8n Cloud) Policendaten verarbeitet, greift Art. 28 DSGVO. Alle genannten Anbieter stellen AVV-Vorlagen bereit — bei Microsoft und n8n als Self-Service, bei Make.com über den Support. Dieser Schritt muss vor dem Produktivbetrieb erledigt sein, nicht danach.

EU-Datenhaltung konkret:

• n8n (Self-hosted): vollständige Kontrolle, keine Drittlandübertragung
• Make.com: EU-Region wählbar, AVV erhältlich, Verarbeitung in der EU möglich
• Microsoft Power Automate: EU Data Boundary wählbar, starke EU-Compliance
• Azure Document Intelligence: EU-Region (West Europe, Switzerland North) explizit auswählbar

Gesundheitsdaten aus Kranken- und Lebensversicherungspolicen: Art. 9 DSGVO (besondere Kategorien) greift, wenn OCR-Systeme oder LLMs auf Dokumente zugreifen, die medizinische Informationen enthalten. Für diesen Teil des Bestands muss die Architektur besonders sorgfältig geplant werden — entweder On-Premises oder mit explizit genehmigter Auftragsverarbeitung. Im Zweifel: Lebens- und Krankenversicherungspolicen erst in Phase 2 automatisieren, nach Prüfung durch den Datenschutzbeauftragten.

Bestandsdatentrennung in Multi-Makler-Strukturen: Wenn mehrere Makler auf einer gemeinsamen Plattform verwaltet werden, müssen Bestandsdaten logisch und technisch getrennt sein. Das gilt auch für KI-Systeme: Ein Monitoring-Modell darf nicht mandantenübergreifend lernen.

Was es kostet — realistisch gerechnet

Einmalige Aufbaukosten

• Pilot mit Make.com oder n8n auf exportierten Daten: intern 2–4 Wochen Aufwand, externe Begleitung: 1.500–4.000 Euro
• Vollständige Bestandsintegration mit CRM-Anbindung, Regeldefinition und Testing: 8.000–25.000 Euro je nach Systemlandschaft
• OCR-Projekt für Altpolizzen (ohne Enterprise-System): 3.000–12.000 Euro für Modelltraining und Validierung
• AVB-Vergleichskomponente mit LLM-Integration: 5.000–15.000 Euro zusätzlich

Laufende Kosten monatlich

• n8n Self-hosted: Infrastrukturkosten 50–150 Euro/Monat (Hosting), LLM-API-Kosten je nach Volumen
• Make.com Teams-Plan: ab 29 USD/Monat für mittleres Operationsvolumen; bei 50.000 Policen täglich höhere Tier nötig
• Azure Document Intelligence (OCR): ca. 1,50–10 USD/1.000 Seiten pay-per-use
• Gesamtbetrieb (integriertes System, mittelgroßer Bestand): 200–600 Euro/Monat

Wie du den Nutzen tatsächlich misst Der ehrlichste Nachweis ist eine Before-After-Messung mit drei Kennzahlen:

1. Bearbeitungszeit je Betreuer für tägliche Bestandschecks (Stunden/Monat)
2. Früherkennungsrate bei ablaufenden Fristen: Wie viele Fristen wurden mindestens 30 Tage im Voraus bearbeitet vs. erst in der letzten Woche?
3. Vertragsverlustquote: Prozentsatz der Policen, die im Jahresvergleich ungeplant abgegangen sind

Wer diese drei Basiszahlen aus den zwölf Monaten vor dem Rollout kennt, hat nach sechs Monaten Betrieb eine belastbare Aussage über den tatsächlichen Nutzen.

Konservatives ROI-Beispiel Ein Maklerunternehmen mit 8.000 Policen und drei Bestandsbetreuenden: täglicher Check-Aufwand vorher 2 Stunden je Person (6 Stunden gesamt). Mit Monitoring: 30 Minuten für die Priorisierungsliste plus Fallbearbeitung (1,5 Stunden gesamt). Einsparung: 4,5 Stunden täglich. Bei einem Bruttostundensatz von 30 Euro: 135 Euro täglich, 2.700 Euro/Monat. Dazu kommen verhinderte Vertragsverluste — schwer zu beziffern, aber bei einem durchschnittlichen Provisionsbarwert von 300–500 Euro je Police bei fünf verhinderten Abgängen jährlich: 1.500–2.500 Euro zusätzlich. Gegen Setup-Kosten von 15.000 Euro amortisiert sich das System in unter einem Jahr.

Drei typische Einstiegsfehler

1. Monitoring ohne Datenbasis starten Der häufigste Fehler: Das Monitoring-System wird aufgesetzt, bevor die Bestandsdaten bereinigt sind. Fehlende Vertragsenddaten, keine einheitlichen Fristformate, Policen ohne Betreuer-Zuweisung — all das erzeugt Fehlalarme und übersieht echte Fälle gleichzeitig. Ein System, das täglich fünfzig irrelevante Alarme auslöst, wird nach zwei Wochen ignoriert. Lösung: Bestandsbereinigung als dediziertes Vorprojekt, mind. vier Wochen.

2. Alle Regeln auf einmal konfigurieren Der Reflex ist verständlich: Wenn man schon ein System baut, soll es alles können. Aber zu viele Regeln beim Start führen zu übervollen Handlungslisten, die niemand abarbeitet. Lösung: Mit einer einzigen Regelkategorie starten (z.B. nur Kündigungsfristen), die Handlungsliste zwei Wochen lang produktiv nutzen, dann erweitern.

3. Das System wird eingeführt — aber wer ist zuständig? Das ist der gefährlichste Fehler, weil er still passiert. Nach drei Monaten läuft das Monitoring zuverlässig, aber die Handlungslisten werden nicht mehr täglich abgearbeitet. Warum? Weil niemand explizit benannt wurde, der dafür verantwortlich ist. Ein KI-Monitoring-System, das warnt, aber nicht zu einer Handlung führt, ist schlimmer als gar kein Monitoring — es gibt dem Makler das Gefühl, dass alles im Griff ist.

Lösung: Vor dem Rollout festlegen, wer die tägliche Handlungsliste abarbeitet, welche Fälle eskalieren können und was passiert, wenn der zuständige Betreuende ausfällt. Das sind organisatorische Fragen, keine KI-Fragen — aber sie entscheiden, ob das System nach sechs Monaten noch läuft.

Bonus-Hinweis: Das Maintenance-Problem Versicherungsregeln ändern sich. AVB-Versionen werden aktualisiert. Neuer Versicherungspartner kommt dazu. Kündigungsfristen-Regelungen ändern sich im Rahmen von Produktreformen. Wer ein Monitoring-System ohne eine definierte Updateprozedur einführt, hat nach 18 Monaten ein System, das mit veralteten Regeln arbeitet — und im schlimmsten Fall Fristen verpasst, weil eine Regeländerung nie eingepflegt wurde. Definiere beim Aufbau, wer für Regelaktualisierungen zuständig ist und welches Ereignis einen Review auslöst.

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

Bestandspflege ist Routinearbeit — und das ist das Problem bei der Einführung. Routinearbeit automatisieren bedeutet, dass Mitarbeitende, die diese Routine jahrelang gemacht haben, jetzt weniger davon machen. Das fühlt sich für manche bedrohlicher an als es ist.

Drei Muster tauchen in der Praxis regelmäßig auf:

Die Kontroll-Skeptiker befürchten, dass das System Fehler macht und niemand sie sieht. Ihre Sorge ist berechtigt. Ein Monitoring-System, das eine ablaufende Frist übersieht, hat reale Konsequenzen. Was hilft: transparente Protokollierung aller geprüften Policen (nicht nur der Treffer), regelmäßige Stichproben und ein klarer Eskalationspfad für Systemfehler. Zeig ihnen die Logs, nicht nur die Ergebnisse.

Die Produktivitäts-Zweifler sind überzeugt, dass sie ihre Policen besser kennen als das System. Das stimmt oft sogar — für die fünfzig Stammkunden, die sie persönlich betreuen. Aber für 4.800 Policen? Da kennt kein Mensch jede Frist. Was hilft: mit den Betreuenden gemeinsam die erste Handlungsliste durchgehen und zeigen, welche Fälle das System gefunden hat, die ihnen nicht präsent waren.

Die “Das haben wir immer so gemacht”-Gruppe wird das System nicht von alleine ausprobieren. Was hilft: eine Pilotphase mit einem freiwilligen Team, das das System vier Wochen lang unter realen Bedingungen testet und dem Rest des Teams anschließend aus eigener Erfahrung berichtet — überzeugender als jede Präsentation.

Was konkret hilft:

• Vor dem Rollout eine Team-Session, in der Betreuende ihre drei wichtigsten Fristrisiken benennen — das wird der erste Regelkatalog
• Wöchentliches kurzes Review der Handlungslisten in den ersten vier Wochen — Feedback einsammeln, Regeln nachjustieren
• Einen internen Champion benennen, der nicht der IT angehört, sondern dem Bestand — jemand, der die Qualität des Systems täglich am eigenen Arbeitsablauf misst

Realistischer Zeitplan mit Risikohinweisen

Wichtig: Der Pilot in Woche 5–7 ist der kritische Meilenstein. Wenn das System in dieser Phase zu viele Fehlalarme produziert oder zu viele echte Fälle übersieht, muss die Regeldefinition überarbeitet werden, bevor der vollständige Rollout stattfindet.

Häufige Einwände — und was dahintersteckt

„Unser CRM kann das schon.” Viele CRM-Systeme bieten einfache Fristerinnerungen — aber kein priorisiertes Monitoring über den gesamten Bestand. Der Unterschied: Ein CRM erinnert dich an Fristen, die du eingepflegt hast. Ein Monitoring-System findet Fristen, die du vergessen hast einzupflegen. Und es priorisiert nach Wert und Dringlichkeit — nicht nach dem Datum der letzten Datenbankeintrags. Das sind grundlegend andere Funktionen.

„Wir haben zu viele Altdaten in Papierform.” Das ist ein Aufwand, kein Ausschlussgrund. Starte das Monitoring mit dem digitalisierten Bestand (typischerweise 60–80 Prozent bei Maklerunternehmen, die seit 2015 digital arbeiten). Der Altbestand kommt in Phase 2 mit OCR-Unterstützung. Ein System, das 70 Prozent des Bestands überwacht, ist deutlich besser als keines.

„Das ist datenschutzrechtlich zu riskant.” Der Einwand ist ernst zu nehmen, aber zu pauschal. Fristmonitoring auf internen Bestandsdaten ohne Cloud-Transfer ist datenschutzrechtlich unkritisch. Das Risiko steigt, wenn Daten an externe LLM-Anbieter übergeben werden (für AVB-Vergleiche oder Kommunikationsentwürfe) oder wenn Gesundheitsdaten aus Kranken- und Lebensversicherungspolicen einbezogen werden. Lösung: Diese Fälle separat bewerten, nicht als pauschales Veto behandeln.

Woran du merkst, dass das zu dir passt

Grüne Signale:

• Du betreust mehr als 1.000 aktive Policen — entweder als Makler, Mehrfachagent oder im Innendienst eines Versicherers
• Dein Team verbringt täglich mehr als eine Stunde mit manuellen Bestandschecks und Fristüberwachung
• In den letzten zwölf Monaten ist mindestens eine Kündigung zu spät bemerkt worden — oder ihr habt Angst, dass das passieren könnte
• Du hast mindestens ein Bestandssystem (CRM, Maklersoftware, PAS), aus dem du strukturierte Daten exportieren kannst
• Ihr betreut Gewerbetransport- oder komplexe Sachversicherungen, bei denen jährliche Anpassungspflichten besonders wichtig sind

Drei harte Ausschlusskriterien:

1. Unter 500 aktiven Policen: Der Einrichtungsaufwand für ein automatisiertes Monitoring-System ist bei diesem Bestandsvolumen nicht gerechtfertigt. Gut gepflegte CRM-Fristerinnerungen und ein wöchentlicher manueller Review-Termin lösen das Problem effektiver. Erst ab etwa 1.000 Policen wird automatisches Monitoring zum Effizienzgewinn.

2. Keine strukturierten Bestandsdaten exportierbar: Wenn dein Bestand ausschließlich in papierbasierten Archiven oder in einem System ohne Datenbankzugang liegt, gibt es keinen Anknüpfungspunkt für ein KI-Monitoring. Die erste Investition muss in ein strukturiertes Bestandssystem fließen, nicht in KI. Ein System, das auf unstrukturierten Rohdaten aufsetzt, produziert unstrukturierten Output.

3. Keine Person verantwortlich für Regelpflege und tägliche Bearbeitung der Handlungslisten: Ein Monitoring-System, das täglich Treffer liefert, die niemand bearbeitet, ist aktiv schädlich — es gibt das Gefühl von Kontrolle ohne echte Kontrolle. Die Gefahr: Ein Fall, der monatelang in der Handlungsliste steht und nie bearbeitet wird, ist in der Rechtsbeziehung zum Kunden schlechter als ein Fall, der gar nicht erkannt wurde.

Das kannst du heute noch tun

Der günstigste Einstieg ohne jedes technische Setup: Exportiere 50 aktuelle Policen aus deinem Bestandssystem als CSV oder Excel — Policennummer, Vertragsbeginn, Vertragslaufzeit, Kündigungsfrist, Versicherungsart, zugeordneter Betreuer. Öffne dann ChatGPT oder Claude und nutze den Prompt unten.

Das gibt dir in 15 Minuten einen ersten Eindruck davon, wie priorisiertes Bestandsmonitoring in der Praxis aussehen kann — bevor du einen Cent in ein System investierst.

Quellen & Methodik

• GDV-Lebensversicherungsstatistik 2024: Gesamtverband der Deutschen Versicherungswirtschaft, „Die deutsche Lebensversicherung in Zahlen 2024” (Publikation, veröffentlicht 2025). Polizzenbestand 80,3 Mio. Verträge, Rückgang 1,4 % gegenüber Vorjahr. URL: gdv.de/resource/blob/180978/
• McKinsey Insurance Productivity 2030: McKinsey & Company, „Insurance productivity 2030: Reimagining the insurer for the future” (2023). 20–40 % Kostensenkungspotenzial im Policy-Administration-Onboarding durch KI-Automatisierung. URL: mckinsey.com/industries/financial-services/our-insights/insurance-productivity-2030-reimagining-the-insurer-for-the-future
• Convista/Konzept & Marketing Praxisfall: Convista Consulting AG, „KI-Projekt beim Assekuradeur Konzept & Marketing” (2023/2024). Erhebliche Reduktion manueller Aufwände bei AVB-Dokumentenvergleich und Bestandsumdeckung, ausgebaut auf mehrere Versicherungssparten. URL: convista.com/kundenprojekte/ki-projekt-beim-assekuradeur-konzept-marketing/
• BaFin MaGo 2025: BaFin, Rundschreiben 09/2025 (VA) — Aufsichtsrechtliche Mindestanforderungen an die Geschäftsorganisation von Versicherungsunternehmen unter Solvabilität II. Anforderungen an automatisierte Geschäftsabläufe: Nachvollziehbarkeit, Qualitätssicherung, regelmäßige Bewertung. URL: bafin.de/SharedDocs/Veroeffentlichungen/DE/Rundschreiben/2025/rs_rundschreiben_09_25_va.html
• Convista AVB-Dokumentenanalyse: Convista Consulting AG, „Ein Fall für KI: Der automatisierte Dokumentenvergleich” (2024). NLP-gestützter AVB-Vergleich reduziert Aufwände bei komplexen Dokumentenvergleichen erheblich, bestätigt durch Branchenpraxis. URL: convista.com/impulse/branche/versicherungswirtschaft/ki-dokumentenvergleich/
• Preisangaben: Azure Document Intelligence (Microsoft, Stand April 2026), Make.com Tarife (Stand April 2026), n8n Cloud-Pläne (Stand April 2026).

Du willst wissen, welcher Einstiegspunkt für deinen Bestand sinnvoll ist — schneller Pilot oder vollständige CRM-Integration? Meld dich — das klären wir gemeinsam in einem kurzen Gespräch.