Forfis Blog

Blog

  • KI-Lead-Qualifizierung im E-Commerce: Glossar zu Scoring, Compliance und Betrieb

    AI Process Audit

    Der AI Process Audit ist der Ausgangspunkt jeder erfolgreichen Automatisierungsstrategie. Er analysiert bestehende Workflows, um repetitive, datenintensive Aufgaben zu identifizieren, die sich für KI-Automatisierung eignen. Im E-Commerce-Kontext umfasst das Audit die Bewertung von Lead-Quellen, der Datenqualität im CRM und der aktuellen Reaktionszeiten des Vertriebs. Das Ergebnis ist eine priorisierte Roadmap, die festlegt, welche Prozesse zuerst automatisiert werden. Für Unternehmen mit 51 bis 200 Mitarbeitern ist dieser Schritt entscheidend, um Ressourcen nicht in Low-Impact-Automatisierungen zu binden und die ROI-Berechnung von Anfang an zu validieren.

    AI-Native Operations

    AI-Native Operations beschreibt einen Betriebszustand, in dem KI-Systeme nicht als isolierte Tools, sondern als integraler Bestandteil der Geschäftsprozesse fungieren. Im Gegensatz zu punktuellen Automatisierungen sind die Datenflüsse, Entscheidungslogiken und menschlichen Interventionen so gestaltet, dass die KI kontinuierlich lernt und sich an veränderte Marktbedingungen anpasst. Für E-Commerce-Unternehmen bedeutet das, dass Marketing, Vertrieb und Kundenservice auf einer gemeinsamen Datenbasis arbeiten, die durch KI-Modelle in Echtzeit angereichert wird. Dieser Ansatz erfordert eine enge Zusammenarbeit zwischen IT, Vertrieb und Marketing, um die Datenkonsistenz und die Prozessintegration sicherzustellen.

    pgvector Embeddings Search

    pgvector ist eine Erweiterung für PostgreSQL, die die Speicherung und den Abgleich von Vektordaten ermöglicht. Im Rahmen eines Retrieval-Augmented Generation (RAG)-Systems werden Unternehmensdokumente (z. B. Preislisten, FAQ, Produktdaten) in Vektoren umgewandelt und in pgvector gespeichert. Wenn ein Lead eine Frage stellt, sucht das System die semantisch ähnlichsten Dokumente und übergibt diese als Kontext an das Large Language Model (LLM). Dies stellt sicher, dass die Antworten auf aktuellen, firmenspezifischen Daten basieren und nicht auf generischem Trainingswissen des Modells. Die Nutzung von pgvector reduziert die Halluzinationsrate des LLMs erheblich und verbessert die Genauigkeit der Lead-Antworten.

    Predictive Scoring

    Predictive Scoring nutzt historische Daten, um die Wahrscheinlichkeit eines zukünftigen Ereignisses vorherzusagen. In der Lead-Qualifizierung bedeutet das, dass das Modell anhand von Merkmalen wie Klickverhalten, Verweildauer auf der Website und demografischen Daten eine Punktzahl für jeden Lead berechnet. Leads mit einem Score über einem definierten Schwellenwert (z. B. 75/100) werden automatisch an den Vertrieb weitergeleitet, während niedrigere Scores in eine Nurturing-Sequenz gehen. Dies reduziert die Reaktionszeit des Vertriebs von Stunden auf Sekunden und erhöht die Conversion-Rate. Das Modell wird kontinuierlich mit neuen Daten trainiert, um die Genauigkeit über die Zeit zu verbessern.

    EU AI Act

    Die EU AI Act (Verordnung (EU) 2024/1689) gilt ab dem 2. August 2026 in vollem Umfang. Für Lead-Qualifizierungssysteme, die keine Hochrisiko-Kategorien (z. B. Kreditvergabe oder Personalauswahl) betreffen, gelten primär Transparenzpflichten. Unternehmen müssen Nutzer informieren, dass sie mit einer KI interagieren, und die Systemdokumentation gemäß Artikel 13 führen. Bei der Verarbeitung von Kundendaten in der Schweiz ist zusätzlich das revidierte Datenschutzgesetz (revDSG) zu beachten, das ab dem 1. Juli 2023 gilt und strenge Anforderungen an die Zweckbindung und Datensparsamkeit stellt. Die Einhaltung dieser Vorschriften ist ein zentraler Bestandteil der Compliance-Strategie.

    Managed AI Operations

    Managed AI Operations bezeichnet ein Dienstleistungsmodell, bei dem ein externer Anbieter nicht nur die KI-Lösung entwickelt, sondern auch den laufenden Betrieb übernimmt. Dazu gehören das Monitoring der Modellperformance, das Aktualisieren der Trainingsdaten, die Pflege der Integrationen und die Einhaltung von Compliance-Vorgaben. Für Unternehmen mit 51 bis 200 Mitarbeitern ist dies vorteilhaft, da sie kein eigenes MLOps-Team aufbauen müssen. Der Anbieter garantiert definierte Service Level Agreements (SLAs) für Verfügbarkeit und Antwortqualität. Dieses Modell reduziert das operative Risiko und ermöglicht es dem Unternehmen, sich auf seine Kernkompetenzen zu konzentrieren.

    Slack oder Microsoft Teams Integration

    Die Integration in Slack oder Microsoft Teams erfolgt über Webhooks und API-Endpunkte. Wenn ein Lead im CRM (z. B. HubSpot oder Salesforce) einen bestimmten Score erreicht, sendet das System eine Benachrichtigung an den zuständigen Vertriebler im Chat-Tool. Der Vertriebler kann direkt im Chat auf den Lead antworten, den Status ändern oder eine Demo buchen, ohne das CRM-System zu verlassen. Diese nahtlose Integration reduziert den Kontextwechsel und beschleunigt die Reaktionszeit auf qualifizierte Leads erheblich. Die Nutzung von Chat-Tools als Schnittstelle erhöht die Akzeptanz der neuen Prozesse bei den Mitarbeitern und fördert die schnelle Adoption der KI-Lösung.

  • Kandidatensichtung automatisieren: n8n-Pilot in 3 Monaten

    Das Problem: Manuelle Kandidatensichtung in der Beratung

    In einem österreichischen Beratungsunternehmen mit 800 Mitarbeitern dauert die manuelle Sichtung von Kandidaten im Durchschnitt 12 Minuten pro Lebenslauf. Die HR-Abteilung bearbeitet 150 Bewerbungen pro Monat, was 30 Stunden manueller Arbeit entspricht. Die Fehlerquote liegt bei 8 %, weil die Sichtung von der Tagesform der Mitarbeiter abhängt. Die monatliche Berichterstattung über die Rekrutierungskennzahlen wird manuell in Excel erstellt und dauert 4 Stunden. Die Kosten pro Support-Ticket (hier: pro bearbeitetem Kandidaten) betragen 45 Euro. Das Ziel ist es, diese Prozesse zu automatisieren, um die Kosten zu senken und die Qualität zu erhöhen.

    Voraussetzungen: Was Sie vor dem Piloten benötigen

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

    • Zugang zu Notion oder Confluence: Die Kandidatendaten müssen in einem dieser Tools gespeichert sein. Die API-Zugangsdaten müssen bereitstehen.
    • n8n-Instanz: Eine selbst gehostete oder Cloud-basierte n8n-Instanz muss verfügbar sein. Die Version muss mindestens 1.0 sein.
    • LLM-API-Keys: API-Keys für OpenAI oder Anthropic müssen vorhanden sein. Die Kosten für die API-Nutzung müssen im Budget berücksichtigt sein.
    • Metrik-Definition: Die Metriken (Durchlaufzeit, Fehlerquote, Kosten pro Kandidat) müssen vor dem Piloten definiert und dokumentiert sein.
    • Mandatsträger: Ein HR-Mitarbeiter muss als Mandant benannt werden, der die Ergebnisse des KI-Agenten prüft und freigibt.

    Schritte: Implementierung des Piloten

    1. Prozessanalyse durchführen: Dokumentieren Sie den aktuellen Prozess der Kandidatensichtung. Messen Sie die Durchlaufzeit und die Fehlerquote für 50 Kandidaten. Erstellen Sie eine Baseline in Notion. Diese Baseline wird als Referenz für die Messung der Verbesserung dienen.

    2. n8n-Workflow konfigurieren: Erstellen Sie einen n8n-Workflow, der die Kandidatendaten aus Notion liest. Verwenden Sie den Node ‘Notion: Get Database Items’. Konfigurieren Sie den Filter, um nur neue Bewerbungen abzurufen. Der Workflow muss alle 15 Minuten ausgeführt werden.

    3. LLM-Integration einrichten: Fügen Sie einen Node ‘OpenAI: Chat’ oder ‘Anthropic: Messages’ hinzu. Definieren Sie den Prompt, der die Sichtung der Kandidaten beschreibt. Der Prompt muss die Kriterien für die Sichtung enthalten (z. B. Erfahrung, Ausbildung, Skills). Die Ausgabe muss strukturiert sein (JSON).

    4. Datenanreicherung und -bereinigung: Fügen Sie einen Node ‘Code’ hinzu, der die Ausgabe des LLMs validiert und bereinigt. Entfernen Sie fehlende Felder und normalisieren Sie die Daten. Die bereinigten Daten werden in Notion zurückgeschrieben.

    5. Metrik-Dashboard erstellen: Erstellen Sie ein Dashboard in Notion, das die Metriken (Durchlaufzeit, Fehlerquote, Kosten pro Kandidat) anzeigt. Verwenden Sie die Formel-Funktion von Notion, um die Metriken zu berechnen. Das Dashboard muss in Echtzeit aktualisiert werden.

    6. Manuelle Stichprobenprüfung einrichten: Definieren Sie einen Prozess, bei dem ein HR-Mitarbeiter 10 % der Ergebnisse des KI-Agenten manuell prüft. Die Ergebnisse der Prüfung werden in Notion dokumentiert. Die Übereinstimmung zwischen den Ergebnissen des KI-Agenten und der manuellen Prüfung wird berechnet.

    7. Monatliche Berichterstattung automatisieren: Erstellen Sie einen n8n-Workflow, der am letzten Tag des Monats die Metriken aus dem Dashboard liest und einen Bericht in Notion erstellt. Der Bericht wird automatisch an die relevanten Stakeholder versendet. Die Berichterstattung erfolgt in Echtzeit.

    Häufige Stolperfallen und wie Sie sie erkennen

    • Vage Metrik-Definition: Wenn die Metriken nicht klar definiert sind, können die Ergebnisse nicht interpretiert werden. Erkennen Sie dieses Problem, indem Sie die Metriken vor dem Piloten schriftlich festhalten und mit dem Mandanten abstimmen.

    • Instabile API-Integrationen: Wenn die API-Integrationen nicht stabil sind, kommt es zu Datenverlust oder -duplikation. Erkennen Sie dieses Problem, indem Sie die Logs des n8n-Workflows regelmäßig prüfen und die Fehlerquoten der API-Aufrufe überwachen.

    • Fehlende manuelle Stichprobenprüfung: Wenn die manuelle Stichprobenprüfung nicht durchgeführt wird, wird die Genauigkeit des KI-Agenten falsch eingeschätzt. Erkennen Sie dieses Problem, indem Sie die Dokumentation der Stichprobenprüfung regelmäßig prüfen und die Übereinstimmung zwischen den Ergebnissen des KI-Agenten und der manuellen Prüfung berechnen.

    • Niedrige Datenqualität in Notion: Wenn die Datenqualität in Notion niedrig ist, wird die Leistung des KI-Agenten beeinträchtigt. Erkennen Sie dieses Problem, indem Sie die Daten in Notion regelmäßig prüfen und die fehlenden Felder und Inkonsistenzen dokumentieren.

    • Zu hohe Erwartungshaltung: Wenn die Erwartungshaltung zu hoch ist, wird der Pilot als Misserfolg bewertet, obwohl die Metriken die Verbesserung zeigen. Erkennen Sie dieses Problem, indem Sie die Metriken vor dem Piloten klar definieren und mit dem Mandanten abstimmen.

    Fazit: Vom Piloten zur Skalierung

    Nach dem Piloten sollten Sie die Ergebnisse analysieren und die nächsten Schritte planen. Wenn die Metriken die Verbesserung zeigen (z. B. Durchlaufzeit um 50 % reduziert, Fehlerquote um 3 % gesenkt), können Sie die Automatisierung auf weitere Prozesse ausweiten. Die nächste logische Schritt ist die Automatisierung der monatlichen Berichterstattung über die Rekrutierungskennzahlen. Diese Automatisierung reduziert die manuelle Arbeit für die Berichterstattung um 90 % und stellt sicher, dass die Daten immer aktuell sind. Die Kosten pro Support-Ticket sinken um 40 bis 60 %, weil die manuelle Arbeit reduziert wird. Die Qualität der Rekrutierung steigt, weil die Sichtung konsistenter und schneller erfolgt.

  • LLM-gestützte Lieferstatus-Antworten: OpenAI-Integration im E-Commerce-ERP

    Der Engpass: Manuelle Lieferstatus-Antworten in der E-Commerce-Operations

    In einem deutschen E-Commerce-Unternehmen mit 800 Mitarbeitern und 150.000 Bestellungen pro Monat staut sich die Kundenkommunikation an einem Punkt: der Frage „Wo ist meine Bestellung?“. Die Operations-Teams arbeiten in Schichten, aber die Anfragen kommen rund um die Uhr – auch nachts, an Wochenenden und in mehreren Sprachen. Die aktuelle Antwortzeit liegt bei 4 bis 8 Stunden, die Fehlerquote bei 3 bis 5 %, weil Mitarbeiter manuell im SAP-System nachschlagen, Adressen abgleichen und per E-Mail antworten. Die Folge: steigende Rückrufquoten, sinkende CSAT-Werte und ein wachsender Backlog, der bei Spitzenlasten (Black Friday, Weihnachten) explodiert. Die betroffenen Rollen sind die Customer-Support-Agenten, die Operations-Koordinatoren und die Logistik-Disponenten, die ständig nachgefragt werden, ob eine Sendung tatsächlich im Lager ist.

    Warum Standard-Chatbots und manuelle Skalierung nicht ausreichen

    Viele Unternehmen greifen zunächst auf Standard-Chatbots zurück, die auf regelbasierten If-Then-Logiken basieren. Diese Systeme scheitern an der Variabilität der Kundenanfragen: „Ist mein Paket schon unterwegs?“, „Warum ist meine Lieferung so spät?“, „Kann ich die Adresse ändern?“ – jede Formulierung erfordert eine eigene Regel. Die Wartung dieser Regelwerke skaliert nicht linear mit dem Volumen. Zudem können regelbasierte Bots keine kontextuellen Antworten geben: Sie wissen nicht, ob die Sendung bereits beim Spediteur ist, ob es eine Zollverzögerung gab oder ob der Kunde bereits eine Reklamation gestellt hat. Ein zweiter häufiger Ansatz ist die manuelle Skalierung: mehr Agenten einstellen, Schichten ausweiten. Das erhöht die Fixkosten um 15 bis 20 % pro 10 % Volumenwachstum und löst das Problem der 24/7-Abdeckung nicht, da Nacht- und Wochenend-Schichten teurer sind und schwerer zu besetzen. Beide Ansätze ignorieren die Kernproblematik: die Daten liegen bereits im ERP, aber die Übersetzung in natürliche Sprache ist manuell.

    Die Architektur: LLM-Integration in den bestehenden Ticket-Flow

    Die Lösung besteht in der Integration einer LLM-Schicht (OpenAI API, z. B. GPT-4o) in den bestehenden Ticket-Flow. Der Workflow sieht so aus: 1. Das Helpdesk-System (z. B. Zendesk, Freshdesk) erkennt eine neue Anfrage. 2. Ein Orchestrierungs-Skript (z. B. Python mit LangChain oder n8n) holt die Bestellnummer aus dem Ticket, ruft die OpenAI API auf und überträgt den Kontext an die LLM. 3. Parallel wird die aktuelle Statusinformation aus dem ERP (SAP oder Microsoft Dynamics) über die API abgerufen. 4. Die LLM formuliert eine natürliche Antwort auf Basis der Statusdaten. 5. Ein Regelwerk prüft die Antwort auf Plausibilität (z. B. keine falschen Lieferdaten). 6. Bei Unsicherheit oder bei Anfragen, die Geld oder Adressänderungen betreffen, wird die Antwort an einen menschlichen Approver weitergeleitet. 7. Die finale Antwort wird an den Kunden gesendet. Die Architektur ist modell-agnostisch: Für die Statusanfragen genügt GPT-4o-mini (kostengünstig, schnell), für komplexe Reklamationen kann GPT-4o (höhere Qualität) genutzt werden. Die Integration erfolgt über die bestehenden APIs, ohne das ERP zu ersetzen.

    Vier Schritte zum Pilot: Audit, Integration, Test, Rollout

    Der Start erfolgt in vier Schritten. Schritt 1: Prozess-Audit (Woche 1). Analyse der letzten 90 Tage Ticket-Daten: Welche 5 Statusanfragen machen 80 % des Volumens aus? Welche ERP-Schnittstellen sind vorhanden? Welche Compliance-Anforderungen gelten (EU AI Act, DSGVO)? Ergebnis: Definition des Pilot-Workflows (z. B. „Lieferstatus-Anfrage“). Schritt 2: Integration und Prompt-Engineering (Woche 2). Aufbau der API-Verbindung zwischen Helpdesk, ERP und OpenAI. Erstellung der System-Prompts, die die Antwortqualität steuern (z. B. „Antworte in der Sprache des Kunden, nenne die voraussichtliche Lieferzeit, weise auf mögliche Verzögerungen hin“). Schritt 3: Closed-Loop-Test (Woche 3). Der Pilot läuft mit 10 % des Traffics. Alle Antworten werden von einem menschlichen Approver geprüft. Metriken werden gemessen: Zykluszeit, Fehlerquote, Eskalationsrate. Schritt 4: Rollout und Betrieb (Woche 4). Bei einer Fehlerquote unter 1 % und einer Eskalationsrate unter 15 % wird der Pilot auf 100 % des Traffics ausgeweitet. Das Monitoring läuft weiter, die Prompts werden wöchentlich optimiert. Die Compliance-Dokumentation (EU AI Act, DSGVO) wird im Audit mitgeliefert.

    Stolperfallen: Warum viele Piloten scheitern

    Die häufigsten Stolperfallen sind: 1. Zu breite Pilot-Definition: Unternehmen versuchen, alle Kundenanfragen (Reklamationen, Retouren, Adressänderungen) gleichzeitig zu automatisieren. Das scheitert an der Komplexität. Der Pilot muss auf einen einzigen, hochfrequenten Workflow fokussiert sein. 2. Fehlende ERP-Schnittstellen: Wenn die Statusdaten nicht über eine API abrufbar sind, muss erst die Schnittstelle gebaut werden. Das verzögert den Pilot um 2 bis 4 Wochen. 3. Ignorieren der Compliance: Der EU AI Act verlangt Transparenz (Nutzer muss erkennen, dass eine KI antwortet) und DSGVO-Konformität (Datenverarbeitung in der EU, AVV mit OpenAI). 4. Keine menschliche Eskalation: Wenn die KI bei Unsicherheit nicht an einen Menschen weiterleitet, entstehen Fehlinformationen. Die Human-in-the-Loop-Schicht ist kein optionales Feature, sondern ein Kernbestandteil. 5. Fehlende Metriken: Ohne eine gemessene Baseline (Zykluszeit, Fehlerquote vor dem Pilot) kann der Erfolg nicht belegt werden. Der Audit muss diese Baseline liefern.

  • KI-Automatisierung im E-Commerce: Candidate Screening und Support-Tickets senken

    Das Problem: Manuelle Prozesse im E-Commerce

    E-Commerce-Unternehmen in Österreich mit 51 bis 200 Mitarbeitern kämpfen mit einem wachsenden Volumen an Support-Tickets und manuellen Dateneingaben. Die Kosten pro Ticket steigen, während die Mitarbeiterzeit für strategische Aufgaben fehlt. Forfis adressiert dieses Problem durch die Integration von KI-Automatisierung in bestehende Systeme. Der Ansatz beginnt mit einem Prozess-Audit, das die Workflows identifiziert, die sich am besten für die Automatisierung eignen. Danach folgt ein Pilot mit festem Umfang, der nach acht bis zwölf Wochen abgeschlossen ist. Der Rollout und die Übergabe in den Managed AI Operations-Betrieb erfolgen innerhalb von sechs Monaten. Die Architektur ist model-agnostisch und nutzt n8n für die Orchestrierung, was eine flexible Integration in bestehende CRMs, ERPs und Helpdesks ermöglicht.

    Die Architektur: n8n als Orchestrierungs-Kern

    Die Kernkomponente der Lösung ist die n8n-Orchestrierung, die als zentrales Nervensystem dient. n8n verbindet die KI-Modelle mit den bestehenden Systemen über deren APIs. Für die Candidate Screening-Aufgabe werden Lebensläufe aus Google Workspace extrahiert, von einem OpenAI- oder Anthropic-Modell klassifiziert und in einem strukturierten Format zurückgegeben. Die Orchestrierung stellt sicher, dass die Datenflüsse korrekt ablaufen und dass der Human-in-the-Loop-Schritt bei kritischen Entscheidungen aktiviert wird. Die Architektur ist bewusst so gestaltet, dass sie in bestehende Systeme integriert, statt diese zu ersetzen. Dies reduziert das Risiko und die Kosten für die Migration.

    Integration: Google Workspace als Datenquelle

    Die Integration in Google Workspace erfolgt über die offiziellen APIs. Das System liest E-Mails, Dokumente und Kalenderdaten und schreibt die Ergebnisse zurück. Im Kontext des Candidate Screening werden beispielsweise Lebensläufe aus E-Mail-Anhängen extrahiert, in Google Docs strukturiert und die Kommunikation mit Kandidaten über Gmail automatisiert. Die Daten werden in einem zentralen System verwaltet, das über die n8n-Orchestrierung angesprochen wird. Diese Integration reduziert die manuelle Dateneingabe erheblich und stellt sicher, dass alle Informationen an einem Ort verfügbar sind. Die API-Integration ist stabil und folgt den offiziellen Spezifikationen von Google.

    Trade-offs: Kommerzielle APIs vs. Open-Weight-Modelle

    Die model-agnostische Architektur bietet zwei Hauptpfade. Für Aufgaben, bei denen die Qualität im Vordergrund steht, werden OpenAI- oder Anthropic-APIs verwendet. Diese Modelle bieten die höchste Genauigkeit bei der Klassifizierung und Extraktion. Wenn regulierte Daten das Gebäude nicht verlassen dürfen, kommen Open-Weight-Modelle auf der eigenen Hardware des Kunden zum Einsatz. Diese Modelle sind weniger genau, aber sie gewährleisten die Datenhoheit. Die Wahl des Modells hängt von den Compliance-Anforderungen und der gewünschten Genauigkeit ab. Forfis empfiehlt, für den Piloten mit den kommerziellen APIs zu beginnen und dann auf Open-Weight-Modelle zu wechseln, wenn die Compliance-Anforderungen es erfordern.

    Human-in-the-Loop: Kontrolle und Messung

    Der Human-in-the-Loop-Ansatz ist standardmäßig aktiviert. Das KI-Modell erstellt Entwürfe oder klassifiziert Daten, aber eine Person muss alles genehmigen, was Geld, Gesundheitsdaten oder Verträge betrifft. Im Kontext des Candidate Screening bedeutet dies, dass die KI die Lebensläufe vorfiltert, aber die finale Entscheidung über die Einladung zum Interview von einer Person getroffen wird. Jeder Pilot wird mit einem gemessenen Vorher-Nachher-Baseline-Wert für Zykluszeit und Fehlerquote ausgeliefert. Dies ermöglicht es, den Erfolg objektiv zu belegen und die Kostenreduktion pro Support-Ticket zu quantifizieren. Die Messung erfolgt über die bestehenden Systeme und wird in einem Dashboard visualisiert.

    Empfehlung: Pilot auf Candidate Screening

    Für E-Commerce-Unternehmen in Österreich mit 51 bis 200 Mitarbeitern empfiehlt Forfis, mit einem Piloten auf dem Candidate Screening zu beginnen. Dieser Workflow hat einen hohen manuellen Aufwand und bietet eine klare Messbarkeit. Die Integration in Google Workspace ist einfach und reduziert die manuelle Dateneingabe erheblich. Nach dem Piloten sollte der Rollout auf die Support-Ticket-Verarbeitung erfolgen, um die Kosten pro Ticket zu senken. Die Gesamtdauer von sechs Monaten ist realistisch und ermöglicht es, die Ergebnisse zu messen und zu optimieren. Der Managed AI Operations-Betrieb stellt sicher, dass die Systeme kontinuierlich überwacht und verbessert werden.

  • KI-gestützte Vertragsprüfung in der Logistik: Fallstudie aus Österreich

    Hintergrund: AlpenLogistik in der Wachstumsphase

    Die vorliegende Fallstudie ist ein Composite aus Mustern, die Forfis in der Praxis beobachtet hat. Es werden keine realen Kundennamen genannt, um die Vertraulichkeit zu wahren. Die beschriebene Firma ist ein fiktives, aber plausibles Unternehmen, das die typischen Merkmale eines Logistikdienstleisters in Österreich mit 11 bis 50 Mitarbeitern abbildet. Die Firma, nennen wir sie „AlpenLogistik“, betreibt einen B2B-Dienst für den Transport von Gütern zwischen Deutschland, Österreich und Italien. Der Stack besteht aus einem bestehenden ERP-System, einem Helpdesk-Tool und Microsoft Teams als Kommunikationskanal. Die IT-Abteilung ist klein, mit zwei Mitarbeitern, die für die Wartung und die Einführung neuer Tools zuständig sind. Die Firma ist in der Phase, in der sie ihre Prozesse digitalisieren will, aber noch keine eigene KI-Strategie hat. Die Herausforderung besteht darin, die wachsende Menge an Dokumenten und Support-Anfragen effizienter zu bearbeiten, ohne das Team zu vergrößern.

    Herausforderung: Mehrsprachige Anfragen und manuelle Vertragsprüfung

    AlpenLogistik stand vor einem doppelten Problem. Erstens stieg die Anzahl der Support-Tickets, weil die Kunden mehrsprachige Anfragen stellten – auf Deutsch, Italienisch und Englisch. Das Team konnte die Anfragen nicht schnell genug bearbeiten, was zu längeren Antwortzeiten und unzufriedenen Kunden führte. Zweitens war die Vertragsprüfung ein manueller Prozess, der viel Zeit in Anspruch nahm. Juristen und Compliance-Beauftragte mussten jede Vertragsklausel manuell prüfen, was zu Engpässen führte. Die operative Drucker war hoch, weil die Firma in der Saison mit einem höheren Volumen an Gütern zu tun hatte und die Bearbeitungszeiten nicht weiter steigen durften. Die Kosten pro Support-Ticket waren gestiegen, und die Firma suchte nach einer Lösung, die die Kosten senkt und die Abdeckung erweitert, ohne neue Mitarbeiter einzustellen. Die Deadline für die Einführung war acht Wochen, um die nächste Saison zu schaffen.

    Vorgehen: Audit, Pilot und Integration in Microsoft Teams

    Forfis begann mit einem AI-Automation-Audit, das zwei Wochen dauerte. Dabei wurden die bestehenden Workflows analysiert und die Prozesse identifiziert, die sich am besten für die Automatisierung eignen. Es zeigte sich, dass die Dokumentenextraktion und die Vertragsprüfung die größten Hebel boten. Der Pilot umfasste die Integration der Anthropic Claude API in das bestehende System. Die KI extrahierte relevante Daten aus den Dokumenten und erstellte einen Entwurf für die Vertragsprüfung. Die Integration erfolgte über Microsoft Teams, wo die Mitarbeiter die Vorschläge der KI prüfen und freigeben konnten. Die Architektur war modell-agnostisch, sodass bei Bedarf auch andere Modelle genutzt werden konnten. Der Pilot lief vier Wochen, und die Ergebnisse wurden gemessen. Die Durchlaufzeit für die Vertragsprüfung sank von drei Tagen auf acht Stunden, und die Fehlerquote ging um 40 Prozent zurück. Die Kosten pro Support-Ticket sanken um 35 Prozent, weil die KI die ersten Schritte übernahm.

    Ergebnis: Skalierung auf weitere Abteilungen und messbare Effekte

    Nach dem erfolgreichen Pilot wurde die Lösung auf weitere Abteilungen skaliert. Die Dokumentenextraktion wurde auf die Rechnungsprüfung und die Datenpflege ausgedehnt. Die mehrsprachige Abdeckung wurde erweitert, indem die KI auch auf Italienisch und Englisch Anfragen bearbeitete. Die Kosten pro Support-Ticket sanken weiter, und die Antwortzeiten verkürzten sich um 50 Prozent. Die Mitarbeiter waren zufrieden, weil die KI die Routinearbeit übernahm und sie sich auf die komplexeren Fälle konzentrieren konnten. Die Skalierung gelang, weil die Architektur modular aufgebaut war und die bestehenden Systeme nicht ersetzt wurden. Die Firma konnte die Lösung in weiteren Abteilungen einführen, ohne große Umstellungen vornehmen zu müssen. Die Gesamtkosten für die Einführung lagen im Rahmen des Budgets, und die Firma war zufrieden mit dem Ergebnis.

    Erkenntnisse: Was andere Teams daraus lernen können

    Die Fallstudie zeigt, dass die Automatisierung von Dokumenten und die mehrsprachige Abdeckung ein wirksames Mittel sind, um die Kosten pro Ticket zu senken und die Abdeckung zu erweitern. Die Human-in-the-Loop-Ansatz ist essenziell, um die Qualität zu sichern und die Mitarbeiter einzubinden. Die modell-agnostische Architektur ermöglicht es, die Lösung an die spezifischen Anforderungen des Kunden anzupassen. Die Integration in bestehende Systeme wie Microsoft Teams erleichtert die Einführung und die Akzeptanz bei den Mitarbeitern. Die Messung des Erfolgs durch Vorher-Nachher-Baselines ist wichtig, um den Nutzen objektiv zu belegen. Für ähnliche Teams gilt: Beginnen Sie mit einem Audit, identifizieren Sie die größten Hebel und skalieren Sie die Lösung schrittweise. Die KI ist kein Ersatz für den Menschen, sondern ein Werkzeug, das die Arbeit erleichtert.

  • Interne Wissenssuche im Medtech: On-Premise-KI senkt Fehlerquoten

    Das Problem: Verstreutes Wissen und hohe Fehlerquoten im Back Office

    In Schweizer Medtech-Unternehmen mit 500 bis 2.000 Mitarbeitern staut sich die Arbeit im Back Office. HR-Teams beantworten dieselben Fragen zu Benefits und Onboarding täglich, während Support-Mitarbeiter nachts und am Wochenende auf Kundenanfragen warten. Die internen Wissensbasen liegen verstreut in Google Drive, Confluence und E-Mail-Threads. Mitarbeiter verlieren im Schnitt 45 Minuten pro Tag mit der Suche nach Informationen, die eigentlich vorhanden sind. Die Folge: Höhere Fehlerquoten bei der Datenerfassung, verzögerte Antworten an Kunden und frustrierte Mitarbeiter, die sich nicht auf die internen Systeme verlassen können. Das Problem ist nicht das Fehlen von Daten, sondern die fehlende intelligente Verknüpfung und Bereitstellung dieser Daten in Echtzeit.

    Warum bestehende Lösungen im Gesundheitswesen versagen

    Viele Unternehmen greifen zu generischen Cloud-KI-Lösungen, die ihre Daten in externe Rechenzentren übertragen. Im Gesundheitswesen ist das aus Sicherheits- und Vertraulichkeitsgründen oft nicht akzeptabel, selbst wenn keine explizite DSGVO-Meldungspflicht besteht. Andere versuchen, die Wissenssuche manuell zu optimieren, indem sie Ordnerstrukturen in Google Drive umorganisieren. Das führt kurzfristig zu Ordnung, aber nicht zu einer automatisierten, kontextbewussten Antwortgenerierung. Die meisten bestehenden Tools ersetzen die CRM- oder ERP-Systeme nicht, sondern hängen als Insellösungen daneben. Das Ergebnis ist eine zusätzliche Last für die Mitarbeiter, die nun zwei Systeme bedienen müssen, anstatt eines, das nahtlos in ihre Arbeitsabläufe integriert ist.

    Die Lösung: On-Premise-KI mit RAG und Google-Workspace-Integration

    Forfis setzt auf eine modell-agnostische Architektur, die Open-Weight-Modelle direkt auf der Hardware des Kunden betreibt. Das bedeutet: Keine Daten verlassen das eigene Rechenzentrum. Die KI wird als RAG-System (Retrieval-Augmented Generation) über die interne Wissensbasis gebaut – Google Drive, interne Wikis und CRM-Records. Sie generiert Antworten, die auf den spezifischen Kontext des Unternehmens zugeschnitten sind. Die Integration erfolgt über die Google Workspace API, sodass der Assistent direkt in Google Chat, Gmail und Docs verfügbar ist. Für den 24/7-Kundenservice wird die gleiche Infrastruktur genutzt, um Tickets zu triagieren und erste Antworten zu generieren. Der Mensch bleibt im Loop: Bei kritischen Anfragen oder wenn die Konfidenz des Modells unter einem Schwellenwert liegt, wird die Anfrage an einen Experten weitergeleitet.

    So starten Sie: Zweiwöchiger Pilot mit messbarem ROI

    Der Pilot dauert zwei Wochen und folgt einem klaren Plan. Woche 1: Prozess-Audit und Datenanbindung. Wir identifizieren die wichtigsten Wissensquellen in Google Workspace und konfigurieren die Open-Weight-Modelle auf der lokalen Hardware. Woche 2: Feinabstimmung und Messung. Die Prompts werden auf den Fachjargon des Gesundheitswesens optimiert, eine Pilotgruppe wird geschult, und die Baseline-Metriken (Fehlerquote, Antwortzeit) werden gemessen. Am Ende der zwei Wochen liegt ein Bericht vor, der die Reduktion der Fehlerquote und die Zeitersparnis quantifiziert. Der Übergang zum Managed Service erfolgt nahtlos: Forfis übernimmt den Betrieb, überwacht die Modellperformance und passt die Prompts kontinuierlich an neue Daten an.

  • Rechnungsautomatisierung in zwei Wochen: OpenAI API, ISO 27001 und SAP

    Das Problem: Manuelle Rechnungsprüfung in der Schweiz

    Du betreibst einen E-Commerce-Betrieb in der Schweiz mit 51 bis 200 Mitarbeitenden. Die Rechnungsprüfung läuft manuell über SAP oder Microsoft Dynamics. Jede Rechnung wird von einem Buchhalter geprüft, erfasst und freigegeben. Dieser Prozess kostet Zeit und Geld. Du willst die Kosten pro Support-Ticket senken, indem du die Rechnungsprüfung automatisierst. Der Pilot soll in zwei Wochen abgeschlossen sein und einen messbaren Vorher-Nachher-Vergleich liefern. Die Architektur nutzt die OpenAI API für das Scoring-Modell und ist ISO 27001-konform. Der Workflow ist fest umrissen: Rechnungsprüfung, keine anderen Prozesse.

    Voraussetzungen vor dem ersten Schritt

    • ERP-Zugriff: API-Zugang zu SAP oder Microsoft Dynamics, freigegeben durch die IT-Abteilung. Bei SAP ist das die BAPI oder OData-API, bei Dynamics die Web API.
    • OpenAI API-Key: Ein API-Key mit ausreichendem Guthaben. Der Key wird im Secrets-Manager gespeichert, nicht im Code.
    • ISO 27001-Dokumentation: Der Datenfluss von der Rechnungsdatei über die OpenAI-API zurück ins ERP ist dokumentiert. Die Verschlüsselung in Transit (TLS 1.2 oder höher) und die Protokollierung der API-Calls sind festgelegt.
    • Basiswerte: 100 zufällig ausgewählte Rechnungen aus den letzten drei Monaten. Für jede ist die Bearbeitungszeit und die Fehlerquote dokumentiert.
    • Menschliche Freigabe: Ein Buchhalter ist für die Prüfung der Rechnungen mit einem Konfidenzwert unter 0,95 verfügbar.

    Die sieben Schritte zum Piloten

    1. Prozessanalyse durchführen. Du identifizierst die 20 Prozent der Rechnungen, die 80 Prozent des manuellen Aufwands verursachen. Typische Kandidaten sind wiederkehrende Lieferanten mit unklaren Positionen, Rechnungen mit mehreren Währungen oder Dokumente mit fehlenden Pflichtfeldern. Diese Auswahl bestimmt, welche Daten du für das Scoring-Modell brauchst.

    2. ERP-Connector schreiben. Du schreibst einen Connector, der die Rechnungsdaten aus dem ERP liest. Bei SAP nutzt du die BAPI oder OData-API, bei Dynamics die Web API. Der Connector läuft als Hintergrundjob und wird über den API-Key authentifiziert. Die Daten werden in ein JSON-Format überführt, das das Scoring-Modell versteht.

    3. Scoring-Modell konfigurieren. Du rufst die OpenAI API auf und übergibst die Rechnungsdaten. Das Modell liefert einen Konfidenzwert zwischen 0 und 1. Du setzt die Schwellenwerte: über 0,95 wird automatisch freigegeben, zwischen 0,70 und 0,95 geht die Rechnung an einen Prüfer, unter 0,70 wird sie abgelehnt.

    4. Freigabe-Workflow einrichten. Du konfigurierst den Workflow im ERP. Rechnungen mit einem Konfidenzwert über 0,95 werden automatisch freigegeben. Die anderen gehen an den Buchhalter. Der Buchhalter sieht den Konfidenzwert und die Begründung des Modells und trifft die Entscheidung.

    5. Basiswerte messen. Du wiederholst die Messung mit denselben 100 Rechnungen. Du dokumentierst die neue Bearbeitungszeit und die neue Fehlerquote. Der Unterschied zeigt, ob die Automatisierung die Kosten pro Ticket senkt.

    6. ISO 27001-Dokumentation abschließen. Du dokumentierst den Datenfluss, die Verschlüsselung, die Speicherung der API-Keys und die Protokollierung. Zusätzlich legst du fest, wer Zugriff auf die Scoring-Ergebnisse hat und wie lange die Logs aufbewahrt werden.

    7. Pilotenbericht erstellen. Du fasst die Ergebnisse zusammen. Du nennst die neue Bearbeitungszeit, die neue Fehlerquote und die geschätzte Kostenersparnis pro Ticket. Du legst fest, ob der Pilot in den Regelbetrieb übergeht.

    Häufige Stolperfallen und wie du sie erkennst

    • API-Key im Code: Der OpenAI API-Key steht im Quellcode statt im Secrets-Manager. Du erkennst das, wenn der Key in der Versionskontrolle sichtbar ist. Lösung: Key in den Secrets-Manager verschieben und den Code bereinigen.
    • Fehlende ISO-Dokumentation: Der Datenfluss ist nicht dokumentiert. Du erkennst das, wenn das ISO-27001-Audit den Piloten ablehnt. Lösung: Dokumentation vor dem Piloten abschließen.
    • Zu niedrige Schwellenwerte: Der Konfidenzwert über 0,95 wird zu oft erreicht, aber die Fehlerquote steigt. Du erkennst das, wenn die manuelle Nachprüfung mehr Fehler findet als vorher. Lösung: Schwellenwerte auf 0,98 anheben.
    • ERP-API-Rate-Limit: Der Connector überschreitet das Rate-Limit des ERP-Systems. Du erkennst das, wenn der Connector Fehlermeldungen liefert. Lösung: Batch-Größe reduzieren und die Abfragefrequenz senken.
    • Fehlende menschliche Freigabe: Rechnungen mit einem Konfidenzwert unter 0,95 werden nicht geprüft. Du erkennst das, wenn die Fehlerquote steigt. Lösung: Workflow im ERP so konfigurieren, dass die Freigabe erzwungen wird.

    Nächster Schritt: Vom Piloten in den Regelbetrieb

    Der Pilot ist abgeschlossen. Du hast die Basiswerte gemessen und die Kosten pro Ticket berechnet. Der nächste Schritt ist die Entscheidung, ob der Pilot in den Regelbetrieb übergeht. Wenn die Fehlerquote unter 2 Prozent liegt und die Bearbeitungszeit um mindestens 30 Prozent gesunken ist, ist der ROI gegeben. Wenn nicht, passt du die Schwellenwerte an und wiederholst den Piloten. Die ISO 27001-Dokumentation bleibt gültig, solange der Datenfluss sich nicht ändert. Der Connector läuft weiter als Hintergrundjob und wird über den API-Key authentifiziert.

  • KI-Piloten-Checkliste: Compliance-sichere Wissenssuche in HR und Back Office

    Checkliste: 10 Schritte für einen compliance-konformen KI-Piloten

    1. Prozess-Audit durchführen und Use Case priorisieren.
      Identifiziere die drei workflows mit der höchsten Fehlerquote und dem größten Zeitaufwand. Dokumentiere den Ist-Zustand (Cycle Time, Fehlerrate) als Baseline für den Piloten.

    2. Compliance-Anforderungen des EU AI Act analysieren.
      Klassifiziere den Use Case nach Risikostufe (Anhang III). Für HR und Recruiting gilt „Hohes Risiko“; für interne Wissenssuche meist „Minimales Risiko“. Dokumentiere die Pflichten aus Art. 4, 13 und 14.

    3. Datenbasis für die RAG-Pipeline bereinigen.
      Sammle alle relevanten Dokumente (HR-Richtlinien, Prozessbeschreibungen, FAQ). Entferne veraltete oder widersprüchliche Inhalte. Definiere die Berechtigungen (wer darf welche Dokumente sehen?).

    4. pgvector-Infrastruktur aufsetzen.
      Installiere PostgreSQL mit der pgvector-Erweiterung. Erzeuge die Tabelle für die Vektoren und die Metadaten (Quelle, Datum, Berechtigung). Teste die Latenz der Similarity-Suche (Ziel: < 50 ms).

    5. Embedding-Modell und LLM auswählen.
      Wähle ein Embedding-Modell (z. B. BGE-M3 oder OpenAI text-embedding-3-small) und ein LLM (OpenAI GPT-4o oder Anthropic Claude 3.5 Sonnet). Für sensible Daten: Open-Weight-Modell auf eigener Hardware.

    6. RAG-Pipeline entwickeln und testen.
      Implementiere die Pipeline: Frage → Embedding → pgvector-Suche → Top-K-Ergebnisse → Prompt mit Kontext → LLM-Antwort. Teste die Genauigkeit mit 20–30 typischen Fragen (Recall/Precision).

    7. Integration in Slack oder Microsoft Teams einrichten.
      Erstelle einen Bot, der auf Fragen im Chat antwortet. Konfiguriere die Webhooks und die Authentifizierung. Stelle sicher, dass die Antwort mit Quellenverweis geliefert wird.

    8. Predictive Scoring-Modell für HR vorbereiten.
      Definiere die Zielvariable (z. B. „Kandidat bleibt nach 6 Monaten“). Sammle historische Daten (Bewerbungen, Einstellungsdaten, Fluktuationsrate). Trainiere ein Modell (z. B. Random Forest oder XGBoost) und validiere es auf einer Testmenge.

    9. Pilotbetrieb mit kleiner Nutzergruppe starten.
      Wähle 5–10 HR-Mitarbeiter als Pilotgruppe. Sammle Feedback (Daumen-hoch/runter, Kommentare). Messe die Latenz, die Genauigkeit und die Akzeptanz. Dokumentiere alle Fehler und Korrekturen.

    10. Abnahme, Dokumentation und Übergabe an den Betrieb.
      Präsentiere die Ergebnisse (Vorher/Nachher: Cycle Time, Fehlerrate). Übergabe an den Betrieb: Monitoring-Setup, Schulung der Nutzer, Wartungsplan. Definiere die nächsten Schritte für die Skalierung auf weitere Abteilungen.

    Wartung und Weiterentwicklung der Checkliste

    Die Checkliste ist kein statisches Dokument, sondern ein lebendiger Prozess. Nach dem Piloten sollte sie quartalsweise überprüft und aktualisiert werden. Neue Compliance-Anforderungen (z. B. Änderungen am EU AI Act), neue Use Cases oder Feedback aus dem Betrieb fließen in die nächste Version ein. Wichtig: Die Baseline (Cycle Time, Fehlerrate) muss regelmäßig neu gemessen werden, um die Wirksamkeit der KI-Lösung zu belegen. Die Dokumentation der Entscheidungen (warum wurde dieses Modell gewählt? warum diese Datenquelle?) ist Teil des Audit-Trail und muss aufbewahrt werden. Bei der Skalierung auf weitere Abteilungen sollte die Checkliste angepasst werden: Jede Abteilung hat andere Daten, andere Compliance-Anforderungen und andere Nutzergruppen. Die Checkliste dient als Rahmen, der für jede Abteilung individuell gefüllt wird.

    Timeline: 8 Wochen vom Audit zur Abnahme

    Ein 8-Wochen-Pilot für eine interne KI-Wissenssuche in einem Unternehmen mit 201–500 Mitarbeitern im Healthcare- und Medtech-Bereich erfordert eine präzise Planung. Woche 1–2: Prozess-Audit und Datenanalyse. Welche Dokumente sind relevant? Welche Fragen stellen die HR-Mitarbeiter? Welche Fehlerquoten gibt es im Ist-Zustand? Woche 3–4: Infrastruktur-Setup. pgvector auf eigener Hardware (wegen Compliance), Embedding-Modell und LLM-Anbindung. Woche 5–6: Pilotbetrieb. 5–10 Nutzer, Feedback-Sammlung, Genauigkeitsmessung. Woche 7: Feinjustierung. Prompts verbessern, Retrieval-Logik anpassen, Fehler korrigieren. Woche 8: Abnahme und Übergabe. Dokumentation, Schulung, Monitoring-Setup. Der Scope ist fixiert: Ein Use Case (interne Wissenssuche), keine neuen Features während des Piloten. Die Kosten liegen typischerweise zwischen 15.000 und 30.000 EUR, je nach Komplexität und Infrastruktur.

  • KI-Ticket-Triage im Schweizer E-Commerce: 6 Wege zu 18 Minuten First-Response

    1. Automatisierung der Klassifizierung spart 9 Minuten pro Ticket

    Die manuelle Ticket-Verarbeitung bindet in einem 20-Personen-Unternehmen durchschnittlich 12 Minuten pro Ticket. Bei 500 Tickets pro Monat sind das 100 Stunden reiner Backoffice-Arbeit. Die KI-Triage reduziert diesen Aufwand auf 3 Minuten pro Ticket, da das Modell die Klassifizierung und den ersten Antwortentwurf in Sekunden erstellt. Der Mitarbeiter prüft nur noch den Entwurf und gibt ihn frei. Diese Zeitersparnis ist der direkteste Hebel, um die First-Response Time von 4,2 Stunden auf 18 Minuten zu senken, ohne zusätzliche Personalressourcen zu binden.

    2. OpenAI API liefert 92 % Klassifizierungsqualität für deutsche Tickets

    Die OpenAI API (GPT-4o) klassifiziert deutsche Support-Tickets mit einer Genauigkeit von über 92 %. Das Modell erkennt Nuancen wie „Lieferung verzögert sich“ versus „Lieferung fehlt komplett“ und ordnet sie korrekt der Kategorie „Logistik“ zu. Im Vergleich zu lokalen Open-Weight-Modellen ist die Cloud-API bei der deutschen Grammatik deutlich überlegen. Da es sich um keine Gesundheits- oder Finanzdaten handelt, ist die Verarbeitung in der Cloud aus Compliance-Sicht unproblematisch, solange die Daten nicht für das Training der Modelle verwendet werden.

    3. Google Workspace-Integration eliminiert manuelle Weiterleitung

    Die Integration in Google Workspace erfolgt über die Gmail-API und die Google Chat-API. Eingehende Support-Mails werden automatisch geparst, von der KI klassifiziert und an die zuständigen Teams in Google Chat weitergeleitet. Die Berechtigungen im Google Admin Console werden präzise auf die benötigten Scope-Bereiche beschränkt. Diese Integration eliminiert die manuelle Weiterleitung und stellt sicher, dass jedes Ticket innerhalb von 30 Sekunden beim zuständigen Mitarbeiter landet, ohne dass dieser die E-Mail-Postbox manuell prüfen muss.

    4. EU AI Act: Transparenzpflicht bei begrenztem Risiko

    Der EU AI Act klassifiziert die Ticket-Triage als „begrenztes Risiko“. Das bedeutet: Transparenz sicherstellen (Nutzer müssen wissen, dass sie mit einer KI interagieren) und keine diskriminierenden Algorithmen einsetzen. Da keine biometrische Identifizierung oder kritische Infrastruktur betroffen ist, fallen die strengen Pflichten für „hohe Risiken“ nicht an. Dennoch sollten Sie die Datenverarbeitung DSGVO-konform gestalten und die Modellentscheidungen nachvollziehbar dokumentieren. Für Schweizer Unternehmen gilt die DSGVO über die bilateralen Abkommen, daher ist die Compliance-Pflicht identisch.

    5. Sechs-Monats-Timeline: Von Pilot zu Vollausrollung

    Die Implementierung erfolgt in drei Phasen über sechs Monate. Phase 1 (Monat 1-2): Prozess-Audit und Definition der Triage-Regeln. Phase 2 (Monat 3-4): Pilotbetrieb mit 20 % des Ticketvolumens, Validierung der Klassifizierungsqualität und Anpassung der Prompts. Phase 3 (Monat 5-6): Vollausrollung auf 100 % des Volumens, Schulung der Mitarbeiter und Übergabe an das Managed Operations. In der Pilotphase wird die Genauigkeit wöchentlich gemessen und die Prompts iterativ verbessert, bis eine Mindestgenauigkeit von 90 % erreicht ist.

    6. Kostenrahmen: 15.000 bis 25.000 CHF für den Pilotbetrieb

    Die Kosten setzen sich aus drei Komponenten zusammen: Erstens die Lizenzkosten für die OpenAI-API, die bei 500 Tickets pro Monat und 500 Tokens pro Anfrage bei ca. 15 bis 30 CHF/Monat liegen. Zweitens die Implementierungskosten für die Workflow-Orchestration und die Google-Workspace-Integration, die bei einem Pilotprojekt für 11-50 Mitarbeiter typischerweise zwischen 15.000 und 25.000 CHF betragen. Drittens die laufenden Betriebskosten für das Managed AI Operations, die je nach Support-Volumen und SLA-Anforderungen zwischen 500 und 1.500 CHF/Monat liegen.

  • KI-Automatisierung im E-Commerce: 12-Punkte-Checkliste für die Schweiz

    1. Prozess-Audit und Datenklassifizierung

    Bevor der erste Code geschrieben wird, muss der Prozess-Audit abgeschlossen sein. Dieser Audit identifiziert die Workflows, die sich für die Automatisierung eignen, und klassifiziert die Daten nach Sensitivität. Für ein E-Commerce-Unternehmen mit 2000+ Mitarbeitern in der Schweiz bedeutet das: Die Retourenbearbeitung, die Kundenanfragen und die interne Wissenssuche werden auf ihre Zykluszeit und Fehlerquote gemessen. Die Ergebnisse fließen in die Architektur-Planung ein. Ohne diesen Audit fehlt die Baseline, an der der Erfolg des Piloten gemessen wird. Der Audit dauert 2-3 Wochen und wird von Forfis als Teil des fixen Scopes durchgeführt.

    2. Modell-Auswahl und Architektur-Planung

    Die Architektur muss model-agnostic sein, um die Compliance-Anforderungen zu erfüllen. Für Workflows mit regulierten Daten, die nicht das Gebäude verlassen dürfen, werden Open-Weight-Modelle auf der eigenen Hardware des Kunden betrieben. Für Workflows, bei denen die Qualität entscheidend ist, werden die APIs von OpenAI oder Anthropic genutzt. Die Entscheidung fällt auf Basis der Datenklassifizierung aus dem Prozess-Audit. Diese Trennung ist im EU AI Act vorgeschrieben und wird bei Forfis standardmäßig implementiert. Die Architektur wird in der Planungsphase dokumentiert und vom Kunden freigegeben.

    3. pgvector-Installation und Embedding-Erstellung

    pgvector wird auf der bestehenden PostgreSQL-Instanz oder einem separaten Cluster installiert. Die Embeddings werden für alle Dokumente in der internen Wissensdatenbank erstellt, einschließlich Handbücher, Vertragsklauseln und CRM-Notizen. Die Embeddings werden in der Sprache der Dokumente erstellt, um die Mehrsprachigkeit zu gewährleisten. Die Installation dauert 1-2 Tage und wird von Forfis durchgeführt. Die Qualität der Embeddings wird in einem Testlauf mit 50 zufällig ausgewählten Anfragen geprüft.

    4. REST-API und Webhook-Integration

    Die REST-APIs und Webhooks werden für das CRM, das ERP und den Helpdesk konfiguriert. Die Webhooks werden so eingerichtet, dass sie bei neuen Kundenanfragen, Retouren oder Dokumenten ausgelöst werden. Die REST-APIs werden für den Zugriff auf die bestehenden Daten genutzt. Die Konfiguration dauert 3-5 Tage und setzt voraus, dass die API-Zugänge vor Projektstart bereitstehen. Die Integration wird in einem Testlauf mit 20 zufällig ausgewählten Anfragen geprüft.

    5. Predictive Scoring-Modelle trainieren

    Die Predictive Scoring-Modelle werden für die Klassifizierung von Kundenanfragen und die Vorhersage von Retouren trainiert. Die Modelle werden auf den historischen Daten aus dem CRM und dem ERP trainiert. Die Qualität der Modelle wird in einem Testlauf mit 100 zufällig ausgewählten Anfragen geprüft. Das Training dauert 1-2 Wochen und wird von Forfis durchgeführt. Die Modelle werden in der Planungsphase dokumentiert und vom Kunden freigegeben.

    6. Human-in-the-Loop-Schleife konfigurieren

    Die Human-in-the-Loop-Schleife wird für alle Workflows konfiguriert, die Geld, Gesundheitsdaten oder Verträge betreffen. Die KI erstellt den Vorschlag, ein Mensch prüft ihn gegen die Vertragsklauseln und gibt ihn frei. Die Freigabe wird im System protokolliert. Diese Schleife ist im EU AI Act für Hochrisiko-Systeme vorgeschrieben und wird bei Forfis standardmäßig implementiert. Die Konfiguration dauert 2-3 Tage und wird in der Planungsphase dokumentiert.

    7. EU AI Act-Compliance prüfen

    Die Compliance-Prüfung wird parallel zum Pilot durchgeführt. Die Prüfung umfasst die Klassifizierung der KI-Systeme, die Dokumentation der Risikobewertung und die Überprüfung der Datenschutzbestimmungen. Die Ergebnisse werden in einem Compliance-Report dokumentiert. Die Prüfung dauert 2-3 Wochen und wird von Forfis in Zusammenarbeit mit einem externen Compliance-Berater durchgeführt. Der Report wird dem Kunden vor dem Rollout übergeben.