Warum einfacher RAG für Versicherungen zu wenig ist

Warum einfacher RAG für Versicherungen zu wenig ist

Österreichische Versicherer sitzen heute auf Tausenden Seiten Bedingungen, Klauseln und Prozesshandbüchern. Parallel steigt der Druck: strengere Regulatorik, höhere Schadenaufwände durch Klimaereignisse, Fachkräftemangel in Schadenbearbeitung und Underwriting – und Kund:innen, die am liebsten in Sekunden eine klare Antwort auf „Bin ich gedeckt?“ wollen.

Viele Häuser reagieren mit Generativer KI und setzen erste Pilotprojekte mit Retrieval Augmented Generation (RAG) auf. Nach den ersten Demos folgt aber oft Ernüchterung: Die Antworten sind zu allgemein, übersehen wichtige Details oder lassen sich fachlich nicht sauber verantworten. Genau hier liegt der Knackpunkt.

Dieser Beitrag aus unserer Serie „KI für österreichische Versicherungen: InsurTech“ zeigt, warum „RAG von der Stange“ für Versicherungen nicht ausreicht – und wie ein wirklich versicherungsfähiger KI-Ansatz aussehen muss, der Schadenbearbeitung, Risikobewertung, Betrugserkennung und Tarifierung in Österreich zuverlässig unterstützt.

---

1. Was RAG kann – und warum das der Versicherungsrealität nicht genügt

Kurz gesagt: RAG kombiniert ein Sprachmodell mit einer Dokumentensuche. Statt frei zu halluzinieren, greift das Modell auf hinterlegte Dokumente (z.B. AVB, Produktfolder, Prozessbeschreibungen) zu und baut darauf seine Antwort.

Für viele Branchen reicht das überraschend weit. In der Versicherung aber prallen zwei Welten aufeinander:

• hohe finanzielle Konsequenzen jedes Fehlers
• strenge Vorgaben von FMA, IDD, VAG, GWG & Co.

Die Realität im Alltag einer österreichischen Versicherung:

• Ein Callcenter-Mitarbeiter in Wien beantwortet 60–80 Anfragen pro Schicht.
• Eine einzige falsche Aussage zu Deckung oder Selbstbehalt kann mehrere Tausend Euro kosten.
• Falschberatung im Vertrieb kann zu Haftung und Aufsichtsthemen führen.

Ein einfaches RAG, das „irgendwo im PDF eine passende Stelle findet“, ist dafür schlicht zu grob. Es versteht weder die Logik eines Versicherungsvertrags noch die typischen Fallkonstellationen im österreichischen Markt.

Der entscheidende Punkt: Für Versicherungen geht es nicht darum, „ungefähr richtige“ Antworten zu generieren, sondern rechtlich belastbare Entscheidungshilfen zu liefern.

---

2. Struktur von Versicherungsdokumenten: warum Standard-RAG scheitert

Versicherungsverträge sind keine normalen Texte. Sie sind mehrschichtig, voller Querverweise, Ausnahmen und Bedingungen. Ein Beispiel aus einer typischen Haushaltsversicherung illustriert das gut.

Beispiel: „Bin ich gedeckt, wenn der Sturm meine Bäume zerstört?“

Eine Kundin in der Steiermark ruft an: „Sind meine Bäume im Garten versichert, wenn der Sturm sie umhaut?“

Im Bedingungswerk (70+ Seiten) steht verteilt:

1. Auf einer Seite: Bäume und Pflanzen sind gedeckt, wenn sie mindestens 2 Jahre vor dem Schaden gepflanzt wurden.
2. Auf einer anderen Seite: Deckung nur, wenn die Option „Außenanlagen“ mitversichert ist.
3. In einer Tabelle: Limit z.B. 300 € pro Baum.
4. Weiter hinten im Dokument: Ausschluss, wenn das Grundstück größer als 5 Hektar ist.
5. In den Schadenbedingungen: Entschädigung nur gegen Nachweis der Wiederbepflanzung innerhalb von zwei Jahren.

Ein einfacher RAG-Ansatz findet meist nur eine dieser Stellen – oft die erste. Die generierte Antwort lautet dann sinngemäß:

„Ja, die Bäume sind gedeckt, wenn sie seit mindestens zwei Jahren gepflanzt sind.“

Das klingt plausibel, ist aber fachlich unvollständig und damit gefährlich. Korrekt wäre eine Antwort, die in strukturierter Form alle Bedingungen sichtbar macht:

• Ist „Außenanlagen“ tatsächlich in der Police eingeschlossen?
• Alter der Bäume ≥ 2 Jahre?
• Grundstücksfläche ≤ 5 Hektar?
• Entschädigungsgrenze pro Baum (z.B. 300 €) klar genannt?
• Hinweis auf Wiederbepflanzungs-Nachweis innerhalb von zwei Jahren.

Ein versicherungsfähiges RAG muss also nicht nur Textpassagen finden, sondern die Vertragslogik verstehen und zusammenführen. Genau daran scheitern generische Lösungen.

