Forfis Blog

Author: Forfis

  • AI-Lead-Qualifikation im Fintech: 8-Wochen-Pilot mit Anthropic Claude

    Das Problem: Manuelle Lead-Qualifikation im Fintech-Backoffice

    In einem österreichischen Fintech-Unternehmen mit 51 bis 200 Mitarbeitern staut sich die Lead-Qualifikation im Backoffice. Marketing liefert täglich 20 bis 50 neue Leads aus Formularen, Webinaren und Partnerkanälen. Die Daten sind unvollständig: Firmennamen fehlen, Branchen sind falsch zugeordnet, Kontaktdaten sind dupliziert. Ein Mitarbeiter braucht im Schnitt 15 Minuten pro Lead, um die Daten zu bereinigen und zu qualifizieren. Das ergibt bei 1 000 Leads pro Monat 250 Stunden manueller Arbeit. Die Fehlerrate liegt bei 8 Prozent, weil Menschen müde werden und Muster übersehen. Gleichzeitig gilt PCI DSS, weil manche Leads Finanzdaten enthalten, und DSGVO, weil personenbezogene Daten verarbeitet werden. Die Aufgabe: Ein AI-System, das die Daten bereinigt, die Leads klassifiziert und die Ergebnisse in Notion oder Confluence schreibt, ohne dass sensible Daten das Gebäude verlassen.

    Voraussetzungen vor dem ersten Schritt

    Bevor du mit der Implementierung beginnst, brauchst du folgende Voraussetzungen: Erstens, ein klar definiertes Lead-Format in deinem CRM (z. B. HubSpot, Salesforce oder ein eigenes System), das die Felder für Name, Firma, Branche, Kontaktdaten und Quelle enthält. Zweitens, eine Notion- oder Confluence-Instanz, in der die qualifizierten Leads landen sollen, mit einer Datenbank- oder Seitenstruktur, die die AI-Entscheidungen dokumentieren kann. Drittens, einen API-Key für Anthropic Claude (z. B. Claude 3.5 Sonnet), der in einer Umgebungsvariable gespeichert wird, nicht im Code. Viertens, eine Compliance-Prüfung durch deinen Datenschutzbeauftragten, die bestätigt, dass die Datenanonymisierung vor dem API-Aufruf erfolgt. Fünftens, einen festen Scope für den Pilot: Welche Felder werden bereinigt, welche Klassifikationen werden vorgenommen, und welche Metriken werden gemessen (Fehlerrate, Zykluszeit).

    Die 7 Schritte zur Implementierung

    Schritt 1: Definiere die Metriken. Miss die aktuelle Fehlerrate und Zykluszeit manuell über zwei Wochen. Dokumentiere in einer Tabelle, wie viele Leads pro Tag ankommen, wie lange die Bearbeitung dauert und wie viele Fehler gefunden werden. Das ist deine Baseline. Schritt 2: Baue die Datenbereinigung. Schreibe eine Python-Skript, das die Lead-Daten aus dem CRM liest, Duplikate entfernt (basierend auf E-Mail-Adresse und Firmennamen) und fehlende Felder mit einer Regel-Engine ergänzt (z. B. Branche aus der Domain ableiten). Schritt 3: Integriere Anthropic Claude. Rufe die API mit einem Prompt auf, der die bereinigten Daten klassifiziert: ‘Klassifiziere diesen Lead nach Branche, Unternehmensgröße und Kaufbereitschaft. Gib das Ergebnis als JSON zurück.’ Schritt 4: Schreibe die Ergebnisse in Notion. Nutze die Notion-API, um einen neuen Datenbank-Eintrag zu erstellen, der die AI-Klassifikation und die bereinigten Daten enthält. Schritt 5: Implementiere die Human-in-the-Loop-Schleife. In Notion wird ein Status-Feld ‘AI-Vorschlag’ gesetzt, das ein Mensch auf ‘Bestätigt’ oder ‘Korrigiert’ ändern muss. Schritt 6: Teste mit historischen Daten. Führe die Pipeline über die letzten 30 Tage an und vergleiche die AI-Ergebnisse mit den manuellen Entscheidungen. Schritt 7: Gehe in den Parallelbetrieb. Die AI arbeitet im Hintergrund, der Mensch entscheidet. Nach zwei Wochen ohne kritische Fehler schaltest du die AI auf ‘Autonom mit Freigabe’ um.

    Häufige Stolperfallen und wie du sie erkennst

    Hier sind die häufigsten Fehler und wie du sie erkennst: Erstens, die API-Kosten explodieren, weil der Prompt zu viel Kontext enthält. Erkennst du das an der monatlichen Abrechnung von Anthropic. Lösung: Halte den Prompt unter 500 Token, indem du nur die relevanten Felder übermittelst. Zweitens, die AI klassifiziert Leads falsch, weil der Prompt zu vage ist. Erkennst du das an der hohen Korrekturrate in Notion. Lösung: Füge Few-Shot-Beispiele in den Prompt ein, die typische Leads und ihre korrekte Klassifikation zeigen. Drittens, die Notion-Integration bricht, weil die API-Rate-Limits überschritten werden. Erkennst du das an fehlenden Einträgen in der Datenbank. Lösung: Implementiere ein Retry-Mechanismus mit exponentiellem Backoff. Viertens, sensible Daten landen in den API-Logs. Erkennst du das durch eine Audit-Prüfung der Log-Dateien. Lösung: Maskiere PAN und andere PCI-DSS-sensible Felder vor dem API-Aufruf. Fünftens, die Metriken werden nicht gemessen, weil das Monitoring fehlt. Erkennst du das, wenn nach 8 Wochen niemand weiß, ob sich die Investition gelohnt hat. Lösung: Logge jede AI-Entscheidung mit Zeitstempel und Ergebnis in eine separate Tabelle.

    Fazit: Vom Pilot zum Managed Operation

    Nach 8 Wochen hast du einen funktionierenden Pilot, der die Lead-Qualifikation automatisiert. Die Fehlerrate ist von 8 Prozent auf 2 Prozent gesunken, die Zykluszeit von 15 Minuten auf 2 Minuten pro Lead. Die AI arbeitet im Managed Operations-Modus: Forfis überwacht die Pipeline, optimiert die Prompts bei API-Änderungen von Anthropic und stellt sicher, dass die Compliance-Anforderungen eingehalten werden. Der nächste logische Schritt ist die Erweiterung auf weitere Prozesse: Rechnungsstellung, Kundenbetreuung oder Dokumentenextraktion. Aber erst, wenn der Pilot stabil läuft und die Metriken über vier Wochen konstant sind. Dann kannst du den zweiten Prozess in den Scope aufnehmen, ohne das erste System zu destabilisieren.

  • Compliance-sichere AI-Support-Automatisierung im österreichischen Fintech

    Hintergrund: Ein österreichisches Fintech im Übergang zu AI

    Dieser Fall ist ein Komposit aus beobachteten Mustern in der Praxis. Wir benennen keine realen Kunden, um die Vertraulichkeit zu wahren. Die beschriebene Firma ist ein österreichisches Fintech-Unternehmen mit 120 Mitarbeitern, das Zahlungsdienstleistungen für den B2B-Handel anbietet. Der Stack besteht aus einem spezialisierten Payment-Backend, einem CRM (HubSpot) und Slack als primärem internem Kommunikationskanal. Das Unternehmen befand sich in der Phase ‘Running Isolated Pilots’: Es hatte bereits einzelne Automatisierungen getestet, aber noch keinen durchgängigen, messbaren AI-Einsatz im Kundensupport. Die Region ist Österreich, was spezifische Datenschutzanforderungen (DSGVO) und einen hohen Qualitätsanspruch an den deutschen Sprachgebrauch mit sich bringt. Die Zielgruppe der Kunden ist international, mit einem starken Fokus auf DACH und zunehmend auf osteuropäische Märkte.

    Herausforderung: Multilingualer Support unter PCI-DSS-Bedingungen

    Der Kundensupport war der Engpass. 40 % der eingehenden Anfragen betrafen einfache Statusanfragen: ‘Wo ist meine Bestellung?’ oder ‘Wann wird die Zahlung gutgeschrieben?’. Diese Anfragen erforderten manuelle Abfragen im ERP und im Payment-Backend, was zu einer durchschnittlichen Antwortzeit von 45 Minuten führte. Gleichzeitig wuchs der Bedarf an mehrsprachiger Unterstützung (Deutsch, Englisch, Ungarisch), da der Kundenstamm diverser wurde. Die Compliance-Abteilung blockierte jedoch die Einführung von generischen Chatbots, da PCI-DSS und DSGVO strenge Anforderungen an die Verarbeitung von Zahlungsdaten und personenbezogenen Daten stellen. Es gab keine klare Strategie, wie man AI einsetzen konnte, ohne die Compliance zu gefährden oder die Datenhoheit zu verlieren. Der Druck kam von der Geschäftsführung: Die Skalierung des Supports musste ohne lineares Wachstum der Headcount erfolgen.

    Ansatz: Isolierte Piloten mit Human-in-the-Loop

    Forfis startete mit einem Prozess-Audit (Woche 1-2). Ziel war es, die Workflows zu identifizieren, die für die Automatisierung geeignet sind und gleichzeitig das Compliance-Risiko minimieren. Der gewählte Pilot-Scope: Order and Shipment Status Updates via Conversational Agent. Die Architektur ist model-agnostic, aber für diesen Piloten wurde die OpenAI API (GPT-4o) gewählt, da die Qualität der deutschen und englischen Antworten entscheidend war. Wichtig: Der Agent greift nicht direkt auf Rohdaten im Payment-Backend zu. Stattdessen liest er über eine Middleware nur bereinigte Status-Codes und anonymisierte Metadaten aus dem ERP. Die Integration erfolgt über Slack, wo der Agent als Bot installiert ist. Das Delivery-Modell ist Managed AI Operations: Forfis übernimmt die Wartung, das Monitoring und die kontinuierliche Optimierung der Prompts. Ein Human-in-the-Loop-Mechanismus ist standardmäßig aktiv: Bei Unsicherheit oder bei Anfragen, die über den Status hinausgehen, eskaliert der Agent an einen Mitarbeiter. Der Pilot lief über 8 Wochen.

    Ergebnis: Messbare Effizienzsteigerung in 8 Wochen

    Nach 8 Wochen zeigte der Pilot messbare Ergebnisse. Die Durchlaufzeit für Statusanfragen sank von 45 Minuten auf unter 2 Minuten. Die Fehlerquote (falsche Statusinformation) lag bei < 1 %, da der Agent nur auf validierte Daten aus dem ERP zugreift. Die Eskalationsrate betrug 15 %, was bedeutet, dass 85 % der Statusanfragen vollständig automatisiert abgewickelt wurden. Die Kundenzufriedenheit (CSAT) für die automatisierten Antworten lag bei 4,6/5, leicht über dem manuellen Durchschnitt (4,4/5). Die Mitarbeiter im Support konnten sich auf komplexe Fälle konzentrieren, was die Arbeitszufriedenheit erhöhte. Die Compliance-Abteilung bestätigte, dass keine PCI-DSS-Verstöße auftraten, da keine sensiblen Zahlungsdaten an die LLM-API übergeben wurden. Der Pilot lieferte die Grundlage für eine Ausweitung auf weitere Use Cases, z. B. Retourenabwicklung.

    Lessons Learned: Was ähnliche Teams beachten sollten

    1. Scope eng halten: Der Pilot auf einen einzigen Use Case (Statusanfragen) zu beschränken, war entscheidend für den Erfolg. Eine breitere Automatisierung hätte das Compliance-Risiko erhöht und die Messung unklar gemacht. 2. Datenbereinigung vor der KI: Die Middleware, die nur bereinigte Daten an den Agent weitergibt, ist der Schlüssel zur Compliance. Nicht die KI selbst ist das Risiko, sondern der Datenfluss. 3. Human-in-the-Loop ist kein Nachteil: Die Eskalation an Menschen bei Unsicherheit schützt vor Fehlinformationen und baut Vertrauen bei den Mitarbeitern auf. 4. Managed Operations sind Pflicht: Ein AI-Agent ist kein ‘Set-and-Forget’-Produkt. Die kontinuierliche Optimierung der Prompts und das Monitoring der Fehlerquoten erfordern laufende Betreuung. 5. Slack/Teams als Einstieg: Die Integration in bestehende Tools wie Slack reduziert die Reibung bei der Adoption. Die Mitarbeiter müssen kein neues System lernen, sondern arbeiten im gewohnten Kanal.

  • AI Automation Audit: 15-Punkte-Checkliste für Fintech in der Schweiz

    Warum ein Audit vor dem Piloten steht

    Ein AI Automation Audit ist kein Beratungsauftrag, sondern ein technisches Due-Diligence-Projekt. Es endet mit einem dokumentierten Plan, der festlegt, welcher Workflow als Pilot dient, welche APIs angebunden werden und welche Compliance-Hürden bestehen. Für eine Fintech-Firma mit 51 bis 200 Mitarbeitern in der Schweiz bedeutet das: Der Audit muss innerhalb von 2 Wochen abgeschlossen sein, um den Cashflow nicht zu belasten. Die Checkliste unten ist so aufgebaut, dass jeder Punkt innerhalb von 1 bis 2 Tagen abgearbeitet werden kann. Sie ersetzt keine Strategie, aber sie verhindert, dass der Pilot an technischen oder regulatorischen Details scheitert, die im Vorfeld hätten erkannt werden können.

    Prozessanalyse und Datenqualität

    Bevor ein einziger Code geschrieben wird, muss der Ist-Zustand der Ticket-Verarbeitung dokumentiert sein. Das Helpdesk-System (z. B. Zendesk, Jira Service Management oder ein eigenes Tool) liefert die Rohdaten. Die Frage ist nicht, wie viele Tickets pro Woche ankommen, sondern wie sie strukturiert sind. Ein Ticket mit dem Betreff ‘Zahlung nicht angekommen’ und dem Körper ‘Kunde X sagt, das Geld ist weg’ ist für ein LLM schwer zu klassifizieren. Ein Ticket mit den Feldern ‘Kunden-ID’, ‘Transaktions-ID’, ‘Fehlercode’ und ‘Beschreibung’ ist es nicht. Der Audit muss also die Datenqualität der Eingaben messen. Wenn weniger als 70 % der Tickets die benötigten Metadaten enthalten, ist der erste Schritt nicht die KI, sondern die Anpassung des Ticket-Formulars. Das kostet 2 Tage Entwicklung, spart aber 4 Wochen Fehlklassifikation im Piloten.

    Compliance und Datenfluss

    PCI DSS v4.0 ist in der Schweiz kein optionales Framework, sondern eine Voraussetzung für die Zusammenarbeit mit Payment-Providern. Abschnitt 3.3 verlangt, dass PANs (Primary Account Numbers) bei Speicherung maskiert werden. In einem RAG-System bedeutet das: Vor dem Einbetten in pgvector muss die PAN aus dem Dokument entfernt oder durch einen Token ersetzt werden. Der Token wird in einem getrennten, verschlüsselten Key-Value-Store abgelegt, der nur dem Entschlüsselungs-Service zugänglich ist. Das Embedding enthält somit keine sensiblen Zahlungsdaten. Zusätzlich muss der Audit prüfen, ob das Helpdesk-System Webhooks für neue Tickets und REST-Endpunkte für das Setzen von Metadaten bietet. Wenn nicht, ist der Pilot auf ein anderes System umzuleiten oder die API muss erst ausgebaut werden.

    Technische Architektur und Integration

    Die Architektur des Piloten ist bewusst model-agnostic. Für die Ticket-Triage wird ein Open-Weight-Modell (z. B. Llama 3 70B oder Mistral 8x7B) auf der eigenen Hardware des Kunden betrieben, da die Tickets PCI DSS-relevante Daten enthalten können. Das Modell wird über eine Custom REST API angesprochen, die die Eingaben validiert und die Ausgaben in das Helpdesk-System zurückspielt. pgvector dient als Vektordatenbank für die Retrieval-Augmented Generation: Die Support-Dokumentation, die FAQ und die letzten 100 gelösten Tickets werden in Vektoren umgewandelt und in pgvector gespeichert. Die Suche erfolgt über einen HNSW-Index, der bei 100.000 Vektoren eine Latenz von unter 50 ms liefert. Die Webhooks des Helpdesk-Systems triggern den Agenten bei jedem neuen Ticket. Der Agent erstellt einen Draft und tragt ihn als Kommentar in das Ticket ein. Der Support-Mitarbeiter prüft und sendet.

    KPIs und Messbarkeit

    Der Pilot ist kein ‘Try and Error’, sondern ein gemessener Vergleich. Vor dem Start wird der Baseline-Wert erfasst: Wie lange dauert es im Durchschnitt, bis ein Ticket klassifiziert und weitergeleitet wird? Wie hoch ist die Fehlerquote bei der manuellen Zuordnung? Diese Zahlen werden in einem Dashboard festgehalten. Nach 4 Wochen Pilotbetrieb wird derselbe Messwert erhoben. Die Zielgröße ist eine Reduktion der Cycle Time um mindestens 40 % und eine Fehlerquote von unter 2 %. Wenn die Zahlen nicht erreicht werden, wird der Pilot nicht fortgesetzt, sondern die Ursache analysiert. Häufige Stolpersteine sind: unklare Ticket-Beschreibungen, fehlende Metadaten, oder ein Modell, das für die deutsche Sprache nicht ausreichend trainiert ist. Die Checkliste unten hilft, diese Punkte im Vorfeld zu identifizieren.

    Pflege und Weiterentwicklung der Checkliste

    Eine Checkliste ist kein statisches Dokument. Nach dem Piloten muss sie aktualisiert werden, um die neuen Erkenntnisse einzuarbeiten. Wenn der Pilot gezeigt hat, dass die Ticket-Beschreibungen zu vage sind, wird ein neuer Punkt ‘Ticket-Formular anpassen’ ergänzt. Wenn das Modell bei bestimmten Ticket-Typen fehlerhaft klassifiziert, wird ein Punkt ‘Modell-Finetuning für Typ X’ hinzugefügt. Die Checkliste wird alle 3 Monate von einem technischen Lead und einem Compliance-Beauftragten gemeinsam durchgegangen. Änderungen werden versioniert und dokumentiert. So bleibt das Dokument ein lebendes Werkzeug, das mit der Reifegrad-Entwicklung der KI-Automatisierung mitwächst.

  • AI-Prozess-Audit: RAG-Assistent für B2B-SaaS-Support in 8 Wochen

    Das Problem: Manuelle Back-Office-Arbeit im B2B-SaaS-Support

    B2B-SaaS-Unternehmen mit 11 bis 50 Mitarbeitern stehen vor einem spezifischen Problem: Die manuelle Bearbeitung von Support-Tickets und die Erstellung monatlicher Berichte binden einen erheblichen Teil der Kapazität des Back-Office-Teams. Die Mitarbeiter müssen für jede Anfrage in Confluence oder Notion nach der richtigen Dokumentation suchen, was zu langen Antwortzeiten und inkonsistenten Informationen führt. Gleichzeitig erfordert die monatliche Berichterstattung das manuelle Zusammenstellen von Daten aus CRM, Helpdesk und Projektmanagement-Tools, was fehleranfällig und zeitintensiv ist. Die Herausforderung liegt nicht in der Technologie, sondern in der fehlenden Struktur: Ohne einen klaren Prozess-Audit und eine definierte Roadmap bleibt die Automatisierung ein theoretisches Konzept. Der folgende Leitfaden zeigt, wie Sie in 8 Wochen einen funktionsfähigen RAG-Assistenten aufbauen, der die manuelle Arbeit reduziert und die Berichterstattung automatisiert.

    Voraussetzungen: Was Sie vor dem Start benötigen

    Bevor Sie mit der technischen Umsetzung beginnen, müssen Sie folgende Voraussetzungen schaffen:

    • API-Zugänge: Read-Only-Zugänge zu Confluence oder Notion sowie zum CRM (z. B. HubSpot oder Salesforce) und zum Helpdesk (z. B. Zendesk oder Freshdesk).
    • Prozess-Dokumentation: Ein schriftlicher Prozess für die monatliche Berichterstattung, der alle Datenquellen und Metriken auflistet.
    • Datenbereinigung: Die relevanten Confluence-Seiten müssen strukturiert sein; unstrukturierte Kommentare oder veraltete Artikel sollten vor der Integration bereinigt werden.
    • Team-Zusammensetzung: Ein Produktverantwortlicher, ein technischer Lead und mindestens zwei Support-Mitarbeiter, die als Testnutzer dienen.
    • Budget-Freigabe: Ein festgelegtes Budget für die Pilotphase, das die Kosten für LLM-APIs und Infrastruktur abdeckt.

    Schritte: Von der Audit-Phase zum skalierbaren Piloten

    1. Prozess-Audit durchführen: Identifizieren Sie die drei häufigsten Support-Anfragen und die drei manuelle Schritte in der monatlichen Berichterstattung. Dokumentieren Sie für jeden Schritt die aktuelle Zykluszeit und die Fehlerquote. Dies bildet die Basis für die spätere Erfolgsmessung.
    2. RAG-Architektur aufbauen: Implementieren Sie eine Vektor-Datenbank (z. B. Pinecone oder Weaviate) und laden Sie die Confluence-Daten in semantische Blöcke auf. Verwenden Sie LangChain für die Embedding-Generierung und die Retrieval-Logik.
    3. LangGraph-Workflow erstellen: Definieren Sie den Zustandsfluss für den Support-Assistenten. Der Workflow sollte entscheiden, ob eine Anfrage automatisch beantwortet werden kann oder an einen Menschen eskaliert wird. Verwenden Sie LangGraph für die Multi-Step-Entscheidung und die Tool-Nutzung.
    4. Integration mit dem Helpdesk: Verbinden Sie den RAG-Assistenten mit dem Helpdesk über die API. Der Assistent sollte in der Lage sein, Tickets zu lesen, die relevanten Confluence-Artikel zu finden und einen Entwurf für die Antwort zu generieren.
    5. Monatliche Berichterstattung automatisieren: Erstellen Sie einen separaten LangGraph-Workflow, der am Ende des Monats die Metriken aus CRM und Helpdesk sammelt und in einen Confluence-Report schreibt. Verwenden Sie die API des CRM für die Datenextraktion.
    6. Pilotphase starten: Lassen Sie zwei Support-Mitarbeiter den Assistenten für zwei Wochen im Live-Betrieb testen. Messen Sie die Antwortzeit, die Genauigkeit der Antworten und den manuellen Aufwand für die Berichterstattung.
    7. Ergebnisse auswerten und skalieren: Vergleichen Sie die Pilotdaten mit der Baseline aus dem Audit. Wenn die Zykluszeit um mindestens 30 % gesenkt wurde und die Fehlerquote unter 5 % liegt, planen Sie die Skalierung auf weitere Abteilungen.

    Häufige Stolperfallen und wie Sie sie erkennen

    • Unstrukturierte Confluence-Daten: Wenn die Dokumentation in Confluence unstrukturiert ist, liefert der RAG-Assistent ungenaue Antworten. Erkennen Sie dies daran, dass die Antwortrate unter 70 % fällt oder die Mitarbeiter die Antworten regelmäßig korrigieren müssen. Lösung: Vorverarbeitung der Confluence-Seiten in saubere, semantische Blöcke.
    • Fehlende Eskalationslogik: Wenn der Assistent keine klare Eskalationsregel hat, beantwortet er auch komplexe Anfragen automatisch, was zu Kundenunzufriedenheit führt. Erkennen Sie dies an einer steigenden Anzahl von Follow-up-Tickets. Lösung: Definieren Sie klare Kriterien für die Eskalation, z. B. bei Erwähnung von „Rechnung“ oder „Vertrag“.
    • API-Rate-Limits: Wenn die API des CRM oder des Helpdesk Rate-Limits hat, kann der Assistent nicht rechtzeitig auf Anfragen reagieren. Erkennen Sie dies an Zeitüberschreitungen in den Logs. Lösung: Implementieren Sie eine Queue-Logik und cachen Sie häufig abgefragte Daten.
    • Fehlende Metrik-Definition: Wenn die Metriken für die monatliche Berichterstattung nicht klar definiert sind, liefert der automatisierte Bericht inkonsistente Zahlen. Erkennen Sie dies an Abweichungen zwischen dem automatisierten Bericht und dem manuellen Bericht. Lösung: Definieren Sie jede Metrik mit einer exakten Formel und einer Datenquelle.

    Fazit: Der Weg zur Skalierung über Abteilungen

    Nach der Pilotphase haben Sie einen messbaren Nachweis, dass der RAG-Assistent die manuelle Back-Office-Arbeit reduziert und die monatliche Berichterstattung automatisiert. Der nächste logische Schritt ist die Skalierung auf weitere Abteilungen. Verwenden Sie die Audit-Methodik aus der Pilotphase, um die Prozesse in Vertrieb, Produkt oder Finanzen zu analysieren. Die technische Infrastruktur (LangGraph-Workflows, Vektor-Datenbank) bleibt identisch, nur die Datenquellen und die Prompts ändern sich. Dies ermöglicht es, die Implementierungszeit für jede weitere Abteilung auf 4 bis 6 Wochen zu verkürzen. Beginnen Sie mit der Abteilung, die die höchste manuelle Arbeitslast hat und die klarsten Erfolgskriterien bietet.

  • KI-Vertragsprüfung in der Medtech-Branche: LangChain versus LangGraph

    Zwei Ansätze für KI-gestützte Vertragsprüfung im Gesundheitswesen

    Die KI-gestützte Vertragsprüfung in der Medtech-Branche steht vor zwei grundlegenden Architekturansätzen: einerseits die Integration von LLMs in bestehende Systeme über LangChain, andererseits ein compliance-sicheres Rollout mit LangGraph und lokalen Modellen. Beide Ansätze zielen auf die Automatisierung manueller Dateneingabe bei der Prüfung von Verträgen, unterscheiden sich jedoch in ihrer technischen Umsetzung und regulatorischen Absicherung. LangChain bietet eine schnelle Integration in bestehende Workflows, während LangGraph durch seine Zustandsmaschinen die menschliche Freigabe als festen Schritt in den Prozess einbettet. Für Unternehmen mit 201 bis 500 Mitarbeitern in Österreich, die dem EU AI Act unterliegen, ist diese Unterscheidung entscheidend für die Wahl des richtigen Ansatzes.

    Kriterien für die Bewertung der beiden Ansätze

    Die Bewertung beider Ansätze erfolgt anhand von acht Kriterien, die für die Medtech-Branche in Österreich relevant sind. Erstens die Latenz: Wie schnell liefert das System eine Extraktion? Zweitens die Kosten: Welche laufenden Aufwendungen entstehen für API-Nutzung und Infrastruktur? Drittens der Vendor-Lock-in: Wie abhängig ist das Unternehmen von einem bestimmten Anbieter? Viertens die Compliance: Wie gut erfüllt der Ansatz die Anforderungen des EU AI Act? Fünftens die Datenhoheit: Bleiben die Daten im eigenen Haus? Sechstens die Skalierbarkeit: Wie leicht lässt sich der Prozess auf weitere Dokumenttypen ausweiten? Siebtens die Integration: Wie nahtlos schließt der Ansatz an bestehende Systeme wie Confluence oder Notion an? Achtens die Fehlerquote: Wie zuverlässig ist die Extraktion unter realen Bedingungen?

    Vergleichstabelle: LangChain versus LangGraph

    Kriterium LangChain mit Cloud-LLMs LangGraph mit lokalen Modellen
    Latenz 120-180 ms pro Anfrage 250-400 ms pro Anfrage
    Monatliche Kosten 800-1.200 EUR 1.500-2.000 EUR
    Vendor-Lock-in Hoch (OpenAI/Anthropic) Gering (offene Modelle)
    EU AI Act Compliance Erfordert zusätzliche Maßnahmen Nativer Support durch lokale Verarbeitung
    Datenhoheit Daten verlassen das Gebäude Daten bleiben auf eigener Hardware
    Skalierbarkeit Einfach durch API-Skalierung Erfordert Hardware-Ausbau
    Integration in Confluence/Notion Über REST-APIs Über REST-APIs mit verschlüsseltem Transport
    Fehlerquote bei Vertragsprüfung 3-5 % 1-2 %

    Szenario 1: Schnelle Integration ohne sensible Daten

    LangChain gewinnt, wenn die Latenz entscheidend ist und die Verträge keine sensiblen Patientendaten enthalten. Für die Prüfung von Lieferverträgen oder Servicelevel-Agreements ohne Gesundheitsdaten ist die schnellere Antwortzeit von 120 ms ein klarer Vorteil. Die geringeren monatlichen Kosten von 800 EUR machen diesen Ansatz für kleinere Pilotprojekte attraktiv. Allerdings scheitert dieser Ansatz an der Compliance, wenn die Verträge Patientendaten oder medizinische Spezifikationen enthalten, die dem EU AI Act unterliegen. Die Datenhoheit bleibt in diesem Szenario ungelöst, was für die Medtech-Branche in Österreich ein K.o.-Kriterium darstellt.

    Szenario 2: Compliance-first mit sensiblen Daten

    LangGraph mit lokalen Modellen gewinnt, wenn die Compliance im Vordergrund steht und die Verträge sensible Daten enthalten. Die Verarbeitung auf eigener Hardware stellt sicher, dass keine Patientendaten das Gebäude verlassen, was eine zentrale Anforderung des EU AI Act ist. Die höhere Latenz von 250-400 ms ist für die Vertragsprüfung akzeptabel, da es sich um einen Batch-Prozess handelt und nicht um Echtzeit-Interaktionen. Die geringere Fehlerquote von 1-2 % resultiert aus der strukturierten Zustandsmaschine, die die menschliche Freigabe als festen Schritt einplant. Für Unternehmen mit 201 bis 500 Mitarbeitern in der Medtech-Branche ist dieser Ansatz die einzige Option, die den regulatorischen Anforderungen gerecht wird.

    Empfehlung für die Medtech-Branche in Österreich

    Für die Medtech-Branche in Österreich mit 201 bis 500 Mitarbeitern und einem festen Pilotumfang von drei Monaten ist LangGraph mit lokalen Modellen die empfohlene Option. Die Compliance-Anforderungen des EU AI Act lassen sich mit Cloud-LLMs nur durch zusätzliche Maßnahmen erfüllen, die den Pilotumfang und die Kosten erheblich erhöhen. LangGraph bietet nativen Support für die menschliche Freigabe, die für Hochrisiko-KI-Systeme vorgeschrieben ist. Die Integration in Confluence oder Notion erfolgt über verschlüsselte REST-APIs, die die Datenhoheit wahren. Die höhere Latenz ist für die Vertragsprüfung irrelevant, da es sich um einen Batch-Prozess handelt. Die geringere Fehlerquote von 1-2 % reduziert den manuellen Aufwand für die Compliance-Abteilung und macht den Pilot innerhalb von drei Monaten wirtschaftlich sinnvoll.

  • Lead-Qualifizierung in 4 Wochen: B2B-SaaS, pgvector und ISO 27001

    Hintergrund: B2B-SaaS in der Schweiz, 120 Köpfe, HubSpot als CRM

    Dieser Fall ist ein Komposit aus Mustern, die Forfis in acht Jahren Delivery in der Schweiz und DACH beobachtet hat. Es handelt sich nicht um einen namentlich genannten Kunden, sondern um eine typische Konstellation aus dem B2B-SaaS-Umfeld. Die Zahlen sind realistische Bandbreiten, keine exakten Messwerte eines einzelnen Engagements.

    Die Firma, nennen wir sie „Helvetia Cloud Solutions“, betreibt eine B2B-Plattform für Dokumentenmanagement im Schweizer Markt. Mit 120 Mitarbeitenden, davon 35 im Vertrieb, läuft der Lead-Flow über HubSpot. Die Sales-Teams verbringen 40 bis 50 Prozent ihrer Arbeitszeit mit Routineaufgaben: Lead-Daten aus Webformularen in HubSpot pflegen, fehlende Firmendaten anreichern, Leads nach Branche und Firmengröße klassifizieren und Erstantworten auf Inbound-Anfragen formulieren. Die Folge: Senior-AE verbringen zu viel Zeit mit Datenpflege statt mit Kundenakquise, und die durchschnittliche Reaktionszeit auf einen neuen Lead liegt bei 4,2 Stunden.

    Herausforderung: ISO 27001, HubSpot und der Mangel an Senior-Kapazität

    Der Druck kam aus zwei Richtungen. Erstens: Die Vertriebsleitung wollte die Kosten pro qualifiziertem Lead senken, ohne das Team aufzustocken. Zweitens: Die ISO 27001-Zertifizierung, die Helvetia Cloud Solutions für Enterprise-Kunden vorweisen muss, verbietet den Abfluss personenbezogener Daten in nicht-zertifizierte Cloud-Dienste. Das schloss die Nutzung von OpenAI- oder Anthropic-APIs für die Lead-Daten aus, solange keine vertragliche Auftragsverarbeitung mit Sitz in der EU/CH vorlag.

    Zusätzlich bestand der Bedarf, die Senior-Staff von Routinearbeit zu befreien. Die drei Senior Account Executives im DACH-Team verbrachten nach internen Schätzungen rund 12 Stunden pro Woche mit manueller Datenanreicherung und Lead-Klassifizierung. Bei einem Stundensatz von 120 CHF ergab das einen versteckten Kostenblock von 15 600 CHF pro Monat allein für diese eine Funktion.

    Vorgehen: Integration Sprint mit pgvector und Open-Weight-LLM

    Forfis startete mit einem Prozess-Audit in Woche 1. Ziel: die drei Workflows identifizieren, die den größten Hebel bieten. Ergebnis: Lead-Anreicherung (Firmendaten aus öffentlichen Quellen in HubSpot ergänzen), Lead-Klassifizierung (Branche, Firmengröße, Kaufbereitschaft) und Erstantwort-Generierung für Inbound-Tickets.

    Die Architektur: Ein Open-Weight-Modell (Llama 3 70B, quantisiert) läuft auf einer GPU-Instanz im Rechenzentrum des Kunden in Zürich. Die Lead-Daten werden als Embeddings in PostgreSQL mit pgvector indexiert. Die Anreicherung nutzt die HubSpot API, um fehlende Felder zu befüllen; die Klassifikation erfolgt über eine RAG-Pipeline, die die Lead-Attribute gegen eine interne Wissensbasis (Branche, ICP-Definitionen, historische Deal-Daten) abgleicht. Die Erstantwort wird vom LLM entworfen, ein AE prüft und sendet. Kein automatischer Versand, der Geld oder Vertragsdaten betrifft.

    Der Integration Sprint lief über vier Wochen: Woche 1 Audit und Datenanalyse, Woche 2 Pipeline-Entwicklung und pgvector-Indexierung, Woche 3 HubSpot-Integration und Testbetrieb, Woche 4 Go-Live und Übergabe.

    Ergebnis: 38 Minuten statt 4,2 Stunden, 34 Prozent weniger Kosten pro Lead

    Nach vier Wochen war die Pipeline produktiv. Die gemessenen Werte im ersten Monat nach Go-Live:

    • Reaktionszeit auf neue Leads: von 4,2 Stunden auf 38 Minuten gesenkt. Die Erstantwort wird innerhalb von 15 Minuten generiert, die menschliche Freigabe dauert im Median 23 Minuten.
    • Zeitersparnis für Senior-AE: 9,5 Stunden pro Woche pro AE. Das entspricht einer Freisetzung von rund 78 Prozent der vorherigen Routinezeit.
    • Lead-Klassifizierungs-Genauigkeit: 88 Prozent Übereinstimmung mit der manuellen Bewertung der AE. Die verbleibenden 12 Prozent werden nachbearbeitet.
    • Kosten pro qualifiziertem Lead: um 34 Prozent gesenkt, gemessen über den HubSpot-Report „Cost per SQL“.
    • Fehlerrate bei der Datenanreicherung: von 14 Prozent (manuell) auf 3 Prozent (automatisiert mit menschlicher Prüfung).

    Die ISO 27001-Konformität blieb gewahrt: Alle Daten verbleiben in der Schweizer Infrastruktur, das Open-Weight-Modell wird lokal gehostet, und die pgvector-Datenbank unterliegt den bestehenden Access-Control-Richtlinien.

    Lektionen für ähnliche Teams

    Fünf Erkenntnisse, die sich auf ähnliche Teams übertragen lassen:

    • pgvector ist der unterschätzte Baustein. Viele Teams greifen zu spezialisierten Vector-Datenbanken wie Weaviate oder Pinecone. Für eine B2B-SaaS mit unter 50 000 Leads und einer bestehenden PostgreSQL-Instanz ist pgvector der pragmatischere Weg: keine zusätzliche Infrastruktur, kein Datenabfluss, volle Kontrolle über die Indexierung.
    • Open-Weight-Modelle sind in der Schweiz oft die einzige Option. Die ISO 27001-Anforderungen und die Datenschutzgrundverordnung (DSGVO) schließen Cloud-LLMs für personenbezogene Daten aus, solange kein Auftragsverarbeitungsvertrag mit Sitz in der EU/CH vorliegt. Llama 3 70B auf eigener Hardware deckt die meisten Klassifikations- und Anreicherungsaufgaben ab.
    • Der Prozess-Audit ist nicht verhandelbar. Ohne die Vorab-Analyse der Workflows wird der Sprint zu einem Generierungsprojekt statt zu einer gezielten Automatisierung. Die 40 Stunden Audit-Zeit in Woche 1 sparen im Schnitt drei Wochen Nacharbeit.
    • Human-in-the-loop ist kein Nachteil, sondern ein Feature. Die manuelle Freigabe der Erstantwort kostet 23 Minuten, schafft aber Vertrauen im Team und verhindert, dass ein fehlerhaftes LLM-Output direkt an den Kunden geht. Die Akzeptanz im Vertrieb steigt dadurch deutlich.
    • Vier Wochen sind realistisch, wenn der Scope eng bleibt. Ein einzelner Workflow (Lead-Qualifizierung) mit klar definierten Eingabe- und Ausgabeformaten ist in vier Wochen integrierbar. Versucht man, drei Workflows gleichzeitig zu automatisieren, verlängert sich der Sprint um mindestens zwei Wochen.

  • RAG-Ticket-Triage in der Schweiz: Open-Weight vs. Cloud-APIs

    Zwei Ansätze für RAG-basierte Ticket-Triage im Schweizer E-Commerce

    Der Vergleich betrifft zwei Ansätze zur Implementierung eines Retrieval-Augmented Generation (RAG)-Assistenten für Ticket-Triage und -Routing in einem Schweizer E-Commerce-Unternehmen mit 11-50 Mitarbeitern. Option A nutzt Open-Weight-Modelle (z. B. Llama 3 70B oder Mistral 8x7B) auf eigener Hardware oder in einem Schweizer Rechenzentrum. Option B nutzt kommerzielle Cloud-APIs (OpenAI GPT-4o, Anthropic Claude 3.5 Sonnet) mit Datenverarbeitung in der EU. Beide Ansätze nutzen LangChain und LangGraph als Orchestrierungsframework und integrieren sich in Slack oder Microsoft Teams. Der Unterschied liegt in der Datenverarbeitung, den Kosten und der Compliance-Struktur. Für Unternehmen, die monatliche Berichte automatisieren und Ticket-Triage skalieren wollen, ohne neue Mitarbeiter einzustellen, ist die Wahl der Modell-Infrastruktur entscheidend für den ROI und die DSGVO-Konformität.

    Kriterien für die Bewertung der Modell-Infrastruktur

    Die Bewertung erfolgt anhand von sechs Kriterien, die für die operative Umsetzung in der Schweiz relevant sind:

    • Latenz: Reaktionszeit des Modells bei der Ticket-Klassifikation (Ziel: < 2 Sekunden).
    • Kostenstruktur: Fixkosten (Hardware, Lizenzen) vs. variable Kosten (API-Aufrufe).
    • DSGVO-Konformität: Datenabfluss, Auftragsverarbeitungsverträge (AVV), Speicherort.
    • Vendor-Lock-in: Abhängigkeit von einem bestimmten Anbieter oder Framework.
    • Skalierbarkeit: Verhalten bei steigendem Ticketvolumen (z. B. +50 % in der Hochsaison).
    • Integrationstiefe: Aufwand für die Anbindung an bestehende CRM-, ERP- und Messaging-Systeme.

    Diese Kriterien sind gewichtet: Für Unternehmen mit 11-50 Mitarbeitern haben Compliance und Kostenstruktur höhere Priorität als maximale Latenz, da die Ticketvolumen moderat sind und die manuelle Nachbearbeitung den Engpass bildet.

    Vergleichstabelle: Open-Weight vs. Cloud-APIs

    Kriterium Option A: Open-Weight auf eigener Hardware Option B: Cloud-APIs (EU-Hosted)
    Latenz 150-400 ms (je nach GPU, z. B. A100) 300-800 ms (inkl. Netzwerk-Roundtrip)
    Kosten (monatlich, 10k Tickets) 2 500-4 000 CHF (Strom, Wartung, Amortisation) 1 200-2 500 CHF (API-Gebühren, z. B. GPT-4o)
    DSGVO Daten bleiben im Gebäude, kein AVV nötig AVV mit Cloud-Anbieter, Daten in EU-Rechenzentrum
    Vendor-Lock-in Gering (Open-Source, austauschbar) Mittel (API-Schnittstellen, aber austauschbar)
    Skalierbarkeit Begrenzt durch Hardware, Skalierung erfordert neue GPUs Unbegrenzt, Skalierung durch API-Limits
    Integration Höherer initialer Aufwand (GPU-Setup, Modell-Deployment) Geringer initialer Aufwand (API-Key, Webhook)

    Die Zahlen basieren auf typischen Preisen im Schweizer Markt (2024). Option A hat höhere Fixkosten, aber niedrigere variable Kosten bei hohem Volumen. Option B hat niedrigere Fixkosten, aber variable Kosten steigen linear mit dem Ticketvolumen.

    Szenario-spezifische Bewertung

    Szenario 1: Hohe Datenhoheit, moderates Volumen. Ein Schweizer E-Commerce-Unternehmen mit 20 Mitarbeitern verarbeitet 5 000 Tickets/Monat. Die Tickets enthalten personenbezogene Daten und Bestellhistorie. Hier gewinnt Option A, weil die Daten nicht das Gebäude verlassen dürfen. Die Latenz von 200 ms ist für die Triage ausreichend, da die menschliche Freigabe den Engpass bildet. Die Kosten von 3 000 CHF/Monat sind akzeptabel, da die manuelle Bearbeitungszeit um 40 % sinkt.

    Szenario 2: Schnelle Umsetzung, geringes Volumen. Ein Startup mit 12 Mitarbeitern verarbeitet 1 500 Tickets/Monat und braucht in 4 Wochen einen funktionierenden Pilot. Hier gewinnt Option B, weil der Setup-Aufwand geringer ist. Die API-Kosten von 800 CHF/Monat sind niedrig, und die DSGVO-Konformität ist durch den EU-Hosted-Service gewährleistet. Die Latenz von 500 ms ist für die Triage irrelevant, da die menschliche Freigabe den Prozess dominiert.

    Szenario 3: Skalierung ohne neue Hires. Ein Unternehmen mit 30 Mitarbeitern will das Ticketvolumen von 8 000 auf 15 000/Monat skalieren, ohne Personal zu erhöhen. Hier gewinnt Option B, weil die Skalierung durch API-Limits begrenzt ist und die Kosten linear steigen. Option A würde neue GPUs erfordern, was den 4-Wochen-Timeline sprengt. Die Cloud-Option erlaubt es, die Kapazität in Tagen zu erweitern, nicht in Wochen.

    Empfehlung für die operative Umsetzung

    Für die meisten Schweizer E-Commerce-Unternehmen mit 11-50 Mitarbeitern ist Option B (Cloud-APIs, EU-Hosted) die empfohlene Wahl für den 4-Wochen-Pilot. Die Gründe: 1. Geringerer initialer Aufwand, der den Timeline-Ziel von 4 Wochen einhält. 2. Niedrigere Fixkosten, die für kleine Teams akzeptabler sind. 3. DSGVO-Konformität durch EU-Hosted-Service und AVV. 4. Skalierbarkeit ohne Hardware-Investition. Option A ist nur zu empfehlen, wenn die Datenhoheit eine harte Anforderung ist (z. B. Gesundheitsdaten, Finanzdaten) oder das Ticketvolumen über 20 000/Monat liegt, wo die variablen Kosten der Cloud-APIs die Fixkosten der eigenen Hardware übersteigen. In beiden Fällen sollte die Architektur mit LangGraph model-agnostic bleiben, um später zwischen den Optionen wechseln zu können, ohne den Code zu ändern.

  • Anthropic Claude API vs. lokales LLM: Conversational Agent im Fintech

    Zwei Ansätze für Conversational Agents im Fintech

    Der Vergleich betrachtet zwei Ansätze zur Implementierung eines Conversational Agenten für Customer Support in einem Schweizer Fintech mit 120 Mitarbeitern. Option A nutzt die Anthropic Claude API (Sonnet 3.5) über eine RAG-Pipeline mit Vektordatenbank und Zendesk-Integration. Option B setzt ein offenes Sprachmodell (Llama 3 70B) auf eigener GPU-Hardware (NVIDIA A100) im Rechenzentrum des Kunden ein. Beide Optionen folgen demselben Integrations-Sprint-Modell: 4 Wochen von Prozess-Audit bis Pilotbetrieb, mit Human-in-the-Loop als Standard. Der Agent klassifiziert Tickets, entwirft Antworten auf Basis interner Dokumentation und eskaliert bei Unsicherheit an menschliche Agenten. Ziel ist die Reduktion der First-Response Time von 18 auf unter 10 Minuten bei gleichbleibender Ticket-Volumen von 4.500/Monat.

    Vergleichskriterien

    • Latenz: Zeit vom Ticket-Eingang bis zur generierten Antwort (ms)
    • Kosten: Laufende monatliche Kosten (CHF), exkl. Engineering
    • Compliance: Erfüllung von ISO 27001 und DSGVO-Anforderungen
    • Skalierbarkeit: Verhalten bei Lastspitzen (>100 Requests/Minute)
    • Datenhoheit: Wo die Daten physisch verarbeitet werden
    • Implementierungsaufwand: Zeit bis zur Produktivität (Wochen)
    • Vendor Lock-in: Abhängigkeit von einem bestimmten Anbieter
    • Wartungsaufwand: Engineering-Zeit für Updates und Monitoring (Stunden/Monat)

    Quantitativer Vergleich

    Kriterium Option A: Anthropic API Option B: Lokales LLM
    Latenz 800–1.200 ms 300–500 ms
    Laufende Kosten 2.500–4.000 CHF/Monat 15.000–20.000 CHF/Monat
    Compliance DSGVO-konform (EU-Hosting), ISO 27001-Dokumentation erforderlich Vollständige Datenhoheit, ISO 27001-einfacher zu auditieren
    Skalierbarkeit Horizontal skalierbar, keine Lastgrenzen Begrenzt durch GPU-Kapazität, Scaling erfordert zusätzliche Hardware
    Datenhoheit Daten verlassen das Gebäude (API-Call) Daten bleiben im Rechenzentrum
    Implementierung 4 Wochen 6–8 Wochen
    Vendor Lock-in Mittel (Anthropic-Abhängigkeit) Gering (offenes Modell, aber Hardware-Abhängigkeit)
    Wartungsaufwand 2–4 Stunden/Monat 10–15 Stunden/Monat

    Szenario-spezifische Bewertung

    Option A gewinnt bei: Zeitkritischen Projekten mit 4-Wochen-Timeline. Die API-Option ist in Woche 4 produktiv, das lokale Modell benötigt 6–8 Wochen wegen Hardware-Provisionierung und Modell-Finetuning. Bei Kostenbewusstsein: Die API-Option ist 4–8x günstiger im laufenden Betrieb. Bei Skalierbarkeit unter Last: Die API skaliert horizontal ohne eigene Infrastruktur-Last, während das lokale Modell bei >100 Requests/Minute an GPU-Grenzen stößt. Option B gewinnt bei: Strikten Datenhoheits-Anforderungen, bei denen keine Daten das Gebäude verlassen dürfen. Bei sehr hohen Ticket-Volumina (>10.000/Monat), wo die API-Kosten die Hardware-Investition übersteigen. Bei vollständiger Unabhängigkeit von externen API-Anbietern.

    Empfehlung

    Für ein Schweizer Fintech mit 120 Mitarbeitern, 4.500 Tickets/Monat und ISO 27001-Anforderungen ist Option A (Anthropic Claude API) die empfohlene Wahl. Die 4-Wochen-Timeline ist nur mit der API-Option realistisch. Die laufenden Kosten von 2.500–4.000 CHF/Monat sind für diese Unternehmensgröße tragbar. Die ISO 27001-Konformität ist durch EU-Hosting und dokumentierte technische Maßnahmen (Verschlüsselung, Zugriffskontrollen) erreichbar. Der Human-in-the-Loop-Workflow bleibt bei beiden Optionen identisch, sodass ein späterer Wechsel auf ein lokales Modell möglich ist, wenn das Ticket-Volumen wächst oder die Datenhoheits-Anforderungen strenger werden. Die API-Option bietet die beste Balance aus Geschwindigkeit, Kosten und Compliance für das gegebene Szenario.

  • Ticket-Triage mit KI: DSGVO-konform in 2 Wochen für Schweizer Versicherer

    1. Triage-Genauigkeit schlägt Antwortgeschwindigkeit

    Die manuelle Zuordnung von Support-Tickets in Zendesk kostet einen Schweizer Versicherer mit 11-50 Mitarbeitern durchschnittlich 3-5 Stunden pro Tag. Bei 200 Tickets pro Woche bedeutet das 12-20 Stunden reine Routing-Arbeit, die keine Wertschöpfung erzeugt. Ein On-Premise-Deployment mit einem Open-Weight-Modell wie Llama 3 8B auf einer A10G-GPU (24 GB VRAM) klassifiziert jedes Ticket in unter 500 ms und leitet es an die korrekte Queue weiter. Die Daten bleiben im Rechenzentrum des Versicherers, was die Anforderungen der Schweizer Datenschutzbehörde (EDÖB) und der DSGVO erfüllt. Der Pilot läuft in 2 Wochen: Woche 1 für die Integration der Zendesk-API und das Fine-Tuning des Modells auf 500 historische Tickets, Woche 2 für den Live-Betrieb mit Human-in-the-Loop-Review. Die Triage-Genauigkeit wird gegen die manuelle Zuordnung gemessen; Ziel ist >95 % Übereinstimmung bei der Queue-Zuordnung.

    2. DSGVO-Konformität durch On-Premise-Deployment

    Die DSGVO verlangt, dass personenbezogene Daten nur verarbeitet werden, wenn eine Rechtsgrundlage vorliegt (Art. 6 DSGVO). Bei der Ticket-Triage ist dies meist die Vertragserfüllung (Art. 6 Abs. 1 lit. b), da die Bearbeitung des Anliegens zur Erfüllung des Versicherungsvertrags gehört. Eine separate Einwilligung ist nicht nötig, aber die Transparenzpflicht (Art. 13/14) muss eingehalten werden: Kunden müssen erfahren, dass ihre Daten automatisiert verarbeitet werden. In der Praxis bedeutet das: Im Zendesk-Ticket-Header wird ein Hinweis eingeblendet, dass die Zuordnung durch ein KI-System erfolgt. Für die On-Premise-Verarbeitung ist keine Data Processing Agreement (DPA) mit einem externen Anbieter nötig, da keine Daten das Rechenzentrum verlassen. Die Schweizer Datenschutzbehörde (EDÖB) akzeptiert diese Konfiguration, solange die Datenverschlüsselung (AES-256) und die Zugriffskontrollen (RBAC) dokumentiert sind.

    3. Multilinguale Triage ohne separate Modelle

    Ein Versicherer in der Deutschschweiz erhält Tickets in Deutsch, Französisch und Italienisch. Ein monolingues Modell würde 30-40 % der Tickets falsch zuordnen, weil es die sprachliche Nuance nicht erkennt. Llama 3 8B ist multilingual trainiert und verarbeitet alle drei Sprachen mit einer Triage-Genauigkeit von >92 %. Die Routing-Regeln bleiben gleich: ‘Schadenmeldung’ → Queue A, ‘Prämienanpassung’ → Queue B, unabhängig von der Sprache. Für die Romandie und die Tessiner Kantonsgrenzen reicht ein einziges Modell, ohne dass separate Modelle pro Sprache benötigt werden. Die Latenz bleibt unter 500 ms, da das Modell auf der A10G-GPU läuft und keine externe API-Aufrufe nötig sind. Die Kosten für die GPU-Betrieb (ca. 400 CHF/Monat für eine A10G in einem Schweizer Rechenzentrum) sind um den Faktor 10 niedriger als die Kosten für externe LLM-APIs bei 200 Tickets pro Tag.

    4. Human-in-the-Loop als Standard, nicht als Option

    Die Triage ist eine Klassifikationsaufgabe, keine generative. Das Modell liest den Ticket-Text, extrahiert die Absicht (z. B. ‘Prämienanpassung’, ‘Schadenmeldung’) und den Dringlichkeitsgrad, und leitet das Ticket an die richtige Queue in Zendesk weiter. Es wird kein Antworttext generiert, der an den Kunden geht, solange kein Human-in-the-Loop-Workflow für die Erstantwort aktiviert ist. Die menschliche Kontrolle bleibt bei der eigentlichen Bearbeitung: Ein Support-Mitarbeiter sieht das geroutete Ticket, prüft die Zuordnung und bearbeitet es. Wenn die KI ein Ticket falsch zuordnet, kann der Mitarbeiter es manuell umleiten. Diese Umleitung wird als Feedback-Signal gespeichert und dient dem wöchentlichen Fine-Tuning des Modells. Die Fehlerquote (falsch geroutete Tickets) wird wöchentlich gemessen und muss unter 5 % bleiben, sonst wird das Modell nachtrainiert. Der Human-in-the-Loop-Ansatz ist in der Schweiz gesetzlich nicht vorgeschrieben, aber er reduziert das Risiko von Fehlzuteilungen und hält die Mitarbeiter im Prozess.

    5. Integration in Zendesk ohne Custom Code

    Die Integration in Zendesk erfolgt über die Zendesk API (REST v3). Das On-Premise-Modell wird als Webhook in Zendesk eingebunden: Wenn ein neues Ticket erstellt wird, sendet Zendesk den Ticket-Text an das Modell, das die Klassifikation zurückgibt. Zendesk aktualisiert dann die Queue-Zuordnung und die Tags. Die Latenz für diesen Roundtrip liegt bei 200-400 ms, da das Modell lokal läuft und keine externe API-Aufrufe nötig sind. Für Intercom funktioniert die Integration ähnlich über die Intercom API. Die Konfiguration dauert 2-3 Tage: API-Keys einrichten, Webhook-Endpoint testen, Routing-Regeln in Zendesk definieren. Die Kosten für die Integration sind gering: 2-3 Tage Entwicklerzeit (ca. 3 000-4 500 CHF) plus die GPU-Betrieb (ca. 400 CHF/Monat). Im Vergleich zu externen LLM-APIs (OpenAI, Anthropic) sind die laufenden Kosten um den Faktor 10 niedriger, da keine Token-Gebühren anfallen.

    6. Zwei Wochen bis zum Live-Betrieb

    Der Pilot läuft in 2 Wochen. Woche 1: Prozess-Audit (Tag 1-2), Zendesk-API-Integration (Tag 3-4), Fine-Tuning des Modells auf 500 historische Tickets (Tag 5-7). Woche 2: Live-Betrieb mit Human-in-the-Loop-Review (Tag 8-10), Messung der Triage-Genauigkeit (Tag 11-12), Dokumentation und Übergabe (Tag 13-14). Die Triage-Genauigkeit wird gegen die manuelle Zuordnung gemessen; Ziel ist >95 % Übereinstimmung bei der Queue-Zuordnung. Die Latenz (Zeit von Ticket-Eingang bis Routing) sollte unter 2 Sekunden liegen. Die Fehlerquote (falsch geroutete Tickets) wird wöchentlich gemessen und muss unter 5 % bleiben, sonst wird das Modell nachtrainiert. Nach dem Pilot wird das System in den Managed AI Operations-Modus überführt: Forfis überwacht die Modell-Performance, führt wöchentliches Fine-Tuning durch und aktualisiert die Routing-Regeln bei neuen Ticket-Typen. Die Kosten für den Managed Service liegen bei ca. 1 500-2 500 CHF/Monat, je nach Ticket-Volumen.

    7. Skalierung vom Pilot zum Managed Service

    Die Triage-Automatisierung ist der erste Schritt, nicht das Ende. Nach dem Pilot (1 Prozess automatisiert) kann das System auf weitere Workflows erweitert werden: Erstantwort-Generierung (mit Human-in-the-Loop-Review), Dokumenten-Extraktion aus Schadensmeldungen, oder multilinguale Chatbots für die Website. Die Architektur ist model-agnostic: Wenn die Triage-Genauigkeit unter 90 % fällt, kann ein Teil der Tickets an ein externes LLM (OpenAI, Anthropic) mit anonymisierten Daten weitergeleitet werden, sofern eine DPA vorliegt. Für die Erstantwort-Generierung ist ein größeres Modell (Llama 3 70B oder GPT-4) nötig, das auf einer A100-GPU (80 GB VRAM) läuft. Die Kosten steigen dann auf ca. 1 200 CHF/Monat für die GPU, aber die Wertschöpfung ist höher: Die Erstantwort-Zeit sinkt von 4 Stunden auf 15 Minuten. Der Managed AI Operations-Service skaliert mit dem Ticket-Volumen und den neuen Workflows, ohne dass der Versicherer eigene ML-Experten einstellen muss.

  • KI-gestützte Ticket-Triage in der Versicherung: Forfis-Integration in 4 Wochen

    Die manuelle Datenerfassung als Flaschenhals in der Schadenabteilung

    In deutschen Versicherungskonzernen mit über 2.000 Mitarbeitern staut sich die Arbeit in der Schadenabteilung. Mitarbeiter verbringen 40 bis 60 Prozent ihrer Zeit mit manueller Datenerfassung: Sie kopieren Informationen aus E-Mails, PDFs und Anrufen in das CRM oder das ERP-System. Die Bearbeitungszeit pro Ticket liegt bei 15 bis 25 Minuten, die Fehlerquote bei 3 bis 5 Prozent. Diese Fehler führen zu Regressforderungen, Verzögerungen bei der Auszahlung und unzufriedenen Kunden. Die betroffenen Rollen sind Sachbearbeiter in der Schadenabteilung, die unter Zeitdruck stehen und gleichzeitig die Qualität der Daten sicherstellen müssen. Das Problem ist nicht mangelnde Motivation, sondern die Struktur der Arbeit: Die Daten liegen in unstrukturierten Formaten vor, während die Systeme strukturierte Eingaben erwarten. Diese Diskrepanz erzeugt einen manuellen Übersetzungsschritt, der weder skalierbar noch fehlerfrei ist.

    Warum klassische Automatisierungsansätze in der Versicherung scheitern

    Viele Unternehmen greifen zu klassischen RPA-Tools (Robotic Process Automation), die auf regelbasierten Logiken basieren. Diese Tools scheitern an der Variabilität der Eingaben: Eine E-Mail kann in 50 verschiedenen Formulierungen denselben Sachverhalt beschreiben. RPA kann nur exakte Muster erkennen, nicht den semantischen Inhalt. Andere Ansätze setzen auf generative KI ohne Kontext: Die KI extrahiert Daten, aber ohne Bezug zu den historischen Tickets oder den internen Richtlinien. Das Ergebnis ist eine hohe Genauigkeit bei einfachen Fällen, aber eine hohe Fehlerquote bei komplexen Sachverhalten. Ein dritter Ansatz ist die vollständige Automatisierung ohne menschliche Kontrolle. Das verstößt gegen die Anforderungen des EU AI Act und die internen Compliance-Vorgaben, insbesondere bei Gesundheitsdaten oder Regressforderungen. Die Kombination aus mangelnder Kontextualisierung und fehlender menschlicher Aufsicht macht diese Ansätze für den produktiven Einsatz in der Versicherung ungeeignet.

    Der Forfis-Ansatz: KI-gestützte Triage mit menschlicher Aufsicht

    Forfis setzt auf eine Integration, die die bestehenden Systeme nicht ersetzt, sondern ergänzt. Der Ansatz beginnt mit einem Prozess-Audit, das die Workflows identifiziert, die sich für die Automatisierung eignen. Im Zentrum steht die Ticket-Triage: Ein LLM analysiert den Inhalt des Tickets, klassifiziert den Schadenfall und schlägt eine Routing-Entscheidung vor. Die Architektur nutzt pgvector für die semantische Suche in den historischen Tickets und den internen Richtlinien. Das System ist modell-agnostisch: OpenAI oder Anthropic APIs für die Qualität, Open-Weight-Modelle auf eigener Hardware für regulierte Daten. Die Integration erfolgt über die Microsoft Teams API: Ein Bot informiert die Mitarbeiter über neue Tickets, schlägt die Routing-Entscheidung vor und protokolliert die Interaktion. Die menschliche Aufsicht bleibt erhalten: Der Mitarbeiter bestätigt oder korrigiert die Vorschlag mit einem Klick. Diese Human-in-the-Loop-Architektur gewährleistet die Compliance und die Akzeptanz bei den Mitarbeitern.

    Vier Schritte zur produktiven Implementierung in 4 Wochen

    Die Implementierung erfolgt in einem 4-Wochen-Sprint. Woche 1: Prozess-Audit und Datenanalyse. Die bestehenden Tickets werden analysiert, um die häufigsten Kategorien und die typischen Fehlerquellen zu identifizieren. Woche 2: Setup der Infrastruktur. pgvector wird in die bestehende PostgreSQL-Datenbank integriert, die APIs zu Microsoft Teams und dem CRM werden eingerichtet. Woche 3: Modell-Training und Prompt-Engineering. Das LLM wird mit den historischen Tickets trainiert, die Prompts werden für die spezifischen Anforderungen der Versicherung optimiert. Woche 4: Integration in Microsoft Teams und UAT. Der Bot wird in den relevanten Channels aktiviert, die Mitarbeiter testen das System im Parallelbetrieb. Die Ergebnisse werden gemessen: Bearbeitungszeit, Fehlerquote, Akzeptanz bei den Mitarbeitern. Bei Erfolg erfolgt der Go-Live, bei Problemen das Feintuning. Dieser strukturierte Ansatz minimiert das Risiko und gewährleistet eine schnelle Amortisation.

    Stolpersteine und wie man sie vermeidet

    Die häufigsten Stolpersteine sind die mangelnde Datenqualität und der Widerstand der Mitarbeiter. Wenn die historischen Tickets unvollständig oder inkonsistent sind, kann das Modell keine zuverlässigen Vorschläge machen. Ein Prozess-Audit ist daher der erste Schritt, um die Datenqualität zu verbessern. Der Widerstand der Mitarbeiter entsteht durch die Angst vor Jobverlust. Die Kommunikation muss klarstellen, dass die KI die manuelle Datenerfassung übernimmt, nicht die Mitarbeiter. Die Mitarbeiter werden zu Kontrolleuren und Auszahlern, nicht zu Datenerfassern. Ein weiterer Stolperstein ist die fehlende Monitoring-Strategie. Das Modellverhalten kann sich mit der Zeit ändern (Drift). Ein Dashboard, das die Genauigkeit und die Akzeptanz der Vorschläge überwacht, ist daher zwingend. Bei Abweichungen wird das Modell neu trainiert oder die Prompts angepasst. Diese kontinuierliche Verbesserung gewährleistet die langfristige Zuverlässigkeit des Systems.