Forfis Blog

Blog

  • AI-Candidate-Screening in 2 Wochen: DSGVO-konforme Integration für E-Commerce

    Das Problem: 48 Stunden bis zur ersten Antwort

    Ein E-Commerce-Unternehmen mit 150 Mitarbeitern in Deutschland kämpft mit einer First-Response-Time von 48 Stunden auf Bewerbungen. Die Recruiter würgen sich durch 500 Lebensläufe pro Monat, extrahieren Daten manuell in das ATS und antworten verzögert. Das Ergebnis: Top-Talente wechseln zu Wettbewerbern, die in 4 Stunden antworten. Die Lösung ist keine neue Software, sondern eine Integration in das bestehende System. Der Ansatz beginnt mit einem Prozess-Audit, das die Workflows im ATS analysiert und die Engpässe identifiziert. Die Roadmap führt über einen 2-Wochen-Piloten zu einem Rollout, der die First-Response-Time auf 4 Stunden senkt. Die Architektur ist model-agnostic: Open-Weight-Modelle auf eigener Hardware für personenbezogene Daten, Anthropic Claude API für nicht-sensitive Aufgaben. Die DSGVO-Konformität ist durch die lokale Verarbeitung und den Human-in-the-Loop-Prozess gewährleistet.

    Architektur: Custom-REST-API und Webhooks

    Die Architektur besteht aus drei Schichten. Die erste Schicht ist das ATS, das über Webhooks neue Bewerbungen signalisiert. Die zweite Schicht ist die Custom-REST-API, die als Middleware fungiert. Sie empfängt den Webhook, ruft das LLM auf und sendet das Ergebnis zurück. Die dritte Schicht ist das LLM selbst. Für die Datenextraktion aus Lebensläufen wird ein lokales Open-Weight-Modell (z. B. Mistral 7B) auf eigener Hardware genutzt. Die Daten verlassen das Gebäude nicht. Für die Generierung der Antworttexte kann die Anthropic Claude API genutzt werden, wenn die Qualität es erfordert. Die API ist in Python (FastAPI) implementiert und skaliert horizontal. Die Webhooks sorgen für Echtzeit-Trigger, die REST-API für asynchrone Verarbeitung. Diese Entkopplung erlaubt es, das LLM-Modell unabhängig vom ATS zu aktualisieren.

    Compliance: DSGVO-konforme Verarbeitung

    Die DSGVO verlangt, dass personenbezogene Daten nur verarbeitet werden, wenn eine Rechtsgrundlage vorliegt (Art. 6 Abs. 1 lit. b DSGVO). Bei der Bewerbung ist dies die Vertragsanbahnung. Das Unternehmen muss die Bewerber über die automatisierte Verarbeitung informieren (Art. 13 DSGVO) und sicherstellen, dass keine diskriminierenden Merkmale extrahiert werden. Die Daten müssen nach Abschluss des Prozesses gelöscht werden (Art. 17 DSGVO). Die Nutzung eines lokalen Modells minimiert das Risiko von Datenlecks und vereinfacht die Nachweispflichten. Die Anthropic-API wird nur für nicht-personenbezogene Metadaten genutzt. Der Human-in-the-Loop-Prozess stellt sicher, dass ein Mensch jede Antwort prüft, bevor sie versendet wird. Dies ist zwingend, um die Compliance zu gewährleisten und Fehler zu vermeiden.

    Pilot: 2 Wochen bis zur messbaren Verbesserung

    Der Pilot dauert 2 Wochen und umfasst drei Phasen. Woche 1: Setup der Custom-REST-API und Konfiguration des lokalen LLMs. Die Webhooks werden mit dem ATS verbunden. Woche 2: Testlauf mit 50 realen Bewerbungen. Die Metriken werden gemessen: First-Response-Time, Fehlerquote bei der Datenextraktion, Zeit für die Freigabe durch den Recruiter. Das Ziel ist eine First-Response-Time von unter 8 Stunden und eine Fehlerquote unter 5 Prozent. Nach dem Piloten wird die Roadmap für den Rollout erstellt. Die Entscheidung, ob die Anthropic-API für die Antwortgenerierung genutzt wird, fällt basierend auf den gemessenen Metriken. Wenn das lokale Modell ausreicht, wird die API entfernt.

    Stolperfallen und wie man sie vermeidet

    Die größte Stolperfalle ist die mangelnde Datenqualität im ATS. Wenn die Lebensläufe in verschiedenen Formaten vorliegen (PDF, DOCX, E-Mail-Body), scheitert die Extraktion oft an unstrukturierten Daten. Die Lösung ist eine Vorverarbeitungs-Schicht, die die Dokumente normalisiert. Eine weitere Stolperfalle ist die fehlende Freigabe-Logik: Wenn das System automatisch antwortet, ohne dass ein Mensch prüft, entstehen Compliance-Risiken. Der Human-in-the-Loop-Prozess muss zwingend implementiert werden. Eine dritte Stolperfalle ist die Skalierung: Bei Lastspitzen (z. B. nach einer Jobbörse) muss die API horizontal skalieren können. Die Architektur mit Webhooks und asynchroner Verarbeitung ist darauf ausgelegt, aber die Infrastruktur muss entsprechend dimensioniert sein.

    Roadmap: Vom Audit zum Rollout

    Der Prozess-Audit dauert 3 bis 5 Tage und liefert die Basis für den Piloten. In dieser Phase analysiert das Team die bestehenden Workflows im ATS, identifiziert die Engpässe und definiert die Metriken. Die Roadmap umfasst drei Phasen: 1. Pilot auf einem Kanal, 2. Rollout auf alle Kanäle, 3. Managed Operation. Der Audit liefert auch die technische Spezifikation für die Custom-REST-API und die Webhook-Endpunkte. Ohne diesen Schritt fehlt die Basis für eine messbare Erfolgskontrolle. Die Kosten für den Audit liegen bei 6 000 EUR. Der ROI rechnet sich, wenn die First-Response-Time von 48 Stunden auf 4 Stunden sinkt und die Recruiter 15 Prozent ihrer Zeit für manuelle Datenpflege einsparen. Die Entscheidung für den Rollout fällt nach dem Piloten basierend auf den gemessenen Metriken.

  • KI-Automatisierung im Schweizer Fintech: Glossar für PCI-konforme Rollouts

    AI Process Audit und Roadmap

    Die AI Process Audit ist die Grundlage jeder erfolgreichen Automatisierung. Sie identifiziert Workflows, die sich für KI-Einsatz eignen, und erstellt eine priorisierte Roadmap. Im Kontext von Forfis beginnt die Audit-Phase mit der Analyse bestehender Systeme (CRM, ERP, Helpdesk) und der Messung der aktuellen Zykluszeiten und Fehlerquoten. Das Ergebnis ist eine belastbare Baseline, die den Erfolg des Piloten messbar macht. Für Unternehmen mit 11 bis 50 Mitarbeitern ist diese Phase entscheidend, da sie begrenzte Ressourcen hat und sich auf die Prozesse mit dem höchsten ROI konzentrieren muss. Die Audit-Phase dauert in der Regel 2 bis 4 Wochen und liefert einen konkreten Plan für die nächsten Schritte.

    Retrieval-Augmented Knowledge Assistant

    Ein Retrieval-Augmented Knowledge Assistant kombiniert die generative Kraft eines LLMs mit einer lokalen Wissensbasis. Im Kontext von Forfis wird die Firmendokumentation (z. B. Support-Handbücher, PCI-DSS-Richtlinien) in Vektordatenbanken indexiert. Wenn ein Ticket eingeht, sucht das System die relevantesten Abschnitte und übergibt sie dem Modell als Kontext. Das reduziert Halluzinationen und stellt sicher, dass Antworten auf aktuellen, internen Richtlinien basieren. Für Fintechs ist dieser Ansatz besonders wertvoll, da er die Compliance-Anforderungen erfüllt und gleichzeitig die Qualität der Antworten verbessert. Die Implementierung erfordert eine sorgfältige Aufbereitung der Dokumente und eine regelmäßige Aktualisierung der Vektordatenbank.

    Open-Weight-Modelle On-Premise

    Open-Weight-Modelle (z. B. Llama 3, Mistral) sind KI-Modelle, deren Gewichte öffentlich verfügbar sind und lokal auf eigener Hardware ausgeführt werden können. Im Gegensatz zu Cloud-APIs (OpenAI, Anthropic) verlassen die Daten das Unternehmen nicht. Für Schweizer Fintechs mit PCI-DSS-Pflichten ist dies oft die einzige zulässige Option, da sensible Finanzdaten nicht an Dritte übertragen werden dürfen. Die lokale Ausführung erfordert zwar eine höhere Anfangsinvestition in Hardware, bietet aber langfristig mehr Kontrolle und Sicherheit. Forfis nutzt diese Modelle für die Verarbeitung sensibler Daten und Cloud-APIs für Aufgaben, bei denen die Qualität im Vordergrund steht und keine sensiblen Daten involviert sind.

    PCI DSS Compliance

    PCI DSS (Payment Card Industry Data Security Standard) ist ein internationaler Sicherheitsstandard für die Verarbeitung von Kreditkartendaten. Für Schweizer Fintechs ist er besonders relevant, da sie oft mit internationalen Zahlungsanbietern zusammenarbeiten. Die Implementierung von KI-Systemen muss sicherstellen, dass keine CHD (Cardholder Data) in unverschlüsselten Formaten gespeichert oder an externe APIs übertragen wird. Forfis integriert dies durch lokale Modellausführung und Datenmaskierung. Das bedeutet, dass Kreditkartennummern und CVV-Codes vor der Übertragung an das LLM maskiert oder durch Token ersetzt werden. Nur die transaktionsbezogene Metadaten (z. B. Transaktions-ID, Betrag, Datum) fließen in den Kontext des Assistenten.

    Ticket Triage und Routing

    Ticket Triage und Routing ist die automatische Klassifizierung und Priorisierung eingehender Support-Anfragen. Ein KI-System liest das Ticket, erkennt die Absicht (z. B. ‘Transaktionsfehler’, ‘Konto sperren’) und leitet es an die passende Fachabteilung weiter. Bei Forfis wird dies durch ein LLM gesteuert, das auf den CRM-Daten des Kunden basiert, um personalisierte Antworten zu generieren und die Bearbeitungszeit zu verkürzen. Das System nutzt Custom REST APIs und Webhooks, um mit bestehenden Helpdesk-Systemen zu kommunizieren. Die Triage-Phase reduziert die Bearbeitungszeit um bis zu 40 % und verbessert die Kundenzufriedenheit, da Anfragen schneller und präziser beantwortet werden.

    Human-in-the-Loop

    Human-in-the-Loop (HITL) ist ein Sicherheitskonzept, bei dem ein Mensch kritische Entscheidungen der KI genehmigt. Bei Forfis gilt: Alles, was Geld, Gesundheitsdaten oder Verträge betrifft, wird vom Modell nur vorgeschlagen, aber nicht ausgeführt. Im Ticket-Triage-Kontext bedeutet das, dass das System Vorschläge für Antworten macht, aber ein Support-Mitarbeiter diese vor dem Versand freigibt. Das minimiert das Risiko von fehlerhaften oder compliance-kritischen Aussagen. Die HITL-Phase ist besonders wichtig in der Anfangsphase, da sie das Vertrauen der Mitarbeiter in das System stärkt und gleichzeitig die Qualität der Antworten sicherstellt. Mit der Zeit kann der Anteil der automatisierten Entscheidungen erhöht werden.

    Managed AI Operations

    Managed AI Operations bezeichnet den fortlaufenden Betrieb und die Optimierung der KI-Systeme nach dem Rollout. Forfis überwacht dabei die Modellperformance, aktualisiert die Vektordatenbanken bei Dokumentenänderungen und passt die Prompts an neue Compliance-Anforderungen an. Das Modell ist ‘model-agnostic’, d. h., es kann je nach Bedarf zwischen Cloud-APIs und lokalen Modellen wechseln, ohne die Architektur zu ändern. Die Managed-Operations-Phase umfasst auch die Schulung der Mitarbeiter und die kontinuierliche Verbesserung der Prozesse. Für Unternehmen mit 11 bis 50 Mitarbeitern ist diese Phase entscheidend, da sie oft keine eigene IT-Abteilung hat, die sich um den Betrieb der KI-Systeme kümmern kann.

  • RAG-Assistent für Candidate Screening und Report-Automatisierung in der Schweiz

    Checkliste: RAG-Assistent für Candidate Screening und Report-Automatisierung

    1. Definiere den Prozess-Audit-Scope. Identifiziere die drei workflows mit dem höchsten manuellen Aufwand: Candidate Screening, monatliche Report-Erstellung und Dokumenten-Extraktion. Der Audit dauert 2-3 Tage und liefert eine priorisierte Liste der automatisierbaren Schritte.

    2. Sichere die Datenbasis. Exportiere alle relevanten Daten aus CRM, Helpdesk und HR-Systemen in ein strukturiertes Format. Fehlende oder inkonsistente Daten sind der häufigste Grund für Pilot-Scheitern.

    3. Wähle das Open-Weight-Modell. Entscheide dich für Llama 3 70B oder Mistral Large, je nach Hardware-Ausstattung. Die Latenz muss unter 40 ms pro Token liegen, um Batch-Verarbeitung zu ermöglichen.

    4. Baue die RAG-Pipeline. Konfiguriere die Vektor-Datenbank und die Embedding-Modell-Integration. Die Pipeline muss Lebensläufe und Stellenprofile in 128-dimensionale Vektoren umwandeln.

    5. Integriere in Google Workspace. Verbinde das System über die Gmail API und Google Drive API. Keine zusätzliche Softwareinstallation ist nötig, die Integration läuft über bestehende APIs.

    6. Definiere die Abnahmekriterien. Setze messbare Ziele: Durchlaufzeit unter 15 Minuten, Fehlerquote unter 5%. Ohne klare Kriterien ist der Pilot nicht validierbar.

    7. Führe den Pilotbetrieb durch. Teste das System mit 10-20 realen Kandidaten und 2-3 Monatsberichten. Der Pilot dauert 2 Wochen und liefert die Baseline für die Validierung.

    8. Schule die Mitarbeiter. Erkläre den Workflow: KI generiert Entwurf, Mensch prüft und approbiert. Die Schulung dauert 2 Stunden und ist Voraussetzung für die Akzeptanz.

    9. Validiere die Ergebnisse. Vergleiche die Pilot-Daten mit der manuellen Baseline. Die Validierung bestätigt, ob die Abnahmekriterien erreicht wurden.

    10. Dokumentiere die Wartungs-Strategie. Definiere, wer das Modell aktualisiert und wie Fehler gemeldet werden. Die Wartung kostet 500-1 000 EUR pro Monat und ist im Sprint-Scope enthalten.

    Checkliste: Integration und Validierung

    1. Konfiguriere die Google Workspace-Integration. Stelle sicher, dass das System E-Mails mit Lebensläufen liest und Zusammenfassungen im Drive erzeugt. Die Integration muss in Woche 5-6 abgeschlossen sein, um den Pilotbetrieb zu ermöglichen.

    2. Setze die monatliche Report-Automatisierung auf. Konfiguriere die Datenaggregation aus CRM, Helpdesk und HR-Systemen. Der Report-Entwurf muss in 45 Minuten generiert werden, nicht in 6 Stunden.

    3. Implementiere die Human-in-the-Loop-Logik. Definiere, welche Schritte die KI automatisch durchführt und welche menschliche Approval erfordern. Alles, was Geld, Gesundheit oder Verträge betrifft, muss menschlich geprüft werden.

    4. Teste die Fehlerbehandlung. Simuliere fehlende Daten, inkonsistente Formate und API-Fehler. Das System muss Fehler klar melden und nicht stillschweigend fehlerhafte Ergebnisse liefern.

    5. Dokumentiere die Wartungs-Checkliste. Erstelle eine Liste der monatlichen Wartungsschritte: Modell-Updates, Daten-Qualitäts-Prüfung, Performance-Monitoring. Die Wartung ist Teil des Managed-Operation-Modells und kostet 500-1 000 EUR pro Monat.

    Wartung der Checkliste

    Die Wartung der Checkliste erfolgt quartalsweise. In Woche 13, 26 und 39 wird die Checkliste gegen die aktuellen Prozess-Daten geprüft. Wenn sich die Datenqualität, die Modell-Performance oder die Integrations-APIs ändern, wird die Checkliste aktualisiert. Die Verantwortung liegt beim technischen Lead des Kunden, der die Wartungs-Checkliste in das operative Monitoring aufnimmt. Die Forfis-Entwickler stehen für die ersten 6 Monate als Ansprechpartner für Modell-Updates und Fehlerbehebung zur Verfügung. Nach 6 Monaten übernimmt der Kunde die volle Verantwortung, unterstützt durch die dokumentierte Wartungs-Strategie.

  • AI-Automation-Audit für Medtech: Compliance-sicherer Rollout in 2 Wochen

    Der Engpass: Manuelle Dokumentenverarbeitung in regulierten Branchen

    In deutschen Medtech-Firmen mit 11 bis 50 Mitarbeitern staut sich Arbeit in den Backoffice-Prozessen. Juristen und Compliance-Beauftragte verbringen bis zu 40 Prozent ihrer Zeit mit der manuellen Extraktion von Daten aus Rechnungen, Zulassungsanträgen und Vertragsentwürfen. Die Folge: Zykluszeiten von 3 bis 5 Tagen für einfache Dokumentenprüfung, während die Nachfrage nach schnelleren Reaktionszeiten in der EU-Medizinprodukteverordnung (MDR) steigt.

    Die betroffenen Rollen sind klar definiert: Compliance-Officer, interne Juristen und Projektmanager. Sie arbeiten in isolierten Silos, oft mit veralteten ERP-Systemen, die keine API-Anbindung an moderne AI-Tools bieten. Die Metrik, die hier zählt, ist nicht die Produktivität im engeren Sinne, sondern die Compliance-Sicherheit: Jeder manuelle Fehler bei der Datenextraktion kann zu einer behördlichen Beanstandung führen.

    Das Problem ist nicht das Fehlen von Technologie, sondern die fehlende Strategie. Viele Unternehmen starten mit einem Proof-of-Concept, das nie in die Produktion überführt wird, weil die Integration in bestehende Workflows nie geplant wurde.

    Warum Standard-Lösungen in der Praxis scheitern

    Der häufigste Fehler ist der „Big-Bang“-Ansatz: Ein Unternehmen kauft eine AI-Plattform, hofft auf automatische Magie und stellt fest, dass die Modelle die spezifischen Formate deutscher Zulassungsanträge nicht korrekt parsen. Die Fehlerquote liegt bei 15 bis 20 Prozent, was für Compliance-Zwecke unbrauchbar ist.

    Ein zweiter Fehler ist die Ignorierung der Datenhoheit. Viele SaaS-Lösungen senden Daten an externe Server. Für ISO-27001-zertifizierte Unternehmen ist das ein K.o.-Kriterium. Die Zertifizierung verlangt nachweisbare Kontrollen über den Datenfluss. Wenn Patientendaten oder Geschäftsgeheimnisse in die Cloud wandern, ohne dass ein angemessener Schutzmechanismus (wie On-Premise-Hosting) existiert, ist die Zertifizierung gefährdet.

    Drittens fehlt oft die Human-in-the-Loop-Architektur. Modelle werden so konfiguriert, dass sie autonom entscheiden. In der Praxis bedeutet das: Das System klassifiziert einen Vertrag als „unproblematisch“, während ein kritischer Haftungsausschluss übersehen wird. Ohne menschliche Freigabe für alles, was Geld, Gesundheit oder Verträge betrifft, ist das Risiko zu hoch.

    Schließlich scheitern Projekte an der Integration. Das AI-Tool läuft als Insellösung. Die Mitarbeiter müssen zwischen dem AI-Tool und ihrem CRM oder ERP hin- und herwechseln. Das erzeugt Reibungsverluste, die den Nutzen der Automatisierung zunichtemachen.

    Der Weg: Audit, Pilot und Integration in bestehende Systeme

    Die Lösung liegt in einer schrittweisen, audit-basierten Einführung. Der erste Schritt ist ein AI-Automation-Audit. Dabei werden die bestehenden Workflows gemessen: Wie viele Dokumente pro Woche? Wie hoch ist die aktuelle Fehlerquote? Wo liegen die Engpässe?

    Auf Basis dieser Daten wird ein fester Pilot ausgewählt. Typischerweise ist das die Dokumenten-Extraktion aus Rechnungen oder die interne Wissenssuche. Die Architektur ist dabei model-agnostic: Für die Wissenssuche über interne Dokumente wird ein Retrieval-Augmented Generation (RAG)-System aufgebaut, das auf Anthropic Claude API setzt, da die Qualität der Textanalyse hier entscheidend ist. Für die Extraktion sensibler Daten, die nicht das Gebäude verlassen dürfen, werden Open-Weight-Modelle auf eigener Hardware betrieben.

    Die Integration erfolgt über die bestehenden APIs von Microsoft Teams oder Slack. Das AI-System wird als Bot eingebunden, der eingehende Dokumente oder Anfragen automatisch klassifiziert und an die zuständige Person weiterleitet. Die menschliche Freigabe erfolgt direkt im Chat-Interface.

    Wichtig ist die mehrsprachige Abdeckung: Das System kann Anfragen in Deutsch, Englisch und Französisch verarbeiten, was für internationale Zulassungsanträge entscheidend ist. Die Baseline aus dem Audit wird während des Pilots kontinuierlich mit den neuen Werten verglichen, um den ROI zu belegen.

    Fünf konkrete Schritte für den Start

    1. Prozess-Messung starten: Dokumentieren Sie die aktuellen Zykluszeiten und Fehlerquoten für drei zentrale Workflows (z. B. Rechnungsverarbeitung, Vertragsprüfung, Wissenssuche). Ohne diese Baseline ist kein ROI messbar.

    2. Datenfluss analysieren: Identifizieren Sie, welche Daten typen (Patienten, Geschäftsgeheimnisse, interne Notizen) extern verarbeitet werden dürfen und welche nicht. Das bestimmt die Architektur: Cloud-API oder On-Premise.

    3. Pilot-Workflow wählen: Wählen Sie einen Workflow mit hoher Wiederholbarkeit und klar definierten Eingaben/Ausgaben. Dokumenten-Extraktion ist ideal, weil die Ergebnisse leicht validierbar sind.

    4. Integration planen: Definieren Sie, wie das AI-System in Microsoft Teams oder Slack eingebunden wird. Welche Benachrichtigungen? Wer gibt die Freigabe? Welche Eskalationspfade gibt es?

    5. Compliance-Check: Stellen Sie sicher, dass die Datenverarbeitung mit Ihrem ISO-27001-Management-System kompatibel ist. Dokumentieren Sie die Maßnahmen zum Schutz der Datenhoheit.

    Diese fünf Schritte bilden die Grundlage für einen erfolgreichen Rollout. Sie verhindern, dass das Projekt in der Planung stecken bleibt, und liefern ein messbares Ergebnis innerhalb von 4 bis 8 Wochen.

  • 6 Schritte: RAG-Pilot senkt First-Response-Time im Medtech-Mittelstand

    1. Prozessaudit statt Bauchgefühl

    Der erste Schritt ist die Prozessanalyse, die in Woche 1 und 2 stattfindet. Forfis identifiziert die Workflows, die den größten Hebel bieten: Bei einem Medtech-Unternehmen mit 120 Mitarbeitern sind das typischerweise die Rechnungsverarbeitung und die Ticket-Kategorisierung im Support. Die Analyse zeigt, dass 60 Prozent der Support-Tickets mit denselben drei Fragen zu tun haben und dass die Rechnungsverarbeitung im Schnitt 15 Minuten pro Dokument dauert. Diese Daten bilden die Basis für den Pilot-Scope und die Erfolgskennzahlen. Ohne diese Messung ist jede spätere Optimierung blind. Die Analyse dauert zwei Wochen, weil sie manuelle Interviews mit den Fachabteilungen und die Auswertung der System-Logs umfasst.

    2. Vektor-Datenbank als Wissensbasis

    Die Vektor-Datenbank ist das Herzstück des RAG-Systems. In Woche 3 und 4 wird die Infrastruktur aufgebaut: Eine Vektor-Datenbank wie Weaviate oder Pinecone speichert die dokumentierten Prozesse, die FAQ-Antworten und die historischen Support-Tickets. Die Anthropic Claude API wird über eine Custom REST API angebunden, die die Prompts formt und die Ergebnisse strukturiert zurückgibt. Die Integration erfolgt über Webhooks, die den Status der Verarbeitung in Echtzeit an das Helpdesk-System melden. Diese Architektur ist model-agnostic: Wenn die Qualität der Claude-Antworten nicht ausreicht, kann das System auf ein Open-Weight-Modell auf eigener Hardware umgestellt werden, ohne die Integration zu ändern.

    3. Human-in-the-Loop als Standard

    Die Human-in-the-Loop-Architektur ist der Standard bei Forfis. Das KI-Modell erstellt einen Entwurf oder eine Klassifizierung, die ein Mensch prüft und freigibt. Bei der Rechnungsverarbeitung wird jede Rechnung mit einem Wert über 1.000 Euro oder mit fehlenden Feldern manuell geprüft. Diese Schicht verhindert, dass fehlerhafte Daten in das ERP-System gelangen. Die Freigabe dauert im Schnitt 30 Sekunden, was die Gesamt-Durchlaufzeit auf 2 Minuten senkt. Ohne diese menschliche Kontrolle wäre die Fehlerquote zu hoch für einen produktiven Betrieb. Die Architektur ist so gestaltet, dass die menschliche Freigabe in den Workflow integriert ist, nicht als zusätzlicher Schritt dazwischengeschaltet wird.

    4. REST-APIs und Webhooks statt Neuaufbau

    Die Integration erfolgt über Standard-REST-APIs und Webhooks. Das RAG-System liest Rechnungsdaten aus dem ERP-System, verarbeitet sie über die Anthropic Claude API und schreibt die Ergebnisse zurück. Zusätzlich werden Webhooks genutzt, um den Status der Verarbeitung in Echtzeit an das Helpdesk-System zu melden. Es ist keine Änderung der bestehenden Systemarchitektur erforderlich, da die Integration über die vorhandenen Schnittstellen erfolgt. Die API-Dokumentation des ERP-Systems wird in Woche 3 analysiert, um die benötigten Endpunkte zu identifizieren. Die Webhook-Konfiguration dauert einen Tag, da sie nur die URL und die Authentifizierung erfordert. Diese Integration ist der Schlüssel dazu, dass das System in den bestehenden Workflow passt, statt ihn zu ersetzen.

    5. Messbare Kennzahlen im Pilotbetrieb

    Der Pilotbetrieb läuft in Woche 7 und 8. Die Messung erfolgt über zwei Kennzahlen: Durchlaufzeit und Fehlerquote. Vor der Implementierung wird ein Baseline-Wert ermittelt, der nach 4 Wochen Pilotbetrieb mit den neuen Werten verglichen wird. Bei einem Medtech-Unternehmen sinkt die Durchlaufzeit der Rechnungsverarbeitung von 15 auf 2 Minuten, die Fehlerquote von 8 auf 3 Prozent. Die Kosten pro Support-Ticket sinken um 35 Prozent, weil die manuelle Erfassung entfällt. Diese Zahlen sind die Grundlage für die Entscheidung, ob der Rollout auf weitere Abteilungen vorbereitet wird. Ohne diese messbaren Ergebnisse ist der Pilot ein Blindflug.

    6. Häufige Stolperfallen vermeiden

    Der häufigste Fehler ist der Versuch, alle Workflows gleichzeitig zu automatisieren. Das führt zu einem überladenen Scope, der die 8-Wochen-Frist sprengt. Der zweite Fehler ist die fehlende Datenbereinigung: Wenn die historischen Support-Tickets unstrukturiert sind, liefert das RAG-System schlechte Antworten. Der dritte Fehler ist die fehlende menschliche Freigabe: Ohne Human-in-the-Loop ist die Fehlerquote zu hoch für einen produktiven Betrieb. Der vierte Fehler ist die Wahl des falschen Modells: Für sensible Daten wie Patientenakten ist die Anthropic Claude API nicht geeignet, weil die Daten das Unternehmen verlassen. Open-Weight-Modelle auf eigener Hardware sind hier die richtige Wahl.

  • RAG-Assistent im E-Commerce: Fehlerquote um 40 % senken

    Hintergrund: E-Commerce-Unternehmen in der Wachstumsphase

    Dieser Fallbericht ist ein Komposit aus Mustern, die in der Praxis beobachtet wurden. Es werden keine realen Firmennamen genannt, um die Vertraulichkeit der Kunden zu wahren. Die beschriebenen Metriken und Prozesse basieren auf typischen Engagements in der Schweiz und in DACH-Märkten.

    Hintergrund:
    Ein Schweizer E-Commerce-Unternehmen mit 320 Mitarbeitern, spezialisiert auf Outdoor-Ausrüstung, betreibt einen eigenen Online-Shop und ein B2B-Portal für Wiederverkäufer. Der Support besteht aus 12 FTE, verteilt auf zwei Schichten. Die IT-Stack umfasst Salesforce als CRM, Zendesk als Helpdesk und Notion als zentrale Wissensdatenbank. Die Firma befindet sich in der Wachstumsphase und plant die Expansion in den DACH-Raum.

    Herausforderung:
    Die Fehlerquote im Back-Office lag bei 18 %, gemessen an fehlerhaften Retourenbearbeitungen und falschen Produktzuordnungen. Die Hauptursache war die unklare Zuordnung von Tickets: 35 % der Anfragen wurden an die falsche Abteilung geroutet, was zu doppelten Bearbeitungen und verzögerten Antworten führte. Zusätzlich drohte der Verlust von Fachwissen durch den Abgang von drei erfahrenen Support-Leads. Die Compliance-Abteilung forderte eine Lösung, die keine Kundendaten an US-Cloud-Provider überträgt, um die DSGVO und den Schweizer Datenschutz zu wahren.

    Herausforderung: Fehlerquote und Compliance-Druck

    Der Auftrag lautete: Reduzierung der Fehlerquote im Back-Office um mindestens 30 % innerhalb von drei Monaten, ohne die bestehende Infrastruktur zu ersetzen. Die operative Dränge resultierte aus der bevorstehenden Black-Friday-Saison, bei der das Ticketvolumen um 40 % steigt. Die Compliance-Abteilung verlangte eine On-Premise-Lösung, da Kundendaten (Namen, Adressen, Bestellhistorie) nicht den Schweizer Standort verlassen durften. Zudem musste das System den EU AI Act erfüllen, der ab August 2024 in Kraft tritt und Transparenzpflichten für KI-Systeme im Kundenkontakt vorsieht.

    Die technische Herausforderung bestand in der Integration eines RAG-Assistenten in das bestehende Zendesk-System, ohne die API-Endpunkte zu modifizieren. Die Wissensbasis in Notion war unstrukturiert: 1.200 Seiten mit gemischter Qualität, veralteten Preisen und widersprüchlichen Retourenrichtlinien. Die Datenbereinigung war daher der kritischste Pfad im Projekt.

    Ansatz: Integration-Sprint mit On-Premise-LLM

    Forfis startete mit einem zweiwöchigen Prozess-Audit, der die Top-5-Ticket-Kategorien identifizierte: Retouren, Produktinformationen, Lieferstatus, Reklamationen und B2B-Abrechnungen. Der Pilot fokussierte sich auf Retouren und Produktinformationen, die 60 % des Volumens ausmachten.

    Technische Architektur:

    • Modell: Mistral Large 70B, On-Premise auf zwei NVIDIA A100 GPUs im Schweizer Rechenzentrum.
    • RAG-Pipeline: LangChain mit Weaviate als Vektor-Datenbank. Embeddings via BGE-M3 (multilingual, optimiert für Deutsch).
    • Integration: Webhook in Zendesk, der neue Tickets an das RAG-System sendet. Das System klassifiziert das Ticket, generiert einen Draft-Antwort und routet es an die zuständige Abteilung.
    • Human-in-the-Loop: Alle Antworten, die Geldbeträge oder Vertragsklauseln enthalten, erfordern eine manuelle Freigabe durch einen Support-Mitarbeiter.

    Die Notion-Dokumente wurden in Chunks von 512 Tokens aufgeteilt und in Weaviate indexiert. Ein Prompt-Template sicherte, dass das LLM nur auf Basis der abgerufenen Chunks antwortet und bei Unsicherheit den Menschen kontaktiert.

    Ergebnis: Metriken nach drei Monaten

    Nach zwölf Wochen im Parallelbetrieb (KI-Entwürfe neben menschlichen Antworten) zeigten die Messungen folgende Ergebnisse:

    • Fehlerquote: Von 18 % auf 11 % gesenkt (-39 %).
    • Routing-Genauigkeit: 92 % der Tickets wurden in die richtige Abteilung geroutet (vorher 65 %).
    • Bearbeitungszeit: Durchschnittliche Zeit pro Ticket von 14 Minuten auf 9 Minuten reduziert (-36 %).
    • Erstantwort-Zeit: Von 4 Stunden auf 45 Minuten verkürzt.
    • Kosten: Keine zusätzlichen Cloud-Kosten. Hardware-Investition von 45.000 EUR, amortisiert nach 14 Monaten durch reduzierte Personalkosten (2 FTE weniger in der Spitzenzeit).

    Die Compliance-Abteilung bestätigte, dass keine Daten den Standort verlassen haben. Der EU AI Act-Check ergab, dass das System unter „limited risk“ fällt, da es keine automatischen Entscheidungen über Personen trifft, sondern nur Vorschläge generiert. Die Transparenzpflicht wurde durch einen Hinweis im Ticket erfüllt: „Diese Antwort wurde von einer KI generiert und von einem Menschen geprüft.“

    Lektionen: Skalierung über Abteilungen hinweg

    Die Skalierung auf weitere Abteilungen (B2B-Abrechnungen, Reklamationen) erforderte drei Anpassungen:

    • Datenqualität: Die Notion-Dokumente mussten monatlich aktualisiert werden. Ein automatisierter Job prüft auf veraltete Preise und leitet Änderungsanfragen an die Produktmanager weiter.
    • Modell-Tuning: Für B2B-Tickets wurde ein separater Prompt mit spezifischen Vertragsklauseln erstellt. Das generische Modell erreichte nur 85 % Genauigkeit, der spezialisierte Prompt 94 %.
    • Human-in-the-Loop-Prozess: Die Freigabe-Schleife wurde von 100 % auf 30 % der Tickets reduziert, da die Routing-Genauigkeit für einfache Fälle (z. B. Lieferstatus) über 98 % lag. Kritische Fälle (Reklamationen über 500 EUR) bleiben manuell.

    Lektionen für ähnliche Teams:

    • Starte mit einem engen Scope (eine Ticket-Kategorie), nicht mit „allem“.
    • Investiere in die Datenbereinigung vor dem Modell-Tuning.
    • On-Premise ist in der Schweiz oft die einzige Compliance-Option für Kundendaten.
    • Mische Open-Weight-Modelle (Kostenkontrolle) mit API-Modellen (Qualität) je nach Sensitivität der Daten.
    • Dokumentiere den Human-in-the-Loop-Prozess für den EU AI Act-Compliance-Check.

  • AI-gestützte Ticket-Triage für Schweizer Fachdienstleister

    Prozess-Audit und Roadmap für die Automatisierung

    Der erste Schritt ist ein strukturierter Prozess-Audit, das in den ersten zwei Wochen des 8-Wochen-Zeitraums stattfindet. Dabei werden die bestehenden Workflows in der Operations- und Supply-Chain-Abteilung analysiert, um die Workflows zu identifizieren, die sich für die Automatisierung eignen. Der Fokus liegt auf der Reduktion manueller Back-Office-Aufgaben, insbesondere bei der Ticket-Triage und dem Routing. Das Audit liefert eine Roadmap, die festlegt, welche Datenquellen aus dem ERP (SAP oder Microsoft Dynamics) angeschlossen werden müssen und welche Metriken für die Erfolgsmessung relevant sind. Die Ergebnisse fließen direkt in die Planung des Piloten ein, der auf einem einzelnen Workflow basiert.

    Architektur: pgvector und semantische Suche

    Die technische Basis bildet eine modell-agnostische Architektur, die auf pgvector für die semantische Suche setzt. Die Vektordatenbank wird in die bestehende PostgreSQL-Infrastruktur integriert und indiziert die interne Dokumentation sowie die CRM-Records. Bei der Ticket-Triage liest das LLM den Tickettext, extrahiert die Absicht und sucht in der Vektordatenbank nach relevanten Kontextinformationen. Diese werden dem Modell als Prompt-Kontext übergeben, sodass die Klassifizierung nicht nur auf dem Text, sondern auf dem gesamten Kundenhistorie basiert. Die Latenz bleibt unter 200 ms, was für eine Echtzeit-Triage entscheidend ist.

    ERP-Integration und Datenanreicherung

    Die Integration in SAP oder Microsoft Dynamics erfolgt über die bestehenden APIs. Das System liest Kundendaten, offene Aufträge und historische Tickets direkt aus dem ERP. Diese Daten werden dem LLM als Kontext übergeben, sodass die Triage auf dem gesamten Kundenhistorie basiert. Die Datenanreicherung umfasst auch die Bereinigung von unvollständigen oder veralteten Datensätzen, die im Audit identifiziert wurden. Durch diese Anbindung wird sichergestellt, dass die Triage nicht nur auf dem Tickettext, sondern auf dem gesamten Kundenhistorie basiert. Die Integration ist so gestaltet, dass sie die bestehenden Prozesse nicht ersetzt, sondern sie ergänzt.

    Pilotbetrieb und Human-in-the-Loop

    Der Pilotbetrieb läuft in den Wochen 3 bis 6 und konzentriert sich auf einen einzelnen Workflow. Das Modell erstellt einen Entwurf oder eine Klassifizierung, aber jede Zuweisung, die Geld, Gesundheitsdaten oder Verträge betrifft, muss von einer Person freigegeben werden. Im Pilotbetrieb wird jede Entscheidung protokolliert, um die Fehlerquote zu messen und die Prompts zu optimieren. Die Metriken umfassen die Zykluszeit und die Fehlerquote vor und nach der Implementierung. Die Ergebnisse des Piloten fließen in die Entscheidung über die Skalierung auf weitere Abteilungen ein.

    Skalierung und Managed-Operation

    Nach dem Piloten wird die Triage auf weitere Abteilungen skaliert. Die Skalierung erfolgt durch die Erweiterung der Vektordatenbank und die Anpassung der Routing-Regeln. Da die Architektur modell-agnostisch ist, können neue Abteilungen einfach angeschlossen werden, indem ihre Dokumentationen in pgvector indiziert werden. Die Managed-Operation übernimmt die fortlaufende Pflege der Embeddings und die Überwachung der Modellperformance. Die Reduktion der First-Response-Time wird durch die automatische Zuweisung und die Bereitstellung von Kontextinformationen erreicht. Der Fachbereich hat sofort den vorgeschlagenen Lösungsweg und die relevanten Daten, was die Reaktionszeit deutlich verkürzt.

  • RAG-Triage im E-Commerce: LangGraph-Setup für Support-Kostensenkung

    Das Problem: Manuelle Triage bindet Kapazitäten im E-Commerce-Support

    In E-Commerce-Unternehmen mit über 2.000 Mitarbeitern staut sich der Support durch das hohe Ticket-Volumen. Manuelle Triage bindet wertvolle Kapazitäten, während Kunden auf Antworten warten. Die Herausforderung besteht darin, die Zuordnung von Tickets zu den richtigen Teams und die Bereitstellung relevanter Antworten zu automatisieren, ohne die Qualität zu opfern. Ein Retrieval-Augmented Generation (RAG) Ansatz kombiniert die Klassifikationsstärke von Large Language Models mit der Präzision Ihrer internen Dokumentation. Durch die Integration in bestehende Systeme über REST-APIs und Webhooks senken Sie die Kosten pro Ticket und automatisieren gleichzeitig die monatliche Berichterstattung über die Support-Kennzahlen. Dieser Ansatz skaliert über Abteilungen hinweg und liefert messbare Ergebnisse innerhalb von sechs Monaten.

    Voraussetzungen für den Integrationssprint

    Bevor Sie mit der Implementierung beginnen, müssen folgende Voraussetzungen erfüllt sein:

    • API-Zugänge: Lese- und Schreibrechte auf die REST-APIs Ihres Ticketing-Systems (z. B. Zendesk, Freshdesk) und Ihres CRM-Systems (z. B. Salesforce, HubSpot).
    • Wissensbasis: Eine strukturierte Sammlung Ihrer Support-Dokumente, FAQs und Produktbeschreibungen in einem maschinenlesbaren Format (Markdown, PDF).
    • Infrastruktur: Ein Kubernetes-Cluster oder ein Managed-Service wie AWS ECS für den Betrieb des Agents. Eine Vektordatenbank wie Pinecone oder Weaviate für die Speicherung der Embeddings.
    • Zugang zu LLMs: API-Keys für OpenAI oder Anthropic, je nach Qualitätsanforderungen und Datenschutzbestimmungen.
    • Team: Ein Entwickler mit Erfahrung in Python und LangChain, sowie ein Product Owner aus dem Support-Bereich.

    Schritte zur Implementierung der RAG-Triage

    1. Prozessanalyse und Datenbereinigung: Dokumentieren Sie den aktuellen Triage-Prozess und identifizieren Sie die häufigsten Ticket-Kategorien. Bereinigen Sie Ihre Wissensbasis, indem Sie veraltete Dokumente entfernen und die Struktur vereinheitlichen. Nutzen Sie ein Skript, um die Dokumente in Chunks von 500 bis 1.000 Zeichen aufzuteilen.
    2. Vektordatenbank befüllen: Generieren Sie Embeddings für alle Chunks und laden Sie sie in Ihre Vektordatenbank. Verwenden Sie ein Embedding-Modell wie text-embedding-3-small von OpenAI. Stellen Sie sicher, dass die Metadaten (Kategorie, Produkt, Datum) mitgeladen werden, um die Filterung zu ermöglichen.
    3. LangGraph-Workflow definieren: Erstellen Sie einen Stateful-Graphen in LangGraph. Definieren Sie Knoten für classify_ticket, retrieve_context und route_ticket. Verbinden Sie die Knoten mit Konditionen, die auf der Klassifikation basieren. Speichern Sie den Graphen in einer Python-Datei triage_graph.py.
    4. REST-API-Integration implementieren: Schreiben Sie einen Webhook-Handler, der neue Tickets empfängt. Der Handler ruft den LangGraph-Workflow auf und sendet das Ergebnis über die Ticketing-API zurück. Verwenden Sie requests oder httpx für die HTTP-Kommunikation. Implementieren Sie Retry-Logik für API-Fehler.
    5. Validierung mit historischen Daten: Testen Sie den Agenten mit einem Datensatz von 500 vergangenen Tickets. Vergleichen Sie die Agent-Entscheidung mit der manuellen Zuordnung. Passen Sie die Schwellenwerte für die Klassifikation an, bis die Genauigkeit über 85 Prozent liegt.
    6. Monatliche Berichterstattung automatisieren: Erstellen Sie einen Cron-Job, der am ersten Werktag des Folgemonats die Ticket-Daten aggregiert. Der Job berechnet die Verteilung der Kategorien, die Reaktionszeit und die Fehlerquote. Senden Sie den Report als JSON über eine Webhook-Verbindung an Ihr BI-System.
    7. Rollout und Monitoring: Stellen Sie den Agenten in der Produktion bereit. Überwachen Sie die Logs und die Metriken in Echtzeit. Schulung der Support-Mitarbeiter im Umgang mit den Vorschlägen des Agents.

    Häufige Stolperfallen und wie Sie sie erkennen

    • Halluzinationen in der Klassifikation: Der Agent ordnet Tickets zu Kategorien, die in der Wissensbasis nicht existieren. Erkennen Sie dies durch die Analyse der Logs, in denen die Kategorie-IDs nicht mit der Datenbank übereinstimmen. Lösung: Fügen Sie eine Validierungsschicht hinzu, die die Kategorie gegen eine Whitelist prüft.
    • Veraltete Wissensbasis: Die Vektordatenbank enthält veraltete Informationen, die zu falschen Antworten führen. Erkennen Sie dies durch eine hohe Fehlerquote bei Tickets zu neuen Produkten. Lösung: Implementieren Sie einen automatisierten Prozess, der die Wissensbasis monatlich aktualisiert und alte Chunks entfernt.
    • API-Rate-Limits: Der Agent überschreitet die Rate-Limits der Ticketing-API und erhält 429-Fehler. Erkennen Sie dies durch die Analyse der HTTP-Status-Codes in den Logs. Lösung: Implementieren Sie eine Queue, die die Anfragen drosselt und die Rate-Limits respektiert.
    • Fehlende Metadaten: Die Vektordatenbank enthält keine Metadaten, was die Filterung der Ergebnisse erschwert. Erkennen Sie dies durch irrelevante Suchergebnisse. Lösung: Erweitern Sie das Ingest-Skript, um die Metadaten aus den Dokumenten zu extrahieren und mit den Embeddings zu speichern.

    Nächste Schritte: Skalierung auf weitere Abteilungen

    Nach dem erfolgreichen Rollout der Ticket-Triage sollten Sie den nächsten Schritt planen: die Skalierung auf weitere Abteilungen. Die Architektur, die Sie mit LangGraph und der Vektordatenbank aufgebaut haben, ist modular genug, um neue Wissensbasen und Routing-Regeln zu integrieren. Beginnen Sie mit einer Abteilung, die ähnliche Datenstrukturen hat, wie der Support, z. B. den Vertrieb oder den Kundenservice. Die monatliche Berichterstattung kann um die Metriken der neuen Abteilungen erweitert werden, indem Sie die Aggregationslogik anpassen. Dieser schrittweise Ansatz minimiert das Risiko und ermöglicht es, die Lektionen aus dem Support-Rollout in die nächste Phase einzubauen.

  • AI-Ticket-Triage im B2B-SaaS: On-Premise-Implementierung in 6 Monaten

    Das Problem: Routine-Tickets binden deine Senior-Staff

    Dein Support-Team in Wien oder Graz bearbeitet 400–800 Tickets pro Woche. Davon sind 60–70 % Routineanfragen: Passwort-Reset, Lizenzfragen, einfache Fehlermeldungen. Deine Senior Engineers und Account Manager verbringen 30–40 % ihrer Arbeitszeit mit dieser Arbeit, statt sich auf Kundenbeziehungen und Produktentwicklung zu konzentrieren. Der EU AI Act (VO (EU) 2024/1689) verlangt ab August 2025 dokumentierte Risikobewertungen für KI-Systeme, die mit personenbezogenen Daten arbeiten. Gleichzeitig dürfen regulierte Daten aus deinem B2B-SaaS-Produkt nicht auf externe Cloud-APIs wandern. Die Lösung: Ein AI-System, das auf deiner eigenen Hardware läuft, Tickets klassifiziert und routet, und menschliche Freigaben für alles, was über Routine hinausgeht, erzwingt. Forfis begleitet dich dabei als dediziertes AI-Team über den gesamten 6-Monats-Zeitraum.

    Voraussetzungen vor dem ersten Schritt

    Bevor du mit der Implementierung beginnst, musst du folgende Voraussetzungen schaffen:

    • API-Zugang zum Helpdesk: Dokumentierte REST-APIs und Webhook-Endpunkte für Ticket-Erstellung, -Lesezugriff und Statusänderung. Bei Zendesk, Freshdesk oder Jira Service Management sind diese standardmäßig verfügbar.
    • On-Premise-Infrastruktur: Ein GPU-fähiger Server (mindestens NVIDIA A100 oder L40S, 48 GB VRAM) in deinem Rechenzentrum oder bei einem österreichischen Hoster. Das Modell muss lokal laufen, damit keine Daten das Gebäude verlassen.
    • Prozessdokumentation: Eine Liste der 10 häufigsten Ticket-Typen mit den zugehörigen Eskalationsregeln. Wer entscheidet, wann ein Ticket an einen Senior geht?
    • Compliance-Verantwortlicher: Eine Person, die die EU AI Act-Risikobewertung signiert und die Freigabeprozesse überwacht.
    • Baseline-Messung: Die aktuellen Durchlaufzeiten und Fehlerquoten für die letzten 90 Tage, exportiert aus dem Helpdesk.

    Schritt 1: Prozess-Audit und Pilot-Workflows auswählen

    Forfis analysiert deinen Ticket-Verlauf der letzten 90 Tage und identifiziert die Workflows mit dem höchsten Automatisierungspotenzial. Konkret: Wir kategorisieren alle Tickets nach Typ, Komplexität und Bearbeitungszeit. Das Ergebnis ist eine Priorisierungsliste, aus der wir den Pilot-Workflow auswählen. Typischerweise ist das die Ticket-Triage: Ein neues Ticket wird eingelesen, klassifiziert (z. B. “Lizenzfrage”, “Fehlermeldung”, “Rechnungsanfrage”) und an die richtige Queue geroutet. Der Pilot umfasst 20–30 % des Ticketvolumens, damit das Team die Ergebnisse validieren kann, ohne den Betrieb zu gefährden. Die Auswahl erfolgt nach zwei Kriterien: Hohe Wiederholbarkeit und klare Eskalationsregeln. Wenn ein Ticket-Typ keine eindeutige Zuordnung erlaubt, kommt er nicht in den Pilot.

    Schritt 2: On-Premise-Modell einrichten

    Du wählst ein Open-Weight-Modell, das auf deiner Hardware läuft. Für Ticket-Triage in deutscher Sprache sind Llama 3.1 70B oder Mistral Large 123B geeignete Kandidaten. Beide Modelle werden über vLLM oder TGI (Text Generation Inference) als REST-API bereitgestellt. Die Konfiguration sieht so aus:

    # vLLM-Server starten