---

3. Tabellen, Klauseln, Ausnahmen: wo Standard-LLMs an Grenzen stoßen

Wer schon einmal österreichische Versicherungsbedingungen gelesen hat, kennt die endlosen Tabellen mit Deckungssummen, Selbstbehalten, Sublimits und Ausschlüssen. Diese Tabellen sind im Alltag zentral:

• Limit für Bargeld im Haushalt
• Höchstentschädigung für Fahrraddiebstahl aus dem Keller
• Sublimit für Elementarereignisse in Risikozonen

Warum „normale“ RAG-Pipelines Tabellen schlecht verstehen

1. Layout ist komplex
   Tabellen werden oft als gescannte PDFs gespeichert. Spalten, Zeilen, Fußnoten, zusammengeführte Felder – ohne zusätzliche Computer-Vision- oder OCR-Schritte bleiben das für ein LLM nur Zeichenwirrwarr.

2. Kontext fehlt
   Eine Zeile „E-Bike – 2.000 €“ sagt allein gar nichts. Relevant wird sie erst im Kontext:

   • welcher Tarif?
   • welche Zusatzbausteine?
   • welcher Geltungsbereich (z.B. Diebstahl außerhalb des Wohnsitzes)?

3. Regelwerke statt Fließtext
   Viele Bedingungsteile sind faktisch Code: Wenn A und B, dann C, sonst D. LLMs können das grundsätzlich, benötigen aber strukturierte Eingaben – nicht einfach nur Text-Fetzen.

Wer also ernsthaft Schadenbearbeitung oder Underwriting mit KI unterstützen will, braucht:

• robuste Extraktion von Tabellen und Formularen
• eine Normalisierung in maschinenlesbare Regeln (z.B. JSON, Wissensgraph)
• ein darüber liegendes KI-System, das diese Regeln konsistent anwendet

RAG ist hier nur der Zugriffspfad auf Dokumente – nicht der eigentliche Entscheidungsautomaten.

---

4. Ohne Lernschleife kein ROI: RAG muss besser werden dürfen

Viele Pilotprojekte laufen so: PDFs werden in einen Vektor-Speicher geladen, ein LLM darüber gelegt, und nach ein paar Tests heißt es: „Trefferquote ungefähr 70 % – sieht gut aus.“

Im operativen Betrieb tauchen dann aber immer wieder dieselben Fehler auf:

• immer wieder der falsche Tarif herangezogen
• Ausschlüsse nicht erwähnt
• Altbestände mit Sonderklauseln ignoriert

Der Grund ist simpel: statische Dokumente lernen nicht. Wenn die Wissensbasis nur aus PDF-Texten besteht, kann das System seine Fehler nicht selbst beheben.

Ein professioneller Ansatz für österreichische Versicherer braucht daher:

1. Feedback-Schleifen mit Fachabteilungen

   • Schaden-Sachbearbeiter:innen, Underwriter, Rechtsabteilung markieren falsche oder unvollständige Antworten.
   • Aus diesen Fällen entstehen kuratierte Wissenseinträge: saubere Q&A-Paare, Entscheidungsbäume, klar formulierte Produktregeln.

2. Schrittweise Ablösung der reinen Dokumentensicht

   • PDFs sind Startpunkt, aber nicht Ziel.
   • Relevantes Wissen wird in domänenspezifische Wissensmodelle überführt.

3. Messbare Qualitätskennzahlen

   • z.B. „Deckungsfragen im Kfz-Bereich: 95 % fachlich korrekt laut Zweitgutachten“.
   • Fehlerquoten werden pro Sparte, Tarifgeneration und Kanal beobachtet.

Ohne diese Lernschleife wird RAG in stark regulierten Bereichen wie der österreichischen Versicherung nie aus dem Pilotstadium herauskommen.

---

5. UX und Kontext: wie KI im Alltag von Agentur bis Schadenservice ankommt

Selbst die beste KI nützt nichts, wenn sie im Alltag nicht bedienbar und vertrauenswürdig ist. Genau hier entscheiden sich Produktivität und Fehlerquote.

Integration in bestehende Workflows

Für maximale Wirkung gehört KI dort hin, wo heute gearbeitet wird:

• im Bestands- und Angebotsystem der Ausschließlichkeit
• im Maklerportal
• in der Schadenbearbeitungsoberfläche
• im Contact-Center-Desktop

Die KI sollte nicht „noch ein zusätzliches Tool“ sein, sondern z.B. als „Insurance Copilot“ im bestehenden System antworten:

• automatische Vorschläge für Deckungsantworten in der Telefonmaske
• Hinweistexte für Beratungsgespräche inkl. Dokumenthinweis
• Vorbefüllung von Schadenakten mit extrahierten Fakten aus E-Mails und Dokumenten

Kontext ist entscheidend

Bevor überhaupt RAG auf Dokumente zugreifen darf, muss der konkrete Kunden- und Vertragskontext klar sein:

