AlpenVersicherung: AI-Pilot für multilingualen Support in 14 Tagen

Hintergrund: Ein österreichischer Insurtech mit 300 Mitarbeitern

Dieser Fall ist ein Komposit aus beobachteten Mustern aus der Praxis. Wir erfinden keine Kunden, sondern verdichten wiederkehrende Herausforderungen aus acht Jahren AI-Implementierungen in der Versicherungsbranche. Die Zahlen sind realistische Bandbreiten, keine exakten Messwerte eines einzelnen Projekts.

Die fiktive Firma „AlpenVersicherung“ (320 Mitarbeiter, Wien) betreibt einen B2C- und B2B-Versicherungsbetrieb mit einem jährlichen Umsatz von 45 Mio. EUR. Der Support-Bereich besteht aus 18 Agenten, die täglich 1.200 Anfragen in Deutsch, Englisch und Ungarisch bearbeiten. Die durchschnittliche Antwortzeit liegt bei 4,2 Stunden, die Fehlerquote bei 12 % (falsche Status-Updates, veraltete Daten). Die IT-Infrastruktur umfasst ein SAP-S/4HANA-ERP, ein Salesforce-CRM und Google Workspace als Kommunikationsplattform. Die ISO-27001-Zertifizierung ist seit 2021 gültig, die nächste Audit-Runde steht in 6 Monaten an.

Herausforderung: Compliance, Kosten und Zeitdruck

Der Druck kam von drei Seiten: Erstens die Regulatorik – die OeNB (Österreichische Nationalbank) verlangt seit 2023 eine dokumentierte KI-Risikobewertung für alle automatisierten Kundenkommunikationen. Zweitens die Kosten – die Support-Kosten lagen bei 1,8 Mio. EUR/Jahr, Tendenz steigend. Drittens die Qualität – die Kundenbefragung 2023 zeigte eine NPS von 32, mit dem Hauptkritikpunkt „langsame und ungenaue Antworten zu Bestellungen und Lieferungen“.

Die Geschäftsführung stellte ein Budget von 80.000 EUR für einen Piloten bereit, mit dem Ziel, die Antwortzeit auf unter 1 Stunde und die Fehlerquote auf unter 5 % zu senken. Die harte Bedingung: Keine Daten dürfen das eigene Rechenzentrum verlassen, und die Lösung muss in 14 Kalendertagen produktiv sein. Ein Cloud-LLM-Anbieter (z. B. OpenAI) kam damit sofort aus der Wahl, da die DSGVO-konforme Datenverarbeitung in der EU zwar gegeben ist, aber die ISO-27001-Audit-Trails nicht lokal geführt werden können.

Vorgehen: On-Premise-LLMs und Google-Workspace-Integration

Forfis startete mit einem AI-Prozess-Audit (3 Tage), das die 1.200 täglichen Support-Anfragen in 12 Kategorien einteilte. Die größte Hebelwirkung zeigte die Kategorie „Bestell- und Lieferstatus“ (38 % der Anfragen). Diese wurde als Pilot-Use Case ausgewählt.

Die Architektur: Open-Weight-Modelle (Llama 3 70B) auf zwei NVIDIA A100-GPU-Servern im eigenen Rechenzentrum in Wien. Die Datenanreicherung (Bestellstatus aus SAP, Lieferstatus aus dem Logistik-ERP) erfolgt über eine lokale Python-API. Die Google-Workspace-Integration (Gmail, Calendar) nutzt die offiziellen OAuth-2.0-APIs; die E-Mail-Inhalte werden lokal verarbeitet. Die Orchestrierung läuft über LlamaIndex mit einem lokalen Weaviate-Vektor-Store. Die Human-in-the-Loop-Schleife: Jede Antwort, die einen Geldbetrag oder eine Vertragsklausel enthält, wird vor dem Versand an einen Support-Agenten zur Freigabe geschickt. Der Pilot lief in 14 Kalendertagen: Tag 1-3 Audit, Tag 4-7 Infrastruktur-Setup, Tag 8-10 Modell-Feintuning, Tag 11-14 Pilot-Betrieb mit 10 % des Traffics.

Ergebnis: 81 % schnellere Antwortzeit in 14 Tagen

Nach 14 Tagen im Pilot-Betrieb (10 % des Traffics, ca. 120 Anfragen/Tag) zeigten sich folgende Ergebnisse: Die durchschnittliche Antwortzeit sank von 4,2 auf 0,8 Stunden (−81 %). Die Fehlerquote bei Status-Updates fiel von 12 % auf 4,3 % (−64 %). Die Kosten pro Anfrage sanken von 1,50 EUR auf 0,45 EUR (−70 %), da die manuelle Recherche entfiel. Die NPS im Pilot-Segment stieg von 32 auf 41. Die ISO-27001-Audit-Trails wurden lokal auf dem On-Premise-Server geführt und bestanden die interne Vor-Audit-Prüfung ohne Beanstandungen.

Die Skalierung auf 100 % des Traffics und die Ausweitung auf die ungarische Sprache sind für Q3 2024 geplant. Die Hardware-Investition (einmalig 65.000 EUR) amortisiert sich nach Prognose in 11 Monaten durch die eingesparten Support-Kosten.

Lektionen für ähnliche Teams

• Scope-Disziplin ist der größte Hebel. Der 14-Tage-Timeline war nur möglich, weil der Use Case auf genau eine Kategorie (Bestellstatus) und eine Sprache (Deutsch) begrenzt war. Jede zusätzliche Sprache oder Kategorie hätte die Timeline um 1-2 Wochen verlängert.
• On-Premise ist kein Nachteil, sondern ein Compliance-Vorteil. Die ISO-27001-Audit-Trails lokal zu führen, sparte 3 Wochen an Audit-Vorbereitung. Die Latenz von 150-300 ms pro Inferenz ist für asynchrone Status-Updates irrelevant.
• Human-in-the-Loop ist kein Overhead, sondern ein Qualitäts-Gate. Die 12 % manuellen Freigaben (Geldbeträge, Vertragsklauseln) reduzierten die Fehlerquote um 40 % im Vergleich zu einem vollautomatisierten Setup.
• Google-Workspace-Integration ist der unterschätzte Engpass. Die OAuth-2.0-Setup und die lokale Datenverarbeitung erforderten 2 Tage zusätzliche Arbeit, die im Audit nicht eingeplant waren.
• Datenbereinigung vor dem Modell-Feintuning. Die 38 % der Anfragen, die „Bestellstatus“ enthielten, waren in 15 % der Fälle mit veralteten oder fehlerhaften Daten im SAP-System. Die Datenanreicherung (Cleanup) war der größte Faktor für die Fehlerreduktion, nicht das LLM selbst.