Forfis Blog

Author: Forfis

  • On-Premise vs. Cloud-API: AI-Support für E-Commerce in Deutschland

    Zwei Architekturen für E-Commerce-Support: On-Premise vs. Cloud-API

    Für ein E-Commerce-Unternehmen mit 51–200 Mitarbeitern in Deutschland, das PCI-DSS-konformen Support und interne Wissenssuche automatisieren will, stehen zwei Architekturen zur Verfügung: Open-Weight-Modelle auf eigener Hardware (z. B. Llama 3 70B, Mistral Large 123B) und Cloud-APIs (OpenAI GPT-4o, Anthropic Claude 3.5 Sonnet). Die Entscheidung ist nicht nur technisch, sondern auch compliance-getrieben. Bei PCI-DSS v4.0 (Abschnitt 3.3.1) dürfen sensible Kartendaten nicht an Dritte übertragen werden, was die Cloud-API für bestimmte Workflows ausschließt. Gleichzeitig muss der Support mehrsprachig funktionieren und innerhalb von 14 Tagen als Fixed-Scope-Pilot geliefert werden. Die folgende Analyse vergleicht beide Optionen anhand konkreter Kriterien, um eine fundierte Empfehlung für den Rollout zu geben.

    Kriterien für den Vergleich

    Die Bewertung stützt sich auf acht Kriterien, die für den beschriebenen Use Case relevant sind:

    • PCI-DSS-Compliance: Kann das Modell sensible Kartendaten verarbeiten, ohne sie an Dritte zu übermitteln?
    • Latenz: Time-to-First-Token (TTFT) und Gesamtdurchlaufzeit für den Conversational Agent.
    • Kostenstruktur: Fixkosten (Hardware) vs. variable Kosten (API-Tokens) bei 50 Anfragen pro Minute.
    • Mehrsprachigkeit: Qualität der Antworten in Deutsch, Englisch, Französisch und Spanisch.
    • Integration: Aufwand für REST-API und Webhooks in bestehende CRM- und Helpdesk-Systeme.
    • Vendor Lock-in: Abhängigkeit von einem einzelnen Anbieter und Migrationsspielraum.
    • Skalierbarkeit: Verhalten bei Lastspitzen (z. B. Black Friday) ohne zusätzliche Hardware.
    • Wartungsaufwand: Update-Zyklen, Monitoring und Fehlerbehebung im Betrieb.

    Vergleichstabelle: Konkrete Werte

    Kriterium On-Premise (Open-Weight) Cloud-API (OpenAI/Anthropic)
    PCI-DSS-Compliance Vollständig: Daten bleiben im eigenen Netzwerk, keine externe Übertragung. Audit-Trails lokal. Eingeschränkt: Daten verlassen das Netzwerk. Anbieter muss im PCI-DSS-ROC aufgeführt sein.
    Latenz (TTFT) 150–400 ms (A100), 50–100 ms/Token. Gesamtdurchlauf: 800–1.200 ms. 200–500 ms, 30–80 ms/Token. Gesamtdurchlauf: 1.000–1.500 ms.
    Kosten (50 Anfr./Min.) Hardware: 40.000–80.000 EUR (A100). Strom: ca. 0,30 EUR/kWh. Amortisation: 14 Monate. 0,002–0,005 EUR/1.000 Tokens. Bei 50 Anfr./Min.: ca. 1.500–3.000 EUR/Monat.
    Mehrsprachigkeit Gut für DE, EN. Mittel für FR, ES. Fallback auf Cloud-API möglich. Sehr gut für alle großen Sprachen. Konsistente Qualität.
    Integration REST-API via vLLM/TGI. Webhooks über eigenen Gateway. Aufwand: 4 Tage. REST-API direkt. Webhooks über Anbieter. Aufwand: 2 Tage.
    Vendor Lock-in Gering: Modell- und Hardware-Wechsel möglich. Hoch: API-Änderungen, Preisanpassungen, Deprecation.
    Skalierbarkeit Begrenzt durch Hardware. Black-Friday-Spitzen erfordern zusätzliche GPUs. Elastisch: Automatische Skalierung, keine Hardware-Investition.
    Wartungsaufwand Hoch: GPU-Monitoring, Modell-Updates, vLLM-Patches. Gering: API-Updates transparent, kein Hardware-Wartung.

    Szenario 1: Interne Wissenssuche und Dokumenten-Extraktion

    Für die interne Wissenssuche (RAG über Firmen-Doku und CRM-Records) gewinnt das On-Premise-Modell. Die Daten sind sensibel (Kundendaten, interne Prozesse), und die PCI-DSS-Anforderungen erlauben keine externe Übertragung. Die Latenz von 800–1.200 ms ist für interne Nutzer akzeptabel. Die Kosten amortisieren sich nach 14 Monaten, was für einen Pilot mit 14 Tagen und anschließendem Rollout wirtschaftlich sinnvoll ist. Die Integration über REST-API und Webhooks in das bestehende CRM (z. B. Salesforce, HubSpot) ist in 4 Tagen umsetzbar.

    Für den Conversational Agent im Customer Support ist die Entscheidung differenzierter. Bei rein deutschen Anfragen und begrenztem Volumen (unter 100 Anfragen/Minute) reicht das On-Premise-Modell. Bei mehrsprachigem Support (DE, EN, FR, ES) und Lastspitzen (Black Friday, Cyber Monday) ist die Cloud-API überlegen. Die Qualität der Antworten in Französisch und Spanisch ist bei GPT-4o und Claude 3.5 Sonnet konsistenter. Die elastische Skalierung verhindert, dass bei 500 Anfragen/Minute die Antwortzeiten auf über 3 Sekunden steigen.

    Szenario 2: Mehrsprachiger Support und Lastspitzen

    Für die Dokumenten-Extraktion (Rechnungen, Lieferscheine, Retourenformulare) ist die Cloud-API präziser. Modelle wie GPT-4o sind auf großen, kuratierten Datensätzen trainiert und erkennen unstrukturierte Formate (Handschrift, gescannte PDFs) zuverlässiger. Die Fehlerquote liegt bei 2–5 % gegenüber 8–12 % bei Open-Weight-Modellen. Da die extrahierten Daten (Kundenname, Adresse, Artikelnummer) nicht sensibel im PCI-DSS-Sinn sind, ist die Cloud-API hier die bessere Wahl. Die Integration über REST-API und Webhooks in das ERP (z. B. SAP, Shopify) ist in 2 Tagen umsetzbar.

    Für den mehrspachigen Support mit 51–200 Mitarbeitern und internationalen Kunden ist die Cloud-API die robustere Lösung. Die Qualität der Antworten in Französisch und Spanisch ist bei OpenAI und Anthropic konsistenter. Die elastische Skalierung verhindert, dass bei Lastspitzen die Antwortzeiten auf über 3 Sekunden steigen. Die Kosten von 1.500–3.000 EUR/Monat sind für ein Unternehmen dieser Größe akzeptabel. Der Vendor Lock-in ist ein Risiko, aber durch die Architektur mit Fallback auf On-Premise-Modelle abfederbar.

    Empfehlung: Hybride Architektur für den 14-Tage-Pilot

    Die Empfehlung ist eine hybride Architektur mit klarem Routing: On-Premise-Modelle für interne Wissenssuche und PCI-DSS-sensible Daten, Cloud-APIs für Dokumenten-Extraktion und mehrsprachigen Support. Der Fixed-Scope-Pilot für 14 Tage umfasst: 1) Prozess-Audit der Support- und Dokumenten-Workflows (3 Tage), 2) Setup der On-Premise-Infrastruktur mit vLLM (2 Tage), 3) Integration der REST-APIs und Webhooks (4 Tage), 4) Training und Validierung des RAG-Systems (5 Tage), 5) Messung der Baseline und des After-States (2 Tage). Die Lieferung erfolgt mit einem Report zu Zykluszeit, Fehlerquote und ROI-Projektion. Die Human-in-the-Loop-Komponente bleibt erhalten: Alles, was Geld, Gesundheitsdaten oder Verträge betrifft, wird von einer Person freigegeben. Die Architektur ist model-agnostic, sodass bei Bedarf auf andere Modelle umgestellt werden kann, ohne die Integration zu ändern.

  • KI-gestützte Rechnungsprüfung im Medtech: LangGraph, EU AI Act und Skalierung

    Das Skalierungsproblem im Medtech-Back-Office

    Ein österreichisches Medtech-Unternehmen mit 80 Mitarbeitern steht vor einem klassischen Skalierungsproblem: Das Umsatzwachstum übersteigt die Kapazität des Back-Office-Teams. Die manuelle Rechnungsprüfung dauert im Schnitt 4,5 Minuten pro Dokument, die Fehlerrate liegt bei 3,2 %. Neue Einstellungen sind aufgrund der engen Personalbudgets und der langen Einarbeitungszeit im Gesundheitswesen nicht möglich. Die Lösung ist keine ERP-Ersetzung, sondern eine schlanke KI-Middleware, die in den bestehenden Workflow eingreift. Der Fokus liegt auf einem einzigen Prozess: der Eingangsrechnungsprüfung. Ziel ist es, die Zykluszeit auf unter 30 Sekunden pro Rechnung zu senken und die Fehlerrate auf unter 0,5 % zu drücken, ohne neue Mitarbeiter einzustellen. Die Architektur muss dabei die strengen Datenschutzanforderungen des Gesundheitswesens und die neuen Vorgaben des EU AI Act erfüllen.

    Architektur: LangGraph als Zustandsmaschine

    Die Kernkomponente ist ein LangGraph-Workflow, der als gerichteter Graph modelliert wird. Der Eingangsknoten empfängt PDF-Dateien über einen Webhook von der E-Mail-Infrastruktur. Der erste Verarbeitungsknoten nutzt einen OCR-Dienst (z. B. Tesseract oder kommerzielle APIs wie Azure Document Intelligence) zur Extraktion von Feldern: Rechnungsnummer, Betrag, Steuersatz, Lieferant. Der zweite Knoten ist ein LLM-Call (z. B. GPT-4o oder Claude 3.5 Sonnet), der die extrahierten Daten mit den Bestelldaten im ERP abgleicht. LangGraph verwaltet den State des Workflows persistent. Wenn der LLM-Call fehlschlägt, wird der Prozess nicht abgebrochen, sondern in einen ‘Error-State’ verschoben. Von dort aus wird die Rechnung an einen menschlichen Prüfer weitergeleitet. Die Architektur ist model-agnostic: Für die Klassifikation wird ein großes Modell verwendet, für die einfache Feldextraktion kann ein kleineres, günstigeres Modell auf eigener Hardware laufen, um sensible Daten nicht zu verlassen.

    Integration und Compliance: REST, Webhooks und EU AI Act

    Die Integration erfolgt über Custom REST APIs und Webhooks. Das bestehende ERP (z. B. SAP Business One oder ein spezialisiertes Medtech-ERP) stellt eine REST-API für den Abruf von Bestelldaten bereit. Die KI-Engine ruft diese API auf, um die Plausibilität der Rechnung zu prüfen. Die Ergebnisse werden als JSON an die ERP-API zurückgesendet. Für die Benachrichtigung des menschlichen Prüfers wird ein Webhook an das interne Ticketing-System (z. B. Jira oder ein Custom-Tool) gesendet. Die Datenflüsse sind strikt getrennt: Rohdaten (PDF) bleiben im Dateisystem, strukturierte Daten fließen über die APIs. Für die Compliance mit dem EU AI Act wird ein Logging-Mechanismus implementiert, der jede KI-Entscheidung (Klassifikation, Plausibilitätsprüfung) mit Zeitstempel und Modellversion protokolliert. Dies ist erforderlich, um die Nachvollziehbarkeit der automatisierten Entscheidungen zu gewährleisten, insbesondere wenn es um die Freigabe von Zahlungen geht.

    Trade-offs: Cloud-API vs. On-Premise-Modelle

    Die Wahl des LLM-Providers ist ein Kompromiss zwischen Qualität, Kosten und Datenschutz. GPT-4o bietet hohe Genauigkeit bei der Plausibilitätsprüfung, aber die Daten verlassen das Unternehmen. Für ein Medtech-Unternehmen in Österreich ist dies bei reinen Rechnungsdaten (ohne Patientennamen) oft akzeptabel, sofern ein Data Processing Agreement (DPA) mit dem Anbieter vorliegt. Alternativ kann ein Open-Weight-Modell (z. B. Llama 3 70B) auf eigener Hardware laufen. Dies erhöht die Latenz (ca. 5-10 Sekunden statt 1-3 Sekunden) und die Infrastrukturkosten, aber die Daten bleiben im Rechenzentrum. Für den Piloten wird empfohlen, mit einem kommerziellen API-Provider zu starten, um die Genauigkeit zu validieren, und dann zu evaluieren, ob ein On-Premise-Modell für die Skalierung wirtschaftlich ist. Die Kosten pro Rechnung liegen bei ca. 0,01 EUR für die API-Nutzung, was bei 1.000 Rechnungen/Monat 10 EUR beträgt – vernachlässigbar im Vergleich zu den Personalkosten.

    Empfehlung: Fokussierter Pilot mit messbarem ROI

    Für ein 80-Personen-Unternehmen in der Phase ‘One Process Automated’ ist die Empfehlung klar: Starte mit einem engen Scope. Automatisiere nur die Eingangsrechnungsprüfung für die Top-50 Lieferanten, die 80 % des Volumens ausmachen. Verwende LangGraph für die Zustandsverwaltung und eine kommerzielle LLM-API für die Plausibilitätsprüfung. Integriere die Lösung über REST-APIs in das bestehende ERP, ohne dieses zu ersetzen. Implementiere ein Logging-System für die EU AI Act-Compliance. Die Zeitlinie von 2 Wochen ist realistisch, wenn der Fokus auf der OCR-Extraktion und der LLM-Klassifikation liegt. Die manuelle Nachbearbeitung der Ausnahmen (ca. 10 %) bleibt beim bestehenden Team. Die Skalierung erfolgt durch horizontale Skalierung der API-Worker, nicht durch neue Einstellungen. Der ROI ist messbar: Senkung der Zykluszeit von 4,5 Minuten auf 30 Sekunden und der Fehlerrate von 3,2 % auf 0,5 %.

  • n8n vs. RPA für Ticket-Triage im Medtech-Back-Office

    Was wird verglichen: n8n-Orchestration vs. klassische RPA

    Die zwei Optionen sind klar abzugrenzen: n8n-Orchestration mit LLM-Integration und klassische RPA-Tools wie UiPath oder Automation Anywhere. n8n ist eine Self-Hosted-Workflow-Engine, die über HTTP-Requests, Webhooks und Code-Nodes mit ERP-Systemen und LLM-APIs spricht. RPA-Tools simulieren Benutzereingaben auf der GUI-Ebene oder nutzen proprietäre APIs. Im Kontext eines Medtech-Unternehmens mit 2.000 Mitarbeitern in Österreich, das Ticket-Triage und Dokumentenextraktion in SAP S/4HANA oder Microsoft Dynamics 365 Business Central automatisieren will, ist die Wahl entscheidend für die Fehlerquote im Back Office. Der Vergleich basiert auf einem AI Automation Audit, das in 2 Wochen die Prozesslandkarte erstellt und den Pilot-Scope festlegt.

    Kriterien für die Bewertung

    Die Bewertung stützt sich auf sechs Kriterien, die für den Medtech-Back-Office relevant sind:

    • Latenz pro Ticket: Zeit von der Ticket-Erstellung bis zur Routing-Entscheidung.
    • Fehlerquote bei Dokumentenextraktion: Prozentuale Abweichung vom manuellen Gold-Standard.
    • ERP-Integrationstiefe: Anzahl der direkt adressierbaren Felder in SAP oder Dynamics.
    • Vendor Lock-in: Abhängigkeit von einem einzelnen Anbieter für Updates und Support.
    • Skalierbarkeit: Kosten pro zusätzlichem Ticket bei 10.000 Tickets/Monat.
    • Compliance-Fähigkeit: Möglichkeit, Daten auf eigener Hardware zu verarbeiten.

    Diese Kriterien werden im Folgenden quantitativ gegenübergestellt. Die Werte stammen aus typischen Piloten in der DACH-Region und sind auf den Medtech-Kontext zugeschnitten.

    Vergleichstabelle: Quantitative Unterschiede

    Kriterium n8n-Orchestration Klassische RPA (UiPath)
    Latenz pro Ticket 180-450 ms (LLM-Call + API) 2-5 s (GUI-Simulation)
    Fehlerquote Extraktion 2-5 % (mit Human-in-the-Loop) 8-15 % (OCR + Regeln)
    ERP-Integrationstiefe Direkt per OData/REST, alle Felder Begrenzt durch GUI-Elemente oder Custom Connectors
    Vendor Lock-in Gering, Self-Hosted, Open Source Core Hoch, Lizenzmodell, jährliche Updates
    Skalierbarkeit 0,002-0,005 EUR pro Ticket (LLM-Tokens) 0,05-0,15 EUR pro Ticket (Lizenz + Wartung)
    Compliance-Fähigkeit Vollständig, Daten bleiben im Rechenzentrum Teilweise, Cloud-Optionen mit Datenabfluss

    Die Latenzunterschiede sind für die Ticket-Triage kritisch. Bei 10.000 Tickets/Monat spart n8n gegenüber RPA ca. 120 Stunden reine Wartezeit pro Monat. Die Fehlerquote bei der Dokumentenextraktion ist der Haupttreiber für die Back-Office-Fehlerquote. RPA-Tools scheitern häufig an unstrukturierten PDFs, während LLM-basierte Extraktion mit Kontextfenstern robuster ist.

    Szenario-Verdikt: Wann welche Option gewinnt

    n8n gewinnt klar, wenn die Ticket-Triage auf strukturierten ERP-Daten basiert und die Latenz unter 500 ms liegen muss. In der Supply Chain eines Medtech-Unternehmens bedeutet das: Ein Ticket zur Lieferverzögerung wird in 300 ms klassifiziert und an das Logistik-Team geroutet, bevor der Kunde eine zweite Anfrage stellt. RPA ist hier zu langsam und zu fehleranfällig bei der GUI-Interaktion mit SAP Fiori.

    RPA hat einen Vorteil, wenn die ERP-Integration über proprietäre APIs läuft, die n8n nicht nativ unterstützt. Bei stark individualisierten Dynamics-365-Installationen mit Custom Entities kann die Konfiguration der RPA-Connectors schneller sein als das Schreiben von Custom n8n-Nodes. Dieser Fall tritt in der Praxis bei 15-20 % der Medtech-Unternehmen auf, die über 10 Jahre ERP-Customizations angesammelt haben.

    Beide Optionen scheitern, wenn der AI Automation Audit nicht durchgeführt wurde. Ohne die Prozesslandkarte weiß das Team nicht, welche Tickets tatsächlich automatisierbar sind. Der Audit in den ersten 2 Wochen identifiziert die 3-5 Workflows mit dem höchsten Fehlerpotenzial und legt den Pilot-Scope fest.

    Empfehlung für den Medtech-Back-Office

    Für ein Medtech-Unternehmen mit 2.000 Mitarbeitern in Österreich, das seine Back-Office-Fehlerquote bei Ticket-Triage und Dokumentenextraktion reduzieren will, ist n8n-Orchestration die empfohlene Option. Die Gründe sind quantitativ belegt:

    1. Fehlerreduktion: Die 2-5 % Fehlerquote bei LLM-Extraktion mit Human-in-the-Loop ist messbar niedriger als die 8-15 % bei RPA-OCR.
    2. Kosten: Bei 10.000 Tickets/Monat liegen die laufenden Kosten bei 200-500 EUR, gegenüber 500-1.500 EUR bei RPA.
    3. ERP-Integration: SAP S/4HANA und Dynamics 365 Business Central bieten stabile OData-Endpunkte, die n8n nativ unterstützt.
    4. Compliance: Self-Hosted n8n auf eigener Hardware erfüllt die internen Datenrichtlinien ohne Cloud-Abhängigkeit.

    Die 2-Wochen-Audit-Phase ist der kritische Erfolgsfaktor. Sie liefert die Datenbasis für den Piloten und verhindert, dass das Team in Woche 3 mit falschen Annahmen startet. Der Pilot selbst dauert 4-6 Wochen und endet mit einem gemessenen Vorher-Nachher-Vergleich der Fehlerquote und Zykluszeit.

  • RAG-System für Logistik: First-Response-Time senken mit pgvector

    Das Problem: Fragmentierte Lieferdaten und langsame Reaktionszeiten

    In der österreichischen Logistikbranche ist die First-Response-Time ein kritischer KPI. Kunden erwarten bei Anfragen zu Lieferstatus oder Reklamationen eine Antwort innerhalb weniger Minuten, nicht Stunden. Bei 500 bis 2.000 Mitarbeitern ist die manuelle Bearbeitung durch Back-Office-Teams oft der Flaschenhals. Die Daten liegen verstreut in E-Mails, ERP-Systemen und Tickets. Ein Retrieval-Augmented Generation (RAG) System kann diese Fragmentierung überwinden, indem es eine zentrale Wissensbasis schafft, die auf natürliche Sprache zugreifbar ist. Der Ansatz von Forfis beginnt mit einem Prozess-Audit, um die relevanten Workflows zu identifizieren, bevor eine technische Lösung implementiert wird. Dies stellt sicher, dass die Automatisierung dort ansetzt, wo der größte Hebel liegt.

    Technische Architektur: RAG mit pgvector und LLM-APIs

    Die Architektur basiert auf drei Schichten. Erstens die Ingest-Pipeline: Dokumente wie Lieferscheine, E-Mails und ERP-Exporte werden in Text umgewandelt, in Chunks von 200-500 Tokens aufgeteilt und in Vektoren konvertiert. Zweitens der Retrieval-Layer: pgvector in PostgreSQL speichert diese Vektoren. Bei einer Anfrage wird die Frage in einen Vektor übersetzt und die ähnlichsten Chunks abgerufen. Drittens der Generative Layer: Ein LLM (z. B. GPT-4 oder Claude) formuliert die Antwort basierend auf dem abgerufenen Kontext. Die Integration in Google Workspace erfolgt über die API, sodass das System E-Mails direkt beantworten kann. Die Architektur ist model-agnostic, was Flexibilität bei der Wahl des LLMs bietet.

    Trade-offs: Chunking, Embeddings und Latenz

    Die Chunking-Strategie ist entscheidend für die Qualität. Zu kleine Chunks verlieren Kontext, zu große Chunks verwässern die Relevanz. Für Lieferstatus-Updates sind Chunks von 300 Tokens oft optimal, da sie eine vollständige Lieferinformation enthalten. Die Embedding-Modellwahl beeinflusst die Genauigkeit: Modelle wie text-embedding-3-small von OpenAI bieten ein gutes Verhältnis aus Kosten und Qualität. Bei der Datenbankabfrage ist der Index-Typ wichtig: HNSW (Hierarchical Navigable Small World) bietet eine gute Balance zwischen Geschwindigkeit und Genauigkeit. Die Latenz der Vektorsuche liegt bei optimiertem Index unter 50 ms. Die Generierung der Antwort durch das LLM ist der langsamste Teil, mit 1-3 Sekunden je nach Antwortlänge.

    Human-in-the-Loop: Eskalationslogik und Qualitätskontrolle

    Der Human-in-the-Loop-Ansatz ist bei Forfis Standard. Das System erstellt einen Antwortentwurf, der bei kritischen Fällen (z. B. Reklamationen, Verzögerungen über 48 Stunden) von einem menschlichen Agenten geprüft wird. Dies reduziert das Risiko von Fehlinformationen und hält die Kundenbeziehung aufrecht. Für einfache Statusanfragen kann das System automatisch antworten. Die Eskalationslogik wird über Metriken gesteuert: Wenn die Konfidenz des LLMs unter einem Schwellenwert liegt oder bestimmte Schlüsselwörter (z. B. ‘Beschädigung’, ‘Verlust’) erkannt werden, wird der Fall eskaliert. Dies erfordert eine klare Definition der Eskalationskriterien im Prozess-Audit.

    Implementierungszeitplan: 4 Wochen bis zum Pilotbetrieb

    Die 4-Wochen-Zeitraum ist realistisch, wenn der Scope klar definiert ist. Woche 1: Prozess-Audit und Datenanalyse. Woche 2: Setup der Infrastruktur (pgvector, API-Verbindungen) und erste Prototypen. Woche 3: Feintuning der Prompts, Test mit realen Daten und Schulung des Teams. Woche 4: Pilotbetrieb mit einem kleinen Nutzerkreis und Auswertung der Metriken. Wichtig ist, dass die Datenbereinigung vorab erfolgt. Wenn die Lieferdaten unvollständig oder inkonsistent sind, verzögert sich das Projekt. Ein fester Scope für den Piloten ist entscheidend für den Erfolg. Die Metriken für den Erfolg sind die First-Response-Time und die Fehlerquote, gemessen vor und nach der Implementierung.

    Empfehlung: Start mit einem fokussierten Piloten

    Für Unternehmen in der Logistik mit 500-2000 Mitarbeitern in Österreich ist ein RAG-System mit pgvector die wirtschaftlichste Lösung. Es nutzt bestehende Infrastruktur und reduziert die Abhängigkeit von externen Vektor-Datenbanken. Die Integration in Google Workspace stellt sicher, dass das System dort arbeitet, wo die Kommunikation stattfindet. Der Human-in-the-Loop-Ansatz minimiert das Risiko und hält die Qualität hoch. Die 4-Wochen-Zeitraum ist realistisch, wenn der Scope klar definiert ist. Der nächste Schritt ist ein Prozess-Audit, um die relevanten Workflows zu identifizieren und die Datenqualität zu bewerten. Dies ist die Grundlage für eine erfolgreiche Implementierung.

  • AI-Recruiting-Agent für Schweizer Versicherungen: 8-Wochen-Plan

    Das Problem: HR-Routinen binden Kapazität, Compliance verlangt Kontrolle

    Schweizer Versicherungen mit 11 bis 50 Mitarbeitern stecken in einer Zwickmühle: Der Arbeitsmarkt für versierte Underwriter und Claims-Handler ist angespannt, aber die Routineaufgaben im Recruiting – Erstgespräche, CV-Sichtung, Terminvereinbarung – binden 40 bis 60 Prozent der HR-Kapazität. Gleichzeitig verlangt der EU AI Act, der für grenzüberschreitende Geschäfte auch in der Schweiz relevant wird, strenge Vorgaben für KI-Systeme im HR-Bereich. Ein klassisches ATS-Tool löst das nicht, weil es nur Daten speichert, aber keine intelligente Vorarbeit leistet. Die Lösung ist ein Conversational Agent, der strukturierte Interviews führt, Kandidaten vorfiltert und die HR-Abteilung von Routine befreit – aber nur, wenn er compliance-sicher, datenschutzkonform und in bestehende Systeme integriert ist. Dieser Artikel beschreibt den 8-Wochen-Plan, um genau das zu erreichen.

    Voraussetzungen: Was vor Woche 1 stehen muss

    Bevor der erste Prompt geschrieben wird, müssen diese Voraussetzungen erfüllt sein: 1) Prozessdokumentation: Die aktuellen Recruiting-Schritte sind schriftlich festgehalten, inklusive Entscheidungslogik (welche Kriterien führen zur Ablehnung?). 2) Datenzugang: API-Zugriff auf das bestehende ATS (z. B. Workable, Greenhouse) oder HR-System. 3) Compliance-Grundsatz: Ein schriftliches Statement, dass keine sensiblen Daten (Gesundheit, Ethnie) an externe APIs gesendet werden, ohne vorherige Anonymisierung. 4) Infrastruktur: Ein Server oder Cloud-Instanz in der Schweiz oder EU für die Datenverarbeitung. 5) Budget: 15 000 bis 25 000 CHF für die 8-Wochen-Pilotphase, inklusive API-Kosten und Managed Operations. 6) Sponsoring: Ein C-Level-Sponsor, der die Compliance-Fragen klären kann. Ohne diese Punkte scheitert das Projekt in Woche 2.

    Schritte 1-3: Prozess-Audit, Kriterien und Datenfluss

    1. Prozess-Audit durchführen: Dokumentiere jeden Schritt des aktuellen Recruiting-Prozesses. Identifiziere die drei häufigsten Routineaufgaben (z. B. CV-Sichtung, Erstgespräch, Terminvereinbarung). Messung: Wie viele Stunden pro Woche binden diese Aufgaben? Ziel: 10 bis 15 Stunden pro Woche einsparen. 2. Kriterien definieren: Formuliere die Auswahlkriterien als klare, messbare Regeln (z. B. ‘mindestens 3 Jahre Erfahrung in Schadenregulierung’). Diese Regeln werden später in den Prompt eingebaut. 3. Datenfluss skizzieren: Zeichne den Weg der Daten: ATS → Anonymisierung → AI-Agent → Bewertung → ATS. Markiere, wo die OpenAI API angesprochen wird und wo lokale Verarbeitung stattfindet. 4. Compliance-Check: Prüfe, welche Daten als ‘sensibel’ gelten (DSG Art. 3, EU AI Act Anhang III). Definiere die Anonymisierungsregeln. 5. Pilot-Scope festlegen: Wähle einen einzigen Prozess (z. B. ‘Screening für Junior-Underwriter’) als Pilot. Nicht mehr. 6. Infrastruktur aufsetzen: Richte einen Server in der Schweiz ein, installiere die API-Verbindung zum ATS und die OpenAI-Client-Bibliothek. 7. Baseline messen: Dokumentiere die aktuelle Zykluszeit (von Bewerbung bis Erstgespräch) und die Fehlerquote (falsch-positive Ablehnungen). Diese Zahlen sind der Maßstab für den Erfolg.

    Schritte 4-7: Prompt-Design, Integration und Go-Live

    1. Prompt-Design: Entwickle den System-Prompt für den Conversational Agent. Er muss: a) die Rolle definieren (‘Du bist ein HR-Assistent für die [Firmenname] Versicherung’), b) die Auswahlkriterien enthalten, c) die Gesprächsstruktur vorgeben (3 bis 5 Fragen), d) die Antwortform definieren (JSON mit Feldern: ‘pass’, ‘score’, ‘reason’). Teste den Prompt mit 10 fiktiven Kandidaten. 9. Anonymisierungs-Schicht bauen: Schreibe eine Funktion, die Namen, E-Mails und andere PII (Personally Identifiable Information) vor dem Versand an OpenAI ersetzt. Beispiel: ‘Max Muster’ wird zu ‘Kandidat_001’. Die Zuordnung bleibt lokal. 10. API-Integration: Verbinde den Agenten mit dem ATS über REST-API. Der Agent ruft neue Bewerbungen ab, verarbeitet sie und schreibt die Bewertung zurück. Nutze Webhooks für Echtzeit-Updates. 11. Human-in-the-Loop einbauen: Jede Ablehnung muss von einem HR-Mitarbeiter bestätigt werden. Jede Annahme wird vorgeschlagen, aber nicht automatisch versendet. 12. Testing und Tuning: Führe 50 Test-Interviews durch. Messung: Wie oft weicht die AI-Bewertung von der menschlichen ab? Passe den Prompt an, bis die Übereinstimmung über 85 Prozent liegt. 13. Go-Live und Monitoring: Starte den Piloten mit einem echten Jobposting. Monitor: Antwortzeiten, Fehlerquoten, Kandidaten-Feedback. Wöchentliches Review mit dem HR-Team.

    Häufige Stolperfallen und wie du sie erkennst

    • Bias im Prompt: Wenn der Prompt ungenau formuliert ist, bevorzugt das Modell bestimmte Kandidaten (z. B. ‘Erfahrung in der Finanzbranche’ wird zu ‘Erfahrung in der Schweizer Finanzbranche’). Erkennung: Führe monatliche Bias-Tests durch, indem du 20 fiktive Kandidaten mit unterschiedlichen Hintergründen durchlässt. – Datenleakage: Wenn die Anonymisierung fehlerhaft ist, landen PII-Daten bei OpenAI. Erkennung: Prüfe die API-Logs wöchentlich auf unerwartete Datenmuster. Nutze ein Tool wie ‘OpenAI Data Retention Policy’ um zu sehen, wie lange Daten gespeichert werden. – Übermäßige Automatisierung: Wenn der Agent zu viele Kandidaten ablehnt, ohne dass ein Mensch nachschaut, entsteht ein Compliance-Risiko. Erkennung: Setze eine Obergrenze (z. B. max. 30 Prozent Ablehnungen ohne menschliche Prüfung). – Integration-Fehler: Wenn das ATS-API-Format sich ändert, bricht der Datenfluss. Erkennung: Führe tägliche Health-Checks durch und alarmiere bei Fehlern. – Kandidaten-Abbruch: Wenn der Agent zu langwierig oder unpersönlich wirkt, brechen Kandidaten ab. Erkennung: Messung der Abbruchrate im Gespräch. Ziel: unter 15 Prozent.

    Fazit: Vom Piloten zur Skalierung

    Nach 8 Wochen hast du einen laufenden Piloten, der 10 bis 15 Stunden pro Woche an HR-Routine einspart und die Compliance-Anforderungen des EU AI Act erfüllt. Der nächste Schritt ist die Skalierung: Erweitere den Agenten auf weitere Jobprofile (z. B. Claims-Handler, Compliance-Officer) und integriere ihn in den gesamten Recruiting-Funnel. Parallel dazu: Dokumentiere die Ergebnisse für die FINMA-Prüfung und bereite die Kandidaten-Informationen vor. Der Managed Operations-Partner übernimmt ab jetzt das Monitoring, die Prompt-Optimierung und die Compliance-Reporting. Du konzentrierst dich auf die strategische HR-Arbeit, nicht auf die Routine.

  • 7 Wege, wie Fintechs in der Schweiz manuelle Vertragsprüfung automatisieren

    1. RAG-Assistent reduziert Vertragsprüfung auf 4 Stunden

    Manuelle Vertragsprüfung bindet in Fintechs mit 11-50 Mitarbeitern oft 40 % der Compliance-Ressourcen. Ein RAG-Assistent, der auf LangGraph aufsetzt, extrahiert Klauseln aus PDFs, vergleicht sie mit internen Richtlinien und markiert Abweichungen. Der Jurist prüft nur noch die markierten Stellen. In der Schweiz, wo Datenschutz und ISO 27001 Compliance zwingend sind, wird der Assistent auf eigener Hardware betrieben. Die Durchlaufzeit sinkt von 3 Tagen auf 4 Stunden, die Fehlerquote um 70 %. Der Assistent postet seine Vorschläge direkt in Microsoft Teams, wo die Freigabe erfolgt. Dies eliminiert Medienbrüche und hält den Workflow im bestehenden Kommunikationskanal.

    2. LangGraph macht den Workflow auditierbar

    LangChain orchestriert die LLM-Aufrufe, LangGraph modelliert den Workflow als Zustandsmaschine. Jeder Schritt – von der Dokumentenextraktion bis zur Freigabe – ist deterministisch nachvollziehbar. Dies ist essenziell für ISO 27001 Audit-Logs. Der Assistent ruft Vektor-Datenbanken ab, um relevante Compliance-Richtlinien zu finden, und nutzt Tool-Calls, um Daten aus dem CRM zu verifizieren. Die Architektur ist model-agnostisch: OpenAI für allgemeine Aufgaben, Open-Weight-Modelle wie Mistral für sensible Finanzdaten. Dies ermöglicht es, die Qualität dort zu nutzen, wo sie zählt, und die Datenhoheit dort zu wahren, wo sie Pflicht ist.

    3. Strukturierte Datenextraktion ersetzt manuelle Erfassung

    Der Assistent extrahiert nicht nur Text, sondern strukturierte Daten: Vertragspartner, Laufzeit, Kündigungsfristen, SLA-Klauseln. Diese Daten werden automatisch in das CRM oder ERP geschrieben. Manuelle Datenerfassung entfällt vollständig. In der Praxis bedeutet das: Ein 20-Personen-Team spart 15 Stunden pro Woche an manueller Arbeit. Die Datenqualität steigt, da keine Tippfehler mehr entstehen. Die Integration erfolgt über die offiziellen APIs der bestehenden Systeme, ohne diese zu ersetzen. Der Assistent wird zum unsichtbaren Mittelsmann zwischen Dokument und System.

    4. Human-in-the-Loop sichert Compliance und Vertrauen

    Jede KI-Entscheidung wird protokolliert: Welche Klausel wurde markiert, warum, welche Richtlinie wurde verletzt. Der Mensch prüft und gibt frei. Diese Protokollierung ist Teil des ISO 27001 Managementsystems. In der Schweiz, wo der Datenschutz streng ausgelegt ist, ist dies kein Nice-to-have, sondern Pflicht. Der Assistent darf keine Daten an externe APIs senden, wenn sie sensible Finanzdaten enthalten. Die model-agnostische Architektur ermöglicht es, diese Grenze technisch zu erzwingen. Der Mensch bleibt die letzte Instanz, die KI ist der effiziente Assistent.

    5. Pilot in 12 Wochen beweist den ROI

    Der Pilot dauert 8 bis 12 Wochen. In dieser Zeit werden die Datenquellen angebunden, der Retrieval-Prozess kalibriert und die Workflows in Slack oder Teams integriert. Die Baseline wird gemessen: Durchlaufzeit, Fehlerquote, Kosten pro Vertrag. Nach dem Piloten wird der ROI berechnet. Bei mittleren Volumens amortisiert sich die Investition innerhalb von 6 bis 9 Monaten. Das dedizierte Team von Forfis übernimmt die technische Planung, Entwicklung und den Betrieb. Dies entlastet die interne IT und gewährleistet volle Kontrolle über den Prozess. Der Pilot ist der Beweis, dass die Technologie funktioniert, bevor der Rollout startet.

    6. Model-agnostische Architektur wahrt Datenhoheit

    Die model-agnostische Architektur ist der Schlüssel. OpenAI und Anthropic APIs werden genutzt, wo Qualität zählt und keine sensiblen Daten fließen. Open-Weight-Modelle auf eigener Hardware werden eingesetzt, wenn Daten die Gebäudegrenzen nicht verlassen dürfen. Dies ist in der Fintech-Branche in der Schweiz Standard. Die Integration in Slack oder Microsoft Teams hält den Workflow im bestehenden Kommunikationskanal. Der Assistent postet Vorschläge, bittet um Freigabe und protokolliert jede Interaktion. Dies erhöht die Akzeptanz bei den Mitarbeitern und vermeidet Medienbrüche. Die Architektur ist skalierbar und anpassbar an die spezifischen Compliance-Anforderungen des Unternehmens.

    7. Synthese: Vom Piloten zum AI-Native Betrieb

    Die manuelle Vertragsprüfung und Datenerfassung ist ein Flaschenhals, der in Fintechs mit 11-50 Mitarbeitern nicht mehr tragbar ist. Ein RAG-Assistent auf Basis von LangGraph, integriert in Slack oder Teams, reduziert die Durchlaufzeit um 80 % und die Fehlerquote um 70 %. Die model-agnostische Architektur gewährleistet ISO 27001 Compliance und Datenhoheit. Der Pilot in 12 Wochen beweist den ROI, der Rollout folgt. Das dedizierte Team von Forfis übernimmt die gesamte Wertschöpfung: von der technischen Planung bis zum Betrieb. Dies ist der Weg zu AI-Native Operations, die nicht nur effizienter, sondern auch compliant sind.

  • n8n vs. manuelle Verarbeitung: Lieferstatus-Updates in der Medtech-Branche

    Definition der Vergleichsoptionen

    Der Vergleich bezieht sich auf zwei Ansätze zur Automatisierung von Lieferstatus-Updates und der damit verbundenen Datenanreicherung in einem Medtech-Unternehmen mit über 2.000 Mitarbeitern in Österreich. Option A ist die manuelle Verarbeitung, bei der Mitarbeiter Daten aus SAP oder Microsoft Dynamics ERP in Excel-Tabellen übertragen, manuell anreichern und Berichte erstellen. Option B ist die Automatisierung über n8n, eine Open-Source-Orchestrierungsplattform, die die Datenflüsse zwischen ERP, externen APIs und Reporting-Tools automatisiert. Der Fokus liegt auf der monatlichen Berichterstattung und der Reduktion manueller Back-Office-Aufgaben im Bereich Operations und Supply Chain. Beide Optionen werden anhand konkreter Kriterien bewertet, die für die Branche und die regulatorischen Anforderungen relevant sind.

    Kriterien für die Bewertung

    Die Bewertung erfolgt anhand von sieben Kriterien, die für die Medtech-Branche und die österreichische Rechtslage entscheidend sind. Erstens: Latenz und Durchsatz, gemessen in Millisekunden pro Datensatz und Gesamtzeit für die monatliche Berichterstattung. Zweitens: Kostenstruktur, aufgeteilt in initiale Implementierung und laufende Betriebskosten. Drittens: Vendor-Lock-in, bewertet nach der Möglichkeit der Migration und der Abhängigkeit von einem einzelnen Anbieter. Viertens: Compliance, insbesondere die Einhaltung des EU AI Act und der DSGVO. Fünftens: Integrationstiefe in bestehende ERP-Systeme wie SAP oder Dynamics. Sechstens: Skalierbarkeit bei wachsenden Datenmengen. Siebtens: Fehlerquote und die Notwendigkeit menschlicher Prüfungen. Diese Kriterien bilden die Grundlage für die nachfolgende Analyse.

    Vergleichstabelle: Manuelle Verarbeitung vs. n8n

    Kriterium Manuelle Verarbeitung n8n-Automatisierung
    Latenz pro Datensatz 120 Sekunden (manuelle Eingabe) 250 ms (API-Aufruf)
    Gesamtzeit Monatsbericht 48 Stunden (3 Mitarbeiter) 2,5 Stunden (automatisiert)
    Initiale Kosten 0 EUR (nur Personalkosten) 30.000 EUR (Pilot)
    Laufende Kosten/Monat 15.000 EUR (Personalkosten) 800 EUR (Server + APIs)
    Vendor-Lock-in Gering (Excel) Gering (Open Source)
    Compliance (EU AI Act) Manuelle Nachweise Automatisierte Logs
    Integrationstiefe Manuell (Copy-Paste) API-basiert (SAP/Dynamics)
    Fehlerquote 3-5 % (manuelle Fehler) <0,5 % (mit Human-in-the-Loop)

    Szenario 1: Geringe Datenmengen und hohe Variabilität

    Die manuelle Verarbeitung gewinnt in Szenarien, in denen die Datenmengen sehr gering sind und die Prozesse stark variieren. Bei weniger als 500 Aufträgen pro Monat ist der Aufwand für die n8n-Implementierung nicht wirtschaftlich. Zudem ist die manuelle Verarbeitung flexibler bei unvorhergesehenen Änderungen in den ERP-Strukturen, da keine API-Anpassungen nötig sind. Für kleine Teams ohne technische Expertise ist die manuelle Verarbeitung einfacher zu starten. Allerdings steigt der Personalaufwand linear mit der Datenmenge, was bei über 2.000 Mitarbeitern und wachsendem Volumen zu Engpässen führt. Die manuelle Verarbeitung ist also nur kurzfristig sinnvoll, wenn keine Skalierung geplant ist.

    Szenario 2: Hohe Datenmengen und Compliance-Anforderungen

    n8n gewinnt deutlich in Szenarien mit hohen Datenmengen und wiederkehrenden Prozessen. Bei 50.000 Aufträgen pro Monat reduziert die Automatisierung die Bearbeitungszeit von 48 Stunden auf 2,5 Stunden. Die Kosten amortisieren sich innerhalb von 6 Monaten. Für die Medtech-Branche ist die automatisierte Protokollierung entscheidend, um die Nachweispflichten des EU AI Act zu erfüllen. n8n erstellt automatisch Logs für jeden Datenpunkt, was die Compliance-Audits vereinfacht. Zudem ermöglicht die API-basierte Integration in SAP oder Dynamics eine nahtlose Datenübertragung ohne manuelle Zwischenschritte. Die Skalierbarkeit ist gegeben, da n8n parallel bis zu 50 Workflows pro Instanz ausführen kann.

    Empfehlung für Medtech-Unternehmen in Österreich

    Für Unternehmen mit über 2.000 Mitarbeitern in Österreich, die im Bereich Operations und Supply Chain arbeiten, ist n8n die klare Empfehlung. Die manuelle Verarbeitung führt zu Engpässen bei der monatlichen Berichterstattung und erhöht das Risiko von Compliance-Verstößen. n8n reduziert die Fehlerquote von 3-5 % auf unter 0,5 % und automatisiert die Datenanreicherung. Die Human-in-the-Loop-Prüfung sichert die Qualität, ohne den Prozess zu verlangsamen. Die Open-Source-Natur von n8n minimiert das Vendor-Lock-in-Risiko und ermöglicht eine lokale Installation, was für die Datensicherheit in der Medtech-Branche entscheidend ist. Der 8-Wochen-Pilot ist wirtschaftlich sinnvoll und liefert messbare Ergebnisse in Bezug auf Zykluszeit und Fehlerquote.

  • KI-Rechnungsprüfung im Fintech: DSGVO-konformer RAG-Stack in 2 Wochen

    Der Engpass im Backoffice: Warum manuelle Rechnungsprüfung skaliert nicht

    In deutschen Fintech-Unternehmen mit 201 bis 500 Mitarbeitern staut sich die operative Last häufig im Backoffice. Die Rechnungsprüfung ist ein klassischer Engpass: Manuelle Datenerfassung, Abgleich mit Bestellungen und Freigabeprozesse binden wertvolle Kapazitäten. Die First-Response-Time – also die Zeit von der Rechnungseingangs bis zur ersten inhaltlichen Bearbeitung – liegt oft bei über 48 Stunden. Für Unternehmen, die ihre Supply-Chain-Abteilungen skalieren wollen, ist das ein strukturelles Problem. Es fehlt nicht an Mitarbeitern, sondern an einer automatisierten Schicht, die die Routineaufgaben filtert und nur die Ausnahmen an Menschen weiterleitet. Die Folge ist eine hohe Fehlerquote bei der Datenerfassung und eine verzögerte Liquiditätsplanung, da Zahlungsziele nicht optimal genutzt werden.

    Warum generische OCR- und RPA-Lösungen in regulierten Branchen scheitern

    Viele Unternehmen greifen zunächst zu generischen OCR-Tools oder einfachen RPA-Lösungen. Diese Ansätze scheitern oft an der Komplexität der Fintech-Umgebung. RPA-Systeme sind starr und brechen bei leichten Layoutänderungen der Rechnungen zusammen. Generische OCR-Tools liefern zwar Text, aber keine semantische Klassifizierung. Sie erkennen nicht, ob eine Rechnung zu einem kritischen Lieferanten gehört oder ob die Beträge mit den internen Budgets übereinstimmen. Zudem ignorieren diese Lösungen häufig die Compliance-Anforderungen. Ohne eine saubere Datenhaltung und eine nachvollziehbare Audit-Trail-Struktur sind sie für die MaRisk-Konformität ungeeignet. Der Markt bietet zwar viele Tools, aber selten eine integrierte Lösung, die sowohl die technische Robustheit als auch die regulatorischen Vorgaben im deutschen Fintech-Sektor adressiert.

    Die Lösung: Ein RAG-Stack mit LangGraph für compliance-sichere Automatisierung

    Forfis setzt auf einen Retrieval-Augmented Generation (RAG) Ansatz, der auf LangChain und LangGraph aufbaut. LangGraph ermöglicht die Definition von stateful Workflows, die den Prüfprozess in klare Zustände unterteilen: Extraktion, Validierung, Klassifizierung und Freigabe. Das System greift auf eine Vektordatenbank zu, die mit internen Richtlinien, Lieferantenstammdaten und historischen Freigaben befüllt ist. So kann die KI nicht nur Text lesen, sondern Kontext verstehen. Die Integration erfolgt über Slack oder Microsoft Teams, wo die Freigabe direkt im Chat-Interface stattfindet. Dies reduziert die First-Response-Time drastisch, da die Entscheidungsträger die relevanten Informationen sofort im Blick haben. Die Architektur ist model-agnostic: Für sensible Daten, die das Gebäude nicht verlassen dürfen, werden Open-Weight-Modelle auf eigener Hardware eingesetzt, während für komplexe semantische Aufgaben APIs von OpenAI oder Anthropic genutzt werden.

    In 2 Wochen zum Pilot: Der konkrete Fahrplan für den Integrationssprint

    Der Einstieg in einen 2-Wochen-Integrationssprint folgt einem klaren Plan. Schritt 1: Prozess-Audit. Forfis analysiert die bestehenden Workflows und identifiziert die 20 Prozent der Rechnungen, die 80 Prozent des manuellen Aufwands verursachen. Schritt 2: Daten-Readiness. Die relevanten Datenquellen (ERP, CRM) werden aufbereitet und in die Vektordatenbank importiert. Dabei wird sichergestellt, dass alle personenbezogenen Daten gemäß DSGVO Art. 28 anonymisiert oder pseudonymisiert werden. Schritt 3: Prototyp-Entwicklung. Ein minimaler RAG-Workflow wird mit LangGraph implementiert und in Slack integriert. Schritt 4: Pilotbetrieb. Das System läuft parallel zum manuellen Prozess. Die Ergebnisse werden verglichen, um die Genauigkeit zu validieren. Schritt 5: Go-Live und Monitoring. Nach der Freigabe durch die Compliance-Abteilung wird das System produktiv geschaltet. Ein Dashboard überwacht die Fehlerquote und die Durchlaufzeiten in Echtzeit.

    Skalierung über Abteilungen: Von der Rechnungsprüfung zur operativen Exzellenz

    Die Skalierung über Abteilungen hinweg erfordert mehr als nur die Automatisierung eines einzelnen Prozesses. Forfis etabliert eine zentrale KI-Infrastruktur, die von verschiedenen Teams genutzt werden kann. Die Supply-Chain-Abteilung nutzt den RAG-Assistenten für die Rechnungsprüfung, während das Customer-Support-Team ihn für die Ticket-Triage einsetzt. Wichtig ist die Implementierung von Rollenbasierten Zugriffskontrollen (RBAC), um sicherzustellen, dass Daten nicht zwischen Abteilungen geleakt werden. Die Governance-Struktur wird durch regelmäßige Audits und die Dokumentation aller Modellentscheidungen gestützt. So wird aus einem isolierten Pilotprojekt ein skalierbarer Betrieb, der die operative Effizienz des gesamten Unternehmens steigert und gleichzeitig die Compliance-Vorgaben erfüllt.

  • 7 Maßnahmen für KI-gestützte Lead-Qualifikation im Fintech-Vertrieb

    1. Prozess-Audit definiert den Hebel

    Der erste Schritt ist eine präzise Prozessanalyse, die die aktuellen Workflows im CRM identifiziert. Bei einem österreichischen Fintech mit 2.000 Mitarbeitern zeigte das Audit, dass 40 % der Vertriebszeit für manuelle Datenpflege und Lead-Bewertung verloren gingen. Das Team definierte klare KPIs: Reduktion der Cycle Time von der Lead-Erfassung bis zur ersten qualifizierten Kontaktaufnahme um 50 %. Diese Basis ist entscheidend, um den ROI der späteren Automatisierung messbar zu machen und sicherzustellen, dass die KI-Lösung auf echte Schmerzpunkte abzielt, nicht auf theoretische Effizienzgewinne.

    2. RAG-Architektur mit pgvector

    Die technische Basis bildet ein Retrieval-Augmented-Generation-System, das auf pgvector setzt. Die internen Wissensdatenbanken in Notion und Confluence werden in semantische Vektoren umgewandelt und in einer PostgreSQL-Datenbank gespeichert. Wenn ein Vertriebsmitarbeiter eine Frage zu einem Produkt oder einer Compliance-Vorgabe stellt, sucht das System die ähnlichsten Dokumentenabschnitte und übergibt diese als Kontext an das LLM. Dies verhindert Halluzinationen und stellt sicher, dass die Antworten auf dem aktuellen, internen Wissen basieren, nicht auf veralteten Trainingsdaten des Modells.

    3. Predictive Scoring für Leads

    Das Herzstück der Automatisierung ist ein prädiktives Scoring-Modell, das neue Leads in Echtzeit bewertet. Basierend auf historischen Daten aus dem CRM berechnet das Modell eine Wahrscheinlichkeit für den Deal-Abschluss. Ein Lead mit einem Score über 80 wird sofort als „Hot“ markiert und erhält eine Prioritätsbenachrichtigung. Ein Lead unter 40 wird als „Cold“ klassifiziert und in einen Nurturing-Workflow verschoben. Diese automatische Sortierung eliminiert die subjektive Bauchentscheidung der Vertriebsmitarbeiter und stellt sicher, dass die knappe Zeit der Senior-Staff für die Leads mit der höchsten Conversion-Wahrscheinlichkeit aufgewendet wird.

    4. Nahtlose CRM-Integration

    Die Integration in bestehende Systeme erfolgt über standardisierte APIs, ohne dass das CRM oder die Dokumentationsplattform ersetzt werden muss. Das System greift direkt in Salesforce oder HubSpot ein, um die Lead-Attribute zu lesen und die Scores zu schreiben. Gleichzeitig wird die Schnittstelle zu Notion oder Confluence eingerichtet, um die Wissensbasis aktuell zu halten. Diese nahtlose Einbettung in die bestehende IT-Landschaft minimiert die Reibungsverluste bei der Adoption und stellt sicher, dass die Vertriebsmitarbeiter keine neuen Tools lernen müssen, sondern ihre gewohnten Workflows mit zusätzlichen, intelligenten Funktionen nutzen.

    5. Drei-Monats-Timeline zum Rollout

    Die Implementierung folgt einem festen Drei-Monats-Zeitraum. Monat 1 umfasst das Audit und die technische Vorbereitung der Infrastruktur. Monat 2 ist der Pilotbetrieb, in dem das System parallel zum manuellen Prozess läuft und die Ergebnisse validiert werden. Monat 3 dient dem Rollout auf alle Vertriebs-Teams und der Übergabe an den Managed-Service. Diese klare Struktur verhindert Scope-Creep und stellt sicher, dass innerhalb von 90 Tagen ein messbarer Mehrwert entsteht. Die enge Zusammenarbeit mit einem dedizierten Team garantiert, dass technische Hürden schnell überwunden werden, ohne dass der Kunde selbst Ressourcen binden muss.

    6. Dediziertes Team statt Agentur

    Ein dediziertes AI-Team besteht aus einem technischen Lead, zwei Full-Stack-Entwicklern und einem Data Engineer, die ausschließlich für den Kunden arbeiten. Im Vergleich zu einer Agentur, die Ressourcen über mehrere Projekte verteilt, garantiert dieses Modell Kontinuität und tiefgreifendes Systemwissen. Bei Forfis übernimmt dieses Team die gesamte Wertschöpfungskette: von der Architektur der pgvector-Indizes über die API-Integration in Salesforce bis hin zum Monitoring der Modell-Drifts. Die Kosten liegen bei einem Fixpreis pro Monat, was Planbarkeit schafft, ohne dass der Kunde selbst Personal einstellen muss.

    7. Modell-Agnostik für Flexibilität

    Das System ist bewusst modell-agnostisch aufgebaut. Für die Vektorsuche wird pgvector verwendet, das unabhängig vom LLM ist. Für die Generierung der Antworten kann zwischen verschiedenen Modellen gewählt werden: OpenAI oder Anthropic APIs für höchste Qualität bei weniger sensiblen Daten, oder Open-Weight-Modelle wie Llama 3 oder Mistral, die auf der eigenen Hardware laufen, wenn Datenhoheit oberste Priorität hat. Der Wechsel des Modells erfordert nur eine Änderung der Konfigurationsdatei, nicht eine Neuentwicklung der gesamten Pipeline. Diese Flexibilität schützt vor Vendor-Lock-in und ermöglicht es, von zukünftigen Fortschritten in der KI-Technologie zu profitieren, ohne die bestehende Infrastruktur zu ändern.

  • KI-Agent für Vertrags-Review: On-Premise-Implementierung in 4 Wochen

    Das Problem: Manuelle Vertragsprüfung bindet Anwaltsstunden

    Österreichische Kanzleien mit 500 bis 2.000 Mitarbeitern stehen vor einem strukturellen Problem: Die manuelle Prüfung von B2B-Verträgen bindet 30 bis 40 % der Anwaltsstunden, ohne dass die Fehlerquote sinkt. Die DSGVO (Art. 32) verlangt technische Maßnahmen zur Datensicherheit, was Cloud-basierte KI-Lösungen für sensible Mandantendaten oft unbrauchbar macht. Ein konversationeller KI-Agent, der auf Open-Weight-Modellen basiert und on-premise läuft, löst dieses Dilemma: Er reduziert die manuelle Back-Office-Arbeit, bleibt datenschutzkonform und integriert sich in die bestehende Kanzlei-Software. Das Ziel ist nicht die vollständige Automatisierung, sondern die Reduktion der Fehlerquote um mindestens 30 % und die Verkürzung der Bearbeitungszeit um 40 %.

    Voraussetzungen: Was Sie vor dem Start benötigen

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

    • Definierte Vertragskategorie: Wählen Sie eine klar umrissene Vertragsart (z. B. B2B-Dienstleistungsverträge), nicht den gesamten Vertragsbestand.
    • Historische Daten: Mindestens 500 anonymisierte Vertragsdokumente für das Fine-Tuning des Modells.
    • Risikokriterien: Eine schriftliche Definition der kritischen Klauseln (z. B. Haftung, Kündigung, Datenschutz).
    • Hardware: Ein GPU-Server (z. B. NVIDIA A100 40GB) für das On-Premise-Deployment des Open-Weight-Modells.
    • Projektteam: Ein dediziertes Team aus zwei Anwälten und einem IT-Entwickler, das für das Pilotprojekt verfügbar ist.
    • Eskalationsregel: Eine klare Definition, welche Fälle der Agent nicht lösen darf und an welche Person sie eskaliert werden.

    Schritte: Von der Baseline zum Pilotprojekt

    1. Prozess-Audit durchführen: Dokumentieren Sie den aktuellen Workflow der Vertragsprüfung. Messen Sie die durchschnittliche Bearbeitungszeit pro Vertrag und die Fehlerquote (z. B. über Stichproben von 50 Verträgen). Erstellen Sie eine Baseline-Metrik, die Sie nach dem Go-Live vergleichen können.

    2. Modell-Feintuning: Trainieren Sie ein Open-Weight-Modell (z. B. Llama 3 70B) auf Ihren historischen Vertragsdaten. Nutzen Sie ein Framework wie Hugging Face Transformers für das Fine-Tuning. Das Modell soll Klauseln erkennen und Risikobewertungen abgeben.

    3. RAG-Pipeline aufbauen: Implementieren Sie eine Retrieval-Augmented-Generation-Pipeline, die das Modell mit Ihrer internen Rechtsdatenbank (z. B. OGH-Urteile, interne Leitfäden) versorgt. Nutzen Sie ein Vektor-Datenbank-System wie Weaviate oder Qdrant für die semantische Suche.

    4. REST-API entwickeln: Bauen Sie eine Custom REST-API, die den Vertragstext als JSON akzeptiert und eine strukturierte Antwort mit erkannten Klauseln und Risikobewertungen zurückgibt. Sichern Sie die API mit API-Keys und OAuth 2.0.

    5. Integration in die Kanzlei-Software: Verknüpfen Sie die API mit Ihrer Kanzlei-Verwaltungssoftware über Webhooks. Die Software sendet den Vertrag an den Agenten und erhält die Antwort. Die Anwälte sehen die Vorschläge direkt in ihrer Arbeitsumgebung.

    6. Human-in-the-Loop-Workflow einrichten: Stellen Sie sicher, dass der Agent nur Vorschläge macht und die finale Entscheidung beim Anwalt liegt. Implementieren Sie ein Audit-Logging, das dokumentiert, welche Vorschläge angenommen oder verworfen wurden.

    7. Pilotprojekt starten: Führen Sie das Pilotprojekt mit zwei Anwalts-Teams über vier Wochen durch. Messen Sie die Metriken (Fehlerquote, Bearbeitungszeit) und vergleichen Sie sie mit der Baseline.

    Häufige Stolperfallen und wie Sie sie erkennen

    • Halluzinationen des Modells: Das Modell erfindet Klauseln, die im Vertrag nicht vorhanden sind. Erkennung: Stichprobenkontrolle durch einen Anwalt. Wenn die Präzision unter 85 % fällt, muss das Modell nachtrainiert werden.

    • Datenlecks über die API: Unbefugter Zugriff auf die REST-API führt zum Verlust von Mandantendaten. Erkennung: Monitoring der API-Logs. Wenn Anfragen von unbekannten IPs kommen, muss die Firewall konfiguriert werden.

    • Hohe Latenz: Die Antwortzeit des Agenten übersteigt 10 Sekunden, was die Anwälte frustriert. Erkennung: Messung der Inferenz-Zeit. Wenn die Latenz über 5 Sekunden liegt, muss die Hardware skaliert oder das Modell optimiert werden.

    • Fehlende Eskalation: Der Agent behandelt einen komplexen Fall, den er nicht lösen kann, und gibt eine falsche Bewertung ab. Erkennung: Review des Audit-Logs. Wenn Fälle mit hohem Risiko nicht eskaliert wurden, muss die Eskalationsregel angepasst werden.

    • Mangelnde Akzeptanz: Die Anwälte nutzen den Agenten nicht, weil sie den Vorschlägen nicht vertrauen. Erkennung: Befragung der Anwälte nach zwei Wochen. Wenn die Nutzungsrate unter 50 % liegt, muss die Schulung intensiviert werden.

    Fazit: Vom Pilotprojekt zum Managed Service

    Nach dem Pilotprojekt steht die Entscheidung an: Skalierung oder Anpassung. Wenn die Metriken die Ziele erfüllen (Fehlerquote um 30 % reduziert, Bearbeitungszeit um 40 % verkürzt), können Sie den Agenten auf weitere Vertragskategorien ausrollen. Wenn nicht, analysieren Sie die Ursachen: Ist das Modell nicht gut genug trainiert? Ist die Integration zu langsam? Ist die Akzeptanz zu niedrig? Der nächste logische Schritt ist die Überführung in einen Managed-AI-Operations-Service, in dem ein externes Team die Wartung, das Monitoring und das kontinuierliche Feintuning übernimmt. Dies reduziert den internen Aufwand und stellt sicher, dass der Agent mit der Rechtsprechung und den internen Leitfäden aktuell bleibt.