Forfis Blog

Blog

  • AI Agent für HR und Back Office: LangGraph-Pilot in 4 Wochen

    Prozessengpässe im Back Office: Wo die Zeit verloren geht

    In Schweizer E-Commerce-Unternehmen mit 501 bis 2000 Mitarbeitern staut sich die Arbeit im Back Office häufig an Dokumenten, die manuell erfasst, klassifiziert und in CRM- oder HR-Systeme übertragen werden müssen. Die Zykluszeit für eine einzelne Bewerbung oder einen Lieferantenvertrag liegt oft bei 48 bis 72 Stunden, die Fehlerquote bei der Dateneingabe bei 3 bis 5 Prozent. Diese Ineffizienz kostet Zeit und Geld, ohne dass die Ursache in der Software liegt, sondern im manuellen Prozess. Ein AI Agent, der auf interne Wissensbasen in Confluence oder Notion zugreift, kann diese Engpässe durch automatisierte Extraktion und Klassifizierung lösen. Der Ansatz ersetzt keine bestehenden Systeme, sondern ergänzt sie um eine intelligente Verarbeitungsstufe, die menschliche Prüfer entlastet und die Durchlaufzeit auf unter 4 Stunden senkt.

    Architektur: LangGraph als Zustandsmaschine für RAG und Scoring

    Die technische Basis bildet eine RAG-Pipeline, die auf LangGraph aufsetzt. LangGraph verwaltet den Zustandsübergang zwischen Dokumentenabruf, Vektorisierung, LLM-Abfrage und Antwortgenerierung. Für die Wissenssuche werden Dokumente aus Confluence über die REST-API abgerufen, in Chunks aufgeteilt und in eine Vektor-Datenbank geladen. Das LLM – je nach Compliance-Anforderung ein OpenAI- oder Anthropic-Modell oder ein Open-Weight-Modell auf eigener Hardware – beantwortet Anfragen auf Basis dieser Inhalte. Predictive Scoring wird als separater Knoten in den Graphen integriert: Das Modell berechnet eine numerische Wertung für eingehende Dokumente, etwa die Passung eines Lebenslaufs zu einer Stellenanzeige. Die Architektur ist modell-agnostisch, um ISO 27001-Anforderungen an Datenhoheit zu erfüllen.

    Fixed-Scope Pilot: Vier Wochen bis zum messbaren Ergebnis

    Der Pilot läuft über vier Wochen mit fixiertem Umfang. Woche 1: Prozess-Audit und Definition der Erfolgskriterien. Es wird eine Baseline zu Zykluszeit und Fehlerquote für den ausgewählten Workflow gemessen. Woche 2: Technische Einrichtung der RAG-Pipeline und Anbindung an Confluence oder Notion. Woche 3: Implementierung des Predictive Scoring-Modells und der menschlichen Freigabe-Schleife. Woche 4: Messung der Ergebnisse und Erstellung des Vorher-Nachher-Berichts. Der Pilot umfasst keine neuen Integrationsziele und keine Änderung der Datenquellen während der Laufzeit. Die menschliche Freigabe bleibt für alle Vorgänge erhalten, die Geld, Gesundheitsdaten oder Verträge betreffen. Das Ergebnis ist ein messbarer Nachweis der Effizienzsteigerung, der als Grundlage für die Skalierung auf weitere Abteilungen dient.

    Skalierung über Abteilungen: Vom Piloten zum Betrieb

    Die Skalierung auf weitere Abteilungen folgt einem standardisierten Muster. Die Prompt-Templates und die Zustandslogik in LangGraph werden als wiederverwendbare Komponenten definiert. Neue Abteilungen werden an die bestehende Infrastruktur angeschlossen, indem ihre Datenquellen in die RAG-Pipeline integriert werden. Die menschliche Freigabe-Schleife bleibt erhalten, aber die Volumenlast verteilt sich auf mehrere Teams. Die Architektur unterstützt horizontale Skalierung ohne Neuentwicklung der Kernkomponenten. Für regulierte Daten, die das Gebäude nicht verlassen dürfen, werden Open-Weight-Modelle auf eigener Hardware betrieben. Die ISO 27001-Zertifizierung erfordert dokumentierte Zugriffskontrollen, Verschlüsselung und Audit-Logs, die in der Architektur von Beginn an berücksichtigt werden. Die Skalierung ist kein Neuprojekt, sondern die Erweiterung eines bewährten Musters.

    Stolperfallen: Datenqualität und Compliance-Vorgaben

    Die häufigste Stolperfalle ist die unklare Definition der Erfolgskriterien vor Pilotbeginn. Ohne eine gemessene Baseline zu Zykluszeit und Fehlerquote lässt sich der Nutzen nicht quantifizieren. Eine weitere Herausforderung ist die Datenqualität in Confluence oder Notion: veraltete oder widersprüchliche Dokumente führen zu unzuverlässigen AI-Antworten. Die Prozess-Audit-Phase muss diese Datenprobleme identifizieren und lösen. Ein weiterer Fehler ist die Annahme, dass die AI-Lösung ohne menschliche Freigabe auskommt. Bei sensiblen Daten wie HR-Informationen ist die menschliche Prüfung gesetzlich und compliance-seitig erforderlich. Die Architektur muss diese Schleife von Beginn an einplanen, nicht nachträglich ergänzen.

  • RAG-System mit pgvector für Lieferstatus-Updates im Fintech

    Das Problem: Routineanfragen binden Senior-Staff

    Ihr Unternehmen mit über 2000 Mitarbeitern im Fintech-Bereich in der Schweiz verarbeitet täglich Tausende von Kundenanfragen zu Sendungsstatus. Diese Anfragen binden Senior-Mitarbeiter, die eigentlich für strategische Aufgaben vorgesehen sind. Sie haben noch kein KI-System in Produktion, wollen aber ohne neue Einstellungen Ihre Operations skalieren. Die Herausforderung: Sie müssen ein System bauen, das auf Ihre eigenen Daten (ERP, Helpdesk) zugreift, die EU AI Act-Anforderungen erfüllt und in 2 Wochen einen messbaren Piloten liefert. Der Use Case ist klar definiert: Kundenanfragen zu Order- und Shipment-Status-Updates automatisieren, damit Ihre Senior-Staff sich auf komplexe Fälle konzentrieren kann.

    Voraussetzungen: Was Sie vor dem Piloten brauchen

    Bevor Sie mit dem Piloten starten, müssen folgende Voraussetzungen erfüllt sein:

    • Datenzugriff: Sie haben API-Zugriff auf Ihr ERP-System (z. B. SAP, Oracle) und Ihr Helpdesk-System (z. B. Zendesk, Freshdesk). Die APIs müssen Webhooks oder REST-Endpunkte für Sendungsstatus-Änderungen unterstützen.
    • Datenqualität: Sie haben eine Stichprobe von mindestens 500 historischen Anfragen mit den zugehörigen Sendungsnummern und Status-Antworten. Diese Daten dienen als Testset für den Piloten.
    • Infrastruktur: Sie haben ein PostgreSQL-Cluster (Version 15 oder höher) mit dem pgvector-Modul installiert. Alternativ können Sie eine Managed-Postgres-Instanz (z. B. AWS RDS, Azure Database for PostgreSQL) mit pgvector-Erweiterung nutzen.
    • Compliance-Review: Ihre Rechtsabteilung hat bestätigt, dass die Verarbeitung von Sendungsdaten (Kundenname, Adresse, Sendungsnummer) unter das revDSG fällt und keine sensiblen Daten (z. B. Gesundheitsdaten) enthalten sind.
    • Team: Sie haben einen technischen Lead (Backend-Entwickler mit PostgreSQL-Erfahrung) und einen Produktmanager, der den Piloten-Scope definiert.

    Schritte: Vom Audit zum produktiven Piloten

    1. Prozess-Audit durchführen: Dokumentieren Sie den aktuellen Workflow für Status-Anfragen. Messen Sie: Wie viele Anfragen pro Tag? Wie lange dauert die Bearbeitung? Wie viele Fehler (falscher Status, falsche Sendung) treten auf? Diese Baseline ist der Maßstab für den Piloten-Erfolg.

    2. pgvector-Infrastruktur aufsetzen: Installieren Sie pgvector auf Ihrem PostgreSQL-Cluster. Erstellen Sie eine Tabelle shipments mit den Feldern: id, tracking_number, status, last_updated, embedding (Vektor, Dimension 1024). Laden Sie die historischen Sendungsdaten in diese Tabelle.

    3. Embeddings generieren: Verwenden Sie ein Open-Weight-Modell (z. B. BGE-M3 oder Llama-3-8B-Instruct) auf Ihrer eigenen Hardware, um Text-Embeddings für die Sendungsbeschreibungen zu erzeugen. Speichern Sie die Embeddings in der embedding-Spalte. Dies garantiert, dass keine Daten das Gebäude verlassen.

    4. RAG-Pipeline entwickeln: Bauen Sie eine Python- oder Node.js-Anwendung, die: a) die Kundenanfrage empfängt, b) ein Embedding der Anfrage erzeugt, c) eine Vektorsuche in pgvector durchführt (SELECT * FROM shipments WHERE embedding <-> $1 ORDER BY embedding <-> $1 LIMIT 5), d) die Top-5-Ergebnisse an ein LLM (z. B. OpenAI GPT-4 oder Anthropic Claude) übergibt, um eine Antwort zu formulieren.

    5. Webhook-Integration einrichten: Verbinden Sie Ihr ERP-System mit dem RAG-System über Webhooks. Jede Status-Änderung im ERP löst einen Webhook aus, der die shipments-Tabelle in Echtzeit aktualisiert. Dies stellt sicher, dass das RAG-System immer aktuelle Daten hat.

    6. Human-in-the-Loop-UI bauen: Entwickeln Sie ein einfaches Web-Formular, in dem ein Mitarbeiter den KI-Entwurf prüfen und freigeben kann. Das Formular zeigt: Kundenanfrage, KI-Entwurf, Top-3-Suchergebnisse aus pgvector. Der Mitarbeiter klickt auf „Freigeben“ oder „Ablehnen“.

    7. Piloten testen und messen: Führen Sie den Piloten mit 100 realen Anfragen durch. Messen Sie: Trefferquote (richtige Sendung identifiziert), Antwortqualität (korrekter Status), Bearbeitungszeit (vorher/nachher), Fehlerquote. Diese Metriken sind die Grundlage für die Entscheidung über den Rollout.

    Häufige Stolperfallen und wie Sie sie erkennen

    • Veraltete Daten: Wenn das ERP-System Status-Änderungen mit mehr als 5 Minuten Verzögerung meldet, liefert das RAG-System veraltete Informationen. Erkennung: Vergleichen Sie die last_updated-Zeitstempel in der shipments-Tabelle mit den tatsächlichen Status-Änderungen im ERP. Wenn die Differenz regelmäßig über 5 Minuten liegt, müssen Sie die Webhook-Integration optimieren oder auf Polling mit 1-Minuten-Intervall umstellen.

    • Falsche Embeddings: Wenn die Embeddings-Modell nicht gut für deutsche Logistik-Begriffe trainiert ist, liefert die Vektorsuche irrelevante Ergebnisse. Erkennung: Prüfen Sie manuell 20 Suchanfragen und vergleichen Sie die Top-5-Ergebnisse mit den erwarteten Sendungen. Wenn weniger als 80 % der Top-5-Ergebnisse die richtige Sendung enthalten, müssen Sie ein anderes Embeddings-Modell testen oder die Datenqualität verbessern.

    • Halluzinationen des LLM: Das LLM kann Informationen erfinden, die nicht in den pgvector-Ergebnissen enthalten sind. Erkennung: Führen Sie 50 Testanfragen durch und prüfen Sie, ob die Antwort ausschließlich auf den Top-5-Suchergebnissen basiert. Wenn das LLM Informationen erfindet, müssen Sie den Prompt anpassen (z. B. „Beantworte ausschließlich auf Basis der folgenden Informationen“) oder ein anderes LLM-Modell verwenden.

    • Performance-Probleme: Wenn die Vektorsuche in pgvector länger als 500 ms dauert, ist die Benutzererfahrung schlecht. Erkennung: Messen Sie die Antwortzeit der Vektorsuche mit EXPLAIN ANALYZE. Wenn die Zeit über 500 ms liegt, müssen Sie einen Index auf der embedding-Spalte erstellen (z. B. CREATE INDEX ON shipments USING ivfflat (embedding) WITH (lists = 100)).

    Fazit: Der nächste Schritt nach dem Piloten

    Der 2-Wochen-Pilot ist abgeschlossen, wenn Sie die Baseline-Metriken (Bearbeitungszeit, Fehlerquote) gemessen haben und die Trefferquote über 90 % liegt. Der nächste Schritt ist die Entscheidung über den Rollout: Wenn der Pilot erfolgreich war, planen Sie die Erweiterung auf weitere Use Cases (z. B. Reklamationen, Zahlungsstatus). Wenn der Pilot nicht erfolgreich war, analysieren Sie die Ursachen (Datenqualität, Embeddings-Modell, LLM-Prompt) und wiederholen Sie den Piloten mit den Anpassungen. Wichtig: Der Pilot ist ein Fixed-Scope-Projekt. Jede Erweiterung (z. B. zusätzliche Sprachen, zusätzliche Datenquellen) ist ein neues Projekt mit neuem Scope und neuem Zeitplan. Planen Sie den Rollout als separates Projekt mit einem eigenen Budget und einem eigenen Team.

  • Voice-Agent vs. RAG-Suche: First-Response-Time in der Logistik reduzieren

    Voice-Agent vs. RAG-Suche: Zwei Wege zur schnelleren Kundenantwort

    Die Reduktion der First-Response-Time in der Kundenbetreuung erfordert zwei komplementäre Technologien: einen Voice-Agent für den sofortigen ersten Kontakt und eine RAG-Suche (Retrieval-Augmented Generation) für die präzise Beantwortung komplexer Anfragen. Der Voice-Agent übernimmt Routineanfragen wie Sendungsverfolgung oder Terminvereinbarung und antwortet in unter 30 Sekunden. Die RAG-Suche indexiert interne Dokumente aus Google Workspace und liefert dem menschlichen Agenten die relevante Information für mehrschichtige Probleme. Beide Komponenten sind in einem 6-Monats-Zeitplan für Unternehmen mit 201 bis 500 Mitarbeitern in der Logistikbranche in Österreich einsetzbar.

    Kriterien für den Vergleich

    Die Bewertung beider Optionen basiert auf acht Kriterien, die für die Kundenbetreuung in der Logistikbranche entscheidend sind:

    • Antwortzeit: Zeit bis zur ersten Reaktion auf eine Kundenanfrage.
    • Genauigkeit: Korrektheit der gelieferten Information.
    • Skalierbarkeit: Fähigkeit, mehrere Abteilungen und Sprachen zu bedienen.
    • Integration: Aufwand der Anbindung an Google Workspace und bestehende Systeme.
    • Kosten: Einmalkosten für Entwicklung und laufende Betriebskosten.
    • Wartungsaufwand: Regelmäßige Aktualisierung der Modelle und Daten.
    • Benutzerakzeptanz: Einarbeitungszeit der Mitarbeiter und Akzeptanz der Kunden.
    • Datenqualität: Abhängigkeit von der Qualität der internen Dokumente.

    Vergleichstabelle: Konkrete Werte

    Kriterium Voice-Agent RAG-Suche
    Antwortzeit Unter 30 Sekunden für Routineanfragen 5 bis 15 Sekunden für komplexe Anfragen
    Genauigkeit 85 bis 90 Prozent bei klaren Anfragen 92 bis 95 Prozent bei dokumentierten Prozessen
    Skalierbarkeit Begrenzt auf definierte Dialogbäume Skalierbar über alle dokumentierten Prozesse
    Integration 2 bis 3 Wochen für Telefonie und Web-Widget 3 bis 4 Wochen für Indexierung und API-Anbindung
    Kosten 20.000 bis 35.000 Euro einmalig, 500 bis 1.000 Euro monatlich 15.000 bis 25.000 Euro einmalig, 300 bis 800 Euro monatlich
    Wartungsaufwand Monatliche Aktualisierung der Dialogbäume Wöchentliche Re-Indexierung bei Dokumentänderungen
    Benutzerakzeptanz Hohe Akzeptanz bei Kunden, geringe Einarbeitung Mittlere Akzeptanz, 2 bis 3 Tage Einarbeitung
    Datenqualität Unabhängig von Dokumentqualität Stark abhängig von Vollständigkeit und Aktualität der Dokumente

    Szenario: Routineanfragen vs. komplexe Probleme

    Der Voice-Agent gewinnt, wenn die First-Response-Time für Routineanfragen unter 30 Sekunden sinken soll. In der Logistikbranche machen Sendungsverfolgung, Terminanfragen und einfache Statusabfragen 40 bis 60 Prozent des Anfragevolumens aus. Hier liefert der Voice-Agent eine sofortige, konsistente Antwort ohne manuelle Eingabe. Die RAG-Suche ist überlegen, wenn die Qualität der Antwort für komplexe, mehrschichtige Probleme entscheidend ist, etwa bei Schadensmeldungen oder Vertragsauslegungen. In einem 6-Monats-Zeitplan für ein Unternehmen mit 300 Mitarbeitern in Österreich ist der Voice-Agent der schnellere Hebel für die messbare Reduktion der First-Response-Time, während die RAG-Suche die langfristige Qualität der Bearbeitung verbessert.

    Szenario: Datenqualität und Benutzerakzeptanz

    Die RAG-Suche ist die bessere Wahl, wenn die interne Wissensbasis in Google Workspace unvollständig oder verstreut ist. In der Logistikbranche liegen Prozesse oft in E-Mails, PDFs und Excel-Tabellen, die nicht zentral verwaltet werden. Die RAG-Suche indexiert diese Dokumente und liefert dem Agenten die relevante Information, auch wenn sie nicht in einem zentralen Wiki liegt. Der Voice-Agent ist die bessere Wahl, wenn die Kundenakzeptanz für eine sofortige Antwort über Telefon oder Chat höher ist als für eine manuelle Eingabe. In Österreich, wo die Kundenbeziehung persönlich geprägt ist, kann der Voice-Agent die Akzeptanz erhöhen, wenn er in einem natürlichen, deutschen Dialog geführt wird. Beide Technologien sind in einem 6-Monats-Zeitplan kombinierbar, wobei der Voice-Agent in Monat 3 und die RAG-Suche in Monat 4 produktiv gehen sollten.

    Empfehlung: Voice-Agent als primärer Hebel, RAG-Suche als Ergänzung

    Für ein Logistikunternehmen mit 201 bis 500 Mitarbeitern in Österreich, das die First-Response-Time in der Kundenbetreuung reduzieren will, ist der Voice-Agent die primäre Empfehlung. Er liefert die schnellste messbare Wirkung auf die KPI und entlastet das Team um 40 Prozent bei Routineanfragen. Die RAG-Suche sollte als zweite Komponente in Monat 4 implementiert werden, um die Qualität der Antworten für komplexe Probleme zu verbessern. Beide Technologien sind über die Google Workspace API integrierbar und erfordern keine Änderung der bestehenden IT-Infrastruktur. Der 6-Monats-Zeitplan ist realistisch, wenn in Monat 1 bis 2 ein Prozess-Audit und ein Pilot auf einer Abteilung durchgeführt werden, in Monat 3 bis 4 die RAG-Suche integriert und in Monat 5 bis 6 der Voice-Agent aktiviert wird. Die Gesamtkosten liegen bei 35.000 bis 60.000 Euro einmalig und 800 bis 1.800 Euro monatlich für den Betrieb.

  • AI-Automatisierung im Fintech-HR: OpenAI-APIs vs. Open-Weight-Modelle

    Zwei Ansätze für AI-Automatisierung im Fintech-HR

    Der Vergleich bezieht sich auf zwei Ansätze zur Implementierung von AI-Automatisierung in der HR- und Recruiting-Abteilung eines Fintech-Unternehmens mit 501 bis 2.000 Mitarbeitern in Deutschland. Option A nutzt kommerzielle LLM-APIs von OpenAI oder Anthropic, die über HTTPS aufgerufen werden. Option B setzt auf Open-Weight-Modellen, die auf der eigenen Hardware des Unternehmens laufen. Beide Optionen integrieren sich in bestehende Systeme wie CRM, ERP und Helpdesk über APIs und nutzen LangChain und LangGraph als Orchestrierungsframework. Der Fokus liegt auf der Automatisierung von manuellen Back-Office-Aufgaben, dem Predictive Scoring von Kandidaten und dem internen Knowledge Search, der über Slack oder Microsoft Teams abgewickelt wird. Die Compliance-Anforderungen umfassen PCI DSS und DSGVO, da sensible Daten aus dem Zahlungsverkehr und dem Personalbereich verarbeitet werden.

    Kriterien für die Bewertung

    • Latenz: Antwortzeit für eine einzelne Anfrage, gemessen in Millisekunden.
    • Kosten: Laufende Betriebskosten pro Monat, einschließlich API-Gebühren und Infrastruktur.
    • Vendor Lock-in: Abhängigkeit von einem bestimmten Anbieter und die Migrationskosten bei einem Wechsel.
    • Compliance: Erfüllung von PCI DSS, DSGVO und branchenspezifischen Vorschriften.
    • Datenhoheit: Ort der Datenverarbeitung und die Möglichkeit, Daten lokal zu speichern.
    • Skalierbarkeit: Fähigkeit, die Last zu erhöhen, ohne dass die Leistung abnimmt.
    • Wartungsaufwand: Zeit und Aufwand für Updates, Monitoring und Fehlerbehebung.
    • Qualität der Ergebnisse: Genauigkeit der Klassifikation und Extraktion, gemessen an der Baseline.

    Vergleichstabelle der Optionen

    Kriterium Option A: Kommerzielle APIs Option B: Open-Weight lokal
    Latenz 180-400 ms pro Anfrage 50-150 ms pro Anfrage
    Kosten 0,002-0,01 EUR pro 1.000 Tokens 0 EUR pro Token, aber 2.000-5.000 EUR/Monat für Hardware
    Vendor Lock-in Hoch, API-Änderungen können Breaking Changes sein Gering, Modell kann lokal aktualisiert werden
    Compliance Erfordert Datenübermittlung an Drittanbieter Daten bleiben im Gebäude, einfacher für PCI DSS
    Datenhoheit Daten verlassen das Unternehmen Daten bleiben lokal
    Skalierbarkeit Automatisch durch den Anbieter Manuell durch zusätzliche Hardware
    Wartungsaufwand Gering, Anbieter kümmert sich um Updates Hoch, eigenes Team für Modell-Updates nötig
    Qualität Sehr hoch, besonders bei komplexen Aufgaben Gut, abhängig von der Modellgröße und Hardware

    Szenario-spezifische Bewertung

    Option A gewinnt, wenn die Qualität der Ergebnisse im Vordergrund steht und die Daten nicht besonders sensibel sind. Für das Predictive Scoring im Recruiting, bei dem komplexe Muster in Lebensläufen erkannt werden müssen, bieten kommerzielle APIs oft eine höhere Genauigkeit. Die Latenz von 180-400 ms ist für die meisten HR-Prozesse akzeptabel, da die Anfragen nicht in Echtzeit abgewickelt werden müssen. Die Kosten sind vorhersehbar und skalieren mit der Nutzung. Allerdings erfordert die Datenübermittlung an OpenAI oder Anthropic eine sorgfältige Prüfung der Datenschutzvereinbarungen, um die DSGVO zu erfüllen.

    Option B gewinnt, wenn die Datenhoheit und die Compliance im Vordergrund stehen. Für die Verarbeitung von sensiblen Daten aus dem Zahlungsverkehr, die unter PCI DSS fallen, ist es oft erforderlich, dass die Daten das Gebäude nicht verlassen. Die Latenz von 50-150 ms ist für die meisten Anwendungen ausreichend. Die Kosten sind höher, da eigene Hardware betrieben werden muss, aber die Abhängigkeit von einem externen Anbieter entfällt. Die Wartung ist aufwendiger, da das eigene Team für Updates und Monitoring verantwortlich ist.

    Empfehlung für den Fintech-Kontext

    Für ein Fintech-Unternehmen in Deutschland mit 501 bis 2.000 Mitarbeitern, das PCI DSS einhalten muss, ist Option B die empfohlene Wahl. Die Datenhoheit ist entscheidend, da sensible Daten aus dem Zahlungsverkehr und dem Personalbereich verarbeitet werden. Die lokale Verarbeitung auf Open-Weight-Modellen erfüllt die Anforderungen von PCI DSS und DSGVO, ohne dass Daten an Drittanbieter übermittelt werden müssen. Die höhere Latenz von Option A ist für die meisten HR-Prozesse akzeptabel, aber die Compliance-Vorteile von Option B überwiegen. Die Kosten für die Hardware sind höher, aber die Migrationskosten bei einem Anbieterwechsel entfallen. Die Wartungsaufwand ist höher, aber das eigene Team kann die Modelle an die spezifischen Anforderungen des Unternehmens anpassen.

  • KI-Assistenten im E-Commerce: First-Response-Time um 91 % senken

    Hintergrund: Mittelständler im E-Commerce mit wachsender Ticket-Last

    Dieser Fall ist ein Composite aus Mustern, die Forfis in der Praxis beobachtet hat. Wir erfinden keine Kunden, sondern verallgemeinern typische Herausforderungen aus dem E-Commerce-Sektor. Das Unternehmen, das wir hier beschreiben, ist ein fiktiver, aber plausibler Vertreter eines Mittelständlers mit 350 Mitarbeitenden, der im deutschen E-Commerce tätig ist und jährlich 12 Millionen Euro Umsatz erzielt. Die IT-Infrastruktur besteht aus einem Shopify-Store, einem SAP-Business-One-ERP, einem Zendesk-Ticketing-System und einem Salesforce-CRM. Die KI-Reifegrad-Phase ist „Isolierte Piloten“: Das Unternehmen hat bereits zwei kleine Piloten durchgeführt (einen für Dokumentenextraktion, einen für interne Wissenssuche), aber noch keine skalierbare Lösung für den Customer-Facing-Bereich implementiert. Die operative Dringlichkeit entsteht durch eine steigende Ticket-Last: 5.000 Tickets pro Monat, eine First-Response-Time von 3,2 Stunden und eine Fehlerquote von 8 % bei der manuellen Bearbeitung. Die Compliance-Anforderungen des EU AI Act und des AGG (Allgemeines Gleichbehandlungsgesetz) für die Candidate Screening-Komponente machen eine strukturierte Einführung notwendig.

    Herausforderung: FRT senken und Kosten pro Ticket reduzieren

    Die zentrale Herausforderung war die Reduktion der First-Response-Time (FRT) bei gleichzeitiger Senkung der Kosten pro Support-Ticket. Das bestehende Team von 12 Support-Agents konnte die steigende Ticket-Last nicht bewältigen, ohne die FRT zu verlängern. Die manuelle Bearbeitung führte zu einer Fehlerquote von 8 %, was zu Nacharbeit und unzufriedenen Kunden führte. Zusätzlich bestand der Bedarf, einen KI-Assistenten für die Candidate Screening-Komponente im Recruiting-Prozess einzuführen, der Lebensläufe parst und vorläufige Eignungsbeurteilungen erstellt. Die operative Dringlichkeit wurde durch eine Deadline im Q3 2024 verschärft: Das Unternehmen musste die Compliance-Anforderungen des EU AI Act bis zum August 2026 erfüllen und wollte bereits im Q4 2024 eine messbare Verbesserung der FRT erreichen. Die Personalkosten für den Support lagen bei 45.000 EUR/Monat, und das Management wollte diese um mindestens 20 % senken, ohne die Qualität zu beeinträchtigen.

    Ansatz: n8n-Orchestrierung mit Human-in-the-Loop

    Forfis startete mit einem Prozess-Audit, das die Workflows identifizierte, die sich am besten für die Automatisierung eignen. Der Fokus lag auf zwei Use Cases: 1) Customer-Facing AI Assistant für Ticket-Triage und First-Response, 2) Conversational Agent für die Candidate Screening-Komponente. Die Architektur basiert auf n8n als Orchestrierungsschicht, die Webhooks vom Zendesk-Ticketing-System empfängt, API-Aufrufe an OpenAI (GPT-4o) und Anthropic (Claude 3.5 Sonnet) sendet und die Ergebnisse in das Ticketing-System zurückspielt. Die Integration erfolgt über Custom REST APIs und Webhooks, die sich in das bestehende Salesforce-CRM und SAP-ERP einfügen. Die Delivery-Modelle ist Managed AI Operations: Forfis übernimmt die technische Planung, das Produkt-Design und die Full-Cycle-Entwicklung. Der Pilot läuft über 3 Monate und umfasst eine gemessene Before/After-Baseline auf FRT und Fehlerquote. Die Human-in-the-Loop-Architektur ist Standard: Das Modell erstellt Entwurf oder Klassifizierung, ein Mensch genehmigt alles, was Geld, Gesundheitsdaten oder Verträge betrifft. Für die Candidate Screening-Komponente wird ein Open-Weight-Modell (Llama 3) auf eigener Hardware eingesetzt, da sensible Daten das Gebäude nicht verlassen dürfen.

    Ergebnis: FRT um 91 % gesenkt, Kosten pro Ticket um 66 %

    Nach 3 Monaten Pilotbetrieb zeigte die gemessene Before/After-Baseline eine deutliche Verbesserung. Die First-Response-Time (FRT) sank von 3,2 Stunden auf 22 Minuten, was einer Reduktion von 91 % entspricht. Die Kosten pro Support-Ticket sanken von 18,50 EUR auf 6,20 EUR, was einer Senkung von 66 % entspricht. Die Fehlerquote bei der manuellen Bearbeitung sank von 8 % auf 2,5 %, da der KI-Assistent die Triage und First-Response übernimmt und die menschlichen Agents nur noch bei Eskalationen eingreifen. Die Candidate Screening-Komponente reduzierte die Zeit für die vorläufige Eignungsbeurteilung von 45 Minuten pro Lebenslauf auf 8 Minuten, was einer Senkung von 82 % entspricht. Die Compliance-Anforderungen des EU AI Act und des AGG wurden erfüllt: Die KI-Systeme sind dokumentiert, die Transparenz gegenüber Nutzern ist gewährleistet, und die menschliche Aufsicht bei finalen Entscheidungen ist fest verankert. Das Management ist mit den Ergebnissen zufrieden und plant die Skalierung auf weitere Use Cases im Q1 2025.

    Lektionen: Was ähnliche Teams daraus lernen können

    Die wichtigsten Erkenntnisse aus diesem Fall sind: 1) Ein klar definierter Pilot-Umfang mit messbaren Erfolgskriterien (FRT, Fehlerquote, Kosten pro Ticket) ist entscheidend für den Erfolg. 2) Die Integration in bestehende Systeme (CRM, ERP, Ticketing) über Custom REST APIs und Webhooks ist wichtiger als die Einführung neuer Tools. 3) Die Human-in-the-Loop-Architektur ist nicht nur eine Compliance-Erfordernis, sondern auch ein Qualitätsfaktor: Die menschliche Freigabe reduziert die Fehlerquote und erhöht das Vertrauen der Mitarbeiter. 4) Die model-agnostic-Architektur (OpenAI, Anthropic, Open-Weight-Modelle) ermöglicht es, je nach Use Case das passende Modell zu wählen und die Kosten zu optimieren. 5) Die Compliance-Anforderungen des EU AI Act und des AGG müssen von Anfang an in die Architektur einfließen, nicht nachträglich ergänzt werden. Diese Lektionen gelten für alle mittelständischen Unternehmen, die KI im Customer-Facing-Bereich einführen möchten.

  • Checkliste: KI-Piloten zu produktiven Knowledge-Search-Systemen skalieren

    Phase 1: Prozess-Audit und Pilot-Design

    1. Definieren Sie den Pilot-Scope auf ein einzelnes, messbares Szenario. Wählen Sie ein Use Case, das eine klare Vorher-Nachher-Messung erlaubt, z. B. die Suchzeit für Support-Dokumente. Ein isolierter Pilot muss in 4 Wochen einen messbaren Baseline-Wert liefern, um Skalierungsentscheidungen zu stützen.

    2. Dokumentieren Sie die bestehenden manuellen Prozesse im Back-Office. Erfassen Sie, wie viele Stunden pro Woche Senior-Staff für Datenpflege und Dokumentenrecherche aufwenden. Diese Daten bilden die Grundlage für die ROI-Berechnung und die Freigabe durch das Management.

    3. Auditieren Sie die Datenqualität im CRM und im DMS. Identifizieren Sie fehlende Felder, Duplikate und veraltete Einträge, die die KI-Performance beeinträchtigen. Ohne saubere Eingabedaten liefert das Embedding-Modell keine verwertbaren Ergebnisse.

    4. Entscheiden Sie sich für eine model-agnostic Architektur. Planen Sie die Nutzung von OpenAI- oder Anthropic-APIs für die Textgenerierung und Open-Weight-Modelle auf eigener Hardware für die Embedding-Erzeugung. Diese Trennung ermöglicht es, sensible Daten innerhalb des Unternehmens zu halten und gleichzeitig die beste Textqualität zu nutzen.

    Phase 2: Technische Architektur und Datenbereinigung

    1. Implementieren Sie pgvector in Ihrer bestehenden PostgreSQL-Instanz. Laden Sie die Dokumente aus dem DMS und dem CRM in die Datenbank und generieren Sie die Vektoren mit einem Embedding-Modell. pgvector erlaubt es, Vektordaten und strukturierte Metadaten in einer einzigen Datenbank zu verwalten, was die Latenz reduziert und die Transaktionskonsistenz sicherstellt.

    2. Integrieren Sie die Knowledge-Search über eine Custom REST API. Verbinden Sie das Such-Tool mit dem bestehenden Helpdesk und dem CRM, ohne diese Systeme zu ersetzen. Die API sollte Filter für Berechtigungslevel, Abteilung und Dokumenttyp unterstützen, um Compliance-Risiken zu minimieren.

    3. Konfigurieren Sie Webhooks für Echtzeit-Updates. Stellen Sie sicher, dass Änderungen im CRM oder im DMS automatisch die Vektordaten aktualisieren. Ohne diese Synchronisation veraltet die Knowledge-Search innerhalb weniger Wochen und verliert ihre Nützlichkeit.

    4. Implementieren Sie einen Human-in-the-Loop-Prozess für die Datenanreicherung. Die KI schlägt fehlende CRM-Felder vor, aber ein Datenpfleger muss diese Vorschläge manuell freigeben. Dieser Schritt verhindert, dass fehlerhafte KI-Ausgaben die operative Datenbasis verschmutzen und ist besonders wichtig bei sensiblen Daten.

    Phase 3: Pilot-Implementierung und Messung

    1. Messen Sie die Baseline-Metriken vor dem Pilot-Start. Erfassen Sie die durchschnittliche Suchzeit, die Fehlerquote und die Anzahl der manuellen Eingriffe pro Woche. Diese Werte sind der Referenzpunkt für die Erfolgsmessung des KI-Systems.

    2. Führen Sie den Piloten mit einer kleinen, definierten Nutzergruppe durch. Beginnen Sie mit 10 bis 20 Mitarbeitenden aus der Customer-Support-Abteilung. Eine kleine Gruppe ermöglicht es, Feedback schnell zu sammeln und die Modelle anzupassen, bevor ein breiter Rollout erfolgt.

    3. Erfassen Sie die Fehlerquote durch ein Feedback-Widget. Lassen Sie die Nutzer jeden Suchtreffer als „hilfreich“ oder „falsch“ markieren. Diese Daten sind essenziell, um die Embedding-Modelle zu retrainen und die Qualität der Knowledge-Search kontinuierlich zu verbessern.

    4. Validieren Sie die Berechtigungslogik im Pilot. Testen Sie, ob die Knowledge-Search nur Dokumente zurückgibt, auf die der jeweilige Nutzer Zugriff hat. Ein Fehler in der Berechtigungslogik kann zu Compliance-Verstößen gegen die DSGVO und den EU AI Act führen.

    Phase 4: Compliance, Rollout und Managed Operations

    1. Prüfen Sie die Compliance mit dem EU AI Act (VO (EU) 2024/1689). Stellen Sie sicher, dass das System als „minimal risk“ klassifiziert ist und dass keine sensiblen Daten in ungesicherte Modelle fließen. Artikel 4 des Gesetzes verlangt KI-Kompetenz der Mitarbeitenden, die durch Schulungen und klare Nutzungsrichtlinien abgesichert werden muss.

    2. Dokumentieren Sie die Datenfluss-Architektur für den Audit. Erstellen Sie eine detaillierte Map, die zeigt, welche Daten von welchem System in welches Modell fließen und wo sie gespeichert werden. Diese Dokumentation ist für interne und externe Audits erforderlich und erleichtert die Nachvollziehbarkeit der Datenverarbeitung.

    3. Planen Sie den Übergang in den Managed-AI-Operations-Betrieb. Definieren Sie SLAs für Verfügbarkeit (z. B. 99,5 Prozent), Reaktionszeit auf kritische Fehler (z. B. 4 Stunden) und regelmäßiges Re-Training der Modelle. Ein Managed-Betrieb stellt sicher, dass das System auch nach dem Rollout auf dem aktuellen Stand bleibt und die Performance nicht nachlässt.

  • Cloud-LLM vs. On-Premise: Vertragsprüfung in der Medizintechnik

    Definition der Vergleichsoptionen

    Der Vergleich konzentriert sich auf zwei Ansätze zur Automatisierung der Vertragsprüfung und Dokumentenextraktion in der Schweizer Medizintechnik: die Nutzung kommerzieller Cloud-LLMs (Option A) und den Betrieb offener Gewichtsmodelle auf eigener Hardware (Option B). Option A nutzt APIs von Anbietern wie OpenAI oder Anthropic, wobei die Daten über verschlüsselte Kanäle in Rechenzentren in der EU oder der Schweiz verarbeitet werden. Option B setzt auf Modelle wie Llama 3 oder Mistral, die auf dedizierten GPU-Servern im eigenen Rechenzentrum des Kunden laufen. Beide Ansätze integrieren sich in bestehende Systeme wie Confluence oder Notion und folgen einem Human-in-the-Loop-Prinzip, bei dem menschliche Prüfer die Ergebnisse vor der Freigabe validieren. Der Fokus liegt auf der Skalierung über Abteilungen hinweg innerhalb eines Zeitrahmens von sechs Monaten.

    Kriterien für die Bewertung

    Die Bewertung basiert auf acht Kriterien, die für Unternehmen mit 51 bis 200 Mitarbeitern in regulierten Branchen entscheidend sind: Latenzzeit pro Dokument, variable Kosten pro Verarbeitung, Vendor-Lock-in-Risiko, Compliance mit ISO 27001 und Schweizer Datenschutzrecht, Genauigkeit bei der Extraktion juristischer Klauseln, Integrationsaufwand in bestehende CRMs und Helpdesks, Skalierbarkeit bei steigendem Volumen und der Aufwand für das Managed AI Operations. Diese Kriterien spiegeln die spezifischen Anforderungen der Medizintechnik wider, wo Fehler in der Dokumentenverarbeitung direkte Auswirkungen auf die Compliance und die Betriebskosten haben können. Die Kriterien werden quantitativ bewertet, wo möglich, und qualitativ, wo Messwerte nicht direkt verfügbar sind.

    Vergleichstabelle der Optionen

    Kriterium Option A: Cloud-LLM Option B: On-Premise
    Latenzzeit 2-5 Sekunden pro Dokument 8-15 Sekunden pro Dokument
    Variable Kosten 0,02-0,05 CHF pro Token 0,001-0,003 CHF pro Token (nach Amortisation)
    Vendor-Lock-in Hoch (API-Abhängigkeit) Gering (eigene Hardware)
    ISO 27001 Erfordert DPA und Audit des Anbieters Vereinfacht (keine externen Datenflüsse)
    Genauigkeit 92-95% bei juristischen Klauseln 88-92% nach Fine-Tuning
    Integrationsaufwand 4-6 Wochen 8-12 Wochen
    Skalierbarkeit Horizontal über API Durch Hinzufügen von GPUs
    Managed Ops Inklusive im API-Preis Separater Servicevertrag nötig

    Szenario-spezifische Bewertung

    Für die Vertragsprüfung in der Medizintechnik, wo patientenbezogene Daten oder klinische Studienprotokolle verarbeitet werden, gewinnt Option B. Die Daten dürfen das Gebäude nicht verlassen, was die Cloud-Lösung nur dann zulässig macht, wenn eine vollständige Anonymisierung vor der Übertragung erfolgt. Option A ist vorteilhaft, wenn es um die Automatisierung der monatlichen Reporting-Prozesse geht, die keine sensiblen Daten enthalten, und wenn die Latenzzeit unter 5 Sekunden liegen muss. In diesem Szenario überwiegt die geringere Integrationszeit und die höhere Genauigkeit der Cloud-Modelle die Compliance-Vorteile der On-Premise-Lösung. Für die Skalierung über Abteilungen hinweg, wie die Integration in den Support zur Senkung der Kosten pro Ticket, ist Option A flexibler, da Lastspitzen ohne zusätzliche Hardware bewältigt werden können.

    Empfehlung für das Szenario

    Für ein Schweizer Medizintechnik-Unternehmen mit 51 bis 200 Mitarbeitern, das innerhalb von sechs Monaten eine ISO 27001-konforme Lösung für die Vertragsprüfung und Dokumentenextraktion benötigt, ist Option B die empfohlene Wahl. Die physische Datenhaltung im eigenen Rechenzentrum vereinfacht die Audit-Vorbereitung und reduziert das Risiko von Compliance-Verstößen. Die höheren initialen Kosten für die Hardware werden durch die geringeren variablen Kosten bei einem Volumen von über 500 Verträgen pro Monat kompensiert. Option A sollte nur für nicht-sensitive Prozesse wie die Automatisierung der monatlichen Reporting-Prozesse oder die Ticket-Triage im Support eingesetzt werden, wo die Latenzanforderungen und die Skalierbarkeit überwiegen. Ein hybrider Ansatz, der beide Optionen kombiniert, ist oft die wirtschaftlich sinnvollste Lösung.

  • KI-Automatisierung in der Schweizer B2B-SaaS: Fallbeispiel

    Hintergrund: SwissSaaS und die Herausforderung der Skalierung

    Dieser Fall ist eine Komposition aus Mustern, die in der Praxis beobachtet wurden. Wir benennen keine echten Kunden, um deren Vertraulichkeit zu wahren. Die beschriebene Firma, nennen wir sie ‘SwissSaaS’, ist ein typisches Beispiel für den Mittelstand in der Schweiz: 30 Mitarbeiter, Fokus auf B2B-SaaS, ISO 27001 zertifiziert. Das Unternehmen befindet sich in der Phase ‘Running Isolated Pilots’, was bedeutet, dass erste KI-Experimente stattgefunden haben, aber noch keine systemische Integration in den Kernprozessen erfolgt ist. Die IT-Infrastruktur besteht aus einem modernen Stack mit Confluence als Wissensbasis, einem CRM für die Sales-Pipeline und einer eigenen Cloud-Infrastruktur. Die Herausforderung war nicht die Technologie, sondern die operative Umsetzung: Wie lässt sich die manuelle Arbeit im Marketing und im Sales-Backoffice reduzieren, ohne die Compliance-Vorgaben zu verletzen?

    Die operative Klemme: Berichte und Leads im Zeitdruck

    Die monatliche Berichterstattung an Investoren und interne Stakeholder war ein Flaschenhals. Drei Marketing-Mitarbeiter verbrachten jeweils zwei bis drei Tage damit, Daten aus Confluence, dem CRM und den Analytics-Tools zu sammeln, zu interpretieren und in einen konsistenten Bericht zu fassen. Gleichzeitig stieg das Volumen an Leads durch die wachsende Bekanntheit im DACH-Raum. Die manuelle Qualifizierung dieser Leads führte zu Verzögerungen von bis zu 48 Stunden, was die Conversion-Rate negativ beeinflusste. Der Druck kam von zwei Seiten: Die Investoren verlangten schnellere, transparentere Reports, und das Sales-Team brauchte priorisierte Leads, um ihre Quote zu halten. Die ISO 27001-Zertifizierung stellte zusätzliche Anforderungen an die Datenverarbeitung, da keine sensiblen Kundendaten unbefugt an externe Dienstleister weitergegeben werden durften.

    Der Ansatz: Dediziertes Team und model-agnostische Architektur

    Forfis wurde als dediziertes AI-Team engagiert, um die Lücke zwischen den isolierten Piloten und einem produktiven System zu schließen. Der Ansatz war zweigleisig: Erstens die Automatisierung der monatlichen Berichte durch einen RAG-Workflow, der Confluence-Dokumente liest und mit der OpenAI API eine erste Fassung des Reports erstellt. Zweitens die Implementierung eines konversationellen Agents für die Lead-Qualifizierung, der neue Anfragen klassifiziert und priorisiert. Die Architektur war bewusst model-agnostisch gehalten, wobei die OpenAI API für die semantische Analyse und Textgenerierung genutzt wurde, da die Qualität der deutschen Sprache und die Kontextlänge entscheidend waren. Die Integration in Confluence und das CRM erfolgte über bestehende APIs, ohne dass die Kernsysteme ersetzt werden mussten. Das Team arbeitete in zweiwöchigen Sprints, mit klaren Meilensteinen für den Pilotbetrieb.

    Ergebnisse: Messbare Effizienzgewinne in sechs Monaten

    Nach sechs Monaten war das System produktiv. Die Erstellung der monatlichen Berichte dauerte von drei Tagen auf vier Stunden. Die Mitarbeiter nutzten diese Zeit für die strategische Analyse und die Kommunikation mit den Stakeholdern, statt für das Zusammenfassen von Daten. Die Lead-Qualifizierung erfolgte innerhalb von 15 Minuten statt 48 Stunden. Die Conversion-Rate der qualifizierten Leads stieg um 12 Prozent, da die Sales-Teams schneller und gezielter ansprechen konnten. Die Fehlerquote in den Berichten sank von 8 Prozent auf unter 2 Prozent, da das System konsistentere Formate erzeugte und die manuelle Prüfung sich auf die inhaltliche Plausibilität konzentrieren konnte. Die ISO 27001-Audits bestanden die neuen Prozesse ohne Beanstandungen, da die Datenflüsse dokumentiert und die API-Zugriffe kontrolliert waren.

    Lektionen für ähnliche Teams

    Erstens: Starte mit einem klar definierten Use Case, der einen messbaren Schmerzpunkt adressiert. Die monatliche Berichterstattung war ideal, weil der Output klar definiert war und der Erfolg leicht messbar. Zweitens: Investiere in die Datenqualität der Quelldokumente. Wenn die Confluence-Seiten nicht aktuell sind, ist der beste LLM nutzlos. Drittens: Behalte den Human-in-the-Loop. Die manuelle Freigabe ist kein Mangel, sondern ein Sicherheitsmechanismus, der das Vertrauen im Team aufbaut. Viertens: Dokumentiere die Datenflüsse für die Compliance. Bei ISO 27001 ist die Nachvollziehbarkeit der Datenverarbeitung entscheidend. Fünftens: Plane die Wartung ein. Ein dediziertes Team ist nicht nur für die Implementierung, sondern auch für den laufenden Betrieb und die Anpassung an sich ändernde Prozesse notwendig.

  • On-Premise vs. Cloud-KI für Ticket-Triage in Schweizer Kanzleien

    Definition der beiden Optionen

    Der Vergleich bezieht sich auf zwei technische Ansätze zur Automatisierung der Ticket-Triage und des monatlichen Reportings in einer Schweizer Kanzlei mit 800 Mitarbeitenden. Option A nutzt kommerzielle Cloud-APIs von OpenAI oder Anthropic, die über HTTPS abgerufen werden. Option B setzt auf Open-Weight-Modelle wie Llama-3 oder Mistral, die auf eigener Hardware im Rechenzentrum der Kanzlei laufen. Beide Ansätze integrieren sich über REST-APIs in Notion und Confluence und folgen dem Prinzip der menschlichen Freigabe. Der entscheidende Unterschied liegt in der Datenhoheit und der Latenz: Bei Option A verlassen die Daten das Gebäude, bei Option B bleiben sie lokal. Für eine Kanzlei, die mit sensiblen Mandatsdaten arbeitet und dem EU AI Act unterliegt, ist diese Unterscheidung nicht nur technisch, sondern regulatorisch relevant.

    Kriterien für die Bewertung

    • Latenz: Zeit von der Anfrage bis zur Antwort, gemessen in Millisekunden.
    • Kostenstruktur: Fixkosten (Hardware, Lizenzen) versus variable Kosten (Token-Abrechnung).
    • Datenhoheit: Ort der Datenverarbeitung und Zugriffsmöglichkeiten Dritter.
    • Compliance: Erfüllung der Pflichten nach EU AI Act und DSGVO.
    • Skalierbarkeit: Verhalten bei Spitzenlasten (z. B. Monatsende-Reporting).
    • Wartungsaufwand: Aufwand für Updates, Monitoring und Fehlerbehebung.
    • Integrationstiefe: Qualität der Anbindung an Notion und Confluence.
    • Qualität der Ausgabe: Genauigkeit der Klassifikation und Vollständigkeit der Report-Entwürfe.

    Vergleichstabelle

    Kriterium Option A: Cloud-APIs Option B: On-Premise
    Latenz 300–800 ms (inkl. Netzwerk) 100–200 ms (lokal)
    Kosten 0,002–0,03 CHF/Token, variabel 15.000–30.000 CHF einmalig, 500–1.000 CHF/Monat
    Datenhoheit Daten verlassen das Gebäude Daten bleiben im Rechenzentrum
    Compliance Erfordert Datenverarbeitungsvertrag (DPA) Kein DPA nötig, volle Kontrolle
    Skalierbarkeit Automatisch durch Cloud-Anbieter Begrenzt durch lokale GPU-Ressourcen
    Wartung Keine eigene Hardware-Wartung Eigenes Monitoring, Updates manuell
    Integration Standard-REST-APIs Standard-REST-APIs, lokale Endpunkte
    Qualität Sehr hoch bei komplexen Aufgaben Hoch bei Klassifikation, mittelmäßig bei kreativen Texten

    Szenario-spezifisches Verdikt

    Option A gewinnt, wenn die Kanzlei keine eigene IT-Infrastruktur für KI betreiben möchte und die Ticketmengen gering sind (unter 50 pro Tag). In diesem Fall sind die variablen Kosten überschaubar, und die Wartung entfällt. Option B gewinnt, wenn die Datenhoheit eine harte Anforderung ist, wie es bei Mandatsdaten in der Schweiz üblich ist. Zudem ist Option B bei hoher Auslastung (über 100 Tickets pro Tag) kostengünstiger, da die Token-Kosten der Cloud-Lösung exponentiell steigen. Für das monatliche Reporting, das große Datenmengen verarbeitet, ist Option B stabiler, da es keine Drosselung durch den Cloud-Anbieter gibt. In der Praxis wird Option B für die Kernprozesse (Triage, Reporting) und Option A für sporadische, komplexe Anfragen empfohlen.

    Empfehlung

    Für die Schweizer Kanzlei mit 800 Mitarbeitenden, die Ticket-Triage und monatliches Reporting automatisieren möchte, ist Option B (On-Premise) die empfohlene Lösung. Die Gründe: Erstens bleibt die Datenhoheit vollständig beim Unternehmen, was die Compliance mit dem EU AI Act und der DSGVO vereinfacht. Zweitens ist die Latenz niedriger, was die Benutzererfahrung verbessert. Drittens sind die Kosten bei der erwarteten Auslastung (ca. 200 Tickets pro Tag) nach 18 Monaten niedriger als bei Cloud-APIs. Der vierwöchige Pilot sollte mit Option B starten, um die Infrastruktur zu validieren. Ein Audit vor dem Piloten ist essenziell, um die genaue Ticketmengen und die Integration in Notion/Confluence zu planen. Die menschliche Freigabe bleibt in beiden Optionen bestehen, da sie eine regulatorische Anforderung ist.

  • Schweizer E-Commerce-Firma automatisiert Status-Updates in 8 Wochen

    Hintergrund: Schweizer E-Commerce-Firma ohne KI in der Produktion

    Dieser Fall ist ein Composite aus Mustern, die Forfis in der Praxis beobachtet hat. Es werden keine realen Kundennamen genannt. Die beschriebene Firma ist fiktiv, aber plausibel: eine Schweizer E-Commerce-Firma mit 120 Mitarbeitern, die über Shopify und ein eigenes ERP-System (Odoo) verkauft. Der Umsatz liegt bei ca. 18 Mio. CHF jährlich, der Fokus liegt auf B2B-Großkunden und B2C-Kleinaufträgen. Die IT-Infrastruktur ist hybrid: Cloud-Hosting für den Shop, On-Premise-Server für das ERP. Bisher gab es keine KI in der Produktion. Der Support bestand aus vier festen Mitarbeitern, die per E-Mail und Telefon Anfragen bearbeiteten. Die monatliche Reporting-Last war hoch: 14 Tage pro Monat für die manuelle Zusammenstellung von Status-Updates, Fehlerquoten und Eskalationen. Die Compliance-Anforderungen waren klar: PCI DSS für alle Zahlungsdaten, DSGVO für personenbezogene Daten. Die Deadline für die Einführung war der 1. März, um die Q1-Reporting-Zyklen zu entlasten.

    Herausforderung: Manuelle Status-Updates und Reporting-Last

    Der Hauptbedarf war die Automatisierung der monatlichen Reporting-Prozesse und die Beschleunigung der Dokumentenbearbeitung. Konkret: Kunden fragten per E-Mail nach dem Status ihrer Bestellungen, und der Support musste manuell im ERP nachschauen, die Antwort formulieren und senden. Das dauerte im Durchschnitt 4,2 Stunden pro Monat pro Mitarbeiter. Zusätzlich mussten monatliche Reports über Fehlerquoten, Lieferverzögerungen und Eskalationen manuell aus Excel-Tabellen zusammengetragen werden. Der operative Druck kam von drei Seiten: Erstens, die Q1-Reporting-Deadline stand bevor. Zweitens, die Compliance-Abteilung verlangte eine dokumentierte, nachvollziehbare Prozesskette für alle Datenzugriffe. Drittens, der Headcount war begrenzt: Vier Support-Mitarbeiter konnten die wachsende Anfragezahl nicht mehr abdecken, ohne dass die Reaktionszeit über 24 Stunden stieg. Die Geschäftsführung wollte eine Lösung, die das bestehende ERP nicht ersetzt, sondern ergänzt.

    Ansatz: AI Automation Audit und Pilot mit LangChain

    Forfis startete mit einem AI Automation Audit über zwei Wochen. Ziel: Identifikation der Workflows, die sich für die Automatisierung eignen, und Prüfung der Compliance-Anforderungen. Das Ergebnis: Der Status-Update-Prozess war der beste Kandidat für einen Piloten, weil er klar definiert, wiederholbar und datenschutzkonform umsetzbar war. Die Tech-Stack-Entscheidung fiel auf LangChain und LangGraph. LangChain diente als Orchestrierungsschicht, die die Kommunikation zwischen LLM, Tools und Datenquellen steuerte. LangGraph wurde für die Zustandsmaschine verwendet, die den Agenten durch die Phasen „Anfrage empfangen“, „ERP-Daten abfragen“, „Antwort formulieren“ und „Mensch einbinden“ führte. Die Integration erfolgte über die Odoo-API für die Bestelldaten und über die Confluence-API für die internen Prozessdokumente. Der Agent wurde so konfiguriert, dass er nur Statusinformationen liefert und keine Zahlungsdaten verarbeitet, um PCI DSS-Konformität zu gewährleisten. Die Entwicklung des Piloten dauerte vier Wochen, die Integration und Schulung zwei Wochen.

    Ergebnis: Messbare Reduktion der Bearbeitungszeit

    Nach acht Wochen war der Pilot live. Die Ergebnisse waren messbar: Die durchschnittliche Bearbeitungszeit für Status-Anfragen sank von 4,2 Stunden auf 0,8 Stunden pro Monat pro Mitarbeiter. Die Fehlerquote bei der manuellen Datenübernahme reduzierte sich von 3,1 % auf 0,4 %. Die monatliche Reporting-Zusammenstellung, die zuvor 14 Tage dauerte, war in 3 Tagen erledigt, weil der Agent die Rohdaten automatisch aus dem ERP extrahierte und in ein standardisiertes Format überführte. Die Kundenzufriedenheit stieg, weil die Reaktionszeit von über 24 Stunden auf unter 4 Stunden sank. Die Compliance-Abteilung bestätigte, dass die Prozesskette dokumentiert und nachvollziehbar war. Der Agent lief parallel zum bestehenden Betrieb, nicht als Ersatz. Das ERP blieb die Single Source of Truth. Der Agent las nur, er schrieb nicht. Das reduzierte das Risiko von Dateninkonsistenzen und machte die Rollback-Strategie trivial: Agent abschalten, System läuft weiter wie vorher.

    Lektionen für ähnliche Teams

    Drei Lektionen lassen sich daraus ableiten. Erstens: Der Audit ist nicht optional. Ohne die zweiwöchige Vorarbeit wäre die Tech-Stack-Entscheidung willkürlich gewesen, und die Compliance-Anforderungen wären erst in der Entwicklungsphase aufgefallen. Zweitens: LangGraph ist für komplexe Workflows mit Verzweigungen und Schleifen die richtige Wahl, nicht für einfache API-Aufruf-Ketten. Die Zustandsmaschine hat die Fallback-Logik (z. B. „ERP nicht erreichbar“) sauber abgebildet. Drittens: Die Integration über Confluence als Wissensbasis für interne Prozesse hat die Akzeptanz im Team erhöht, weil die Mitarbeiter die Regeln nachvollziehen konnten. Der Agent war nicht eine Blackbox, sondern ein transparentes Tool, das auf dokumentierte Prozesse zugriff. Viertens: Die Human-in-the-Loop-Strategie war entscheidend. Alles, was über den Standard-Status hinausging, wurde automatisch an einen Support-Mitarbeiter weitergeleitet. Das reduzierte das Risiko von Fehleinschätzungen und hielt die Compliance-Abteilung zufrieden. Fünftens: Die 8-Wochen-Timeline war realistisch, weil der Pilot parallel zum bestehenden Betrieb lief und nicht als Ersatz diente.