Forfis Blog

Author: Forfis

  • KI-Agenten in HR und Compliance: 15-Schritte-Checkliste für Medtech

    Checkliste: 15 Schritte für den 4-Wochen-Rollout

    1. Definieren Sie den Scope des Piloten. Beschränken Sie sich auf einen einzigen Workflow, z. B. die Sichtung von Bewerbungen oder die erste Antwort auf Patienten-Anfragen. Ein klarer Scope verhindert, dass das Projekt in der 4-Wochen-Frist scheitert.

    2. Auditieren Sie den aktuellen Prozess. Messen Sie die aktuelle First-Response-Time und die Fehlerquote bei der Datenerfassung. Diese Baseline ist der Maßstab für den Erfolg des Piloten.

    3. Wählen Sie die Integrationsplattform. Entscheiden Sie, ob der Agent in Slack oder Microsoft Teams läuft. Beide Plattformen bieten stabile APIs für Bot-Integrationen.

    4. Konfigurieren Sie die Datenflussanalyse. Dokumentieren Sie, welche Daten in die OpenAI-API wandern und welche lokal verarbeitet werden. ISO 27001 Anhang A.8.32 verlangt diese Nachvollziehbarkeit.

    5. Implementieren Sie die Pseudonymisierung. Entfernen Sie alle direkt identifizierenden Daten (Name, E-Mail, Telefon) vor der Verarbeitung durch das LLM. So schützen Sie die Bewerberdaten gemäß DSGVO.

    6. Entwickeln Sie die Prompts für die Klassifizierung. Definieren Sie, welche Kriterien ein Kandidat erfüllen muss, um weitergeleitet zu werden. Klare Regeln reduzieren die Fehlerquote bei der Sichtung.

    7. Integrieren Sie den Agenten in das bestehende CRM. Verknüpfen Sie den Agenten mit Ihrem HR-System oder ERP, um doppelte Dateneingaben zu vermeiden. Die Integration erfolgt über die offiziellen APIs.

    8. Richten Sie die Eskalationspfade ein. Definieren Sie, welche Anfragen sofort an einen Menschen weitergeleitet werden müssen. Bei medizinischen Details oder Vertragsfragen ist die menschliche Freigabe zwingend.

    9. Testen Sie den Agenten mit 10 % des Traffics. Lassen Sie den Agenten nur einen Teil der Anfragen bearbeiten, um die Qualität zu prüfen. So minimieren Sie das Risiko bei der Einführung.

    10. Validieren Sie die Metriken. Vergleichen Sie die First-Response-Time und die Fehlerquote vor und nach der Einführung. Die Zielwerte müssen vor dem Rollout festgelegt sein.

    11. Dokumentieren Sie die menschliche Kontrolle. Protokollieren Sie, wer die Freigabe erteilt und wie die Entscheidungen nachvollziehbar sind. Dies ist ein Kernanforderung für das ISO-27001-Audit.

    12. Schulen Sie das Team. Erklären Sie den Mitarbeitern, wie der Agent funktioniert und wann sie eingreifen müssen. Akzeptanz im Team ist entscheidend für den Erfolg.

    13. Planen Sie den Rollout auf weitere Abteilungen. Übertragen Sie die Architektur auf andere Workflows, z. B. die Patienten-Triage. Die standardisierten Prompts und Datenmodelle erleichtern die Skalierung.

    14. Überwachen Sie die Antwortqualität. Prüfen Sie regelmäßig, ob der Agent noch korrekt klassifiziert und antwortet. Modelle können durch Drift an Qualität verlieren.

    15. Optimieren Sie die Prompts kontinuierlich. Passen Sie die Regeln an, wenn sich die Anforderungen ändern. Managed AI Operations umfasst diese laufende Optimierung.

    Architektur: Conversational Agent in Slack und Teams

    Die Einführung eines Conversational Agenten in der Personalabteilung und im Compliance-Bereich erfordert eine enge Abstimmung zwischen Technik und Recht. Der Agent wird in Slack oder Microsoft Teams eingebunden und übernimmt die erste Reaktion auf eingehende Anfragen. Bei der Kandidatensichtung extrahiert er strukturierte Daten aus den CVs und berechnet einen Match-Score. Nur qualifizierte Kandidaten werden an die HR-Verantwortlichen weitergeleitet. Die First-Response-Time sinkt dadurch von Stunden auf Minuten. Gleichzeitig muss der Agent bei medizinischen Details oder Vertragsfragen sofort eskalieren. Die menschliche Freigabe ist bei Forfis standardmäßig aktiviert, sobald Geld, Gesundheit oder Verträge im Spiel sind. Diese Architektur erfüllt die Anforderungen von ISO 27001, da die Datenflussanalyse und die menschliche Kontrolle dokumentiert sind.

    Compliance: ISO 27001 und DSGVO im Medtech-Umfeld

    ISO 27001 verlangt in Anhang A.8.32, dass KI-Systeme kontrolliert werden. Für die Kandidatensichtung bedeutet das: Sie müssen dokumentieren, welche Daten in den OpenAI-Context wandern, wie Pseudonymisierung erfolgt und wer die Freigabe erteilt. Ein reines „Wir nutzen KI“ reicht nicht; der Betriebsplan muss die menschliche Kontrolle nachweisen. Die OpenAI-API sendet Daten in die USA. Für sensible Gesundheitsdaten oder unanonymisierte Bewerberdaten in Österreich ist das ohne Auftragsverarbeitungsvertrag (AVV) und Datenflussanalyse riskant. Forfis setzt daher auf Open-Weight-Modelle auf eigener Hardware, wenn Daten das Gebäude nicht verlassen dürfen, und nutzt OpenAI nur für nicht-sensitive Triage-Schritte. Diese Hybrid-Architektur ermöglicht es, die Vorteile der OpenAI-API zu nutzen, ohne die Compliance zu gefährden.

    Skalierung: Von HR auf andere Abteilungen

    Die Skalierung gelingt durch standardisierte Prompts und gemeinsame Datenmodelle. Wenn der Screening-Agent im HR-Bereich funktioniert, lässt sich dieselbe Architektur auf die Patienten-Triage im medizinischen Bereich übertragen. Wichtig ist, dass die Compliance-Regeln (z. B. DSGVO, ISO 27001) in der Konfiguration zentral verwaltet werden, nicht in jedem einzelnen Prompt. Der Agent wird in Slack oder Microsoft Teams eingebunden. Er überwacht eingehende Nachrichten, extrahiert strukturierte Daten (Name, Erfahrung, Verfügbarkeit) und erstellt einen Ticket-Eintrag im bestehenden CRM oder HR-System. Die Integration erfolgt über die offiziellen APIs der jeweiligen Plattform, ohne dass bestehende Tools ersetzt werden müssen. So bleibt die bestehende Infrastruktur erhalten, während die KI-Ebene dazukommt.

    Betrieb: Managed AI Operations und Kosten

    Managed AI Operations bedeutet, dass der Dienstleister nicht nur die Software liefert, sondern auch den Betrieb übernimmt: Modell-Updates, Prompt-Optimierung, Monitoring der Antwortqualität und Anpassung an neue Compliance-Vorgaben. Für Teams mit 11 bis 50 Mitarbeitern ist das wirtschaftlicher als eine eigene KI-DevOps-Position. Die Kosten setzen sich aus der Lizenz für die Managed-Operations, der API-Nutzung (OpenAI oder lokale Inferenz) und der Integrationsarbeit zusammen. Bei 11 bis 50 Mitarbeitern liegt der monatliche Aufwand typischerweise unter dem Gehalt einer halben HR-Kraft, die manuell sichtet. Die Einsparung entsteht durch die Reduktion der First-Response-Time und die Eliminierung manueller Dateneingaben. Die 4-Wochen-Frist ist realistisch, wenn der Scope auf einen einzigen Workflow beschränkt bleibt. Erweiterungen auf weitere Abteilungen erfordern zusätzliche Sprints.

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

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

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

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