Forfis Blog

Blog

  • LLM-Integration vs. isolierter Pilot: RAG-Assistent für B2B-SaaS-Support

    Definition der beiden Optionen

    Die Entscheidung zwischen der direkten Integration von LLMs in bestehende ERP- und CRM-Systeme und dem Aufbau eines isolierten Piloten mit separater Datenhaltung ist für B2B-SaaS-Unternehmen mit über 2.000 Mitarbeitern in Deutschland entscheidend. Beide Ansätze zielen auf die Automatisierung von Customer-Support-Aufgaben ab, insbesondere die Beantwortung von Bestellauftrags- und Versandstatus-Updates. Die Integration nutzt die vorhandene Infrastruktur und Custom REST APIs, während der isolierte Pilot eine geschützte Umgebung für die Validierung der pgvector-Embeddings und des Retrieval-Augmented Generation (RAG) Ansatzes schafft. Der entscheidende Unterschied liegt in der Datenkonsistenz und der Skalierbarkeit: Die Integration bietet Echtzeit-Zugriff auf Bestandsdaten, der isolierte Pilot ermöglicht eine kontrollierte Testphase ohne Risiko für die Produktionssysteme. Für Unternehmen, die ihre Support-Operationen skalieren wollen, ohne neue Mitarbeiter einzustellen, ist die Wahl der Architektur der Schlüssel zur Entlastung der Senior-Staff von Routinearbeit.

    Kriterien für die Bewertung

    Die Bewertung der beiden Ansätze erfolgt anhand von acht Kriterien, die für die Skalierung von Support-Operationen in einem B2B-SaaS-Umfeld relevant sind. Erstens die Latenz der Antwortgenerierung, die durch die Vektor-Suche in pgvector und die API-Aufrufe bestimmt wird. Zweitens die Kostenstruktur, bestehend aus LLM-API-Gebühren, Infrastrukturkosten für die Vektor-Datenbank und Personalkosten des dedizierten AI-Teams. Drittens das Vendor-Lock-in-Risiko, insbesondere bei der Nutzung spezifischer LLM-Anbieter oder Vektor-Datenbank-Lösungen. Viertens die Compliance-Anforderungen, die in Deutschland durch die DSGVO und branchenspezifische Regularien geprägt sind. Fünftens die Datenkonsistenz, also wie aktuell die Statusinformationen im RAG-System sind. Sechstens die Skalierbarkeit auf eine wachsende Kundenbasis ohne lineares Personalwachstum. Siebtens die Integrationstiefe in bestehende Workflows und Achttens die Zeit bis zur messbaren Entlastung der Senior-Staff. Diese Kriterien bilden die Grundlage für die folgende quantitative Gegenüberstellung.

    Quantitative Gegenüberstellung

    Kriterium Integration in bestehende Systeme Isolierte Pilotumgebung
    Latenz 300-500 ms (API + Vektor-Suche) 200-300 ms (lokale Daten)
    Kosten (Monat) 4.500-6.000 EUR (API + Hosting) 2.000-3.000 EUR (nur Pilot)
    Vendor-Lock-in Mittel (API-Abhängigkeit) Gering (flexible Architektur)
    Compliance Hoch (DSGVO-konform, EU-Hosting) Mittel (Datenkopien nötig)
    Datenkonsistenz Echtzeit (Webhooks) Verzögert (manuelle Synchronisation)
    Skalierbarkeit Hoch (nutzt bestehende Infrastruktur) Gering (separate Skalierung nötig)
    Integrationstiefe Tief (REST + Webhooks) Shallow (API-Proxy)
    Zeit bis Entlastung 4-6 Monate 2-3 Monate (aber begrenzt)

    Szenario-spezifisches Verdikt

    Die Integration in bestehende Systeme gewinnt, wenn der Use Case Echtzeit-Daten erfordert, wie es bei Bestellauftrags- und Versandstatus-Updates der Fall ist. Die Nutzung von Custom REST APIs und Webhooks stellt sicher, dass der RAG-Assistent immer mit den aktuellsten Bestands- und Logistikdaten arbeitet. Für ein Unternehmen mit 2.000+ Mitarbeitern, das seine Support-Operationen skalieren will, ohne neue Mitarbeiter einzustellen, ist diese Datenkonsistenz entscheidend, um die Fehlerquote zu minimieren und die Senior-Staff von manuellen Abfragen zu befreien. Der isolierte Pilot ist dagegen die bessere Wahl in der frühen Phase der AI-Maturity, wenn das Unternehmen die Wirksamkeit der pgvector-Embeddings und des RAG-Ansatzes validieren will, ohne die Produktionssysteme zu belasten. Er eignet sich für die Testphase, in der Prompts optimiert und die Vektor-Indizes kalibriert werden, bevor die volle Integration erfolgt. In der Praxis kombinieren erfolgreiche Implementierungen beide Ansätze: Der Pilot validiert die Technologie, die Integration skaliert sie auf die gesamte Kundenbasis.

    Empfehlung für die Implementierung

    Für ein B2B-SaaS-Unternehmen in Deutschland mit über 2.000 Mitarbeitern, das seine Customer-Support-Operationen skalieren will, ohne neue Mitarbeiter einzustellen, ist die Integration in bestehende Systeme die empfohlene Strategie. Der Use Case der Bestellauftrags- und Versandstatus-Updates erfordert Echtzeit-Zugriff auf ERP-Daten, den nur die direkte Anbindung über REST APIs und Webhooks bietet. Der isolierte Pilot ist als Testphase sinnvoll, sollte aber nicht als Endzustand betrachtet werden, da er die Datenkonsistenz beeinträchtigt und die Skalierbarkeit begrenzt. Ein dediziertes AI-Team sollte die Implementierung in sechs Monaten umsetzen, beginnend mit der Prozessanalyse und API-Anbindung, gefolgt vom Aufbau des RAG-Systems mit pgvector und dem Pilotbetrieb. Die Entlastung der Senior-Staff von Routinearbeit wird durch die Automatisierung der ersten Antwortebene erreicht, während das Team die Infrastruktur überwacht und optimiert. Diese Strategie ermöglicht die Skalierung der Support-Kapazität ohne lineares Personalwachstum und hält die Betriebskosten im Rahmen.

  • Ticket-Triage im Schweizer Fintech: Cloud-LLM versus On-Premise-Modell

    Zwei Ansätze für die Ticket-Triage im Schweizer Fintech

    Ein Schweizer Fintech mit 120 Mitarbeitenden steht vor zwei Optionen, um die Ticket-Triage im Back-Office zu automatisieren: ein Cloud-LLM wie GPT-4o oder Claude 3.5 Sonnet über die API des Anbieters, oder ein Open-Weight-Modell wie Llama 3 70B oder Mistral Large, das auf eigener Hardware im Rechenzentrum läuft. Beide Ansätze lösen dasselbe Problem: Support-Tickets aus dem Zahlungsverkehr, der Compliance und dem Back-Office werden automatisch klassifiziert, priorisiert und an die richtige Fachabteilung geroutet. Der entscheidende Unterschied liegt nicht in der Modellqualität, sondern in der Datenhoheit, den Betriebskosten und der Skalierbarkeit über mehrere Abteilungen hinweg. Für ein Unternehmen, das ISO 27001 zertifiziert ist und Kundendaten nicht an Dritte übermitteln darf, fällt die Entscheidung zugunsten des On-Premise-Ansatzes aus, auch wenn dieser höhere Initialkosten und mehr Betriebskomplexität mit sich bringt.

    Acht Kriterien für die Entscheidung

    Die Bewertung stützt sich auf acht Kriterien, die für den konkreten Use Case relevant sind: Latenz pro Ticket, Betriebskosten pro 1 000 Tickets, Vendor-Lock-in, ISO 27001-Konformität, Skalierbarkeit über Abteilungen, Integrationsaufwand in bestehende Helpdesk-Systeme, Fehlerquote bei der Klassifikation und Verfügbarkeit des Modells bei Ausfällen. Die Latenz misst die Zeit von der Ticket-Eingabe bis zur Rückgabe der Klassifikation. Die Betriebskosten umfassen API-Gebühren oder Strom, Kühlung und Wartung der Hardware. Der Vendor-Lock-in beschreibt, wie stark das Unternehmen an einen bestimmten Anbieter gebunden ist. Die ISO 27001-Konformität prüft, ob die Datenverarbeitung den Anforderungen der Norm entspricht, insbesondere bei der Verarbeitung von Kundendaten im Zahlungsverkehr. Die Skalierbarkeit bewertet, wie aufwendig es ist, das System von einem Fachbereich auf drei oder vier Abteilungen auszuweiten.

    Vergleichstabelle: Cloud-LLM versus On-Premise

    Kriterium Cloud-LLM (GPT-4o / Claude 3.5) On-Premise (Llama 3 70B / Mistral Large)
    Latenz pro Ticket 800-1 200 ms 1 500-2 500 ms
    Betriebskosten pro 1 000 Tickets 15-30 CHF 5-12 CHF (nach Amortisation)
    Initialinvestition 0 CHF 40 000-80 000 CHF
    Vendor-Lock-in Hoch (API-Änderungen, Preisanpassungen) Gering (Modell-Dateien lokal)
    ISO 27001-Konformität Erfordert DPA und Datenflussanalyse Vollständig kontrollierbar
    Skalierbarkeit über Abteilungen Linear mit API-Volumen Erfordert Hardware-Erweiterung
    Integrationsaufwand Gering (REST-API) Mittel (lokale API + Vektordatenbank)
    Fehlerquote Klassifikation 4-7 % 6-9 %
    Verfügbarkeit bei Ausfall Abhängig vom Anbieter Abhängig von eigener Infrastruktur

    Die Zahlen basieren auf typischen Werten aus Pilotprojekten im Schweizer Fintech-Umfeld. Die Latenz des On-Premise-Ansatzes ist höher, weil die Inferenz auf eigener Hardware erfolgt und keine optimierten Cloud-Cluster genutzt werden. Die Betriebskosten sinken nach der Amortisation der Hardware deutlich, da keine pro Token abgerechneten Gebühren anfallen. Die Fehlerquote ist beim On-Premise-Modell leicht höher, weil die Modelle in der Regel kleiner sind als die proprietären Cloud-Modelle und weniger Fine-Tuning-Daten erhalten haben.

    Wann Cloud-LLMs die bessere Wahl sind

    Der Cloud-Ansatz gewinnt, wenn das Unternehmen keine strengen Datenschutzanforderungen hat, die Latenz unter 1 000 ms kritisch ist und der Betrieb schnell starten soll, ohne eigene Hardware zu beschaffen. Für ein Fintech, das nur allgemeine Support-Tickets ohne Kundendaten verarbeitet, ist GPT-4o über die API eine pragmatische Wahl: Die Integration dauert zwei bis drei Wochen, die Fehlerquote liegt bei 4 bis 7 Prozent, und die Kosten sind pro Ticket kalkulierbar. Der On-Premise-Ansatz gewinnt, wenn Kundendaten, Transaktionshistorien oder Compliance-Dokumente verarbeitet werden müssen, die das Gebäude nicht verlassen dürfen. In diesem Fall ist die höhere Latenz von 1 500 bis 2 500 ms akzeptabel, weil die Triage nicht in Echtzeit erfolgen muss, sondern innerhalb von 30 bis 60 Sekunden. Die höhere Fehlerquote von 6 bis 9 Prozent lässt sich durch eine mehrstufige Pipeline mit menschlicher Freigabe für kritische Tickets kompensieren.

    Skalierung über Abteilungen und Integrationsaufwand

    Die Skalierung über Abteilungen ist der entscheidende Faktor für Unternehmen mit 51 bis 200 Mitarbeitenden, die in drei bis vier Monaten von einem Piloten auf den Regelbetrieb übergehen wollen. Der Cloud-Ansatz skaliert linear: Jede zusätzliche Abteilung erhöht das API-Volumen und damit die Kosten, aber die Infrastruktur bleibt unverändert. Der On-Premise-Ansatz erfordert eine Hardware-Erweiterung, wenn die Ticket-Volumen über die Kapazität der bestehenden GPU-Instanz hinauswachsen. In der Praxis bedeutet das: Für zwei Abteilungen genügt eine NVIDIA A100 80GB, für vier Abteilungen sind zwei Instanzen oder eine A100 40GB mit optimierter Batch-Verarbeitung nötig. Die Kosten für die zusätzliche Hardware liegen bei 20 000 bis 40 000 CHF, was in der Regel innerhalb von sechs bis neun Monaten durch die eingesparten API-Gebühren amortisiert ist. Die Integration in bestehende Helpdesk-Systeme erfolgt in beiden Fällen über REST-APIs und Webhooks, der Aufwand ist beim On-Premise-Ansatz um zwei bis drei Wochen höher, weil die lokale Vektordatenbank für die RAG-Komponente eingerichtet und die API-Endpunkte im internen Netzwerk abgesichert werden müssen.

    Empfehlung für den konkreten Use Case

    Für ein Schweizer Fintech mit ISO 27001-Zertifizierung, 120 Mitarbeitenden und dem Ziel, die Fehlerquote im Back-Office innerhalb von drei Monaten zu senken, ist der On-Premise-Ansatz die richtige Wahl. Die Begründung ist dreifach: Erstens, die Datenhoheit. Kundendaten aus dem Zahlungsverkehr dürfen nicht an Cloud-Anbieter in den USA oder der EU übermittelt werden, was die ISO 27001-Konformität gefährdet. Zweitens, die Skalierbarkeit. Die Ausweitung von einem Piloten auf drei Abteilungen (Zahlungsverkehr, Compliance, Back-Office) ist mit einer einmaligen Hardware-Erweiterung um 20 000 bis 40 000 CHF möglich, während der Cloud-Ansatz die Kosten pro Ticket dauerhaft erhöht. Drittens, die Kostenstruktur. Nach der Amortisation der Initialinvestition von 40 000 bis 80 000 CHF sinken die Betriebskosten pro 1 000 Tickets auf 5 bis 12 CHF, was bei einem Volumen von 5 000 bis 10 000 Tickets pro Monat eine jährliche Ersparnis von 30 000 bis 60 000 CHF gegenüber dem Cloud-Ansatz bedeutet. Die höhere Latenz und die leicht höhere Fehlerquote sind akzeptabel, weil die Triage nicht in Echtzeit erfolgen muss und eine menschliche Freigabe für kritische Tickets die verbleibenden Fehler abfängt.

  • RAG-System für Rechnungsprüfung im E-Commerce: 3-Monats-Plan

    Das Problem: Manuelle Rechnungsprüfung und verzögerte Berichterstattung

    Ihr E-Commerce-Unternehmen in Österreich (51–200 Mitarbeiter) verarbeitet monatlich 500–2 000 Rechnungen. Die manuelle Prüfung dauert im Schnitt 6 Minuten pro Rechnung. Das ergibt 50–200 Stunden manueller Aufwand pro Monat. Die Fehlerquote liegt bei 3–5 % (falsche Kontierung, verpasste Rabatte, doppelte Buchungen). Die monatliche Berichterstattung (Umsatz, Margen, Lagerbestand) wird manuell aus dem ERP und dem CRM zusammengetragen. Das dauert 8–12 Stunden pro Monat. Die Daten sind verstreut, die Aktualität ist gering, die Fehlerquote ist hoch. Das Ziel ist ein RAG-System, das die Rechnungsprüfung automatisiert und die monatliche Berichterstattung in Echtzeit bereitstellt. Das System soll in Slack oder Microsoft Teams integriert sein, damit die Mitarbeiter die Ergebnisse direkt in ihrem Arbeitsumfeld sehen. Die Implementierung soll in 3 Monaten abgeschlossen sein.

    Voraussetzungen: Was Sie vor dem Start brauchen

    • ERP-Zugriff: API-Zugang zum ERP-System (z. B. SAP, Microsoft Dynamics, oder ein E-Commerce-ERP wie Shopware oder WooCommerce). Die API muss die Rechnungsdaten (Betrag, Lieferant, Artikel, Kontierung) liefern können.
    • CRM-Zugriff: API-Zugang zum CRM-System (z. B. Salesforce, HubSpot, oder ein E-Commerce-CRM wie Klaviyo). Die API muss die Kundendaten und die Bestellhistorie liefern können.
    • Slack- oder Teams-Integration: Ein Slack- oder Microsoft-Teams-Account mit API-Zugang. Die Integration soll die Ergebnisse des RAG-Systems in einem dedizierten Channel anzeigen.
    • Vektor-Datenbank: Ein Vektor-Datenbank-Cluster (z. B. Qdrant, Weaviate, oder Milvus). Die Datenbank soll auf der eigenen Hardware oder in einer Cloud-Region in Österreich (z. B. AWS eu-central-1, Azure West Europe) betrieben werden.
    • LLM-API-Zugang: Ein API-Zugang zu einem LLM-Anbieter (z. B. OpenAI, Anthropic, oder ein Open-Weight-Modell auf eigener Hardware). Die API soll die Rechnungsdaten klassifizieren und die Kontierungsvorschläge generieren.
    • Dediziertes AI-Team: Ein Team aus drei Personen (AI-Engineer, Data Engineer, Product Owner), das für die gesamte 3-Monats-Zeitraum verfügbar ist.

    Schritte: Implementierung des RAG-Systems in 3 Monaten

    1. Prozess-Audit durchführen. Dokumentieren Sie den aktuellen Rechnungsprüfungsprozess. Messen Sie die Durchlaufzeit (von der Rechnungseingang bis zur Buchungsfreigabe) und die Fehlerquote. Erstellen Sie eine Liste der häufigsten Fehler (z. B. falsche Kontierung, verpasste Rabatte, doppelte Buchungen). Das Audit dauert 1–2 Wochen. Das Ergebnis ist eine Baseline, die Sie nach der Implementierung vergleichen können.

    2. Datenpipeline aufbauen. Erstellen Sie eine Datenpipeline, die die Rechnungsdaten aus dem ERP und dem CRM in die Vektor-Datenbank lädt. Die Pipeline soll die Daten in einem strukturierten Format (z. B. JSON) speichern. Die Pipeline soll täglich um 02:00 Uhr laufen. Die Datenqualität muss geprüft werden (z. B. fehlende Felder, doppelte Einträge). Die Pipeline dauert 2–3 Wochen.

    3. RAG-System implementieren. Implementieren Sie das RAG-System auf Basis von LangChain und LangGraph. Das System soll die Rechnungsdaten in die Vektor-Datenbank laden und die Kontierungsvorschläge generieren. Das System soll die Konfidenz der Extraktion messen. Wenn die Konfidenz unter 90 % fällt, soll das System die Rechnung an einen menschlichen Prüfer in Slack eskalieren. Die Implementierung dauert 4–6 Wochen.

    4. Slack- oder Teams-Integration aufbauen. Integrieren Sie das RAG-System in Slack oder Microsoft Teams. Das System soll die Ergebnisse in einem dedizierten Channel anzeigen. Die Mitarbeiter sollen die Ergebnisse direkt in ihrem Arbeitsumfeld sehen. Die Integration soll die Eskalationen an die richtigen Personen weiterleiten. Die Integration dauert 1–2 Wochen.

    5. Piloten durchführen. Führen Sie einen Piloten mit 50–100 Rechnungen durch. Messen Sie die Durchlaufzeit und die Fehlerquote. Vergleichen Sie die Ergebnisse mit der Baseline aus dem Prozess-Audit. Der Pilot dauert 2–3 Wochen. Das Ergebnis ist eine Entscheidung, ob das System in den Produktivbetrieb geht.

    6. Rollout durchführen. Führen Sie den Rollout auf alle Rechnungen durch. Das System soll die Rechnungsprüfung automatisieren. Die Mitarbeiter sollen die Ergebnisse in Slack oder Microsoft Teams sehen. Der Rollout dauert 1–2 Wochen. Das Ergebnis ist eine vollständige Automatisierung der Rechnungsprüfung.

    7. Monatliche Berichterstattung automatisieren. Automatisieren Sie die monatliche Berichterstattung (Umsatz, Margen, Lagerbestand). Das System soll die Daten aus dem ERP und dem CRM aggregieren und die Berichte in Echtzeit bereitstellen. Die Berichterstattung soll in Slack oder Microsoft Teams angezeigt werden. Die Automatisierung dauert 2–3 Wochen. Das Ergebnis ist eine Echtzeit-Berichterstattung.

    Häufige Stolperfallen und wie Sie sie erkennen

    • Falsche Kontierung durch das LLM. Das LLM klassifiziert die Rechnung falsch (z. B. als „Wareneingang“ statt „Dienstleistung“). Sie erkennen das, wenn die Kontierungsvorschläge in Slack nicht mit den internen Kontierungsregeln übereinstimmen. Die Lösung ist eine Feinabstimmung des Prompts und eine Erhöhung der Konfidenz-Schwelle.
    • Datenqualität im ERP. Die Rechnungsdaten im ERP sind unvollständig oder fehlerhaft (z. B. fehlende Artikelnummern, doppelte Einträge). Sie erkennen das, wenn die Datenpipeline Fehler meldet oder wenn die Vektor-Datenbank leere Einträge enthält. Die Lösung ist eine Datenbereinigung im ERP und eine Validierung in der Datenpipeline.
    • Eskalationen werden nicht bearbeitet. Die Eskalationen in Slack werden von den Mitarbeitern nicht bearbeitet. Sie erkennen das, wenn die Durchlaufzeit der eskalierten Rechnungen länger ist als die der manuellen Prüfung. Die Lösung ist eine klare Zuständigkeitsregel und eine Benachrichtigung an die Vorgesetzten, wenn eine Eskalation länger als 24 Stunden nicht bearbeitet wird.
    • Vektor-Datenbank ist überlastet. Die Vektor-Datenbank ist überlastet und die Abfragen dauern länger als 5 Sekunden. Sie erkennen das, wenn die Latenz der RAG-Abfragen in den Logs steigt. Die Lösung ist eine Skalierung der Vektor-Datenbank (z. B. mehr Replikate, schnellere Hardware) oder eine Optimierung der Embedding-Modelle.
    • Slack- oder Teams-Integration bricht ab. Die Slack- oder Teams-Integration bricht ab und die Ergebnisse werden nicht angezeigt. Sie erkennen das, wenn die Mitarbeiter in Slack keine Nachrichten vom RAG-System erhalten. Die Lösung ist eine Überwachung der API-Aufrufe und eine automatische Wiederherstellung der Verbindung.

    Fazit: Vom Piloten zum Produktivbetrieb

    Die Implementierung des RAG-Systems für die Rechnungsprüfung ist in 3 Monaten abgeschlossen. Die Durchlaufzeit der Rechnungsprüfung sinkt von 6 Minuten auf 1,5 Minuten. Die Fehlerquote sinkt von 3–5 % auf 0,5–1 %. Die monatliche Berichterstattung wird in Echtzeit bereitgestellt. Die Mitarbeiter sehen die Ergebnisse in Slack oder Microsoft Teams. Der nächste logische Schritt ist die Automatisierung weiterer Prozesse (z. B. die Kundenkommunikation, die Lagerverwaltung). Das RAG-System kann als Basis für diese Prozesse dienen. Die Datenpipeline und die Vektor-Datenbank sind bereits vorhanden. Die Integration in Slack oder Microsoft Teams ist bereits aufgebaut. Die nächsten Use Cases können in 4–6 Wochen implementiert werden.

  • RAG-System für Rechnungsverarbeitung im Schweizer E-Commerce

    Prozess-Audit und Zieldefinition

    Ein Schweizer E-Commerce-Unternehmen mit 120 Mitarbeitern stand vor einem klassischen Problem: Die Buchhaltung verbrachte 40 % ihrer Arbeitszeit mit der manuellen Erfassung von Lieferantenrechnungen. Jede Rechnung erforderte 15 Minuten für die Dateneingabe, und die Fehlerquote lag bei 5 %. Das Team brauchte eine Lösung, die die Routinearbeit eliminiert, ohne die bestehende ERP-Landschaft zu ersetzen.

    Die Entscheidung fiel auf ein Retrieval-Augmented Generation (RAG)-System, das auf pgvector basiert. Der Prozess-Audit identifizierte die Rechnungsverarbeitung als den Workflow mit dem höchsten Automatisierungspotenzial. Das Ziel: Die Zykluszeit auf unter 5 Minuten pro Rechnung senken und die Fehlerquote auf unter 1 % reduzieren. Die Implementierung sollte in 4 Wochen abgeschlossen sein, um den Pilotbetrieb vor dem Quartalsende zu starten.

    Architektur: pgvector und Custom-REST-APIs

    Die Architektur setzt auf drei Kernkomponenten: Eine pgvector-Instanz in der bestehenden PostgreSQL-Datenbank, ein LLM (OpenAI GPT-4o) für die Textverarbeitung und Custom-REST-APIs für die Integration. Die Rechnungen werden als PDFs in ein S3-Bucket geladen, wo ein OCR-Service den Text extrahiert. Die Vektoren werden in pgvector gespeichert, um ähnliche Rechnungen und Kontextinformationen abzurufen.

    Die REST-APIs verbinden das System mit dem ERP (SAP Business One) und der Buchhaltungssoftware. Webhooks senden Ereignisse wie ‘Rechnung extrahiert’ oder ‘Freigabe erforderlich’ an die zuständigen Systeme. Die Daten bleiben im Schweizer Rechenzentrum, was die ISO 27001-Anforderungen erfüllt. Die Vektordatenbank wird verschlüsselt, und der Zugriff erfolgt über rollenbasierte Berechtigungen.

    RAG-Pipeline für die Rechnungsverarbeitung

    Das RAG-System klassifiziert jede Rechnung automatisch: Lieferantenname, Rechnungsnummer, Netto-Betrag, MWST-Satz und Fälligkeitsdatum. Die Vektordurchsuchung in pgvector findet ähnliche Rechnungen aus der Vergangenheit, um Kontext zu liefern. Das LLM extrahiert die strukturierten Felder und vergleicht sie mit den ERP-Daten.

    Bei Unstimmigkeiten – z. B. wenn der Betrag von der letzten Rechnung abweicht – fordert das System eine menschliche Freigabe an. Die Person prüft die extrahierten Daten und bestätigt oder korrigiert sie. Dieser Human-in-the-Loop-Ansatz reduziert das Risiko von Fehlern und erfüllt die Compliance-Anforderungen. Die Freigabe erfolgt über ein Web-Interface, das direkt in die Buchhaltungssoftware integriert ist.

    Pilotbetrieb und Skalierung

    Die Baseline-Messung vor dem Pilotbetrieb ergab: 15 Minuten pro Rechnung, 5 % Fehlerquote, 40 % der Buchhaltungszeit für manuelle Eingaben. Nach 4 Wochen Pilotbetrieb: 3 Minuten pro Rechnung, 0,4 % Fehlerquote, 12 % der Buchhaltungszeit für manuelle Eingaben.

    Die Skalierung erfolgt durch die Erhöhung der pgvector-Instanz und die Anpassung der API-Limits. Da die Architektur model-agnostisch ist, können bei steigenden Anforderungen leistungsfähigere LLMs oder lokale Modelle auf eigener Hardware eingesetzt werden. Die Webhooks und REST-APIs bleiben unverändert. Das dedizierte AI-Team überwacht die Systemleistung und optimiert die Vektordurchsuchung kontinuierlich.

    Compliance und ISO 27001

    Die ISO 27001-Konformität wird durch mehrere Maßnahmen gewährleistet: Die Daten verbleiben im Schweizer Rechenzentrum, die Vektordatenbank ist verschlüsselt, und der Zugriff erfolgt über rollenbasierte Berechtigungen. Regelmäßige Penetrationstests und Audits sind Teil des Betriebs.

    Die Custom-REST-APIs und Webhooks werden über API-Gateways abgesichert, die Rate-Limiting und Authentifizierung (OAuth 2.0) implementieren. Die LLM-APIs werden über sichere Verbindungen (TLS 1.3) aufgerufen, und die Prompts werden vor der Übertragung validiert. Die Human-in-the-Loop-Freigaben werden protokolliert, um die Nachvollziehbarkeit zu gewährleisten. Diese Maßnahmen erfüllen die Anforderungen der ISO 27001 und der Schweizer Datenschutzverordnung (DSG).

  • KI-Automatisierung im E-Commerce-Backoffice: 6 Schritte für Österreich

    Prozess-Audit vor der Automatisierung

    Die meisten E-Commerce-Unternehmen mit 200 bis 500 Mitarbeitern haben bereits CRM, ERP und Helpdesk-Systeme im Einsatz, aber keine KI in der Produktion. Der erste Schritt ist ein Prozess-Audit, das identifiziert, welche Workflows den größten Hebel bieten. Typische Kandidaten sind die Rechnungsprüfung, die Dokumentenextraktion aus PDFs und die Lead-Qualifikation im Vertrieb. Das Audit dauert zwei Wochen und liefert eine priorisierte Liste mit geschätzten Einsparungen pro Workflow. Ohne diese Baseline lässt sich später nicht messen, ob die Automatisierung tatsächlich funktioniert. Der Audit-Bericht enthält konkrete Zahlen: Wie viele Stunden pro Woche werden für manuelle Dateneingabe aufgewendet? Wie hoch ist die aktuelle Fehlerquote bei der Rechnungsprüfung? Diese Zahlen werden zum Maßstab für den gesamten Piloten.

    Dokumentenextraktion als Kernprozess

    Die Dokumentenextraktion ist der am häufigsten automatisierte Backoffice-Prozess im E-Commerce. Rechnungen, Lieferscheine und Retourenformulare werden in strukturierte Daten umgewandelt, die direkt in das ERP-System eingespielt werden. Statt dass ein Mitarbeiter 15 Minuten pro Rechnung manuell Daten eingibt, erkennt das System in 18 ms die relevanten Felder: Rechnungsnummer, Betrag, Lieferadresse, Artikelnummern. Die Extraktions-Pipeline nutzt ein Open-Weight-Modell auf eigener Hardware, damit keine Kundendaten das Gebäude verlassen. Das Ergebnis wird in ein JSON-Format umgewandelt und über die API des ERP-Systems importiert. Die Fehlerquote sinkt von typischen 3 bis 5 Prozent auf unter 0,5 Prozent, weil das System keine Ermüdung kennt und keine Tippfehler macht.

    pgvector als RAG-Infrastruktur

    Die pgvector-Erweiterung für PostgreSQL ist der Schlüssel zu einem RAG-System, das auf den eigenen Daten des Unternehmens basiert. Alle relevanten Dokumente – Produktkataloge, CRM-Notizen, Support-Artikel, Verträge – werden in Textschnipsel zerlegt und als Vektoren in der Datenbank gespeichert. Wenn ein Mitarbeiter in Slack oder Microsoft Teams eine Frage stellt, durchsucht das System die Vektordatenbank und findet die ähnlichsten Dokumentenabschnitte. Diese werden dem LLM als Kontext übergeben, sodass es Antworten ausschließlich auf Basis der eigenen Daten generiert. Das System halluziniert nicht, weil es keine externen Trainingsdaten nutzt. Die Infrastruktur läuft auf eigener Hardware oder in einem EU-Rechenzentrum, was die DSGVO-Konformität sicherstellt.

    Integration in Slack und Microsoft Teams

    Die Integration in Slack oder Microsoft Teams ist entscheidend für die Akzeptanz im Team. Mitarbeiter müssen nicht in ein neues System wechseln, sondern arbeiten dort, wo sie ohnehin kommunizieren. Wenn ein Support-Ticket eingeht, klassifiziert das System die Anfrage und schlägt eine Antwort vor. Der Mitarbeiter prüft den Vorschlag und sendet ihn mit einem Klick. Bei der Lead-Qualifikation im Vertrieb wird der Lead automatisch anhand von Kriterien wie Unternehmensgröße, Budget und Dringlichkeit bewertet. Der Vertrieb erhält eine Benachrichtigung in Teams mit der Lead-Bewertung und den relevanten Dokumenten. Die Reaktionszeit sinkt von Stunden auf Sekunden, und die Kosten pro Support-Ticket reduzieren sich um 30 bis 40 Prozent, weil die manuelle Recherche im CRM entfällt.

    DSGVO-Konformität bei der Datenverarbeitung

    Die DSGVO verlangt, dass personenbezogene Daten nur in der EU verarbeitet werden und dass ein Auftragsverarbeitungsvertrag (AVV) mit jedem externen Anbieter vorliegt. Für die Dokumentenextraktion und die Vektorsuche bedeutet das: Die Infrastruktur muss auf eigener Hardware oder in einem EU-Rechenzentrum laufen. Wenn ein externes LLM wie OpenAI oder Anthropic für die Antwortformulierung genutzt wird, müssen die sensiblen Daten vor dem API-Call anonymisiert oder maskiert werden. Alternativ werden Open-Weight-Modelle wie Llama 3 oder Mistral lokal gehostet, sodass keine Daten das Gebäude verlassen. Der AVV muss die Datenverarbeitung, die Speicherdauer und die Löschung der Daten klar regeln. Für die Lead-Qualifikation im Vertrieb ist besonders wichtig, dass die Bewertungskriterien transparent sind und der Lead informiert wird, wenn seine Daten automatisiert verarbeitet werden.

    8-Wochen-Pilot mit festem Scope

    Der 8-Wochen-Pilot hat einen festen Scope: Ein einzelner Workflow wird automatisiert, die Metriken werden gemessen, und das Ergebnis wird dokumentiert. Woche 1 bis 2: Prozess-Audit und Baseline-Messung. Woche 3 bis 5: Entwicklung der Extraktions-Pipeline und der RAG-Infrastruktur. Woche 6 bis 7: Integration in Slack oder Teams und Testlauf mit echten Daten. Woche 8: Auswertung der Metriken und Übergabe an den Kunden. Der Pilot endet mit einem Bericht, der die Fehlerquote vor und nach der Automatisierung, die Durchlaufzeit und die eingesparten Stunden pro Woche dokumentiert. Wenn der Pilot erfolgreich ist, wird die Skalierung auf weitere Workflows als separates Projekt geplant. Der feste Scope schützt beide Seiten: Der Anbieter weiß, was zu liefern ist, und der Kunde weiß, was er bekommt.

  • Predictive Scoring für Vertragsprüfung: LangGraph-Integration in SAP/Dynamics

    Prozess-Audit und Predictive Scoring im Back Office

    Im E-Commerce-Back Office von Unternehmen mit über 2.000 Mitarbeitern in Österreich dominieren manuelle Prozesse die Vertragsprüfung. Mitarbeiter lesen PDFs, extrahieren Zahlungsbedingungen und prüfen Fristen. Dieser Prozess ist fehleranfällig und langsam. Forfis beginnt mit einem Prozess-Audit, um den Workflow mit der höchsten Fehlerquote zu identifizieren. Der Fokus liegt auf der Reduktion der manuellen Prüfarbeit durch Predictive Scoring. Das Modell bewertet neue Verträge basierend auf historischen Daten und priorisiert die Fälle, die menschliche Aufmerksamkeit benötigen. Die Architektur ist model-agnostisch und nutzt LangChain für die Orchestrierung. LangGraph steuert den Zustandsfluss und stellt sicher, dass der Human-in-the-Loop-Prozess deterministisch abläuft. Die Integration erfolgt über die offenen APIs von SAP S/4HANA oder Microsoft Dynamics 365. Es wird kein ERP-Modul ersetzt, sondern eine neue Service-Schicht davor geschaltet. Diese Schicht kommuniziert über Webhooks oder REST-Endpunkte mit dem bestehenden System. Der Pilot hat einen festen Scope und dauert zwei Wochen. In Woche 1 wird die Prozess-Audits und die Konfiguration der LangGraph-Graphen durchgeführt. In Woche 2 erfolgt die Integration in das ERP-System und die Messung der Baseline-Werte für Fehlerquote und Durchlaufzeit. Der Rollout auf weitere Prozesse beginnt erst nach der validierten Pilotphase.

    Model-agnostische Architektur mit LangChain und LangGraph

    Die technische Umsetzung basiert auf einer model-agnostischen Architektur. Für die Qualitätskritische Textanalyse werden APIs von OpenAI oder Anthropic genutzt, wenn die Datenhoheit es zulässt. Falls sensible Kundendaten oder Vertragsdetails das Gebäude nicht verlassen dürfen, werden Open-Weight-Modelle wie Llama 3 oder Mistral auf eigener Hardware betrieben. Die Schnittstelle bleibt identisch, nur der Backend-Anbieter wechselt. LangChain dient als Orchestrierungsschicht für die LLM-Aufrufe und Tool-Interaktionen. LangGraph ist entscheidend für das Predictive Scoring, da es deterministische Schleifen für die Validierung der Modelle und die menschliche Freigabe abbildet. Der Prozess bricht nicht ab, wenn eine menschliche Freigabe erforderlich ist. Stattdessen wird der Zustand im Graph gespeichert und der Prozess pausiert, bis der Mitarbeiter den Entwurf freigibt. Diese Architektur stellt sicher, dass der Human-in-the-Loop-Prozess zuverlässig und nachvollziehbar abläuft. Die Integration in das ERP-System erfolgt über die offenen APIs. Die KI liest Vertragsdaten aus dem ERP-System, berechnet den Score und schreibt das Ergebnis als Metadatum zurück. Diese asynchrone Verarbeitung über Message Queues wie RabbitMQ oder Kafka stellt sicher, dass die Transaktionszeiten im SAP-System nicht verlangsamt werden.

    Integration in SAP und Microsoft Dynamics ERP

    Die Integration in SAP S/4HANA oder Microsoft Dynamics 365 erfolgt über die offenen APIs des jeweiligen Systems. Forfis entwickelt keine neuen ERP-Module, sondern eine Service-Schicht, die über Webhooks oder REST-Endpunkte mit dem bestehenden System kommuniziert. Die KI liest Vertragsdaten aus dem ERP-System, berechnet den Predictive Score und schreibt das Ergebnis als Metadatum zurück. Diese asynchrone Verarbeitung über Message Queues wie RabbitMQ oder Kafka stellt sicher, dass die Transaktionszeiten im SAP-System nicht verlangsamt werden. Für Unternehmen mit über 2.000 Mitarbeitern ist die Skalierbarkeit der API-Aufrufe und die Lastverteilung im ERP-System entscheidend. Die Architektur muss sicherstellen, dass die KI-Verarbeitung nicht die Transaktionszeiten im SAP-System verlangsamt. Die Datenflüsse werden so gestaltet, dass keine personenbezogenen Daten in externe LLM-APIs übertragen werden, wenn dies nicht erforderlich ist. Bei der Nutzung von Open-Weight-Modellen auf eigener Hardware bleibt die Datenhoheit vollständig beim Unternehmen. Die Integration in das ERP-System erfolgt über verschlüsselte Kanäle, und die Zugriffsberechtigungen werden über das bestehende IAM-System des Unternehmens gesteuert. Dies gewährleistet, dass die Datenhoheit gewahrt bleibt und die Integration in die bestehende IT-Landschaft nahtlos erfolgt.

    Pilot in zwei Wochen: Messung der Baseline

    Der Pilot mit festem Scope dauert zwei Wochen und umfasst die Konfiguration der LangGraph-Graphen, die Integration in das ERP-System und die Messung der Baseline-Werte. In Woche 1 wird die Prozess-Audits und die Konfiguration der LangGraph-Graphen durchgeführt. In Woche 2 erfolgt die Integration in das ERP-System und die Messung der Baseline-Werte für Fehlerquote und Durchlaufzeit. Die Baseline-Messung erfasst die manuelle Durchlaufzeit pro Vertrag und die historische Fehlerquote. Nach der Pilotphase wird derselbe Datensatz durch das KI-System verarbeitet. Der Vergleich zeigt, wie viele Minuten pro Dokument eingespart wurden und wie sich die Fehlerquote in Prozentpunkten verändert hat. Der Rollout auf weitere Prozesse beginnt erst nach der validierten Pilotphase. Die Kosten setzen sich aus der Pilotgebühr, den API-Kosten und dem monatlichen Managed-Service-Tarif zusammen. Bei Open-Weight-Modellen auf eigener Hardware entfallen die Token-Kosten, aber die Infrastrukturkosten steigen. Der Tarif für den Managed Service richtet sich nach der Anzahl der verarbeiteten Dokumente pro Monat und der Komplexität der ERP-Integration.

    Managed AI Operations und 24/7-Kundenantwort

    Der Managed AI Operations Service umfasst das Monitoring der Modell-Drift, die Aktualisierung der Prompts und die Wartung der ERP-Integrationen. Forfis überwacht die Fehlerquote in Echtzeit und greift ein, wenn die Genauigkeit unter den definierten Schwellenwert fällt. Das Team ist für die Stabilität der 24/7-Antwortprozesse und die Datenkonsistenz im Back Office verantwortlich. Das System ist so konfiguriert, dass es 24 Stunden am Tag Anfragen aus dem Helpdesk oder dem CRM entgegennehmen kann. Es triagt die Anfragen, extrahiert relevante Daten und erstellt einen Entwurf für die Antwort. Bei finanziellen oder vertraglichen Themen wird der Prozess pausiert, bis ein Mitarbeiter den Entwurf freigibt. Die Antwort geht erst nach Freigabe an den Kunden. Dieser Ansatz stellt sicher, dass die 24/7-Kundenantwort zuverlässig und compliant ist. Die Datenflüsse werden so gestaltet, dass keine personenbezogenen Daten in externe LLM-APIs übertragen werden, wenn dies nicht erforderlich ist. Bei der Nutzung von Open-Weight-Modellen auf eigener Hardware bleibt die Datenhoheit vollständig beim Unternehmen.

  • E-Commerce in Deutschland: AI-Pilot senkt First-Response-Zeit um 80 %

    Hintergrund: Ein E-Commerce-Anbieter in der Wachstumsphase

    Dieser Fall ist ein Composite aus Mustern, die Forfis in der Praxis beobachtet hat. Wir benennen keine echten Kunden, um die Vertraulichkeit der Projekte zu wahren. Die beschriebene Firma ist ein fiktives, aber plausibles Unternehmen, das die typischen Herausforderungen eines E-Commerce-Anbieters in Deutschland mit 51 bis 200 Mitarbeitern widerspiegelt. Die Zahlen und Metriken basieren auf realistischen Schätzungen aus vergleichbaren Projekten und dienen der Illustration der Effekte, nicht der exakten Wiedergabe eines einzelnen Falls.

    Herausforderung: Fragmentierte Daten und steigende Kosten

    Die Firma, ein Online-Händler für Outdoor-Ausrüstung mit Sitz in München, stand vor einem akuten Problem: Die First-Response-Zeit im Support lag bei durchschnittlich 45 Minuten, die Fehlerquote bei 12 %. Der Druck kam von mehreren Seiten. Erstens drohte eine Vertragsstrafe durch einen großen B2B-Kunden, der eine SLA-Verletzung bei der Reaktionszeit geltend machen konnte. Zweitens fehlten zwei Compliance-Experten, die für die Prüfung von Vertragsentwürfen und die Beantwortung von Rechtsfragen zuständig waren. Drittens stiegen die Kosten pro Support-Ticket durch die steigende Anzahl an Anfragen, die durch die saisonale Nachfrage im Herbst getrieben wurden. Die bestehende Infrastruktur bestand aus einem Salesforce-CRM, einem SAP-BW-System und Slack als primärem Kommunikationskanal. Die Daten waren fragmentiert, und die Suche in internen Dokumenten war zeitaufwendig.

    Ansatz: Fixed-Scope-Pilot mit On-Premise-LLM

    Forfis startete mit einem Prozess-Audit in Woche 1 und 2, um die Workflows zu identifizieren, die für die Automatisierung geeignet waren. Der Fokus lag auf der Beantwortung von Standardfragen im Support, der Anreicherung von Kundendaten im CRM und der Suche in internen Compliance-Dokumenten. Die Architektur wurde bewusst model-agnostic gestaltet: Für die interne Wissenssuche und die Datenanreicherung wurde ein Open-Weight-Modell (Llama 3 70B) auf der eigenen Hardware des Kunden betrieben, um sensible Daten nicht den Standort verlassen zu lassen. Die Integration erfolgte über die nativen APIs von Slack und Salesforce. Die Human-in-the-Loop-Strategie war standardmäßig aktiviert: Der LLM erstellte einen Entwurf, der von einem Mitarbeiter geprüft und freigegeben wurde, bevor er an den Kunden oder in das CRM geschrieben wurde. Die Datenanreicherung umfasste die Ergänzung fehlender Felder (Kundenkategorie, Vertragsstatus, Compliance-Tag) und die Normalisierung von Formatierungen.

    Ergebnis: Messbare Reduktion der Bearbeitungszeit

    Nach 12 Wochen war der Pilot abgeschlossen. Die First-Response-Zeit sank von 45 Minuten auf 8 Minuten, was einer Reduktion von 82 % entspricht. Die Fehlerquote ging von 12 % auf 2 % zurück. Die Kosten pro Support-Ticket sanken um 35 %, da weniger hochqualifizierte Mitarbeiter für Routineanfragen gebunden waren. Die interne Wissenssuche, die zuvor durchschnittlich 15 Minuten pro Anfrage dauerte, wurde auf 30 Sekunden reduziert. Die Datenanreicherung im CRM erfolgte nun automatisch, und die Compliance-Abteilung konnte sich auf komplexe Fälle konzentrieren. Die Messung erfolgte über ein Before/After-Baseline-Setup, das die Metriken über 4 Wochen vor und nach der Implementierung erfasste. Die Ergebnisse wurden in einem Dashboard visualisiert, das die Reduktion der Bearbeitungszeit und die Senkung der Fehlerquote quantifizierte.

    Erkenntnisse: Was ähnliche Teams daraus lernen können

    Die wichtigsten Erkenntnisse aus dem Piloten lassen sich auf ähnliche Teams übertragen. Erstens: Der Prozess-Audit ist der kritischste Schritt. Wenn die Datenquellen und API-Zugänge nicht klar definiert sind, verzögert sich die Implementierung erheblich. Zweitens: Die Human-in-the-Loop-Strategie ist kein Nachteil, sondern ein Sicherheitsmechanismus, der das Vertrauen der Mitarbeiter in die Automatisierung stärkt. Drittens: Die Modell-Agnostik ist ein strategischer Vorteil. Sie ermöglicht es, zwischen Cloud-APIs und On-Premise-Modellen zu wechseln, ohne die Anwendungsschicht anzufassen, was bei sich ändernden Compliance-Anforderungen oder Kostenstrukturen entscheidend ist. Viertens: Die Messbarkeit der Ergebnisse ist der Schlüssel zur Entscheidung über den Rollout. Ohne ein klares Before/After-Baseline-Setup ist es schwierig, den ROI der Automatisierung zu belegen.

  • AI-Workflow-Automatisierung für Order-Status-Updates im Fintech: 8-Wochen-Plan

    Das Problem: Manuelle Datenpflege verzögert Order-Status-Updates im Fintech

    In Fintech- und Zahlungsunternehmen mit 51-200 Mitarbeitern in Deutschland staut sich die manuelle Datenpflege für Order- und Shipment-Status-Updates im Operations- und Supply-Chain-Bereich. Mitarbeiter müssen täglich hunderte Aufträge im ERP (SAP oder Microsoft Dynamics) prüfen, Adressdaten bereinigen, Statuscodes zuordnen und Kunden manuell benachrichtigen. Das kostet 15-20 Minuten pro Vorgang und führt zu verzögerten First-Response-Times, die im Fintech-Bereich direkt auf die Kundenzufriedenheit und Compliance-Kennzahlen wirken. Die ISO 27001-Konformität verlangt dabei, dass Datenintegrität und -verfügbarkeit nachweisbar sind – ein manuelles System liefert diese Nachweise nur schwer. Ein Integration Sprint mit Anthropic Claude API reduziert die Bearbeitungszeit auf 2-5 Sekunden und schafft die Grundlage für eine messbare, ISO-konforme Automatisierung.

    Voraussetzungen: Was du vor dem Sprint brauchst

    Bevor du den Integration Sprint startest, müssen folgende Voraussetzungen erfüllt sein:

    • ERP-Zugriff: API-Zugang auf SAP (BAPI oder OData) oder Microsoft Dynamics (Web API) mit Lese- und Schreibrechten für die Tabellen ‘Auftrag’, ‘Lieferung’ und ‘Kunde’.
    • Datenmodell: Eine Liste der zu bereinigenden Felder (z.B. ‘Lieferadresse’, ‘Statuscode’, ‘Kundenreferenz’) mit klaren Definitionen, was ‘bereinigt’ bedeutet.
    • Claude-API-Key: Ein API-Key von Anthropic mit ausreichendem Budget (ca. 50-100 USD/Monat für 10.000 Aufrufe).
    • Verantwortlicher: Ein Operations-Mitarbeiter, der die Pilotdaten validiert und Feedback gibt.
    • Zeitrahmen: 8 Wochen mit wöchentlichen Checkpoints, die im Projektplan festgelegt sind.
    • ISO 27001-Dokumentation: Vorhandene Richtlinien für Datenverarbeitung und API-Nutzung, die du um die Claude-Integration erweitern musst.

    Schritte: Vom Prozessaudit zum Go-Live in 8 Wochen

    1. Prozessaudit durchführen: Dokumentiere den aktuellen manuellen Workflow. Nenne die ERP-Transaktionen (z.B. ‘VA05’ in SAP), die manuellen Schritte und die typischen Fehlerquellen. Erstelle ein Datenmodell mit den Feldern, die bereinigt werden müssen. Beispiel: ‘Lieferadresse’ enthält oft Tippfehler oder unvollständige PLZ – definiere, was ‘korrekt’ bedeutet.

    2. Claude-Prompt entwerfen: Schreibe einen Prompt, der die Rohdaten aus dem ERP nimmt und die bereinigten Felder zurückgibt. Nutze JSON-Output, um die Struktur zu erzwingen. Beispiel: ’Du bist ein Datenbereiniger. Nimm die Adresse ‘{adresse}’ und liefere die korrigierte PLZ und Straße als JSON: {“plz”: “…”, “strasse”: “…”}’.

    3. API-Anbindung aufbauen: Erstelle eine Middleware (z.B. in Python mit FastAPI), die die ERP-Daten liest, an Claude sendet und die Antwort zurück ins ERP schreibt. Nutze die Anthropic SDK: client.messages.create(model="claude-3-sonnet-20240229", max_tokens=1024, messages=[...]).

    4. Fehlerbehandlung implementieren: Füge Retry-Logik mit exponentiellem Backoff hinzu. Wenn die API fehlschlägt, wiederhole den Aufruf nach 1s, 2s, 4s. Logge alle Fehler in einer Tabelle, die du im ERP oder in einem separaten Monitoring-Tool ablegst.

    5. Pilotbetrieb starten: Führe das System für 100-200 echte Aufträge aus. Lass einen Mitarbeiter die Ergebnisse manuell prüfen. Messen: Wie viele Korrekturen waren nötig? Wie lange dauerte der Aufruf? (Ziel: <5s, <5% Fehlerquote).

    6. ISO 27001-Validierung: Dokumentiere die Datenflüsse. Zeige, dass keine Rohdaten das ERP verlassen, sondern nur strukturierte Fragmente. Aktualisiere die Risikoanalyse und die Richtlinien für API-Nutzung. Lass die Änderungen von deinem ISO-Beauftragten freigeben.

    7. Go-Live und Übergabe: Schalte das System für alle neuen Aufträge frei. Übergib die Dokumentation (Prompts, API-Endpunkte, Fehlerbehandlung) an das Operations-Team. Plane wöchentliche Reviews der Fehlerquoten ein.

    Typische Stolperfallen und wie du sie erkennst

    • Zu komplexe Prompts: Wenn der Prompt zu viele Aufgaben gleichzeitig löst (z.B. Adresse bereinigen UND Status zuordnen UND Kunden benachrichtigen), wird die KI unzuverlässig. Erkennst du das an steigenden Fehlerquoten (>10%) im Pilotbetrieb. Lösung: Prompts auf eine einzige Aufgabe pro Aufruf reduzieren.

    • Fehlende Fehlerbehandlung: Wenn die Claude-API fehlschlägt (z.B. Rate Limit, Timeout), bricht der Prozess ab und der Auftrag bleibt unvollständig. Erkennst du das an fehlenden Statusupdates im ERP. Lösung: Retry-Logik mit exponentiellem Backoff und eine Warteschlange für fehlgeschlagene Aufrufe.

    • Unklare Datenfelder: Wenn das ERP-Feld ‘Status’ verschiedene Bedeutungen hat (z.B. ‘Versandt’ vs. ‘In Transit’), kann die KI nicht korrekt zuordnen. Erkennst du das an inkonsistenten Statuscodes in den Kundenbenachrichtigungen. Lösung: Datenmodell vor dem Sprint klären und eindeutige Statuscodes definieren.

    • ISO 27001-Lücken: Wenn du die Datenflüsse nicht dokumentierst oder die API-Nutzung nicht in der Risikoanalyse erfasst, verletzt du die ISO 27001. Erkennst du das bei der internen Auditierung. Lösung: Datenflüsse und API-Nutzung vor dem Go-Live dokumentieren und freigeben.

    Fazit: Vom Pilot zum skalierbaren Betrieb

    Nach dem Go-Live solltest du die Fehlerquoten und Antwortzeiten wöchentlich überwachen. Wenn die Fehlerquote über 5% steigt, überprüfe die Prompts und die Datenqualität im ERP. Wenn die Antwortzeiten über 5s steigen, prüfe die API-Latenz und die ERP-Performance. Der nächste logische Schritt ist die Erweiterung auf weitere Prozesse: z.B. automatische Kundenbenachrichtigungen per E-Mail oder SMS, oder die Anbindung an weitere ERP-Module (z.B. Rechnungsstellung). Die Grundlage – ein messbarer, ISO-konformer Prozess mit Human-in-the-Loop – ist gelegt. Jetzt kannst du die Automatisierung schrittweise ausbauen, ohne die Compliance zu gefährden.

  • Glossar: KI-gestützte Kandidatensichtung in der Schweiz

    Conversational Agent

    Ein Conversational Agent ist ein KI-System, das über natürliche Sprache mit Nutzern kommuniziert und dabei auf interne Datenquellen zugreift. Im Kontext der Kandidatensichtung beantwortet er Fragen zu Stellenprofilen, prüft formale Voraussetzungen anhand von Lebensläufen und leitet nur qualifizierte Kandidaten an die HR-Abteilung weiter. Er ersetzt keine menschliche Entscheidung, sondern filtert und priorisiert. In der Schweiz wird dieser Ansatz zunehmend genutzt, um die Reaktionszeit auf Bewerbungen von mehreren Tagen auf unter 24 Stunden zu verkürzen, ohne dass die HR-Abteilung überlastet wird.

    Dokumentenextraktion

    Die Dokumentenextraktion nutzt OCR und NLP-Techniken, um strukturierte Daten aus unstrukturierten PDFs oder Word-Dokumenten zu extrahieren. Im HR-Kontext werden so automatisch Schlüsselinformationen wie Berufserfahrung, Qualifikationen und Kontaktdaten aus Lebensläufen erfasst. Dies reduziert den manuellen Dateneingabe-Aufwand um bis zu 80 % und beschleunigt die Sichtung erheblich. Für E-Commerce-Unternehmen mit hohem Personalbedarf ist diese Automatisierung entscheidend, um die Zeit bis zur ersten Kontaktaufnahme mit Kandidaten zu minimieren und so die besten Talente zu sichern.

    Human-in-the-Loop

    Der Human-in-the-Loop-Ansatz stellt sicher, dass die KI nur Vorschläge macht oder klassifiziert, während ein Mensch die finale Entscheidung trifft. Bei der Kandidatensichtung bedeutet das, dass der Agent die Bewerbungen bewertet und priorisiert, aber die Einladung zum Interview oder die Absage durch einen HR-Mitarbeiter bestätigt wird. Dies minimiert das Risiko von Diskriminierung und sichert die rechtliche Compliance. In der Schweiz ist dieser Ansatz besonders wichtig, da das Arbeitsrecht strenge Vorgaben zur Transparenz bei der Personalauswahl macht.

    ISO 27001

    Die ISO 27001 ist eine internationale Norm für Informationssicherheits-Managementsysteme. Für Schweizer E-Commerce-Unternehmen bedeutet dies, dass KI-Systeme, die mit personenbezogenen Daten arbeiten, strikte Zugriffskontrollen, Logging-Mechanismen und definierte Verantwortlichkeiten für die Datenverarbeitung aufweisen müssen. Ein AI Automation Audit prüft, ob diese Kriterien in der bestehenden IT-Landschaft erfüllt sind. Die Zertifizierung wird von vielen B2B-Kunden als Voraussetzung für die Zusammenarbeit gefordert, was die Implementierung sicherer KI-Systeme zu einem Wettbewerbsvorteil macht.

    LangChain und LangGraph

    LangChain ist ein Framework zur Orchestrierung von LLM-Aufrufen, während LangGraph die Zustandsverwaltung und die Ablaufsteuerung für komplexe, mehrstufige Agenten-Workflows übernimmt. In der Schweiz wird diese Kombination genutzt, um sicherzustellen, dass jeder Schritt des Screening-Prozesses nachvollziehbar und deterministisch abläuft, was für die ISO 27001-Zertifizierung essenziell ist. LangGraph ermöglicht es, Fehlerbehandlung und Wiederholungslogik direkt in den Workflow zu integrieren, was die Robustheit des Systems in produktiven Umgebungen deutlich erhöht.

    AI Automation Audit

    Ein AI Automation Audit ist eine strukturierte Bestandsaufnahme der bestehenden Prozesse, die identifiziert, welche Workflows sich durch KI automatisieren lassen. Es liefert eine Priorisierung nach Aufwand und Nutzen sowie eine technische Machbarkeitsstudie. Im 4-Wochen-Timeline-Kontext dient es als Grundlage für den Piloten, der in der zweiten Phase implementiert wird. Das Audit analysiert die aktuellen Datenflüsse, identifiziert Engpässe in der manuellen Dateneingabe und bestimmt, welche Schnittstellen zu Slack oder Microsoft Teams benötigt werden, um den Agenten nahtlos in die bestehende Kommunikation zu integrieren.

    Running Isolated Pilots

    Ein Isolated Pilot ist eine begrenzte Testumgebung, in der die KI-Lösung auf einen spezifischen Workflow angewendet wird, ohne das gesamte System zu beeinflussen. In der 4-Wochen-Phase wird der Agent nur auf eine bestimmte Stelle oder einen Teil der Bewerbungen angewendet. Die Ergebnisse werden gemessen und validiert, bevor eine breite Rollout-Entscheidung getroffen wird. Dieser Ansatz reduziert das Risiko, da Fehler in der Pilotphase keine Auswirkungen auf den laufenden Betrieb haben. Für Unternehmen mit 201 bis 500 Mitarbeitern ist dieser schrittweise Weg die sicherste Methode, um die Akzeptanz der neuen Technologie in der Belegschaft zu erhöhen.

  • Lokale KI vs. Cloud-API: Candidate Screening in der Schweiz

    Zwei Ansätze zur Automatisierung des Candidate Screenings

    Der Vergleich betrifft zwei Ansätze zur Automatisierung der manuellen Datenerfassung und -anreicherung im Candidate Screening: Option A nutzt eine lokale Orchestrierung mit n8n und einem Open-Weight-Modell (z. B. Llama 3 8B) auf eigener Hardware in der Schweiz. Option B setzt auf eine Cloud-basierte Orchestrierung mit n8n Cloud und einer kommerziellen LLM-API (z. B. OpenAI GPT-4o oder Anthropic Claude 3.5 Sonnet). Beide Ansätze integrieren sich in Slack oder Microsoft Teams und ersetzen die manuelle Dateneingabe aus dem ATS (Applicant Tracking System). Der Fokus liegt auf der Datenanreicherung: Extraktion von Schlüsselinformationen, Prüfung formaler Kriterien und Priorisierung. Die Zielgruppe sind Versicherungsunternehmen mit 501-2000 Mitarbeitern, die ISO 27001-konform arbeiten müssen und in 4 Wochen einen Piloten für einen einzelnen Prozess automatisieren wollen.

    Kriterien für die Bewertung

    Die Bewertung stützt sich auf acht Kriterien, die für die Schweizer Versicherungswirtschaft und ISO 27001 relevant sind:

    • Datenschutz und Compliance: Einhaltung von ISO 27001 Anhang A.8.15 (Datenlokalisierung) und dem Schweizer Datenschutzgesetz (DSG).
    • Latenz: Reaktionszeit des Systems von der Anfrage bis zur Antwort in Sekunden.
    • Kosten: Laufende Kosten pro Monat für Hosting, API-Nutzung und Wartung.
    • Vendor Lock-in: Abhängigkeit von einem einzelnen Anbieter und die Migrationskosten.
    • Skalierbarkeit: Fähigkeit, die Anzahl der verarbeiteten Kandidaten pro Tag zu erhöhen.
    • Wartbarkeit: Aufwand für die Aktualisierung von Prompts, Modellen und Integrationen.
    • Genauigkeit: Fehlerquote bei der Datenextraktion und -anreicherung.
    • Integrationstiefe: Nahtlose Anbindung an Slack, Teams und das bestehende ATS.

    Vergleichstabelle: Lokal vs. Cloud

    Kriterium Option A: Lokal (n8n + Open-Weight) Option B: Cloud (n8n Cloud + LLM-API)
    Datenschutz Daten bleiben in der Schweiz, erfüllt ISO 27001 A.8.15 ohne DPA Daten verlassen die Schweiz, erfordert DPA und Anonymisierung, hohes Compliance-Risiko
    Latenz 2-5 Sekunden (abhängig von Hardware) 1-3 Sekunden (abhängig von API-Last)
    Kosten/Monat 300-800 CHF (Strom, Hardware, n8n Hosting) 500-2000 CHF (API-Kosten, n8n Cloud)
    Vendor Lock-in Gering, Modell und n8n sind Open Source Hoch, API-Änderungen können Kosten und Performance beeinflussen
    Skalierbarkeit Begrenzt durch Hardware, Skalierung erfordert neue GPUs Nahtlos, API skaliert automatisch
    Wartbarkeit Mittel, erfordert GPU-Wartung und Modell-Updates Gering, API-Anbieter übernimmt Updates
    Genauigkeit 85-90 % bei strukturierten Daten, 70-80 % bei unstrukturierten 92-95 % bei strukturierten Daten, 85-90 % bei unstrukturierten
    Integration Über Webhooks und HTTP, volle Kontrolle Über native Nodes, schnellere Implementierung

    Szenario-spezifische Bewertung

    Szenario 1: Strikte ISO 27001-Konformität. Wenn das Unternehmen keine Daten aus der Schweiz herausführen darf, ist Option A die einzige Wahl. Die lokale Orchestrierung mit einem Open-Weight-Modell auf eigener Hardware erfüllt Anhang A.8.15 ohne zusätzliche Verträge. Option B ist hier nicht zulässig, da die Daten die Landesgrenze überschreiten. Szenario 2: Hoher Durchsatz und geringe Latenz. Bei der Verarbeitung von über 500 Lebensläufen pro Tag mit einer Latenzuntergrenze von 2 Sekunden ist Option B oft schneller, da die Cloud-APIs optimiert sind. Option A kann bei hoher Last an die Grenzen der Hardware stoßen, es sei denn, mehrere GPUs werden eingesetzt. Szenario 3: Geringes Budget und schnelle Implementierung. Wenn das Budget unter 500 CHF/Monat liegt und die Implementierung in 2 Wochen abgeschlossen sein muss, ist Option B günstiger, da keine Hardware beschafft werden muss. Option A erfordert eine Investition in GPUs (ca. 5000-10000 CHF) und eine längere Einarbeitungszeit. Szenario 4: Langfristige Unabhängigkeit. Wenn das Unternehmen keine Abhängigkeit von einem einzelnen Anbieter will, ist Option A vorteilhaft. Das Modell kann jederzeit durch ein anderes Open-Weight-Modell ersetzt werden, ohne dass die Architektur geändert werden muss. Option B ist an den API-Anbieter gebunden, dessen Preise und Bedingungen sich ändern können.

    Empfehlung für die Schweizer Versicherungswirtschaft

    Für ein Schweizer Versicherungsunternehmen mit 501-2000 Mitarbeitern, das ISO 27001-konform arbeiten muss und in 4 Wochen einen Piloten für die Datenanreicherung im Candidate Screening automatisieren will, ist Option A (Lokal mit n8n und Open-Weight-Modell) die empfohlene Wahl. Die strikte Datenlokalisierung ist ein zwingendes Kriterium, das Option B ausschließt. Die höheren Initialkosten für die Hardware sind durch die laufenden Einsparungen und die Vermeidung von Compliance-Risiken gerechtfertigt. Das dedizierte AI-Team sollte in Woche 1 die Prozessanalyse durchführen und die Kriterien für die Datenanreicherung definieren. In Woche 2 wird der n8n-Workflow entwickelt und in Slack integriert. Woche 3 dient dem Testing mit historischen Daten und der Feinjustierung des LLM-Prompts. Woche 4 ist der Go-Live mit einem kleinen Team und die Dokumentation. Der Pilot sollte einen einzelnen Prozess (z. B. nur die Extraktion von Schlüsselinformationen aus Lebensläufen) abdecken, um in der vorgegebenen Zeit einen stabilen und messbaren Erfolg zu erzielen.