KI-gestützte Echtzeit-Tarifierung am Angebotspunkt

Das echte Ausmaß des Problems

Das klassische Underwriting-Problem ist ein Informationsproblem. Tarif-Raster fassen Antragsteller in Gruppen zusammen — und vergeben dann einen Gruppen-Preis. Das ist effizient, aber es ignoriert die Signale, die ein individuelles Risikoprofil auseinandernehmen.

Das Problem entsteht nicht bei den Grenzfällen, die Underwriter sowieso manuell prüfen. Es entsteht bei den Standardanträgen, die das System automatisch akzeptiert — weil die Tarifraster-Kriterien erfüllt sind, aber die Kombination mehrerer Merkmale ein erhöhtes Risiko signalisiert, das kein einzelnes Merkmal allein auslöst.

In der Praxis bedeutet das: Neugeschäft hat oft eine höhere Schadenquote als Bestand. Nicht weil neue Kunden schlechtere Risiken sind — sondern weil das Pricing zum Zeitpunkt des Angebots ungenauer ist als nach zwölf Monaten Erfahrung. Laut McKinsey-Analyse 2023 verlieren europäische Sachversicherer durch ungenaue Erstpreisfindung im Neugeschäft durchschnittlich 4–8 Punkte auf die Combined Ratio im ersten Vertragsjahr.

Das ML-gestützte Echtzeit-Scoring löst dieses Problem nicht vollständig — aber es verschiebt den Erkennungszeitpunkt von „nach dem Schaden” auf „vor der Angebotserstellung”.

Mit vs. ohne KI — ein ehrlicher Vergleich

Einschätzung auf einen Blick

Zeitersparnis — niedrig (2/5) Das System spart kaum Zeit bei einfachen Standardfällen — die liefen ohnehin automatisch. Der Gewinn liegt bei Grenzfällen: statt 20–30 Minuten manuelle Analyse liefert das System in Sekunden einen begründeten Score, der die Entscheidung des Underwriters auf 10–15 Minuten reduziert. Kein strukturell transformativer Zeitgewinn, aber ein spürbarer Qualitätsgewinn für den Underwriter.

Kosteneinsparung — sehr hoch (5/5) Der finanzielle Hebel ist vergleichbar mit dem ML-Risikomodell (Anwendungsfall 7) — aber der Wirkungsmechanismus ist ein anderer. Während Risikomodellierung die Bestandsqualität verbessert, verbessert Echtzeit-Scoring die Neugeschäftsqualität. Für einen Versicherer mit 15 Millionen Euro Neugeschäft pro Jahr bedeuten 3 Punkte weniger Schadenquote im ersten Vertragsjahr 450.000 Euro bessere Combined Ratio — nachweisbar innerhalb von drei Quartalen.

Schnelle Umsetzung — niedrig (2/5) Die API-Integration ins Policy-Administration-System ist ein echtes IT-Projekt. Das Modell selbst kann in 2–4 Monaten entwickelt werden — aber die Live-Integration, Testläufe, Fallback-Logik und BaFin-Dokumentation bringen die reale Projektdauer auf 4–12 Monate. Besser als die reine ML-Risikomodellierung (Anwendungsfall 7), aber kein Kurzprojekt.

ROI-Sicherheit — hoch (4/5) Das ist der entscheidende Unterschied zur Risikomodellierung: Statt 12–24 Monate auf Schadensverlauf-Daten zu warten, sieht man die Neugeschäftsqualität nach 2–3 Quartalen. Anträge, die das System mit hohem Score bewertet, können direkt mit der Schadenentwicklung der folgenden Monate abgeglichen werden. Kurzer Messhorizont, klares ROI-Signal.

Skalierbarkeit — mittel (3/5) Das Modell skaliert linear mit dem Antragsvolumen — kein manueller Mehraufwand pro Antrag. Der Engpass ist die Modellqualität: Ohne quartalsweise Rekalibrierung auf aktuelle Schadendaten beginnt das Modell, veraltete Risikosignale zu gewichten. Wartungsaufwand bleibt dauerhaft.

Richtwerte — stark abhängig von Datenbasis, Sparte und Antragsvolumen.

Was das System konkret macht