python -m vllm.entrypoints.openai.api_server \
  --model meta-llama/Llama-3.1-70B-Instruct \
  --tensor-parallel-size 2 \
  --max-model-len 8192 \
  --port 8000

    Das Modell wird nicht für die generische Texterstellung genutzt, sondern für eine spezifische Klassifizierungs- und Routing-Aufgabe. Der Prompt ist eng gefasst: Er enthält die Ticket-Typen, die Eskalationsregeln und die Ausgabe-Formatierung (JSON mit Feldern category, priority, route_to, requires_human_review). Die Latenz liegt bei 18–35 ms pro Inferenz auf einer A100, was für Echtzeit-Triage ausreicht.

    Schritt 3: REST-API und Webhooks integrieren

    Du baust die Integration zwischen deinem Helpdesk und dem AI-Service. Der Helpdesk sendet jedes neue Ticket per Webhook an deinen Endpunkt. Dein Service ruft das Modell ab, erhält die Klassifizierung und schreibt das Ergebnis zurück in den Helpdesk. Die REST-API-Endpunkte, die du implementierst:

    • POST /webhooks/ticket-created – empfängt das neue Ticket
    • GET /api/classify – ruft das Modell ab und liefert die JSON-Antwort
    • POST /helpdesk/tickets/{id}/update – schreibt Kategorie, Priorität und Routing zurück

    Die Webhook-Authentifizierung erfolgt über HMAC-Signaturen, um Manipulationen zu verhindern. Jede Anfrage wird mit einem Zeitstempel und einer korrelierenden ID protokolliert. Diese Logs sind für die EU AI Act-Dokumentation und interne Audits erforderlich. Die Integration wird in einem separaten Container-Orchestrator (Kubernetes oder Docker Compose) betrieben, damit sie unabhängig vom Helpdesk skaliert.

    Schritt 4: Pilotbetrieb mit Human-in-the-Loop

    Der Pilot läuft 4–6 Wochen mit 20–30 % des Ticketvolumens. Das AI-System klassifiziert und routet die Tickets, aber jede Antwort, die an den Kunden geht, wird von einem Menschen freigegeben. Die Freigabemaske zeigt dem Support-Mitarbeiter die vorgeschlagene Klassifizierung, den Routing-Vorschlag und den Entwurf der Antwort. Der Mitarbeiter kann akzeptieren, korrigieren oder ablehnen. Jede Entscheidung wird protokolliert. Nach 4 Wochen vergleichst du die Baseline mit den Pilot-Ergebnissen: Durchlaufzeit, Fehlerquote, Eskalationsrate. Wenn die Fehlerquote unter 5 % liegt und die Durchlaufzeit um mindestens 40 % gesunken ist, ist der Pilot erfolgreich. Falls nicht, iterierst du an den Prompts und den Eskalationsregeln. Forfis liefert ein wöchentliches Report mit den Metriken und den korrigierten Tickets, um das Modell zu verbessern.

    Schritt 5: Rollout und Managed Operation

    Nach dem erfolgreichen Pilot rollst du das System auf 100 % des Ticketvolumens aus. Die Eskalationsregeln werden schärfer: Tickets mit finanziellen Auswirkungen (Rückbuchungen, Vertragsänderungen) oder Gesundheitsdaten erfordern dauerhaft eine menschliche Freigabe. Alle anderen Tickets werden vom System abschließend geroutet, aber die Antwort wird erst nach 24 Stunden automatisch versendet, falls keine Korrektur eingegangen ist. Das Monitoring umfasst: Latenz des Modells, Fehlerquote der Klassifizierung, Anzahl der Eskalationen pro Tag und Customer Effort Score. Forfis übernimmt den Managed Operation: Modell-Updates, Prompt-Optimierung, Monitoring und Support. Die Übergabe an dein internes Team erfolgt in Monat 6, inklusive Dokumentation und Schulung.

  • RAG-Pilot für den Support: LangGraph mit Notion in 4 Wochen

    Das Problem: Verstreutes Wissen im Support

    Ein Logistikunternehmen mit 80 Mitarbeitern in Wien bearbeitet täglich 150 Support-Tickets. Davon sind 40 Prozent Routineanfragen: Sendungsverfolgung, Schadensmeldungen, Zollabfertigung. Die Support-Mitarbeiter verbringen 60 Prozent ihrer Zeit mit der Suche in Confluence und Notion, statt die Tickets zu lösen. Die Durchlaufzeit pro Ticket liegt bei 45 Minuten, die Fehlerquote bei 12 Prozent. Das Problem ist nicht mangelnde Kompetenz, sondern fehlende Kontextverfügbarkeit. Die relevanten Informationen sind in 3.200 Confluence-Seiten und 800 Notion-Dokumenten verstreut, ohne einheitliche Struktur. Ein RAG-System kann diese Lücke schließen, indem es die Wissensbasis in einen durchsuchbaren Vektorindex überführt und die Antwortgenerierung an die LLM-API delegiert. Der Pilot zielt darauf ab, die Durchlaufzeit auf 25 Minuten zu senken und die Fehlerquote auf unter 5 Prozent zu reduzieren.

    Architektur: LangGraph mit Notion-Anbindung

    Die Architektur besteht aus vier Komponenten: (1) einem Ingest-Pipeline, die über die Confluence und Notion REST-APIs Inhalte abruft, in Chunks von 512 Token aufteilt und mit dem Embedding-Modell text-embedding-3-small in Vektoren konvertiert; (2) einem Vektordatenbank-Backend (Qdrant oder Weaviate) mit HNSW-Indexierung für sub-100-ms-Suche; (3) einem LangGraph-Workflow, der die Anfrage klassifiziert, die Top-5-Ergebnisse abruft und ein Prompt mit Kontext an die LLM-API sendet; (4) einem Human-in-the-Loop-Interventionspunkt, bei dem der Support-Mitarbeiter den Vorschlag vor der Kundenantwort freigibt. Die API-Endpunkte sind über FastAPI exponiert, mit Rate-Limiting auf 10 Requests pro Minute pro Benutzer. Die Latenz liegt bei 1.200 ms für die Gesamtantwort, davon 800 ms für die LLM-Generierung.

    Trade-offs: Chunking, Embeddings und Latenz

    Die Chunk-Größe ist der kritischste Parameter. Zu kleine Chunks (unter 256 Token) verlieren Kontext, zu große (über 1.024 Token) reduzieren die Suchpräzision. Für Logistik-Dokumentation mit vielen Tabellen und Aufzählungen empfiehlt sich eine semantische Chunking-Strategie, die Absätze und Tabellen als eigene Einheiten behandelt. Die Embedding-Modell-Wahl ist ein Trade-off zwischen Kosten und Qualität: text-embedding-3-small kostet 0,02 USD pro 1.000 Token und reicht für die meisten Fälle. Wenn die Genauigkeit unter 80 Prozent liegt, lohnt sich der Wechsel zu text-embedding-3-large (0,13 USD pro 1.000 Token). Die Vektordatenbank-Wahl hängt von der Skalierbarkeit ab: Qdrant ist für unter 100.000 Vektoren ausreichend, Weaviate bietet bessere Filterung für strukturierte Metadaten.

    Empfehlung: 4-Wochen-Plan für den Piloten

    Für ein 51-200-Mitarbeiter-Unternehmen in der Logistik mit Confluence und Notion als Wissensbasis empfiehlt sich folgender 4-Wochen-Plan: Woche 1: Prozessanalyse und Auswahl der 20 häufigsten Ticket-Typen, Einrichtung des Vektordatenbank-Backends, Implementierung der Ingest-Pipeline. Woche 2: LangGraph-Workflow mit Human-in-the-Loop, Integration der LLM-API, Latenz-Optimierung. Woche 3: Pilotbetrieb mit 5 Support-Mitarbeitern, Messung der Antwortgenauigkeit und Latenz, Iteration an den Prompts. Woche 4: Auswertung der Metriken, Dokumentation, Übergabe an das Support-Team. Die wichtigsten Erfolgskriterien sind: Antwortgenauigkeit über 85 Prozent, P95-Latenz unter 2 Sekunden, Mitarbeiter-Zufriedenheit über 4/5. Wenn diese Kriterien nicht erfüllt sind, sollte der Pilot nicht in den Produktivbetrieb überführt werden.

    Stolperfallen: Was den Piloten scheitern lässt

    Die häufigsten Fehler bei RAG-Piloten in der Logistik sind: (1) unstrukturierte Quelldaten – Confluence-Seiten mit veralteten Informationen oder widersprüchlichen Anweisungen; (2) fehlende Metadaten – ohne Tags wie ‘Zoll’, ‘Schaden’, ‘Versicherung’ kann die Suche nicht filtern; (3) zu aggressive Automatisierung – wenn die KI ohne menschliche Freigabe antwortet, steigt das Risiko von Fehlinformationen; (4) mangelnde Messung – ohne Baseline vor dem Piloten kann man den Erfolg nicht belegen. Die Lösung ist eine strenge Scope-Definition: Nur die 20 häufigsten Ticket-Typen werden im Piloten abgedeckt, alle anderen gehen weiterhin manuell. Die menschliche Freigabe bleibt für alle Antworten, die Kunden betreffen.