Forfis Blog

Blog

  • 7 Maßnahmen für KI-gestützte Ticket-Triage im B2B-SaaS

    1. Triage-Engine ersetzt manuelle Kategorisierung

    Ein B2B-SaaS-Unternehmen mit 800 Mitarbeitern in München verarbeitet 12.000 Support-Tickets pro Monat. 60 % davon sind repetitive Anfragen: Passwort-Reset, Lizenzstatus, Fehlermeldungen mit bekannten Workarounds. Die durchschnittliche Bearbeitungszeit liegt bei 14 Minuten pro Ticket, die Fehlerquote bei der Kategorisierung bei 18 %. Ein dediziertes AI-Team von Forfis implementiert eine Triage-Engine auf Basis von LangGraph, die Tickets automatisch klassifiziert, priorisiert und an die richtige Abteilung routet. Nach drei Monaten sinkt die Bearbeitungszeit auf 8 Minuten, die Klassifikationsgenauigkeit steigt auf 96 %. Die Einsparung beträgt 42.000 EUR pro Monat an Personalkosten, ohne dass die Servicequalität leidet.

    2. Datenanreicherung über ERP-Integration

    Die Triage-Engine extrahiert aus jedem Ticket strukturierte Daten: Kunden-ID, Produktversion, Fehlercode, Dringlichkeit und Sprache. Diese Daten werden über die API von Microsoft Dynamics 365 in das ERP-System geschrieben, wo sie für die Operations- und Supply-Chain-Planung verfügbar sind. Ein Data-Enrichment-Schritt ergänzt die Tickets mit historischen Daten aus dem CRM: Wie oft hat dieser Kunde in den letzten 90 Tagen ein Ticket gestellt? Welche Produkte nutzt er? Diese Anreicherung ermöglicht es dem Support-Team, personalisierte Antworten zu generieren und wiederkehrende Probleme proaktiv zu adressieren. Die Datenfließt vollständig innerhalb der EU, was die DSGVO-Anforderungen erfüllt.

    3. Mehrsprachige Abdeckung ohne Übersetzungsschleife

    Die Triage-Engine nutzt ein mehrsprachiges Embedding-Modell, das Tickets in Deutsch, Englisch, Französisch und Spanisch korrekt klassifiziert. Die Antwortgenerierung erfolgt in der Sprache des Kunden. Für die Datenanreicherung werden multilinguale Entitäten erkannt, z. B. Kundennummern, Produktnamen und Fehlercodes, unabhängig von der Sprache des Tickets. Dies ermöglicht es einem deutschen Team, Tickets aus dem gesamten DACH-Raum und darüber hinaus ohne Sprachbarriere zu bearbeiten. Die Mehrsprachigkeit ist kein Add-on, sondern ein Kernbestandteil der Architektur, da Forfis für Kunden in Tier-1-Märkten arbeitet, die international agieren.

    4. LangChain und LangGraph als Orchestrierungsschicht

    LangChain dient als Orchestrierungsschicht, die LLM-Aufrufe, Vektor-Datenbank-Abfragen und Tool-Integrationen koordiniert. LangGraph erweitert dies um Zustandsmaschinen, die komplexe, mehrstufige Workflows wie Ticket-Triage mit Verzweigungen, menschlichen Freigaben und Fehlerbehandlung abbilden. Für Forfis ist diese Kombination entscheidend, weil sie deterministische Abläufe mit probabilistischen Modellantworten verbindet. Die Zustandsmaschine stellt sicher, dass ein Ticket mit finanziellen Auswirkungen immer an einen menschlichen Agenten weitergeleitet wird, bevor eine Antwort versendet wird. Diese Architektur ist model-agnostic: OpenAI oder Anthropic APIs für allgemeine Tickets, Open-Weight-Modelle auf eigener Hardware für sensible Daten.

    5. SAP und Microsoft Dynamics als Datenrückgrat

    Die Triage-Engine wird über die nativen APIs von Microsoft Dynamics 365 oder SAP S/4HANA angebunden. Tickets aus dem Helpdesk (z. B. Zendesk, Jira Service Management) werden in eine Warteschlange geschleust, wo die KI-Klassifikation stattfindet. Die Ergebnisse werden als neue Felder oder Kommentare in das ERP-System zurückgeschrieben. Die Integration erfolgt über Webhooks und REST-Endpunkte, sodass keine manuelle Datenübertragung mehr nötig ist. Die Datenkonsistenz zwischen Support und Operations bleibt gewährleistet, da beide Systeme auf derselben Datenbasis arbeiten. Für Unternehmen mit 501 bis 2000 Mitarbeitern ist diese Integration der kritische Hebel, der die Automatisierung von einer Insellösung zu einem systemischen Vorteil macht.

    6. Human-in-the-Loop als Compliance-Sicherheitsnetz

    Die Triage-Engine klassifiziert das Ticket anhand von Kategorie, Dringlichkeit und Sprache. Bei Tickets mit finanziellen Auswirkungen, Vertragsfragen oder Gesundheitsdaten wird der Fall an einen menschlichen Agenten weitergeleitet, der die KI-Empfehlung prüft und freigibt. Bei reinen Statusanfragen oder bekannten Fehlermeldungen wird die Antwort automatisch generiert und versendet. Die Entscheidung, ob ein Fall menschlich bearbeitet wird, ist regelbasiert und nicht modellabhängig. Diese Architektur stellt sicher, dass die DSGVO-Anforderungen der Art. 6 und 9 erfüllt werden, da personenbezogene Daten nicht an externe API-Endpunkte übertragen werden, die nicht in der EU liegen. Open-Weight-Modelle auf eigener Hardware des Kunden gewährleisten, dass sensible Daten das Gebäude nicht verlassen.

    7. Drei Monate von Audit bis Rollout

    Der Pilot umfasst die Triage und Routing-Automatisierung für einen definierten Ticket-Typ, z. B. technische Fehlermeldungen. Die Messgröße ist die Reduktion der Bearbeitungszeit pro Ticket und die Genauigkeit der Klassifikation. Baseline: 12 Minuten pro Ticket, 85 % Klassifikationsgenauigkeit. Ziel nach drei Monaten: 7 Minuten pro Ticket, 95 % Genauigkeit. Der Pilot wird mit echten Tickets aus dem bestehenden Helpdesk gefahren, nicht mit Testdaten. Nach dem Piloten folgt der Rollout auf alle Ticket-Typen und die Übergabe an das interne Operations-Team. Forfis bleibt als Managed-Operation-Partner an Bord, um die Modelle zu überwachen, zu aktualisieren und auf Änderungen in der Systemlandschaft zu reagieren. Die drei Monate sind realistisch, weil das Team dediziert arbeitet und keine parallelen Projekte hat.

  • 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.

  • AI-Lead-Qualifikation im Medtech: ISO 27001-konformer Rollout in Österreich

    Prozess-Audit und Roadmap für Medtech-Unternehmen

    Der Einstieg in die KI-Automatisierung beginnt nicht mit der Auswahl eines Modells, sondern mit der Analyse der bestehenden Prozesse. Forfis führt ein AI-Prozess-Audit durch, das repetitive Workflows identifiziert, bei denen manuelle Dateneingabe den größten Zeitfresser darstellt. Im Medtech-Bereich betrifft das oft die Erfassung von Anfragen aus Facharztpraxen oder Kliniken. Das Audit liefert eine priorisierte Roadmap, die nach ROI und Compliance-Risiko sortiert ist. Für Unternehmen mit 500 bis 2000 Mitarbeitern ist diese Phase entscheidend, um zu vermeiden, dass man teure Infrastruktur für Prozesse aufbaut, die sich nicht amortisieren. Die Roadmap definiert klar, welche Workflows in den Pilot gehen und welche später folgen, was die Skalierung über verschiedene Abteilungen hinweg vorbereitet.

    Technische Architektur mit LangChain und LangGraph

    Die technische Basis der Automatisierung bildet eine model-agnostische Architektur, die auf LangChain und LangGraph setzt. LangChain dient als Abstraktionsschicht für die Interaktion mit Large Language Models, während LangGraph die Zustandsmaschine für komplexe, mehrstufige Workflows orchestriert. Für die Lead-Qualifikation nutzt man LangGraph, um den Entscheidungsbaum deterministisch zu steuern. Nur bei Unsicherheit greift das System auf das LLM zurück. Diese Trennung ist wichtig, weil sie die Nachvollziehbarkeit der Entscheidungen erhöht, was für die ISO 27001-Zertifizierung entscheidend ist. Die Architektur erlaubt es, für sensible Daten offene Modelle auf eigener Hardware zu nutzen und für weniger kritische Aufgaben die APIs von OpenAI oder Anthropic einzusetzen.

    Lead-Qualifikation durch Workflow-Orchestrierung

    Die Implementierung der Lead-Qualifikation erfolgt über eine Custom REST API und Webhooks, die das bestehende CRM an das AI-System anbinden. Das System reichert neue Anfragen automatisch über die CRM-API an und prüft, ob der Kontakt zu den Zielgruppenkriterien passt, wie etwa ‘Facharztpraxis in der DACH-Region’. Bei einem Treffer wird der Lead als ‘Hot’ markiert und an den Vertrieb übergeben. Bei einem Fehltreffer wird eine standardisierte Antwort generiert. Die Integration ersetzt das CRM nicht, sondern ergänzt es um eine intelligente Schicht. Für die Skalierung über Abteilungen hinweg wird dieselbe Orchestrierungslogik auf weitere Prozesse angewendet, was die Konsistenz der Datenhaltung sicherstellt.

    Pilot in zwei Wochen und Managed Operations

    Ein Pilotprojekt mit festem Scope dauert in der Regel zwei Wochen. Woche 1 dient der Prozessanalyse und der API-Anbindung, Woche 2 der Implementierung der Orchestrierungslogik und dem Testlauf mit realen, anonymisierten Daten. Die Messung der Baseline, also der aktuellen Fehlerrate und Zykluszeit, erfolgt parallel zur Implementierung. Nach dem Go-Live übernimmt Forfis die Managed AI Operations. Das bedeutet, dass das System überwacht, die Modelle bei Bedarf neu trainiert und die Integrationen gepflegt werden. Der Kunde zahlt eine monatliche Pauschale für Monitoring, Incident-Response und kontinuierliche Optimierung der Prompt-Logik, ohne eigenes ML-Personal einstellen zu müssen.

    Compliance: ISO 27001 und DSGVO im Medtech

    Die Einhaltung von ISO 27001 und der DSGVO ist bei der AI-Integration zentral. Forfis integriert die AI-Komponenten in das bestehende Information Security Management System (ISMS) des Kunden. Alle API-Keys werden in einem Secrets-Manager verwaltet, und die Log-Dateien der AI-Entscheidungen werden für die Audit-Trail-Anforderungen der Norm aufbewahrt. Bei der Verarbeitung von Gesundheitsdaten greift zusätzlich Art. 9 DSGVO. Die Nutzung von Cloud-APIs ist nur zulässig, wenn ein Auftragsverarbeitungsvertrag (AVV) vorliegt und die Daten nicht für andere Zwecke genutzt werden. Für besonders sensible Daten kann das Modell auf eigener Hardware laufen, was durch die model-agnostische Architektur ermöglicht wird.

  • KI-Vertragsprüfung in der Versicherung: 2-Wochen-Pilot mit LangChain

    Das Problem: Manuelle Vertragsprüfung in der Versicherung

    Versicherungsunternehmen mit 201 bis 500 Mitarbeitern stehen vor einem spezifischen Problem: Die manuelle Datenerfassung aus Verträgen und Policen bindet Compliance-Teams, während die Dokumentenlaufzeit unter Druck steht. In Deutschland ist die DSGVO (Art. 5, 6) strenger als in anderen Märkten, was bedeutet, dass personenbezogene Daten nicht einfach an US-Cloud-LLMs gesendet werden dürfen. Gleichzeitig fehlt es an Skalierbarkeit: Ein Compliance-Experte braucht im Schnitt 45 Minuten für die Vorprüfung eines Standardvertrags, während ein automatisierter Prozess diese Zeit auf unter 5 Minuten senken kann. Der Kern des Problems ist nicht die KI-Technologie selbst, sondern die Integration in bestehende Workflows ohne den Austausch von CRM, ERP oder Helpdesk-Systemen. Ein isolierter Pilot, der nicht in den täglichen Betrieb eingebettet ist, liefert keine messbaren Ergebnisse. Die Lösung liegt in einem zweiwöchigen Integration Sprint, der einen Conversational Agent aufsetzt, der über Slack oder Microsoft Teams mit den Mitarbeitern interagiert, Dokumente über ein RAG-System prüft und die manuelle Datenerfassung ersetzt.

    Voraussetzungen für den zweiwöchigen Sprint

    Bevor der Sprint startet, müssen folgende Voraussetzungen erfüllt sein:

    • Zugang zu den Quelldokumenten: Die Verträge und Policen müssen in einem zentralen Repository (SharePoint, S3, oder lokales NAS) liegen. Gescannte PDFs ohne OCR sind nicht geeignet; die Dokumente müssen textbasiert sein.
    • API-Zugänge: Sie benötigen Read-Only-Zugänge zu Ihrem CRM (z. B. Salesforce, HubSpot) und ERP (z. B. SAP, Microsoft Dynamics) über REST-APIs. Diese werden für die Kontextanreicherung des RAG-Systems benötigt.
    • Chat-Kanal-Integration: Ein Bot-Token für Slack oder Microsoft Teams, der in den relevanten Compliance-Channel eingebunden werden kann.
    • Datenklassifizierung: Eine klare Definition, welche Daten als personenbezogen gelten. Für diese Daten muss ein On-Premise-Modell (z. B. Llama 3 auf eigener Hardware) oder ein EU-Hosting-Dienstleister mit Standardvertragsklauseln (Art. 46 DSGVO) vorbereitet sein.
    • Baseline-Messung: Sie müssen die aktuelle Zykluszeit und Fehlerquote für die Vertragsprüfung dokumentieren. Ohne diese Baseline können Sie den Erfolg des Piloten nicht messen.

    Schritte zur Implementierung des Conversational Agents

    1. Prozess-Audit und Scope-Definition: Identifizieren Sie den spezifischen Vertrags-Typ, der im Piloten abgedeckt wird (z. B. B2B-Versicherungsverträge). Definieren Sie die 5-10 Felder, die extrahiert werden müssen (z. B. Versicherungsnehmer, Laufzeit, Prämie). Dokumentieren Sie die Freigabekriterien: Welche Felder müssen ein Mensch prüfen? Dies wird in einem 2-stündigen Workshop mit Compliance und IT festgelegt.

    2. RAG-Infrastruktur aufsetzen: Laden Sie die relevanten Dokumente in einen Vektor-Datenbank (z. B. Pinecone oder Weaviate) ein. Verwenden Sie langchain.vectorstores für die Indexierung. Für die Embedding-Modellierung nutzen Sie ein DSGVO-konformes Modell (z. B. all-MiniLM-L6-v2 lokal oder ein EU-gehostetes API). Testen Sie die Retrieval-Genauigkeit mit 20 Stichproben aus dem Dokumentenbestand.

    3. LangGraph-Workflow konfigurieren: Definieren Sie den Zustandsautomaten in langgraph.graph. Die Nodes sind: extract (Extraktion der Felder), validate (Prüfung der Plausibilität), human_approval (Pause für die Freigabe), und update_crm (Schreiben der Daten ins CRM). Verwenden Sie StateGraph mit einem MessageHistory-State, um den Kontext im Chat-Kanal zu erhalten.

    4. Conversational Agent für Slack/Teams implementieren: Verwenden Sie das slack-bolt oder botframework-Framework. Der Agent antwortet auf den Befehl /review <dateiname>. Er lädt das Dokument, führt die RAG-Abfrage durch und postet die extrahierten Felder als Markdown-Message in den Channel. Die Latenz sollte unter 3 Sekunden liegen; bei Cloud-LLMs muss die Anfrage asynchron abgewickelt werden.

    5. Human-in-the-Loop-Integration: Implementieren Sie den human_approval-Node so, dass der Agent eine Interaktive-Message mit Buttons (‘Freigeben’, ‘Ablehnen’, ‘Korrigieren’) sendet. Die Freigabe wird im CRM als Status ‘Approved’ markiert. Ohne diese Freigabe wird kein Datenpunkt in das ERP geschrieben. Dies erfüllt die Anforderung der DSGVO, dass automatisierte Entscheidungen überprüfbar sein müssen.

    6. Baseline-Vergleich und Messung: Führen Sie 50 Testverträge durch. Messen Sie die Zeit von der Dokumentenübergabe bis zur Freigabe. Vergleichen Sie die Fehlerquote (z. B. falsche Prämien-Eingabe) mit der manuellen Baseline. Dokumentieren Sie die Ergebnisse in einem kurzen Report, der als Grundlage für den Rollout dient.

    Häufige Stolperfallen und wie Sie sie erkennen

    • OCR-Fehler bei gescannten PDFs: Wenn die Quelldokumente gescannte Bilder sind, ohne vorherige OCR-Bearbeitung, wird die Extraktionsrate unter 70 % fallen. Erkennen Sie dies im Schritt 2, wenn die Retrieval-Genauigkeit bei den Stichproben niedrig ist. Lösung: Vorverarbeitung mit Tesseract oder einem kommerziellen OCR-Dienst, bevor die Dokumente in den Vektor-Index geladen werden.
    • API-Rate-Limits im CRM: Wenn der Agent zu viele parallele Anfragen an das CRM sendet, werden diese abgelehnt. Erkennen Sie dies an HTTP-429-Fehlern in den Logs. Lösung: Implementieren Sie einen Rate-Limiter in LangChain (z. B. tenacity mit Exponential Backoff) und begrenzen Sie die parallelen Anfragen auf 5 pro Minute.
    • Halluzinationen bei fehlenden Daten: Wenn ein Feld im Dokument nicht vorhanden ist, erfindet das LLM manchmal einen Wert. Erkennen Sie dies, wenn die validate-Node-Prüfung eine Inkonsistenz meldet. Lösung: Konfigurieren Sie das Prompt so, dass das Modell ‘Nicht gefunden’ zurückgibt, wenn ein Feld fehlt, und erzwingen Sie dies durch eine structured_output-Konfiguration in LangChain.
    • Latenz im Chat-Kanal: Wenn die Antwortzeit über 10 Sekunden liegt, wird der Agent von den Nutzern als unzuverlässig empfunden. Erkennen Sie dies durch User-Feedback oder durch Messung der API-Latenz. Lösung: Verwenden Sie ein kleineres, schnelleres Modell für die Extraktion (z. B. Llama 3 8B) und ein größeres Modell nur für die semantische Prüfung, oder nutzen Sie Caching für häufige Abfragen.
    • Fehlende Freigabe-Logik: Wenn der human_approval-Node nicht korrekt pausiert, wird der Prozess fortgesetzt, ohne dass ein Mensch zugestimmt hat. Erkennen Sie dies, wenn Daten im CRM aktualisiert werden, obwohl keine Button-Interaktion stattfand. Lösung: Testen Sie den Workflow explizit mit einem ‘Timeout’-Szenario, bei dem keine Freigabe erfolgt, und stellen Sie sicher, dass der Prozess in einem ‘Pending’-Status bleibt.

    Nächste Schritte nach dem Piloten

    Der zweiwöchige Sprint liefert einen funktionierenden Piloten, der die manuelle Datenerfassung für einen spezifischen Vertrags-Typ ersetzt. Die gemessenen Baseline-Werte zeigen, ob die Zykluszeit und Fehlerquote signifikant verbessert wurden. Der nächste logische Schritt ist die Ausweitung auf weitere Vertrags-Typen und die Integration in den gesamten Compliance-Prozess. Dabei sollten Sie die Modell-Agnostizität nutzen: Wenn die Cloud-LLMs für bestimmte Daten zu langsam oder zu teuer sind, können Sie auf On-Premise-Modelle umstellen, ohne die Architektur zu ändern. Die Architektur ist so gestaltet, dass sie in bestehende Systeme integriert wird, nicht sie ersetzt. Das bedeutet, dass Ihr CRM, ERP und Helpdesk weiterhin die zentrale Rolle spielen, während der KI-Agent als Beschleuniger fungiert. Für den Rollout sollten Sie ein Change-Management-Programm aufsetzen, das die Compliance-Teams schult und die Akzeptanz des neuen Workflows fördert. Die Messung der Ergebnisse sollte kontinuierlich erfolgen, um sicherzustellen, dass die Qualität der Extraktion und die Nutzerzufriedenheit auf einem hohen Niveau bleiben.

  • Lead-Qualifikation in der Schweizer Beratung: KI-Integration in 8 Wochen

    Der Engpass in der Schweizer Beratungsbranche

    In der Schweizer Beratungsbranche (Professional Services) mit 51-200 Mitarbeitenden staut sich die Lead-Qualifikation oft im Backoffice. Neue Anfragen aus Deutschland, Frankreich oder Italien landen im CRM, werden manuell gelesen, kategorisiert und an den zuständigen Account Manager weitergeleitet. Die durchschnittliche Reaktionszeit liegt bei 4-6 Stunden, die Fehlerrate bei der Kategorisierung bei 10-15 %. Das kostet nicht nur Zeit, sondern auch Konversionsraten: Studien zeigen, dass die Wahrscheinlichkeit einer Konvertierung um 400 % sinkt, wenn die Reaktionszeit von 5 auf 30 Minuten steigt. Der Ansatz von Forfis adressiert genau diesen Engpass: Ein Integration-Sprint, der in 8 Wochen eine AI-Schicht über das bestehende CRM legt, ohne die Software zu ersetzen. Das Ziel ist nicht die vollständige Automatisierung, sondern die Reduktion der Kosten pro Support-Ticket und die Beschleunigung der Lead-Qualifikation durch Predictive Scoring.

    Architektur: pgvector, Predictive Scoring und Slack-Integration

    Die Architektur basiert auf drei Komponenten: (1) Ein RAG-Stack mit pgvector für die semantische Suche über CRM-Records und interne Dokumentation. (2) Ein Predictive Scoring-Modell, das die Wahrscheinlichkeit einer Konvertierung basierend auf historischen Daten und semantischen Ähnlichkeiten berechnet. (3) Eine Integration in Slack oder Microsoft Teams, die das Ergebnis an den Account Manager liefert. Der RAG-Stack nutzt Embeddings (z. B. von BGE-M3 oder multilingual-e5-large), die in pgvector als Vektoren gespeichert werden. Bei einer neuen Lead-Anfrage wird der Text in einen Vektor transformiert und die nächsten Nachbarn (k-NN) im Vektorraum gesucht. Diese Ähnlichkeit wird zusammen mit dem Predictive Score (z. B. ein Gradient Boosting Classifier oder ein einfaches Logistisches Regressionsmodell) in eine Slack-Nachricht gepackt. Das Modell ist model-agnostisch: Für die Embeddings und das Scoring können Open-Weight-Modelle auf eigener Hardware genutzt werden, da keine regulierten Daten (Gesundheit, Finanzen) vorliegen. Die LLM-Schicht für die Zusammenfassung kann über API-Calls (OpenAI, Anthropic) oder lokal laufen.

    Trade-offs: Modellwahl, Datenlage und Akzeptanz

    Die zentrale Entscheidung ist die Wahl des Embedding-Modells. Multilinguale Modelle wie BGE-M3 oder multilingual-e5-large erkennen semantische Ähnlichkeiten über Sprachgrenzen hinweg, sind aber rechenintensiver. Monolinguale Modelle sind schneller, aber ungenau bei Leads in Französisch oder Italienisch. Der Kompromiss: Ein multilinguales Modell für die Embeddings, ein leichtes Modell (z. B. Llama 3 8B) für die Zusammenfassung. Der Predictive Score nutzt historische Konversionsdaten aus dem CRM. Wenn die Datenlage dünn ist (< 500 qualifizierte Leads), ist ein einfaches Logistisches Regressionsmodell besser als ein komplexes Deep Learning-Modell, da es weniger Overfitting erzeugt. Die Slack-Integration ist bewusst einfach: Eine Nachricht mit Score, Zusammenfassung und empfohlener Aktion. Kein Chatbot, keine komplexe UI. Das reduziert die Akzeptanzbarriere bei den Account Managern.

    Empfehlung: 8-Wochen-Sprint mit messbarer Baseline

    Für ein Schweizer Beratungsunternehmen mit 100 Mitarbeitenden und 500 neuen Leads pro Monat ist der 8-Wochen-Sprint wirtschaftlich sinnvoll, wenn die Reaktionszeit von 4 Stunden auf < 15 Minuten sinkt und die Fehlerrate unter 5 % fällt. Die Kosten für den Sprint liegen bei 40.000-80.000 CHF, plus laufende Infrastrukturkosten (Server für Open-Weight-Modelle oder API-Calls). Die Einsparung pro Lead (weniger manuelle Arbeit, höhere Konversionsrate) muss diese Kosten innerhalb von 6-12 Monaten übersteigen. Der Pilot wird mit einer gemessenen Baseline ausgeliefert: Vorher-Nachher-Vergleich der Reaktionszeit und Fehlerrate. Wenn die Metriken nicht erreicht werden, wird der Scope angepasst, nicht das Modell. Die menschliche Kontrolle bleibt: Der Account Manager bestätigt oder korrigiert die Lead-Qualifikation. Das System ersetzt nicht, sondern unterstützt.

  • KI-gestützte Status-Updates: Compliance-sichere Automatisierung im B2B-SaaS

    Das Problem: Manuelle Status-Updates als Fehlerquelle

    In der B2B-SaaS-Industrie, insbesondere im österreichischen Markt, stößt die manuelle Bearbeitung von Bestellaufträgen und Versandstatus auf eine strukturelle Grenze. Bei Unternehmen mit 51 bis 200 Mitarbeitern liegt der Fokus auf Skalierung, doch die Back-Office-Prozesse wachsen linear mit dem Umsatz. Ein typisches Problem: Kundenanfragen nach dem aktuellen Versandstatus werden per E-Mail oder Ticket gestellt. Die Antwort erfordert einen manuellen Abgleich zwischen dem CRM und dem ERP-System. Diese manuelle Abfrage führt zu zwei Hauptproblemen: Erstens zu langen Antwortzeiten (oft über 4 Stunden), zweitens zu einer Fehlerquote von 3 bis 5 Prozent, wenn Statusdaten manuell übertragen oder interpretiert werden. Die Motivation für einen Deep Dive in KI-gestützte Automatisierung ist daher nicht nur Effizienz, sondern die Reduktion dieser Fehlerquote auf ein Niveau, das manuelle Prozesse nicht erreichen können. Der EU AI Act, der ab 2026 in vollem Umfang gilt, verlangt zudem, dass KI-Systeme, die mit personenbezogenen Daten arbeiten, transparent und nachvollziehbar sind. Ein Pilotprojekt muss daher nicht nur technisch funktionieren, sondern auch compliance-sicher sein.

    Architektur: Wie die Status-Automatisierung technisch funktioniert

    Die Architektur basiert auf einer drei-Schichten-Struktur, die bewusst model-agnostic gehalten ist. Die erste Schicht ist die Datenquelle: Das ERP-System (z. B. SAP, Odoo oder ein Custom-System) stellt Bestelldaten über eine REST-API bereit. Die zweite Schicht ist die Verarbeitungslogik: Hier kommt die KI ins Spiel. Für die reine Statusabfrage (Read-Only) wird ein offenes Modell auf eigener Hardware oder ein API-Call an OpenAI genutzt. Das Modell extrahiert den aktuellen Status und formuliert eine natürliche Sprachantwort. Die dritte Schicht ist die Integrations-Schicht: Eine Custom REST-API und Webhooks verbinden das KI-System mit dem Helpdesk (z. B. Zendesk, Freshdesk) oder dem eigenen Portal. Ein Webhook wird ausgelöst, wenn sich der Status im ERP ändert. Das KI-System empfängt das Signal, generiert die Antwort und sendet sie zurück. Wichtig ist die Human-in-the-Loop-Komponente: Bei Abweichungen zwischen ERP-Status und KI-Interpretation wird ein Ticket an einen Mitarbeiter eskaliert. Diese Architektur stellt sicher, dass keine automatisierten Entscheidungen mit finanziellen oder rechtlichen Auswirkungen ohne menschliche Prüfung getroffen werden, was eine zentrale Anforderung des EU AI Acts ist.

    Trade-offs: Modellwahl und Datenhaltung

    Die zentrale Designentscheidung liegt in der Wahl des Modells und der Datenhaltung. Für die Statusabfrage genügt ein kleines, offenes Modell (z. B. Llama 3 8B) auf eigener Hardware, da die Aufgabe klar definiert ist und keine komplexe Reasoning-Kette erfordert. Das reduziert die Kosten pro Anfrage auf unter 0,001 Euro und hält die Daten in der EU. Für die Formulierung der Kundenantwort kann ein größeres Modell wie GPT-4o oder Claude 3.5 Sonnet genutzt werden, da hier die Qualität der Sprache entscheidend ist. Der Trade-off: Externe APIs bieten höhere Qualität, aber die Daten verlassen das eigene Rechenzentrum. Für Compliance-Sicherheit wird daher eine Hybrid-Strategie empfohlen: Die Datenextraktion und Validierung erfolgt lokal, nur die generierte Antwort (ohne sensible Daten) geht an die externe API. Ein weiterer Trade-off ist die Latenz: Lokale Modelle sind schneller (unter 200 ms), aber weniger flexibel bei Prompt-Änderungen. Externe APIs haben eine Latenz von 500 ms bis 2 Sekunden, bieten aber bessere Anpassbarkeit. Für Status-Updates, die Echtzeit-Ansprüche haben, ist die lokale Verarbeitung der bevorzugte Weg.

    Empfehlung: Der 2-Wochen-Pilot für Compliance-Sicherheit

    Ein Pilotprojekt mit festem Scope sollte in zwei Wochen abgeschlossen sein. Woche 1: Prozess-Audit und API-Anbindung. Dabei wird die bestehende REST-API des ERP-Systems analysiert und die Webhook-Endpunkte konfiguriert. Woche 2: Modell-Feintuning und Testlauf. Hier werden historische Daten (z. B. 1.000 vergangene Bestellungen) durch das KI-System gejagt, um die Fehlerquote zu messen. Der Pilot läuft im ‘Shadow Mode’: Die KI generiert Antworten, die aber nicht an den Kunden gesendet werden, sondern nur mit den manuellen Antworten verglichen werden. Ab Woche 3 geht das System in den Live-Betrieb, aber nur für eine bestimmte Produktlinie oder Region. Die Erfolgsmetriken sind klar definiert: Antwortzeit (Ziel: unter 5 Minuten statt 4 Stunden), Fehlerquote (Ziel: unter 0,5 Prozent statt 3-5 Prozent) und Kundenzufriedenheit (CSAT-Score). Nach vier Wochen wird evaluiert, ob der Pilot auf weitere Produktlinien ausgedehnt wird. Dieser Ansatz minimiert das Risiko und liefert messbare Ergebnisse, die für die Skalierung und die Compliance-Dokumentation notwendig sind.

  • AI-Lead-Qualifizierung im B2B-SaaS: Ein Schweizer Fallbeispiel

    Hintergrund: Helvetia SaaS und die Herausforderung der Skalierung

    Dieser Fall ist ein Komposit aus Mustern, die Forfis in der Praxis beobachtet hat. Wir benennen keine echten Kunden, um deren Vertraulichkeit zu wahren. Die beschriebene Firma, nennen wir sie „Helvetia SaaS“, ist ein Schweizer B2B-SaaS-Anbieter mit 800 Mitarbeitern, der sich auf Compliance-Software für den Finanzsektor spezialisiert hat. Das Unternehmen ist in der Wachstumsphase und operiert in der Schweiz und in Deutschland. Die bestehende IT-Infrastruktur umfasst Salesforce als CRM, Google Workspace für die Kommunikation und ein internes Dokumentenmanagement-System. Die IT-Abteilung ist schlank, aber kompetent, und das Unternehmen ist ISO 27001-zertifiziert, was strenge Anforderungen an die Datenverarbeitung und -speicherung mit sich bringt. Die Marketing- und Sales-Teams arbeiten eng zusammen, aber die Übergabe von Leads ist manuell und fehleranfällig.

    Die Herausforderung: Fehlerquote und Compliance-Druck

    Das Kernproblem lag in der Lead-Qualifizierung und der damit verbundenen Dokumentenverarbeitung. Leads kamen über verschiedene Kanäle – Website, E-Mail, Telefon – und mussten manuell in Salesforce eingetragen werden. Die Mitarbeiter mussten dabei E-Mails lesen, relevante Informationen extrahieren und die Daten in das CRM übertragen. Dieser Prozess war zeitaufwendig und fehleranfällig. Die Fehlerquote lag bei etwa 15 %, was zu unvollständigen Lead-Profilen und verzögerten Sales-Aktivitäten führte. Zudem gab es einen Compliance-Druck: Da Helvetia SaaS im Finanzsektor tätig ist, müssen alle personenbezogenen Daten streng geschützt werden. Die Nutzung von externen AI-Diensten war aus Datenschutzgründen problematisch. Das Management stellte eine Deadline von drei Monaten, um einen messbaren Verbesserungsprozess zu starten, ohne die ISO 27001-Zertifizierung zu gefährden.

    Der Ansatz: RAG-Architektur und lokale Modell-Infrastruktur

    Forfis startete mit einem Prozess-Audit, um die Workflows zu identifizieren, die sich am besten für die Automatisierung eignen. Der Fokus lag auf der Lead-Qualifizierung und der Dokumentenextraktion aus E-Mails. Die Architektur basierte auf einem RAG-System mit pgvector als Vektor-Datenbank. Die Dokumente und CRM-Daten wurden in Vektoren umgewandelt und lokal gespeichert. Für die Textgenerierung und Klassifikation wurde ein Open-Weight-Modell auf der eigenen Hardware von Helvetia SaaS eingesetzt, um sicherzustellen, dass keine Daten das Gebäude verließen. Die Integration erfolgte über die Google Workspace APIs, um E-Mails und Kalendertermine zu lesen. Die Workflow-Orchestration wurde mit einem festen Scope definiert: Das System sollte E-Mails klassifizieren, relevante Informationen extrahieren und einen Vorschlag für die CRM-Eintragung erstellen. Die menschliche Freigabeschleife war so gestaltet, dass jeder Vorschlag von einem Mitarbeiter bestätigt werden musste, bevor er in Salesforce geschrieben wurde.

    Das Ergebnis: Messbare Verbesserungen in drei Monaten

    Nach drei Monaten war der Pilot abgeschlossen und die Ergebnisse messbar. Die Fehlerquote bei der Datenextraktion sank von 15 % auf unter 3 %. Die Bearbeitungszeit pro Lead reduzierte sich von durchschnittlich 12 Minuten auf 4 Minuten. Die Mitarbeiter im Back Office konnten sich auf komplexere Aufgaben konzentrieren, während das System die Routinearbeit übernahm. Die Compliance-Anforderungen wurden vollständig erfüllt, da alle Daten lokal verarbeitet wurden und die ISO 27001-Audits keine neuen Risiken aufzeigten. Die Mitarbeiter waren anfangs skeptisch, aber die menschliche Freigabeschleife sorgte für Vertrauen. Das System wurde als zuverlässig empfunden, da es keine autonomen Entscheidungen traf, sondern immer einen menschlichen Check einbaute. Die ROI-Berechnung zeigte, dass sich die Investition innerhalb von sechs Monaten amortisieren würde, basierend auf den eingesparten Arbeitsstunden und der reduzierten Fehlerquote.

    Lehren für ähnliche Teams

    Aus dem Fall lassen sich mehrere Lehren für ähnliche Teams ziehen. Erstens: Beginnen Sie mit einem engen Scope. Ein Pilot auf einem einzigen Workflow ist erfolgreicher als ein breiter Ansatz, der viele Prozesse gleichzeitig automatisieren will. Zweitens: Investieren Sie in die Datenqualität. Ein RAG-System ist nur so gut wie die Daten, die es verarbeitet. Saubere, strukturierte Dokumente sind die Grundlage für präzise Antworten. Drittens: Planen Sie die menschliche Freigabeschleife von Anfang an ein. Sie ist nicht nur ein Compliance-Tool, sondern auch ein Vertrauensaufbau für die Mitarbeiter. Viertens: Wählen Sie die Modell-Infrastruktur basierend auf den Compliance-Anforderungen. Lokale Hardware ist oft die sicherste Wahl für regulierte Branchen. Fünftens: Messen Sie die Baseline vor dem Pilot. Ohne klare Metriken vor dem Start ist es schwierig, den Erfolg zu belegen und die ROI zu berechnen.

  • Checkliste: KI-gestützte Status-Updates im E-Commerce mit n8n und ISO 27001

    1. Ist-Zustand und Baseline messen

    Bevor Sie mit der technischen Umsetzung beginnen, müssen Sie den Ist-Zustand dokumentieren. Messen Sie die aktuelle Zykluszeit für die Bearbeitung einer Statusanfrage. Erfassen Sie die Fehlerquote bei manuellen Eingaben. Diese Baseline ist der Maßstab für den Erfolg des Projekts. Ohne diese Zahlen können Sie den ROI nicht belegen. Die Messung sollte über mindestens zwei Wochen erfolgen, um saisonale Schwankungen auszugleichen. Dokumentieren Sie auch die aktuellen Touchpoints: E-Mail, Chat, Telefon. Jeder Kanal hat andere Anforderungen an die Antwortzeit und den Tonfall. Diese Daten fließen direkt in die Konfiguration der n8n-Workflows ein. Sie bilden die Grundlage für die späteren Erfolgskennzahlen.

    2. Compliance-Rahmen und Datenflüsse definieren

    Definieren Sie die Grenzen des Systems. Welche Daten dürfen die KI verarbeiten? Welche Aktionen darf sie ohne menschliche Freigabe ausführen? Bei Forfis ist die Standardregel: Alles, was Geld, Gesundheitsdaten oder Verträge betrifft, muss von einer Person genehmigt werden. Dokumentieren Sie diese Regeln schriftlich. Sie sind Teil der ISO 27001-Konformität. Definieren Sie auch die Eskalationspfade: Wann wird ein Fall an einen Menschen weitergeleitet? Welche Rolle ist dafür zuständig? Diese Definitionen verhindern, dass das System in unklare Grauzonen gerät. Sie schaffen Transparenz für Auditoren und Mitarbeiter gleichermaßen.

    3. Modellstrategie und Infrastruktur festlegen

    Wählen Sie die Modellstrategie pro Workflow. Für die Statuskommunikation reicht oft ein Open-Weight-Modell auf eigener Hardware. Das hält die Kosten niedrig und die Daten im Haus. Für komplexe Anfragen, die Kontext aus dem CRM benötigen, kann ein API-basiertes Modell wie GPT-4 oder Claude sinnvoll sein. Testen Sie beide Varianten mit echten Daten. Messen Sie die Latenz und die Qualität der Antworten. Die Entscheidung sollte nicht von der Begeisterung für eine Technologie abhängen, sondern von den gemessenen Werten. Dokumentieren Sie die Wahl und die Begründung. Das ist Teil der technischen Dokumentation für die ISO 27001-Audits.

    4. n8n-Orchestrierung und API-Integrationen aufbauen

    Setzen Sie die n8n-Instanz auf. Konfigurieren Sie die Verbindungen zu Ihrem ERP, CRM und Helpdesk über REST-APIs und Webhooks. Testen Sie jede Verbindung mit Testdaten. Stellen Sie sicher, dass die Authentifizierung über API-Keys oder OAuth2 funktioniert. Dokumentieren Sie die Endpunkte und die Parameter. Diese Dokumentation ist entscheidend für die Wartung. Wenn ein System aktualisiert wird, müssen Sie wissen, welche Endpunkte betroffen sind. Testen Sie auch die Fehlerbehandlung: Was passiert, wenn das ERP nicht erreichbar ist? Der Workflow muss abbrechen und einen Fehler melden, nicht stillschweigend fehlschlagen.

    5. Prompt-Engineering und Antwortlogik entwickeln

    Entwickeln Sie die Prompts für die KI. Definieren Sie den Tonfall: freundlich, präzise, auf Deutsch. Geben Sie dem Modell die Struktur der Antwort vor: Begrüßung, Status, voraussichtlicher Liefertermin, Verabschiedung. Testen Sie die Prompts mit 50 echten Anfragen. Messen Sie die Qualität der Antworten. Passen Sie die Prompts an, bis die Fehlerquote unter 5 % liegt. Dokumentieren Sie die finalen Prompts. Sie sind Teil des Systems und müssen versioniert werden. Wenn Sie die Prompts ändern, müssen Sie die Tests wiederholen. Das ist Teil des Change-Managements.

    6. Human-in-the-Loop-Freigabeprozess implementieren

    Richten Sie die Freigabeschleife ein. Konfigurieren Sie n8n so, dass es bei bestimmten Auslösern eine Benachrichtigung an den zuständigen Mitarbeiter sendet. Der Mitarbeiter kann die Antwort genehmigen oder ablehnen. Dokumentieren Sie die Reaktionszeit: Wie lange dauert es im Durchschnitt, bis ein Mitarbeiter die Freigabe erteilt? Diese Zeit muss in die Gesamtzykluszeit einfließen. Testen Sie die Schleife mit 20 Fällen. Stellen Sie sicher, dass die Benachrichtigung zuverlässig ankommt und die Freigabe korrekt im System protokolliert wird. Das ist der kritische Punkt für die Akzeptanz im Team.

    7. Pilotphase mit Messung durchführen

    Führen Sie den Piloten durch. Schalten Sie das System für einen begrenzten Kundenkreis frei. Messen Sie die Zykluszeit und die Fehlerquote. Vergleichen Sie die Werte mit der Baseline aus Schritt 1. Dokumentieren Sie alle Abweichungen und Fehler. Analysieren Sie die Ursachen: Liegt es am Prompt, an der API-Verbindung oder an der Freigabeschleife? Passen Sie das System an. Wiederholen Sie die Messung. Der Pilot ist erfolgreich, wenn die Zykluszeit um mindestens 30 % sinkt und die Fehlerquote unter 2 % liegt. Diese Zahlen sind die Grundlage für den Rollout.

  • AI-Vertragsprüfung im Versicherungsbetrieb: Fallstudie NordRisk

    Hintergrund: NordRisk und die manuelle Vertragsprüfung

    Die vorliegende Fallstudie ist ein Composite, basierend auf Mustern, die in der Praxis bei mittelständischen Versicherern in Deutschland beobachtet wurden. Es werden keine realen Kundennamen genannt, um die Vertraulichkeit zu wahren. Die beschriebene Firma, nennen wir sie „NordRisk“, ist ein fiktiver Vertreter eines typischen Insurtech-Unternehmens mit 120 Mitarbeitern, das sich auf Sachversicherungen spezialisiert hat. NordRisk nutzt ein bestehendes ERP-System und verwaltet seine internen Richtlinien in Confluence. Die Herausforderung war nicht die Einführung von KI an sich, sondern die Integration in einen hochregulierten, manuell geprägten Prozess, der unter Zeitdruck stand. Die folgende Analyse zeigt, wie ein dediziertes AI-Team in drei Monaten einen messbaren Wandel im Backoffice herbeiführte, ohne die bestehende IT-Landschaft zu ersetzen.

    Herausforderung: Fehlerquote und Zeitdruck im Backoffice

    NordRisk litt unter einer steigenden Fehlerquote bei der Prüfung von Neugeschäftsverträgen. Manuelle Sachbearbeiter mussten Klauseln gegen interne Richtlinien prüfen, die in Confluence-Dokumenten verstreut waren. Die Durchlaufzeit betrug im Schnitt 48 Stunden pro Vertrag, mit einer Fehlerquote von 12 Prozent, die zu Nachträgen und Kundenbeschwerden führte. Der operative Druck kam von zwei Seiten: Erstens drohte ein Verlust von Marktanteilen an schnellere Wettbewerber, zweitens war das Team überlastet, da die Vertragsvolumina um 20 Prozent gestiegen waren. Es gab keine Compliance-Hürden im Sinne von Gesundheitsdaten, aber die DSGVO erforderte eine saubere Datenhaltung. Das Ziel war klar: Die Fehlerquote auf unter 5 Prozent senken und die Durchlaufzeit halbieren, ohne zusätzliche Headcount zu stellen.

    Ansatz: Dediziertes Team und LangGraph-Architektur

    Forfis stellte ein dediziertes AI-Team zusammen, bestehend aus einem Tech Lead, einem ML-Engineer und einem Product Manager. Die Architektur basierte auf LangChain und LangGraph, um den Workflow als Zustandsmaschine zu modellieren. Der Agent holte sich die relevanten Policy-Dokumente aus Confluence über die API, chunkte sie und speicherte sie in einer Vektordatenbank. Bei der Prüfung eines neuen Vertrags führte der Agent eine Retrieval-Augmented Generation (RAG) durch, um die ähnlichsten Richtlinien zu finden. LangGraph steuerte den Flow: Wenn der Agent eine Klausel als riskant einstufte, wechselte er in einen Warteknoten und eskalierte an einen menschlichen Sachbearbeiter. Dieser bestätigte oder korrigierte die Einschätzung. Die menschliche Entscheidung wurde als Feedback in das System zurückgespielt, um die Genauigkeit zu verbessern. Die Integration erfolgte über die bestehenden APIs des ERP-Systems, ohne dass dieses ersetzt wurde.

    Ergebnis: Messbare Reduktion der Fehlerquote

    Nach drei Monaten Pilotbetrieb zeigte sich ein deutlicher Effekt. Die Fehlerquote sank von 12 Prozent auf 4,2 Prozent, was einer Reduktion von über 60 Prozent entspricht. Die Durchlaufzeit pro Vertrag fiel von 48 Stunden auf 18 Stunden, da der Agent die ersten 80 Prozent der Prüfung automatisierte und nur noch die kritischen 20 Prozent an den Menschen eskalierte. Der Automatisierungsgrad lag bei 65 Prozent, was bedeutet, dass 65 Prozent der Verträge ohne menschliche Korrektur durchliefen. Die Zufriedenheit der Sachbearbeiter stieg, da sie sich auf komplexe Fälle konzentrieren konnten, statt Routineklauseln zu prüfen. Die Investition in das dedizierte Team amortisierte sich nach sechs Monaten durch die eingesparten personellen Kosten und die vermiedenen Nachträge.

    Erkenntnisse: Skalierung und Lessons Learned

    Die Skalierung auf weitere Abteilungen gelang durch die Modularisierung der Workflows. Da die Architektur auf LangGraph basiert, lassen sich neue Vertragsarten einfach als neue Zustandsmaschinen hinzufügen, ohne den Kern zu ändern. Das dedizierte Team dokumentierte die Prompts und die Logik so, dass interne Teams nach dem Piloten kleinere Anpassungen selbst vornehmen können. Wichtig ist, dass die Integration in bestehende Systeme über stabile APIs erfolgt, nicht über manuelle Exporte. Ein häufiger Fehler ist, die KI als Blackbox zu behandeln. Stattdessen sollte der Prozess transparent bleiben, damit menschliche Sachbearbeiter die Entscheidungen nachvollziehen können. Die Kombination aus technischer Präzision und menschlicher Kontrolle ist der Schlüssel zur erfolgreichen Skalierung in regulierten Branchen.

  • AI-Agent für Rechnungsprüfung: 8-Wochen-Pilot im Schweizer E-Commerce

    Hintergrund: Schweizer E-Commerce-Unternehmen mit 2.500 Mitarbeitern

    Dieser Fall ist ein Composite aus Mustern, die Forfis in der Praxis beobachtet hat. Wir nennen keine echten Kundennamen, um die Vertraulichkeit zu wahren. Die folgende Geschichte basiert auf einem typischen Mandat im Schweizer E-Commerce-Sektor. Der Kunde ist ein mittelständischer Händler mit über 2.500 Mitarbeitern, der in der DACH-Region aktiv ist. Die operative Herausforderung lag im Backoffice: Die manuelle Erfassung von Lieferantenrechnungen und die Erstellung der monatlichen Berichtsdaten binden ein ganzes Team. Die IT-Infrastruktur besteht aus einem SAP-ERP-System und einer veralteten Dokumentenverwaltung. Das Ziel war klar: Die Kosten pro Support-Ticket senken, indem die manuelle Datenerfassung eliminiert wird, ohne das bestehende ERP zu ersetzen.

    Herausforderung: Manuelle Datenerfassung und hohe Kosten pro Ticket

    Der operative Druck war hoch. Die monatliche Berichtsphase dauerte bisher 10 Arbeitstage, da die Daten aus PDFs manuell in Excel kopiert und dann ins SAP-System übertragen wurden. Fehler bei der Währungsumrechnung oder der Zuordnung zu den falschen Kostenstellen führten zu Verzögerungen in der Finanzabteilung. Zudem stieg die Anzahl der Lieferanten, was die Komplexität der Rechnungsformate erhöhte. Die bestehende Lösung, eine einfache OCR-Software, konnte die semantischen Zusammenhänge nicht erfassen und scheiterte an neuen Layouts. Die Geschäftsführung forderte eine Lösung, die innerhalb von 8 Wochen einen messbaren Piloten lieferte, der die manuelle Arbeit für einen spezifischen Prozess reduziert.

    Ansatz: RAG-Architektur mit pgvector und modell-agnostischer Integration

    Forfis startete mit einem Prozess-Audit, um den Workflow mit dem höchsten Hebel zu identifizieren: die Lieferantenrechnungsprüfung. Der Pilot umfasste die Entwicklung eines AI-Agenten, der auf einer RAG-Architektur (Retrieval-Augmented Generation) basiert. Statt die Dokumente nur zu lesen, wurden die relevanten Kontexte aus der internen Dokumentation und den CRM-Daten über pgvector Embeddings abgerufen. Die Architektur ist modell-agnostisch: Für die Extraktion kamen offene Modelle auf der Hardware des Kunden zum Einsatz, während die semantische Einordnung über APIs von OpenAI und Anthropic erfolgte. Die Integration in SAP lief über die Standard-APIs. Der Scope war festgelegt: Nur die Rechnungsprüfung, keine anderen Prozesse. Die Lieferung erfolgte als Fixed-Scope Pilot mit klaren Abnahmekriterien.

    Ergebnis: Messbare Reduktion der Durchlaufzeit und Fehlerquote

    Nach 8 Wochen war der Pilot live. Die Ergebnisse waren messbar: Die Durchlaufzeit für die Rechnungsprüfung sank von durchschnittlich 45 Minuten pro Beleg auf 8 Minuten. Die Fehlerquote bei der Datenerfassung reduzierte sich von 12 Prozent auf unter 2 Prozent. Die Kosten pro Support-Ticket, die durch manuelle Nachfragen bei Lieferanten entstanden, sanken um 35 Prozent. Die monatliche Berichtsphase verkürzte sich von 10 auf 3 Arbeitstage. Die manuelle Arbeit wurde nicht eliminiert, sondern auf die 6 Prozent der Fälle reduziert, die die KI nicht sicher zuordnen konnte. Das Team konnte sich auf die Ausnahmen konzentrieren, statt auf die Routine. Die Integration in SAP funktionierte stabil, ohne dass das ERP-System angepasst werden musste.

    Lektionen: Was ähnliche Teams daraus lernen können

    1. Prozess-Audit vor Technologie: Die Auswahl des richtigen Workflows ist wichtiger als die Wahl des besten Modells. Ein Prozess mit klaren Eingaben und Ausgaben eignet sich besser für einen Piloten als ein komplexer, unstrukturierter Workflow. 2. Human-in-the-Loop ist Standard: Die KI entwirft, der Mensch genehmigt. Dies ist nicht nur eine Sicherheitsmaßnahme, sondern auch der Weg, um die Genauigkeit der Modelle durch Feedback zu verbessern. 3. Modell-Agnostik ist Flexibilität: Die Architektur sollte es erlauben, Modelle je nach Bedarf zu wechseln, ohne die gesamte Integration neu aufzubauen. 4. Feste Scope-Grenzen: Ein Pilot mit klarem Umfang liefert schneller messbare Ergebnisse als ein offenes Projekt. 5. Integration statt Ersetzung: Das System muss in die bestehende Infrastruktur passen, nicht umgekehrt.