Schritt 1 — Antrag eingeht, Scoring-API wird aufgerufen Sobald ein neuer Antrag im Policy-Administration-System eingeht, werden die relevanten Merkmale in Echtzeit an das ML-Scoring-Modell übergeben. Der Aufruf dauert unter einer Sekunde. Das Modell liefert einen Risikoscore (z.B. 0–100), eine Kategorisierung (Standard / Grenzfall / Ablehnungsempfehlung) und die drei stärksten Prädiktoren, die zu diesem Score geführt haben.

Schritt 2 — Score wird im Underwriting-System angezeigt Der Underwriter sieht im Antragsformular: Tarif-Ergebnis (wie bisher) + ML-Score mit Begründung. Bei Standardfällen mit hoher Konfidenz kann das System automatisch durchlassen. Bei Grenzfällen markiert es den Antrag für manuelle Prüfung — mit den Hauptgründen bereits aufbereitet.

Schritt 3 — Tarif-Empfehlung bei Grenzfällen Das System berechnet keinen verbindlichen Tarif, sondern eine Empfehlung: Normaltarif / +5–15 Prozent Aufschlag / Ablehnungsempfehlung. Der Underwriter entscheidet. Die KI begründet. Das ist die regulatorisch sauberste Trennung — und die akzeptableste für erfahrene Underwriter.

Schritt 4 — Feedback-Loop: Schäden kalibrieren das Modell Jeder Schaden aus dem Neugeschäft wird automatisch dem Antragsscore des betreffenden Vertrages zugeordnet. Das Modell lernt, welche Scores tatsächlich zu erhöhter Schadenquote geführt haben. Quartalsweise Rekalibrierung verbessert die Präzision laufend.

Konkrete Werkzeuge — was wann passt

Python (XGBoost, scikit-learn) + FastAPI als Scoring-Endpunkt Standard-Architektur für ein ML-Scoring-System. Das Modell wird in Python entwickelt und validiert, dann als REST-API eingesetzt. Das Policy-Administration-System ruft die API bei jedem Antragseingang auf. Für Teams mit Data-Science-Kapazität und API-Erfahrung.

Azure Machine Learning + Azure API Management Vollständige Plattform für Modell-Einsatz, Monitoring und Skalierung. Managed Service reduziert den Betriebsaufwand erheblich — kein eigener Server, automatisches Scaling, integriertes Model-Monitoring. Für Versicherer auf Azure-Infrastruktur.

Julius AI Für explorative Vorbereitung: Bevor das Integrationsprojekt startet, kann Julius AI historische Antrags- und Schadendaten analysieren und zeigen, welche Merkmale tatsächlich prädiktiv sind. Hilft, das Projekt zu priorisieren und den Business Case zu quantifizieren. Ab 20 Dollar/Monat.

Power BI Für Monitoring-Dashboards: Score-Verteilung im Neugeschäft, Vergleich der Schadenquoten nach Score-Bucket, Kalibrierungsmonitoring. Ab 9 Euro/Nutzer/Monat.

Guidewire PolicyCenter + ML-Integration Für Versicherer, die bereits Guidewire nutzen: PolicyCenter unterstützt externe Scoring-APIs direkt im Underwriting-Workflow. Integration über den Guidewire InsuranceSuite Cloud API Layer.

Rechtliche Besonderheiten

EU AI Act — Hochrisiko-Klassifizierung: Systeme, die Versicherungsprämien berechnen oder Underwriting-Entscheidungen unterstützen, fallen unter Anhang III Nr. 5b als Hochrisiko-KI-Systeme. Pflichten: Registrierung in der EU-AI-Datenbank, Conformity Assessment, vollständige Trainingsdaten-Dokumentation, Audit-Log für alle Score-Entscheidungen, und menschliche Aufsicht über alle Ablehnungen. Zeitplan: Anwendungspflicht für Hochrisiko-Systeme ab August 2026 — der Governance-Prozess sollte jetzt beginnen.