• Welche Verträge hat die Kundin wirklich (Haushalt, Eigenheim, Kfz, Rechtsschutz)?
• Welcher Tarifstand? Welche Klauseln? Welche Summen?
• Liegt der Schadenort in einer Hochrisikozone (z.B. Hochwasser)?

Erst wenn diese strukturierten Daten aus Bestands- und Schadensystem abgefragt sind, sollte die KI die passenden Wissenselemente (Bedingungen, interne Leitfäden) ziehen und eine Antwort bauen.

Gute KI in der Versicherung verbindet strukturierte Daten mit unstrukturiertem Wissen zu einer sauberen Entscheidungsempfehlung – nicht nur zu einem hübsch formulierten Text.

Vertrauen, Nachvollziehbarkeit und Compliance

Für österreichische Versicherer ist ein Punkt besonders sensibel: Erklärbarkeit.

• Jede KI-Antwort muss zeigen, woher die Information stammt (Bedingungsdokument, Klauselnummer, interne Richtlinie).
• Mitarbeitende müssen auf einen Blick sehen, wie sicher die Antwort ist und welche Punkte sie manuell prüfen sollten.
• Für FMA-Prüfungen und interne Revision müssen Entscheidungswege rekonstruierbar sein.

Ein sauberes UX-Design könnte z.B. enthalten:

• Farbliche Markierung der Antwortsicherheit (grün/gelb/rot)
• Anzeige der zugrundeliegenden Klauseln zum Aufklappen
• Hinweis „interne Empfehlung – keine Rechtsauskunft“ bei heiklen Fällen

So wird aus KI ein Assistenzsystem, kein intransparenter „Black Box“-Orakel.

---

6. Structured + Unstructured: der eigentliche Hebel für österreichische Versicherer

Die wahre Stärke von Generativer KI in der Versicherung liegt nicht nur im Umgang mit Textdokumenten, sondern im Brückenschlag zwischen zwei Welten:

1. Strukturierte Daten

   • Bestandsdaten aus Polizzenverwaltung und CRM
   • Schadenhistorie und Risikodaten
   • Tarifierungslogik und Pricingparameter

2. Unstrukturierte Daten

   • Bedingungswerke, Produktfolder, Schulungsunterlagen
   • E-Mails, Schadenmeldungen, Fotos, Gesprächsnotizen
   • Interne Wissensdatenbanken und Prozessbeschreibungen

Bislang mussten Sachbearbeiter:innen diese Welten im Kopf verbinden. Mit einem intelligenten, versicherungsspezifischen Entscheidungs-Engine kann KI:

• in der Schadenbearbeitung automatisch prüfen, ob alle Deckungsvoraussetzungen erfüllt sind
• im Underwriting Risikoinformationen aus Freitext (z.B. Makler-E-Mails) extrahieren und mit Tarifregeln kombinieren
• in der Betrugserkennung Auffälligkeiten in Datenmustern mit Hinweisen aus Notizen und Dokumenten verbinden
• bei personalisierten Tarifen Kundendaten, Telematik-Informationen und Regelwerke dynamisch zusammenführen

Gerade im österreichischen Markt – mit vielen Altbeständen, Sondervereinbarungen und regionalen Besonderheiten – ist dieser Brückenschlag ein riesiger Produktivitäts- und Qualitätshebel.

---

Fazit: Von einfachem RAG zum Insurance Decision Engine

Wer in der österreichischen Versicherungswelt nur „ein bisschen RAG“ einführt, wird scheitern – spätestens, wenn der erste komplexe Schadenfall oder eine FMA-Anfrage auf dem Tisch liegt.

Der Weg zu echtem Mehrwert führt über:

1. Domänenspezifisches Verständnis von Versicherungsdokumenten statt bloßer Textsuche.
2. Saubere Erschließung von Tabellen, Limits und Ausnahmen in maschinenlesbarer Form.
3. Kontinuierliche Lernschleifen mit Fachabteilungen, die das System messbar besser machen.
4. Kontext- und workflowgerechte Einbettung von KI in Vertrieb, Service und Schaden.
5. Verknüpfung strukturierter und unstrukturierter Daten zu belastbaren Entscheidungsvorschlägen.

Für Häuser, die 2025 ernsthaft in KI für österreichische Versicherungen investieren, heißt das: Weg von Piloten mit generischen Chatbots – hin zu einer Insurance Decision Engine, die wirklich auf die Besonderheiten von Produkten, Regulatorik und Prozessen im österreichischen Markt zugeschnitten ist.

Wer jetzt startet, kann in den nächsten 12–24 Monaten:

• Bearbeitungszeiten in Schaden und Service deutlich senken
• Fehlerquoten und Regressrisiken reduzieren
• Mitarbeitende spürbar entlasten und gleichzeitig Beratungsqualität steigern

Die Frage ist also nicht mehr, ob Generative KI in der österreichischen Versicherungswelt ankommt – sondern wer sie zuerst so einsetzt, dass sie fachlich hält, was sie verspricht.