DSGVO Art. 22 — automatisierte Einzelentscheidungen: Wenn der ML-Score zu einer automatischen Angebots-Ablehnung führt, ist Art. 22 DSGVO einschlägig: Recht auf menschliche Überprüfung, Erläuterung der Entscheidungslogik, Widerspruchsmöglichkeit. Empfohlenes Design: Das System gibt Empfehlungen, der Mensch entscheidet. Ablehnungen ohne Underwriter-Prüfung sind rechtlich riskant.

BaFin-Meldepflicht für wesentliche Risikomodell-Änderungen: Eine grundlegende Änderung des Tarifierungsverfahrens durch Echtzeit-ML-Scoring ist in vielen Sparten meldepflichtig. Frühzeitige Abstimmung mit dem Aktuariat und Compliance empfohlen.

Diskriminierungsverbote: Das Modell muss auf Proxy-Diskriminierung geprüft werden — insbesondere bei Merkmalen wie Wohnort (PLZ als Proxy für Ethnizität), Beruf und Fahrzeugsegment. Anti-Diskriminierungstests vor dem Go-Live sind rechtlich und ethisch Pflicht.

Was es kostet — realistisch gerechnet

Phase 1 — Machbarkeitsstudie und Modellentwicklung:

• Julius AI + Python-Umgebung: 20–50 Dollar/Monat
• Data-Science-Kapazität: 4–8 Wochen (intern) oder 800–1.500 Euro/Tag (extern)
• Ziel: Pilotmodell auf historischen Daten, Business-Case-Quantifizierung

Phase 2 — API-Integration und IT-Projekt:

• Integrations-Entwicklung ins Policy-Administration-System: 4–10 Personenwochen Entwicklung
• Azure ML Einsatz: 300–1.500 Euro/Monat je nach Antragsvolumen
• Regulatorische Dokumentation (EU AI Act, BaFin): 20–40 Personentage
• Gesamtprojektdauer: 4–12 Monate

ROI-Beispiel: Sachversicherer, 15 Millionen Euro Neugeschäft pro Jahr, aktuelle Neugeschäfts-Schadenquote 78 Prozent. Nach ML-Echtzeit-Scoring: Neugeschäfts-Schadenquote verbessert sich auf 74 Prozent. Effekt: 600.000 Euro bessere Combined Ratio im ersten Jahr bei Projektkosten von 150.000–250.000 Euro.

Vier typische Einstiegsfehler

1. Modell auf Bestandsdaten trainieren, aber Neugeschäft vergessen. Ein Modell, das auf historischen Bestandsverträgen trainiert wurde, kennt das Risikoprofil bestehender Kunden — nicht das von Neukunden, die heute anfragen. Neugeschäft hat andere Merkmalsverteilungen. Trainingsdaten müssen Neuantrags-Charakteristika repräsentieren, nicht Bestandscharakteristika.

2. API-Integration unterschätzen. Das ML-Modell in Python zu entwickeln ist der einfache Teil. Die Integration in ein bestehendes Policy-Administration-System (Guidewire, SAP FS-RI, Eigenentwicklung) mit Echtzeit-Anforderungen und Fallback-Logik ist ein eigenständiges IT-Projekt. Wer den Integrationsaufwand nicht einplant, scheitert nicht am Modell, sondern am Einsatz im Produktivsystem.

3. Underwriter übergehen statt einbinden. Erfahrene Underwriter werden skeptisch reagieren, wenn das System Empfehlungen gibt, die ihrer Intuition widersprechen — und ihnen nicht erklärt wird, warum. SHAP-Werte (Erklärbarkeit der Modellentscheidung) müssen im Underwriting-Interface sichtbar sein. Underwriter, die die Logik verstehen, werden zu den stärksten Fürsprechern.

4. Modell nach Go-Live nicht rekalibrieren. Ein Scoring-Modell, das nach der Einführung nicht regelmäßig auf aktuelle Schadendaten kalibriert wird, beginnt nach 6–12 Monaten systematisch falsch zu gewichten — weil sich Risikostrukturen (Fahrzeugmarkt, Klimaereignisse, wirtschaftliche Lage) verändern. Quartalsweise Rekalibrierung ist kein Optional-Feature, sondern Betriebsvoraussetzung.

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

Die Underwriter-Akzeptanzfrage. Kein erfahrener Underwriter akzeptiert eine „Black Box”, die seine Einschätzung überstimmt. Der Schlüssel: Das System gibt immer eine erklärte Empfehlung (die drei wichtigsten Prädiktoren), und der Underwriter entscheidet immer. In der Praxis zeigt sich, dass Underwriter das System nach den ersten 20–30 Fällen als nützliche Vorbereitung erleben — nicht als Kontrolle.

Das IT-Dependency-Problem. Die Go-Live-Entscheidung liegt oft nicht beim Fachbereich, sondern bei der IT. Policy-Administration-Systeme haben häufig lange Release-Zyklen, und eine neue API-Integration braucht Priorisierung. Ein realistischer Projektplan muss die IT-Koordination als kritischen Pfad einplanen.

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände — und was dahintersteckt

„Unser Policy-Administration-System unterstützt keine externen APIs.” Viele Kernversicherungssysteme haben API-Schnittstellen, die selten genutzt werden. Als Alternative: Batch-Scoring statt Echtzeit — Anträge täglich exportieren, Scores über Nacht berechnen, Ergebnis am nächsten Morgen im System. Kein Echtzeit-Signal, aber ein pragmatischer erster Schritt ohne IT-Großprojekt.

„Wir dürfen bestimmte Merkmale nicht verwenden — Diskriminierungsverbote schränken ein.” Das stimmt für Geschlecht, Ethnizität und direkten Wohnortbezug ohne sachliche Rechtfertigung. Aber es gibt viele regulatorisch akzeptable Merkmale, die deutlich prädiktiver sind als die aktuell genutzten: Kilometerleistung, Fahrzeugalter, Selbstbehalt-Präferenz (Signal für Risikobereitschaft), Anzahl Vorverträge. ML-Modelle können aus diesen Merkmalen mehr herausholen als Raster-Tarifierung.

Woran du merkst, dass das zu dir passt

• Dein Neugeschäft zeigt systematisch eine höhere Schadenquote als dein Bestand — besonders im ersten Vertragsjahr
• Underwriter berichten, dass sie regelmäßig Fälle manuell prüfen, bei denen das System keine klare Empfehlung gibt, obwohl die Merkmale eigentlich ausreichen sollten
• Du hast mindestens 3 Jahre historische Antrags- und Schadendaten mit mindestens 10.000 abgeschlossenen Fällen in einer Sparte

Wann es sich (noch) nicht lohnt: Unter 5.000 Neuanträgen pro Jahr ist das Modell nicht robust genug und der Integrationsaufwand unverhältnismäßig. Manuelle Underwriting-Regeln oder klassische Tarif-Raster-Optimierung sind dann effizienter. Auch ohne API-Zugang zum Policy-Administration-System wird das Projekt zum IT-Marathonprojekt.

Das kannst du heute noch tun

Exportiere aus deinem Schadensystem alle abgeschlossenen Neuanträge der letzten drei Jahre mit Antragsdatum, relevanten Merkmalen und Schadeninformation. Lade den Datensatz in Julius AI und stelle die Frage: „Welche Merkmale der Antragsteller korrelieren am stärksten mit der Schadenshäufigkeit im ersten Vertragsjahr?”

Das ist keine Modellentwicklung — aber eine erste Machbarkeitsstudie in einer Stunde.

Quellen & Methodik

• Neugeschäfts-Schadenquoten-Differenz 4–8 Punkte: McKinsey & Company, „Insurance Pricing and Underwriting Excellence”, 2023.
• EU AI Act, Anhang III Nr. 5b: Verordnung (EU) 2024/1689 — Hochrisiko-KI bei Versicherungsprämienberechnung und Underwriting.
• DSGVO Art. 22: Automatisierte Einzelentscheidungen mit rechtlicher Wirkung — Anforderungen an menschliche Aufsicht.
• BaFin Rundschreiben 10/2018 (VA): Anforderungen an Tarifierungsmodelle und wesentliche Risikomodell-Änderungen.
• XGBoost SHAP-Erklärbarkeit: Lundberg & Lee, „A Unified Approach to Interpreting Model Predictions”, NeurIPS 2017.
• Guidewire PolicyCenter API-Integration: Guidewire Developer Documentation, 2024.