Forfis Blog

Blog

  • Kandidatensichtung in der Versicherung: Lokale LLMs statt manueller Datenpflege

    Das Problem der manuellen Vorqualifizierung im Versicherungsumfeld

    In der deutschen Versicherungsbranche stößt das Recruiting an physikalische Grenzen. Eine mittelständische Insurtech-Firma mit 120 Mitarbeitern erhält monatlich über 400 Bewerbungen für technische und beratende Positionen. Die manuelle Sichtung durch zwei Recruiter bindet 60 Prozent ihrer Kapazität. Das Ergebnis: Eine Reaktionszeit von 5 bis 7 Tagen, bei der Top-Talente bereits bei der Konkurrenz unterschrieben haben. Die Herausforderung ist nicht das Fehlen von Bewerbern, sondern die Ineffizienz der Vorqualifizierung. Manuelle Datenextraktion aus PDFs und die subjektive Bewertung von Soft Skills führen zu Inkonsistenzen. Ein strukturierter Ansatz, der die harten Filter automatisiert und die weiche Bewertung unterstützt, ist die einzige skalierbare Lösung, ohne die HR-Abteilung aufzublähen.

    Architektur: Workflow-Orchestrierung mit lokalen LLMs

    Die Architektur basiert auf einem Workflow-Orchestrator, der als zentraler Knotenpunkt zwischen dem Applicant Tracking System (ATS) und dem lokalen Large Language Model (LLM) fungiert. Neue Bewerbungen werden per Webhook an den Orchestrator geschickt. Dieser extrahiert strukturierte Daten (Name, Skills, Erfahrung) und übergibt den Text an das LLM. Das Modell, ein offenes Gewicht-Modell wie Llama 3 70B, läuft auf einer NVIDIA A100 GPU im Rechenzentrum des Kunden. Die Inferenz erfolgt über die vLLM-API, die eine Batch-Verarbeitung mit einer Latenz von unter 300 ms ermöglicht. Die Antwort des LLMs ist ein JSON-Objekt mit den Feldern ‘seniority’, ‘skill_match’ und ‘risk_flags’. Der Orchestrator validiert dieses Schema und schreibt die Daten zurück in das ATS. Diese Trennung von Orchestrierung und Inferenz erlaubt es, das Modell jederzeit zu tauschen, ohne die Integrationslogik anzufassen.

    Trade-offs: Datenhoheit versus Modellgenauigkeit

    Die Entscheidung für offene Modelle auf eigener Hardware ist ein bewusster Trade-off. Cloud-APIs wie GPT-4 bieten höhere Genauigkeit bei der semantischen Analyse, erfordern aber den Datentransfer in externe Rechenzentren. Für viele Versicherer ist das ein No-Go, da Bewerberdaten als besonders sensibel gelten. Lokale Modelle sind in der Initialkostenstruktur teurer (GPU-Hardware, Betrieb), aber die laufenden Kosten pro Inferenz sind nach Amortisation nahezu null. Der Nachteil: Offene Modelle sind bei sehr spezifischen, deutschen Fachbegriffen im Versicherungswesen anfällig für Halluzinationen. Dies wird durch eine strenge Prompt-Engineerung und eine menschliche Freigabeschleife (Human-in-the-Loop) kompensiert. Der Recruiter sieht immer die Begründung des Modells und kann sie mit einem Klick überstimmen.

    Skalierung der Operationen ohne Personalzuwachs

    Der Pilotbetrieb startet mit einer einzigen Stellenkategorie, z. B. ‘Softwareentwickler Backend’. Das System läuft parallel zur manuellen Arbeit. Die Metriken werden täglich verglichen: Wie viele Kandidaten hat das Modell als ‘Top Match’ markiert, die der Recruiter abgelehnt hat? Und umgekehrt? Nach vier Wochen wird die Genauigkeit auf über 90 Prozent bei den harten Kriterien stabilisiert. Die Skalierung erfolgt dann auf weitere Profile. Der entscheidende Hebel ist die Reduktion der Datenpflege: Statt manuell ‘Python’ in ein Feld zu tippen, wird es automatisch erkannt. Das spart pro Bewerbung 10 Minuten. Bei 400 Bewerbungen sind das 66 Stunden pro Monat, die für die persönliche Ansprache genutzt werden. Die Skalierung gelingt ohne neue Einstellungen, weil die Kapazität der bestehenden Recruiter durch die Automatisierung der Routineaufgaben multipliziert wird.

    Empfehlung: Dediziertes Team und 6-Monats-Roadmap

    Die Implementierung folgt einem 6-Monats-Zeitraum. Monat 1: Prozess-Audit und Definition der Kriterien. Monat 2: Aufbau der GPU-Infrastruktur und Anbindung an das ATS via REST-API. Monat 3: Feinabstimmung des Modells auf historische Daten und Validierung. Monat 4: Pilotbetrieb mit einer Stellenkategorie. Monat 5: Skalierung auf alle technischen Profile. Monat 6: Stabilisierung und Übergabe an das interne IT-Team. Das dedizierte Forfis-Team besteht aus einem Tech Lead, einem ML-Engineer und einem Product Owner. Sie arbeiten direkt im Unternehmen, um die Domänenlogik der Versicherung zu verstehen. Die Kosten liegen bei ca. 15.000 EUR pro Monat für das Team plus 800 EUR für die GPU-Infrastruktur. Die Amortisation erfolgt durch die eingesparte Recruiter-Zeit innerhalb der ersten zwei Monate nach Go-Live.

  • KI-Glossar für Logistik und HR: Automatisierung in der Schweiz

    Dokumentenextraktions-Pipeline

    Die Dokumentenextraktions-Pipeline ist das technische Fundament für die Automatisierung unstrukturierter Daten. Sie verarbeitet Eingaben wie PDF-Lebensläufe oder Arbeitszeugnisse und wandelt diese in maschinenlesbare JSON-Strukturen um. Der Prozess umfasst optische Zeichenerkennung (OCR), Layout-Analyse zur Identifikation von Abschnitten und semantische Zuordnung von Feldern. Im Kontext des Candidate Screenings extrahiert die Pipeline Schlüsselinformationen wie Berufserfahrung, Qualifikationen und Kontaktdaten. Forfis implementiert diese Pipeline als modulare Komponente, die über eine Custom REST API angesprochen werden kann. Dies ermöglicht die nahtlose Anbindung an bestehende HR-Systeme, ohne dass die Infrastruktur des Kunden verändert werden muss. Die Genauigkeit der Extraktion ist entscheidend, da fehlerhafte Daten die nachgelagerte KI-Klassifikation beeinträchtigen würden. Durch iterative Optimierung der Extraktionsregeln wird eine Zuverlässigkeit von über 95 % angestrebt, bevor die Daten an das LLM übergeben werden.

    Retrieval-Augmented Generation (RAG)

    Retrieval-Augmented Generation (RAG) ist eine Methode, die die Genauigkeit von Large Language Models durch den Zugriff auf externe, aktuelle Datenquellen erhöht. Statt auf dem trainierten Wissen des Modells zu basieren, durchsucht das System zunächst eine Vektordatenbank mit relevanten Dokumenten. Diese Dokumente werden als Kontext an das LLM übergeben, das daraufhin eine Antwort oder Klassifikation generiert. Bei Forfis wird RAG eingesetzt, um Kandidatenprofile gegen interne Stellenbeschreibungen und Compliance-Richtlinien abzugleichen. Dies stellt sicher, dass die KI-Empfehlungen auf den spezifischen Anforderungen des Unternehmens basieren und nicht auf allgemeinen Mustern. Die Vektordatenbank wird regelmäßig mit neuen Dokumenten aktualisiert, um die Relevanz der Ergebnisse zu gewährleisten. RAG reduziert zudem das Risiko von Halluzinationen, da das Modell auf konkrete, verifizierte Quellen zurückgreift. Diese Technik ist besonders wertvoll in regulierten Branchen, wo Nachvollziehbarkeit und Präzision oberste Priorität haben.

    DSGVO (Datenschutz-Grundverordnung)

    Die DSGVO (Datenschutz-Grundverordnung) ist die zentrale Datenschutzvorschrift der EU, die auch in der Schweiz durch das revidierte Datenschutzgesetz (revDSG) und bilaterale Abkommen relevant ist. Sie regelt die Verarbeitung personenbezogener Daten und verlangt unter anderem die Einhaltung der Prinzipien der Zweckbindung, Datenminimierung und Speicherbegrenzung. Im Kontext der KI-Automatisierung bedeutet dies, dass nur die für den jeweiligen Zweck notwendigen Daten verarbeitet werden dürfen. Forfis implementiert diese Vorgaben durch technische Maßnahmen wie Pseudonymisierung, Verschlüsselung und strikte Zugriffskontrollen. Bei der Verarbeitung von Kandidatendaten wird sichergestellt, dass sensible Informationen nicht in ungeschützten Cloud-Diensten verarbeitet werden, wenn dies vermeidbar ist. Die Dokumentation der Datenflüsse und die Einholung der erforderlichen Einwilligungen sind Teil des Compliance-Frameworks. Durch diese Maßnahmen wird ein datenschutzkonformer Betrieb gewährleistet, der auch bei Audits standhält.

    OpenAI API

    Die OpenAI API ist ein kommerzieller Zugang zu Large Language Models (LLMs) wie GPT-4o, die über HTTPS-Anfragen abgerufen werden können. Sie bietet hohe Leistungsfähigkeit bei der Textanalyse, Klassifikation und Generierung. Forfis nutzt die OpenAI API für die semantische Bewertung von Lebensläufen und die Generierung von Screening-Empfehlungen. Die API wird über eine sichere Verbindung mit API-Keys authentifiziert, und die Datenübertragung erfolgt verschlüsselt. Da die Verarbeitung in der Cloud stattfindet, ist es entscheidend, dass nur nicht-sensible Daten oder pseudonymisierte Informationen an die API übergeben werden. Forfis implementiert eine Vorverarbeitungsstufe, die sicherstellt, dass personenbezogene Daten vor der Übertragung an OpenAI entfernt oder anonymisiert werden. Dies ermöglicht die Nutzung der fortschrittlichen NLP-Fähigkeiten von OpenAI, während gleichzeitig die datenschutzrechtlichen Anforderungen erfüllt werden. Die Kosten für die API-Nutzung werden durch die Reduktion manueller Arbeitsschritte schnell amortisiert.

    Webhook

    Ein Webhook ist ein ereignisgesteuerter HTTP-Callback, der eine Aktion in einem System triggert, wenn ein bestimmtes Ereignis in einem anderen System eintritt. Wenn beispielsweise ein neuer Kandidat in einem Applicant Tracking System (ATS) registriert wird, sendet das ATS eine POST-Anfrage an eine definierte URL. Diese Anfrage enthält die relevanten Daten des Kandidaten. Forfis nutzt Webhooks, um die Automatisierungspipeline in Echtzeit zu starten, ohne dass manuelle Abfragen (Polling) nötig sind. Dies reduziert die Latenz und entlastet die Server-Ressourcen. Die Webhook-Endpunkte sind mit Signaturen signiert, um die Authentizität der Anfragen zu gewährleisten. Bei der Verarbeitung der Webhook-Daten wird zunächst die Validierung der Datenstruktur durchgeführt, bevor die Extraktions- und Klassifikationsprozesse angestoßen werden. Diese ereignisgesteuerte Architektur ermöglicht eine skalierbare und reaktive Automatisierung, die sich nahtlos in bestehende Workflows integrieren lässt.

    Custom REST API

    Eine Custom REST API ist eine individuelle Schnittstelle, die auf HTTP-Methoden (GET, POST, PUT, DELETE) basiert und strukturierte Daten im JSON- oder XML-Format austauscht. Sie ermöglicht die Kommunikation zwischen verschiedenen Systemen über das Internet oder ein internes Netzwerk. Forfis entwickelt Custom REST APIs, um Daten aus ERP-, HR- oder CRM-Systemen sicher und formatiert in die AI-Pipeline zu übergeben. Diese APIs sind so gestaltet, dass sie die spezifischen Anforderungen des Kunden erfüllen, einschließlich Authentifizierung, Rate-Limiting und Fehlerbehandlung. Durch die Nutzung von REST-APIs wird sichergestellt, dass die Automatisierung unabhängig von proprietären Plattformen bleibt und leicht an neue Anforderungen angepasst werden kann. Die Dokumentation der APIs erfolgt in Form von OpenAPI-Spezifikationen, die eine klare Übersicht über Endpunkte, Parameter und Antwortformate bieten. Dies erleichtert die Integration und Wartung durch das technische Team des Kunden.

    Human-in-the-Loop (HITL)

    Human-in-the-Loop (HITL) ist ein Designprinzip, bei dem Menschen in den Entscheidungsprozess einer KI-System eingebunden bleiben. Das KI-Modell erstellt einen Entwurf, eine Klassifikation oder eine Empfehlung, die ein Mensch prüfen und freigeben muss, bevor die Aktion ausgeführt wird. Bei Forfis ist HITL der Standard für alle Prozesse, die Geld, Gesundheitsdaten oder Verträge betreffen. Im Candidate Screening bedeutet dies, dass die KI die erste Filterung vornimmt, aber die endgültige Entscheidung über die Einladung zu einem Interview durch einen HR-Mitarbeiter getroffen wird. Dieses Prinzip minimiert Haftungsrisiken und stellt sicher, dass ethische und rechtliche Aspekte berücksichtigt werden. Die HITL-Schritte werden in der Workflow-Orchestrierung klar definiert und protokolliert. Durch die Kombination von KI-Effizienz und menschlicher Kontrolle wird ein ausgewogenes Verhältnis zwischen Automatisierung und Verantwortung geschaffen.

  • Voice-Agent für B2B-Support in Deutschland: ISO 27001-konforme Implementierung

    Das Problem: Langsame Versandstatus-Antworten im B2B-Support

    Ihr B2B-SaaS-Unternehmen (11–50 Mitarbeiter) in Deutschland kämpft mit langsamen Reaktionszeiten bei Versandstatus-Anfragen. Kunden erwarten schnelle Antworten, aber Ihr Support-Team verbringt 40 % der Zeit mit manuellen Nachschauen im ERP-System. Die Folge: Lange Wartezeiten, unzufriedene Kunden und steigende Kosten. Ein Voice-Agent kann diese Anfragen automatisieren, aber nur, wenn er ISO 27001-konform ist und auf eigener Hardware läuft. Dieser Artikel zeigt, wie Sie in 6 Monaten einen Voice-Agenten für den deutschen Markt implementieren, der Auftrags- und Versandstatus in Echtzeit beantwortet und in Slack oder Microsoft Teams integriert ist.

    Voraussetzungen: Was Sie vor dem Start brauchen

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

    • ISO 27001-Zertifizierung: Ihr Unternehmen muss bereits zertifiziert sein oder im Prozess der Zertifizierung. Der Voice-Agent muss in Ihre Information Security Policy integriert werden.
    • Eigene Hardware: Ein Server mit mindestens 24 GB VRAM (z. B. NVIDIA A100 oder H100) für das Open-Weight-Modell. Alternativ: Ein Cloud-Server in der EU (z. B. Hetzner oder OVH) mit GPU.
    • Zugriff auf CRM/ERP: API-Zugriff auf Ihr CRM (z. B. Salesforce, HubSpot) und ERP (z. B. SAP, Dynamics 365) für Auftrags- und Versanddaten.
    • Slack oder Microsoft Teams: Ein Workspace, in dem der Voice-Agent integriert werden soll. Sie benötigen Admin-Rechte für die App-Installation.
    • Prozess-Dokumentation: Eine Liste der häufigsten Versandstatus-Fragen und der aktuellen Bearbeitungszeiten (Baseline).
    • Budget: 15.000–30.000 EUR für Hardware, Lizenzen und Managed-Service über 6 Monate.

    Schritte: Implementierung in 7 Phasen

    1. Prozess-Audit durchführen: Dokumentieren Sie die 10 häufigsten Versandstatus-Fragen und messen Sie die aktuelle Bearbeitungszeit. Ziel: Eine Baseline von z. B. 12 Minuten pro Ticket und 8 % Fehlerquote. Nutzen Sie ein Tool wie Jira oder Confluence für die Dokumentation.

    2. Hardware und Modell auswählen: Installieren Sie ein Open-Weight-Modell wie Llama 3 70B oder Mixtral 8x22B auf Ihrer Hardware. Verwenden Sie vLLM oder TGI (Text Generation Inference) für die Inferenz. Testen Sie die Latenz: Sie sollte unter 500 ms liegen.

    3. ASR und TTS einrichten: Integrieren Sie Whisper large-v3 für die Spracherkennung und Piper für die Sprachsynthese. Beide laufen lokal auf Ihrer Hardware. Testen Sie die Erkennungsrate mit deutschen Sprachproben: Ziel ist über 95 % Genauigkeit.

    4. CRM/ERP-Integration bauen: Erstellen Sie eine API-Anbindung, die Auftragsnummern und Versandstatus abfragt. Verwenden Sie REST-APIs mit OAuth 2.0 für die Authentifizierung. Testen Sie die Antwortzeiten: Sie sollten unter 200 ms liegen.

    5. Slack/Teams-Integration implementieren: Installieren Sie die Slack- oder Teams-App. Der Voice-Agent sollte Tickets automatisch erkennen und antworten. Verwenden Sie Webhooks für die Echtzeit-Kommunikation. Testen Sie die Integration mit 50 simulierten Tickets.

    6. Pilot mit 10 Mitarbeitern starten: Lassen Sie 10 Support-Mitarbeiter den Voice-Agenten für 2 Wochen testen. Messen Sie die Durchlaufzeit und Fehlerquote. Ziel: Reduktion auf 3 Minuten und unter 2 % Fehlerquote.

    7. Rollout und Managed-Service: Übergeben Sie den Betrieb an einen Managed-Service. Dieser übernimmt Modell-Updates, Monitoring und Fehleranalyse. Sie erhalten monatliche Reports mit Kennzahlen.

    Häufige Stolperfallen und wie Sie sie vermeiden

    • Zu hohe Latenz: Wenn die Antwortzeit über 1 Sekunde liegt, wirkt das Gespräch unnatürlich. Detektion: Messen Sie die End-to-End-Latenz mit einem Tool wie Grafana. Lösung: Optimieren Sie die Inferenz mit vLLM oder reduzieren Sie die Modellgröße.

    • Fehlende CRM-Daten: Wenn der Agent keine aktuellen Auftragsdaten hat, gibt er falsche Antworten. Detektion: Prüfen Sie die API-Antworten im Log. Lösung: Verwenden Sie Caching für häufig abgefragte Daten und aktualisieren Sie den Cache alle 5 Minuten.

    • Unklare Eskalationsregeln: Wenn der Agent nicht sicher ist, weiß er nicht, wann er an einen Menschen eskalieren soll. Detektion: Analysieren Sie die Tickets, die der Agent nicht gelöst hat. Lösung: Definieren Sie klare Schwellenwerte (z. B. Konfidenz unter 80 % = Eskalation).

    • Mangelnde ISO 27001-Dokumentation: Wenn die Datenflüsse nicht dokumentiert sind, scheitern Sie bei der Auditierung. Detektion: Prüfen Sie Ihre Information Security Policy. Lösung: Dokumentieren Sie alle Datenflüsse, Modell-Updates und Zugriffsberechtigungen.

    • Zu enger Pilot-Scope: Wenn der Pilot nur einen Use-Case abdeckt, ist er nicht übertragbar. Detektion: Prüfen Sie, ob der Agent auch andere Versandstatus-Fragen beantworten kann. Lösung: Erweitern Sie den Pilot auf 3–5 Use-Cases.

    Fazit: Vom Pilot zum laufenden Betrieb

    Nach 6 Monaten haben Sie einen Voice-Agenten, der 60 % der Versandstatus-Anfragen automatisch beantwortet. Die Durchlaufzeit ist von 12 auf 3 Minuten gesunken, die Fehlerquote von 8 auf 1,5 %. Ihr Support-Team konzentriert sich auf komplexe Fälle, während der Agent die Routinefragen übernimmt. Der Managed-Service sorgt dafür, dass der Agent über die Zeit besser wird: Modell-Updates, Prompt-Anpassungen und Monitoring sind inklusive. Der nächste Schritt: Erweitern Sie den Agenten auf weitere Use-Cases, z. B. Rechnungsstatus oder Produktinformationen. Oder integrieren Sie ihn in Ihre monatliche Reporting-Automatisierung, um die Auslastung des Teams zu visualisieren.

  • RAG-Pilot für interne Knowledge Search in B2B-SaaS: 14-Tage-Plan

    Warum ein 14-Tage-Pilot für interne Knowledge Search in B2B-SaaS

    Ihr Support-Team in einem B2B-SaaS-Unternehmen mit 800 Mitarbeitern beantwortet täglich 40 bis 60 Fragen zu internen Prozessen, Produkt-Features und Compliance-Vorgaben. Die Antworten liegen verstreut in Confluence, SharePoint und E-Mail-Archiven. Neue Mitarbeiter brauchen 3 bis 4 Wochen, um sich zurechtzufinden. Die Compliance-Abteilung fordert nachvollziehbare Antworten, weil einige Fragen betreffen, wie Kundendaten verarbeitet werden. Ein RAG-System über die interne Dokumentation reduziert die Antwortzeit von 4 Stunden auf 15 Minuten und liefert zitierte Quellen. Der Pilot muss in 14 Tagen laufen, weil das Q3-Budget Ende des Monats freigegeben wird. Die technische Herausforderung: LangGraph muss mit den bestehenden APIs von Confluence und SharePoint sprechen, ohne dass die IT-Abteilung neue Infrastruktur aufbaut. Die Compliance-Herausforderung: Keine Kundendaten dürfen in den Vektorindex wandern, und jede Antwort muss auditierbar sein.

    Voraussetzungen vor dem ersten Tag

    • Datenzugang: API-Keys für Confluence und SharePoint mit Lesezugriff auf die relevanten Spaces. Die IT-Abteilung muss diese vor Tag 1 freigeben.
    • Datenklassifizierung: Eine Liste der Dokumenttypen, die indiziert werden dürfen (z. B. „Prozessdokumente“, „Produkt-Handbücher“) und die, die ausgeschlossen sind (z. B. „Kundenverträge“, „HR-Daten“). Die Compliance-Abteilung muss diese Liste signieren.
    • Infrastruktur: Ein AWS- oder Azure-Account mit Zugriff auf S3/Blob-Storage für den Vektorindex und eine PostgreSQL-Instanz für die LangGraph-State-Logs. Alternativ: On-Premise-Server, wenn die IT-Abteilung Cloud-Nutzung verbietet.
    • Slack-Integration: Ein Slack-Workspace mit Admin-Rechten, um einen Bot zu erstellen und die API-Keys für die Webhooks zu generieren.
    • Team: 2 Entwickler (Backend/ML), 1 Product Owner aus dem Fachbereich, 1 Compliance-Beauftragter für Freigaben, 5 bis 10 Power-User aus dem Support für die Testphase.
    • Modell-APIs: Zugänge zu OpenAI (gpt-4o, text-embedding-3-large) oder Anthropic (claude-3-5-sonnet, embedding-v3). Für EU-Compliance: Verifizieren, dass die Daten in Frankfurt oder Dublin verarbeitet werden.

    Schritt 1 bis 5: Von der Datenanbindung zum Slack-Bot

    1. Datenquellen anbinden: Schreiben Sie einen Python-Skript, das über die Confluence-API (REST, Endpoint /api/v2/spaces/{spaceKey}/pages) und die SharePoint-Graph-API (/sites/{siteId}/drive/root/children) die relevanten Dokumente lädt. Speichern Sie die Rohdaten in einer lokalen JSON-Datei. Konfiguration: CHUNK_SIZE = 512, CHUNK_OVERLAP = 64. Filtern Sie Dokumente anhand der Compliance-Liste: Wenn das Metadatum classification auf „confidential“ steht, überspringen Sie das Dokument.

    2. Embeddings generieren und Vektorindex aufbauen: Nutzen Sie text-embedding-3-large von OpenAI (1536 Dimensionen). Laden Sie die JSON-Datei, generieren Sie Embeddings für jedes Chunk und speichern Sie sie in Qdrant (lokal, Port 6333). Code-Snippet: client.upsert(collection_name="knowledge", points=[PointStruct(id=i, vector=embedding, payload={"text": chunk, "source": url, "classification": "internal"})]). Verifizieren: client.count(collection_name="knowledge") muss die Anzahl der Chunks liefern.

    3. LangGraph-Agent konfigurieren: Definieren Sie den State in langgraph.graph.StateGraph. Nodes: retrieve (RAG-Suche), generate (LLM-Antwort), validate (Compliance-Check). Kanten: retrieve → generate → validate → END. In validate: Wenn die Konfidenz-Score unter 0.7 liegt, leiten Sie die Anfrage an einen menschlichen Agenten weiter. Speichern Sie den State in PostgreSQL: checkpointer = PostgresSaver(conn_string). Code: graph = builder.compile(checkpointer=checkpointer).

    4. Slack-Bot integrieren: Erstellen Sie einen Slack-App mit den Scopes chat:write, channels:join, reactions:write. Implementieren Sie einen Webhook-Handler, der Slack-Nachrichten empfängt, den Text an den LangGraph-Agenten übergibt und die Antwort in den Channel postet. Konfiguration: SLACK_BOT_TOKEN, SLACK_SIGNING_SECRET. Test: Senden Sie eine Nachricht in den Test-Channel, der Bot muss innerhalb von 5 Sekunden antworten.

    5. Compliance-Filter und Audit-Logs aktivieren: In jedem Node des LangGraph-Graphen: Loggen Sie die Eingabe, die abgerufenen Chunk-IDs und die Konfidenz-Score in eine Tabelle audit_logs (Spalten: timestamp, user_id, query, chunk_ids, confidence, action). Implementieren Sie einen Filter in retrieve: Wenn ein Chunk die Metadaten classification: "confidential" hat, wird es nicht abgerufen. Test: Stellen Sie eine Frage, die auf ein „confidential“-Dokument verweist. Der Bot muss antworten: „Keine autorisierte Information gefunden.“

    Schritt 6 und 7: Pilotbetrieb und Go/No-Go

    1. Pilot mit Power-Usern starten: Aktivieren Sie den Bot in einem dedizierten Slack-Channel mit 5 bis 10 Support-Mitarbeitern. Sie stellen täglich 5 bis 10 reale Fragen. Sie bewerten jede Antwort: „Korrekt“, „Teilweise korrekt“, „Falsch“, „Keine Antwort“. Die Bewertungen fließen in ein Google-Sheet, das der Product Owner täglich prüft.

    2. Metriken messen und iterieren: Nach 5 Tagen: Analysieren Sie die Audit-Logs. Welche Fragen wurden nicht beantwortet? Welche Chunk-IDs wurden häufig abgerufen, aber die Antwort war falsch? Passen Sie die CHUNK_SIZE an (z. B. von 512 auf 256, wenn die Antworten zu generisch sind). Aktualisieren Sie den Vektorindex, wenn neue Dokumente in Confluence veröffentlicht wurden. Code: client.delete(collection_name="knowledge", filter=Filter.must([FieldCondition(key="source", match=MatchAny(any=[old_url]))])).

    3. Compliance-Review durchführen: Die Compliance-Abteilung prüft die Audit-Logs: Wurden keine „confidential“-Dokumente abgerufen? Sind die Logs vollständig? Sie signiert den Pilot-Report. Wenn es Abweichungen gibt: Passen Sie die Filter an und wiederholen Sie den Test.

    4. Go/No-Go-Entscheidung: Am Tag 14: Präsentieren Sie die Metriken an die Geschäftsführung: Antwortzeit (Ziel: < 20 Sekunden), Genauigkeit (Ziel: > 85 % „Korrekt“), Compliance-Verstöße (Ziel: 0). Wenn die Ziele erreicht sind: Freigabe für die Produktivphase. Wenn nicht: Identifizieren Sie die Ursachen (z. B. schlechte Chunking-Strategie, unvollständige Daten) und planen Sie einen zweiten Pilot mit erweitertem Scope.

    Häufige Stolperfallen und wie Sie sie erkennen

    • Chunking-Strategie zu grob: Wenn CHUNK_SIZE = 1024 ist, enthält ein Chunk oft mehrere Themen. Die RAG-Suche findet das relevante Chunk, aber das LLM generiert eine Antwort, die auch irrelevante Informationen enthält. Erkennen: Die Power-User bewerten die Antwort als „Teilweise korrekt“. Lösung: Reduzieren Sie CHUNK_SIZE auf 256 und testen Sie erneut.
    • Compliance-Filter nicht aktiv: Wenn die Metadaten classification in den Dokumenten fehlen oder falsch gesetzt sind, werden „confidential“-Dokumente indiziert. Erkennen: Die Compliance-Abteilung findet in den Audit-Logs Chunk-IDs, die auf „confidential“-Dokumente verweisen. Lösung: Validieren Sie die Metadaten vor dem Indexing. Wenn classification fehlt, setzen Sie den Default auf „confidential“.
    • Slack-Latenz zu hoch: Wenn die Antwortzeit > 30 Sekunden beträgt, sind die Power-User frustriert. Ursache: Die Embedding-Generierung dauert zu lange oder die Qdrant-Suche ist langsam. Erkennen: Messen Sie die Latenz pro Node in den Audit-Logs. Lösung: Cachen Sie die Embeddings in Redis, wenn sich die Dokumente nicht ändern. Optimieren Sie die Qdrant-Indizes (HNSW-Parameter).
    • Daten nicht aktuell: Wenn neue Dokumente in Confluence veröffentlicht werden, sind sie nicht im Vektorindex. Erkennen: Die Power-User stellen Fragen zu neuen Features, die der Bot nicht kennt. Lösung: Implementieren Sie einen Cron-Job, der täglich die Confluence-API abfragt und neue/aktualisierte Dokumente in den Index aufnimmt.

    Nächster Schritt nach dem Piloten

    Der 14-Tage-Pilot liefert die Metriken, die Sie für die Go/No-Go-Entscheidung benötigen. Wenn die Ziele erreicht sind, ist der nächste Schritt die Produktivphase: Erweitern Sie den Bot auf alle Support-Teams, integrieren Sie weitere Datenquellen (z. B. Jira, Salesforce) und automatisieren Sie die Dokument-Aktualisierung. Wenn die Ziele nicht erreicht sind, identifizieren Sie die Ursachen und planen Sie einen zweiten Pilot mit erweitertem Scope. Die technische Architektur (LangGraph, Qdrant, Slack-Integration) bleibt gleich; nur der Datenbestand und die Filter werden angepasst. Die Compliance-Abteilung muss die Produktivphase separat freigeben, weil die Datenmenge und die Nutzerzahl steigen. Planen Sie für die Produktivphase 4 bis 6 Wochen ein, inklusive Schulung und Prozessanpassung.

  • Voice-Agent für Lead-Qualifizierung: Open-Weight-Modelle in der Schweiz

    Das Problem der manuellen Lead-Qualifizierung in Schweizer Beratungsfirmen

    Beratungsfirmen in der Schweiz mit 501-2000 Mitarbeitern stehen vor einem strukturellen Problem: Die Lead-Qualifizierung erfolgt manuell. Vertriebsmitarbeiter nehmen Anrufe entgegen, notieren Details in ein CRM und erfassen Daten in Notion oder Confluence. Dieser Prozess dauert im Durchschnitt 15 Minuten pro Lead und enthält eine Fehlerquote von 5-8 %. Die Folge: Leads werden nicht rechtzeitig qualifiziert, und das Vertriebs-Team verliert Zeit für administrative Aufgaben. Die DSGVO und das schweizerische Datenschutzgesetz (DSG) erfordern zudem, dass personenbezogene Daten in der Schweiz oder der EU verarbeitet werden. Eine API-basierte Lösung, die Daten in die USA sendet, ist für viele Beratungsfirmen nicht akzeptabel. Die Lösung: Ein Voice-Agent, der auf Open-Weight-Modellen läuft und lokal auf der Hardware des Kunden betrieben wird. Dieser Agent nimmt Anrufe entgegen, transkribiert sie, klassifiziert Leads und schreibt die Daten automatisch in das CRM und die Dokumentation. Der Pilot dauert 14 Tage und misst die Reduktion der Bearbeitungszeit und der Fehlerquote.

    Architektur: Voice-Agent auf Open-Weight-Modellen

    Die Architektur des Voice-Agenten besteht aus vier Schichten. Erstens die Audio-Erfassung: Ein Telephonie-System (z. B. Twilio oder ein lokaler SIP-Trunk) leitet Anrufe an den Agenten. Zweitens die Transkription: Ein lokales ASR-Modell wie Whisper (open-weight) wandelt die Sprachdaten in Text um. Die Latenz liegt bei 200-300 ms. Drittens die Klassifizierung: Ein LLM (z. B. Llama 3 13B oder Mistral 7B) auf einer NVIDIA H100 GPU extrahiert strukturierte Daten (Name, Firma, Budget, Timeline) und klassifiziert den Lead. Die Inferenzzeit beträgt 30-50 ms pro Token. Viertens die Integration: Ein API-Connector schreibt die Daten in das CRM (HubSpot, Salesforce) und in Notion oder Confluence. Die Dokumentation in Notion/Confluence dient als Wissensbasis für Retrieval-Augmented Generation (RAG). Der Agent ruft relevante Informationen ab, um auf Fragen zu antworten. Die gesamte Pipeline läuft lokal, keine Daten verlassen das Gebäude. Die Latenz von der Sprachaufnahme bis zur Antwort liegt bei 600-800 ms, was für eine Lead-Qualifizierung akzeptabel ist.

    Trade-offs: On-Premise vs. API-basierte Lösungen

    Die Entscheidung für Open-Weight-Modelle On-Premise hat klare Trade-offs. Der Vorteil: Datenhoheit und Compliance. Keine Übermittlung in Drittländer, keine Abhängigkeit von externen APIs. Die DSGVO (Art. 6, 9) und das DSG werden eingehalten, da die Daten in der Schweiz bleiben. Der Nachteil: Höhere Initialkosten. Ein NVIDIA H100 GPU-Server kostet 30.000-50.000 CHF. Zudem ist ein MLOps-Team erforderlich, um das Modell zu feintunen und zu warten. Die Latenz ist höher als bei API-Diensten (50-100 ms vs. 20-30 ms), aber bei hoher Auslastung sinken die Kosten pro Token drastisch. Im Vergleich zu einer API-Lösung von OpenAI oder Anthropic ist die Qualität der Klassifizierung bei lokalen Modellen etwas geringer, aber durch Feintuning auf die firmenspezifischen Daten kann die Lücke geschlossen werden. Für eine Firma mit 501-2000 Mitarbeitern, die täglich über 1000 Anrufe verarbeitet, ist die Investition in lokale Hardware wirtschaftlich. Die Amortisation erfolgt nach 6-12 Monaten durch die Reduktion der manuellen Dateneingabe.

    Der 14-tägige Pilot: Scope und Messgrößen

    Der 14-tägige Pilot mit festschichtigem Scope folgt einem klaren Plan. Woche 1: Integration und Setup. Der Voice-Agent wird in das bestehende Telephonie-System integriert. Die lokale Hardware (GPU-Server) wird installiert und das Modell (Llama 3 13B) wird auf die firmenspezifischen Daten feingetunt. Die Integration in das CRM und Notion/Confluence erfolgt über die APIs. Die Baseline wird gemessen: Durchschnittliche Bearbeitungszeit pro Lead (15 Minuten), Fehlerquote (5-8 %). Woche 2: Test und Messung. Der Agent nimmt echte Anrufe entgegen. Die Daten werden automatisch in das CRM und Notion geschrieben. Die Mitarbeiter prüfen nur noch Ausreißer. Die Metriken werden gemessen: Bearbeitungszeit pro Lead (Ziel: unter 2 Minuten), Fehlerquote (Ziel: unter 1 %), Latenz (Ziel: unter 800 ms). Am Ende des Piloten wird ein Bericht erstellt, der die Reduktion der Bearbeitungszeit und der Fehlerquote dokumentiert. Der Pilot ist abgeschlossen, wenn die Ziele erreicht sind. Der Rollout auf alle Standorte erfolgt dann in einem separaten Projekt.

    Empfehlung: Implementierung in der Praxis

    Für Beratungsfirmen in der Schweiz mit 501-2000 Mitarbeitern ist der Voice-Agent auf Open-Weight-Modellen die richtige Wahl, wenn die Datenhoheit und die Compliance Priorität haben. Die Empfehlung: Starten Sie mit einem 14-tägigen Piloten auf einem Standort. Integrieren Sie den Agenten in das bestehende CRM und Notion/Confluence. Messen Sie die Baseline und die Ergebnisse. Wenn die Ziele erreicht sind (Bearbeitungszeit unter 2 Minuten, Fehlerquote unter 1 %), rollen Sie den Agenten auf alle Standorte aus. Die Investition in lokale Hardware (NVIDIA H100) ist wirtschaftlich, wenn täglich über 1000 Anrufe verarbeitet werden. Die laufenden Kosten betragen 2.000-4.000 CHF/Monat für Wartung und Updates. Der Agent ersetzt die manuelle Dateneingabe und ermöglicht eine 24/7-Verfügbarkeit für die Lead-Qualifizierung. Die Mitarbeiter können sich auf die Beratung konzentrieren, statt auf administrative Aufgaben. Die DSGVO und das DSG werden eingehalten, da die Daten in der Schweiz bleiben. Der Voice-Agent ist nicht ein Ersatz für den Menschen, sondern ein Werkzeug, das die manuelle Arbeit reduziert und die Qualität der Lead-Qualifizierung erhöht.

  • Rechnungsautomatisierung mit offenen KI-Modellen im E-Commerce

    Das Problem der manuellen Rechnungsverarbeitung im Mittelstand

    In der Buchhaltung eines E-Commerce-Unternehmens mit 150 Mitarbeitern stapeln sich täglich hunderte Eingangsrechnungen. Die manuelle Erfassung in das ERP-System bindet zwei bis drei Fachkräfte vollständig. Das Problem ist nicht die Komplexität der Daten, sondern die Wiederholung: 80 Prozent der Rechnungen stammen von denselben Lieferanten und folgen denselben Layouts. Eine KI-Lösung, die diese Routinearbeit übernimmt, kann die Zykluszeit von der Rechnungseingangs bis zur Buchung von drei Tagen auf unter vier Stunden senken. Der entscheidende Punkt ist nicht die Automatisierung an sich, sondern die Integration in die bestehenden Prozesse. Das System darf das ERP nicht ersetzen, sondern muss als eine Schicht davor agieren, die die Daten bereinigt und klassifiziert, bevor sie in das Buchhaltungssystem fließen. Dieser Ansatz minimiert das Risiko und ermöglicht einen schrittweisen Rollout, bei dem die Mitarbeiter die Kontrolle behalten.

    Die technische Architektur: Von der OCR bis zur ERP-Integration

    Die Architektur basiert auf einer Pipeline, die in drei Stufen unterteilt ist. Zuerst wird das Dokument in ein einheitliches Format gebracht. Hier kommen OCR-Modelle wie Tesseract oder kommerzielle APIs zum Einsatz, die den Text aus dem PDF oder Scan extrahieren. Im zweiten Schritt übernimmt ein Large Language Model (LLM) die semantische Analyse. Das Modell identifiziert die relevanten Felder: Rechnungsnummer, Betrag, Steuern, Lieferant, Leistungszeitraum. Bei der Nutzung offener Modelle wie Llama 3 oder Mistral auf eigener Hardware bleibt das Dokument im Gebäude, was für Unternehmen mit sensiblen Daten ein entscheidender Vorteil ist. Die dritte Stufe ist die Validierung. Die extrahierten Daten werden gegen die Stammdaten im ERP geprüft. Stimmt der Lieferant, ist der Betrag plausibel, sind alle Pflichtfelder vorhanden? Erst wenn diese Checks bestehen, wird die Rechnung als ‘freigabefähig’ markiert. Die Kommunikation mit dem ERP erfolgt über REST-APIs. Bei SAP S/4HANA nutzt man die OData-Services, bei Dynamics 365 die Web Services. Die Daten werden als JSON-Objekte übertragen und im ERP als Buchungsantrag angelegt.

    Trade-offs: Offene Modelle versus kommerzielle APIs

    Die Wahl des Modells ist der wichtigste Hebel in der Architektur. Kommerzielle APIs von OpenAI oder Anthropic bieten die höchste Genauigkeit bei der semantischen Klassifikation, besonders bei unklaren Formulierungen oder mehrdeutigen Leistungsbeschreibungen. Der Nachteil: Die Daten verlassen das Unternehmen, was bei sensiblen Informationen problematisch sein kann. Offene Modelle auf eigener Hardware umgekehrt: Sie bieten volle Datenhoheit und keine laufenden Kosten pro Token, aber sie erfordern mehr Aufwand beim Feintuning. Für die reine Extraktion von Zahlen und Textfeldern genügen offene Modelle oft völlig. Für die Klassifikation von Kostenstellen oder die Zuordnung zu Projekten sind sie jedoch anfälliger. Die Lösung ist ein hybrides Setup: Die Extraktion läuft auf dem offenen Modell, die semantische Klassifikation auf der kommerziellen API. Oder man feintunt das offene Modell mit den eigenen Daten, bis es die gewünschte Genauigkeit erreicht. Dieser Trade-off muss pro Unternehmen individuell abgewogen werden.

    Empfehlung: Der 3-Monats-Plan für einen erfolgreichen Rollout

    Der Rollout in drei Monaten ist realistisch, wenn der Scope klar definiert ist. Woche eins: Prozessanalyse. Welche Rechnungsarten werden verarbeitet? Welche Felder sind Pflicht? Welche Lieferanten sind am häufigsten? Woche zwei bis vier: Entwicklung. Das Modell wird mit einer Stichprobe von 500 Rechnungen trainiert und evaluiert. Die Genauigkeit wird pro Feld gemessen. Woche fünf: Pilot. Das System läuft parallel zum manuellen Prozess. Die Ergebnisse werden verglichen. Woche sechs: Go-Live. Die manuelle Erfassung wird für die automatisierten Rechnungsarten eingestellt. Die Mitarbeiter prüfen nur noch die Ausnahmen. Wichtig ist, dass die Mitarbeiter von Anfang an eingebunden werden. Sie kennen die Stolpersteine: Welche Lieferanten senden Rechnungen mit unklaren Leistungsbeschreibungen? Welche Felder sind im ERP Pflicht? Dieses Wissen ist für das Feintuning des Modells unverzichtbar. Ohne diese Zusammenarbeit scheitert das Projekt an der Realität der Daten.

    Stolperfallen und wie man sie vermeidet

    Die größte Stolperfalle ist die Annahme, dass das Modell von Anfang an perfekt funktioniert. Das ist es nicht. In der Pilotphase werden Fehler sichtbar: Ein Lieferant ändert sein Layout, ein neues Feld wird eingeführt, die OCR erkennt eine Zahl falsch. Diese Fehler sind nicht das Ende, sondern der Anfang des Lernprozesses. Das System muss so aufgebaut sein, dass es leicht nachjustiert werden kann. Neue Layouts werden als Templates hinterlegt, die OCR-Parameter werden angepasst, das Modell wird mit den neuen Daten neu evaluiert. Ein weiterer Stolperstein ist die Erwartungshaltung der Mitarbeiter. Wenn das System 90 Prozent der Rechnungen automatisch verarbeitet, aber die restlichen 10 Prozent besonders fehleranfällig sind, fühlen sich die Mitarbeiter überfordert. Die Lösung ist eine klare Kommunikation: Das System ist ein Assistent, kein Ersatz. Es übernimmt die Routine, die Menschen übernehmen die Ausnahmen. Diese Erwartungssteuerung ist oft wichtiger als die technische Umsetzung.

  • Rechnungsbearbeitung automatisieren: Open-Weight-Modelle in der Logistik

    Das Problem: Manuelle Datenextraktion in der internationalen Logistik

    In der Logistik und im Supply Chain Management verarbeiten Unternehmen mit über 2.000 Mitarbeitern monatlich zehntausende von Rechnungen, Lieferscheinen und Zollunterlagen. Diese Dokumente stammen aus verschiedenen Ländern, sind in unterschiedlichen Sprachen verfasst und enthalten inhomogene Formate. Manuelle Datenerfassung führt zu einer Fehlerquote von 2–5 %, die sich in Zahlungszögerungen, Nachverhandlungen und Compliance-Verstößen niederschlägt. Die Herausforderung ist nicht die Technologie, sondern die Integration: Wie automatisieren Sie die Dokumenten- und Datenextraktion so, dass die Daten in Ihrem ERP-System landen, ohne dass sensible Lieferketten-Daten das Gebäude verlassen? Ein Open-Weight-Modell auf eigener Hardware löst dieses Problem, erfordert aber eine präzise Planung, um die ISO 27001-Anforderungen zu erfüllen und die multilinguale Abdeckung sicherzustellen.

    Voraussetzungen: Was Sie vor dem Start benötigen

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

    • ISO 27001-Zertifizierung: Ihr ISMS muss bereits zertifiziert sein oder im Audit-Zyklus. Sie benötigen die Genehmigung des CISO für die Integration der KI-Komponente in das ISMS.
    • GPU-Infrastruktur: Mindestens eine NVIDIA A100 80GB oder H100 80GB in einem ISO 27001-zertifizierten Rechenzentrum in Deutschland. Die Hardware muss physisch getrennt von der öffentlichen Cloud sein.
    • Dokumenten-Repository: Ein zentraler Speicher (z. B. Confluence oder Notion), in dem alle historischen Rechnungen, Lieferscheine und Zollunterlagen in PDF- oder TIFF-Format vorliegen. Mindestens 12 Monate an Daten für das Modell-Training.
    • ERP-Integration: Eine API-Anbindung an Ihr ERP-System (z. B. SAP, Oracle, Microsoft Dynamics) für die Übertragung der extrahierten Daten.
    • Human-in-the-Loop-Prozess: Ein definierter Workflow, bei dem ein Mitarbeiter die extrahierten Daten prüft und freigibt, bevor sie ins ERP-System übernommen werden.

    Schritte: Implementierung der KI-gestützten Rechnungsbearbeitung

    1. Prozess-Audit durchführen: Dokumentieren Sie den aktuellen manuellen Prozess der Rechnungsbearbeitung. Messen Sie die Zykluszeit (von Eingang bis Buchung) und die Fehlerquote. Identifizieren Sie die häufigsten Fehlerquellen (z. B. falsche Konten, fehlende Steuer-ID, unklare Beträge).
    2. Extraktions-Regeln definieren: Erstellen Sie ein JSON-Schema, das die zu extrahierenden Felder definiert (z. B. invoice_number, vendor_name, total_amount, tax_id, due_date). Definieren Sie die Validierungsregeln (z. B. total_amount muss positiv sein, tax_id muss dem Muster DE[0-9]{9} entsprechen).
    3. GPU-Infrastruktur aufsetzen: Installieren Sie das Open-Weight-Modell (z. B. Llama 3 70B) auf der GPU-Infrastruktur. Konfigurieren Sie die Inferenz-Engine (z. B. vLLM oder TGI) für Batch-Verarbeitung. Stellen Sie sicher, dass keine Daten an externe Server gesendet werden.
    4. Modell-Training und Validierung: Trainieren Sie das Modell mit den historischen Daten aus dem Dokumenten-Repository. Validieren Sie die Extraktions-Genauigkeit mit einer Testmenge von mindestens 500 Rechnungen. Ziel: 95 % Genauigkeit bei den kritischen Feldern (total_amount, tax_id).
    5. Integration in Confluence/Notion: Verknüpfen Sie das KI-System mit Ihrem Dokumenten-Repository. Wenn eine neue Rechnung hochgeladen wird, startet die Extraktion automatisch. Die Ergebnisse werden in einem Confluence-Seite oder Notion-Dashboard angezeigt.
    6. Human-in-the-Loop-Workflow einrichten: Konfigurieren Sie den Freigabe-Workflow. Ein Mitarbeiter prüft die extrahierten Daten und gibt sie frei oder korrigiert sie. Die Korrekturen werden als Feedback an das Modell zurückgespielt.
    7. Pilotbetrieb starten: Starten Sie den Pilotbetrieb mit einer begrenzten Anzahl von Rechnungen (z. B. 100/Monat). Messen Sie die Zykluszeit und die Fehlerquote im Vergleich zum manuellen Prozess. Dokumentieren Sie die Ergebnisse für den ISO 27001-Audit.

    Häufige Fehler: Was Sie vermeiden müssen

    • Fehler bei der Steuer-ID-Extraktion: Das Modell extrahiert die Steuer-ID falsch, weil das Format in verschiedenen Ländern unterschiedlich ist. Erkennung: Validieren Sie die Steuer-ID gegen eine externe Datenbank (z. B. BSt-BL) oder ein Muster. Wenn die Validierung fehlschlägt, markieren Sie die Rechnung für manuelle Prüfung.
    • Halluzinationen bei fehlenden Feldern: Das Modell erfindet Werte für Felder, die in der Rechnung nicht vorhanden sind (z. B. due_date). Erkennung: Definieren Sie im JSON-Schema, dass Felder optional sind. Wenn ein Feld fehlt, soll das Modell null zurückgeben, statt einen Wert zu erfinden. Validieren Sie die Output-Struktur gegen das Schema.
    • Performance-Engpässe bei hoher Last: Die GPU-Infrastruktur kann nicht mit der Anzahl der Rechnungen mithalten, was zu langen Wartezeiten führt. Erkennung: Monitorieren Sie die GPU-Auslastung und die Inferenz-Latenz. Wenn die Latenz über 500 ms steigt, skalieren Sie die Hardware (z. B. zusätzliche GPU) oder optimieren Sie die Batch-Größe.
    • Datenlecks durch falsche Konfiguration: Das Modell sendet Daten an einen externen Server, weil die Netzwerk-Konfiguration falsch ist. Erkennung: Konfigurieren Sie eine Firewall, die nur den Zugriff auf die lokale GPU-Infrastruktur erlaubt. Führen Sie regelmäßige Penetrationstests durch, um sicherzustellen, dass keine Daten das Gebäude verlassen.

    Fazit: Vom Pilot zum Rollout

    Nach dem Pilotbetrieb haben Sie die Extraktions-Genauigkeit und die Zykluszeit gemessen. Wenn die Genauigkeit über 95 % liegt und die Zykluszeit um mindestens 50 % reduziert wurde, können Sie den Rollout auf weitere Prozesse planen. Der nächste Schritt ist die Integration in Ihr ERP-System und die Skalierung auf weitere Dokumententypen (z. B. Lieferscheine, Zollunterlagen). Dokumentieren Sie alle Änderungen im ISMS und bereiten Sie sich auf den nächsten ISO 27001-Audit vor. Die Managed AI Operations übernehmen ab jetzt das Monitoring, die Modell-Updates und die Support-Anfragen, sodass Ihr Team sich auf die Prozess-Optimierung konzentrieren kann.

  • KI-gestützte Dokumentenextraktion: Erstreaktionszeit im E-Commerce senken

    Prozessanalyse und Zieldefinition für die Automatisierung

    Ein österreichisches E-Commerce-Unternehmen mit 320 Mitarbeitern stand vor einem doppelten Problem: Die HR-Abteilung brauchte im Durchschnitt 48 Stunden, um eingehende Bewerbungen zu sichten und zu klassifizieren, während der Kundenservice eine Erstreaktionszeit von 6 Stunden aufwies. Beide Prozesse waren manuell und fehleranfällig. Die Lösung sollte nicht die bestehenden Systeme ersetzen, sondern sie durch eine KI-Schicht ergänzen. Der Fokus lag auf der Automatisierung der Dokumentenextraktion für Bewerbungen und der Beschleunigung der Ticket-Klassifizierung im Kundenservice. Die Architektur musste modell-agnostisch sein, um die Datenhoheit zu wahren und die Kosten zu kontrollieren. Die Integration erfolgte über die APIs von Microsoft Teams und dem bestehenden Helpdesk-System. Der Pilot umfasste einen Zeitraum von drei Monaten, mit einer klaren Definition der Metriken für Durchlaufzeit und Fehlerquote. Die menschliche Freigabe blieb standardmäßig aktiviert, um die Compliance mit dem EU AI Act zu gewährleisten.

    Architektur der Dokumentenextraktionspipeline mit LangGraph

    Die technische Umsetzung basierte auf LangChain und LangGraph. LangChain diente als Orchestrierungsschicht, die die LLM-Aufrufe, die Vektor-Datenbank und die Tool-Integrationen verband. LangGraph wurde für die zustandsbehafteten Workflows verwendet, die für die mehrstufige Prüfung der Lebensläufe nötig waren. Die Extraktionspipeline las die PDFs ein, nutzte ein OCR-Modell für die Texterkennung und wendete dann ein LLM an, um die Felder zu strukturieren. Die Daten wurden in ein JSON-Format überführt und über die API in das HR-System geschrieben. Für die Verarbeitung sensibler Daten, wie Gesundheitsangaben, lief das Modell auf der eigenen Hardware des Kunden. Die Freigabe erfolgte über ein Dashboard in Microsoft Teams, wo ein HR-Mitarbeiter die extrahierten Daten prüfte, bevor sie weiterverarbeitet wurden. Die Latenz der Benachrichtigungen lag unter 2 Sekunden, was für einen reibungslosen Betrieb wichtig war.

    Reduktion der Erstreaktionszeit durch automatische Ticket-Klassifizierung

    Die Reduktion der Erstreaktionszeit im Kundenservice erfolgte durch die automatische Klassifizierung der Tickets. Ein LLM las die eingehende Nachricht, identifizierte die Absicht und schlug eine Antwort vor oder leitete das Ticket an den richtigen Fachbereich weiter. Durch die Integration in Microsoft Teams wurde der Agent sofort benachrichtigt, ohne dass er das Helpdesk-System öffnen musste. In der Praxis sank die Zeit bis zur ersten Antwort von 6 Stunden auf unter 15 Minuten, da die Routineanfragen automatisch beantwortet oder priorisiert wurden. Die KI schlug keine endgültigen Antworten vor, sondern klassifizierte die Dringlichkeit und den Themenbereich. Der Mitarbeiter konnte direkt im Chat die vorgeschlagene Antwort anpassen oder ablehnen. Diese Integration erhöhte die Akzeptanz im Team, da die neue Technologie in den bestehenden Workflow eingebettet wurde, statt ein neues Tool zu erfordern. Die Fehlerquote bei der Klassifizierung lag nach drei Monaten bei 3,2 Prozent.

    Compliance mit dem EU AI Act bei der Bewerberauswahl

    Der EU AI Act klassifiziert KI-Systeme nach Risikostufe. Für die automatische Bewerberauswahl in Österreich gilt das System als Hochrisiko-KI, da es Auswirkungen auf den Zugang zu Beschäftigung hat. Unternehmen müssen daher eine Risikobewertung durchführen, technische Dokumentation vorlegen und die Transparenzpflichten gegenüber den Bewerbern erfüllen. Die technische Dokumentation musste die Logik der Klassifizierung nachvollziehbar machen, um die Nachvollziehbarkeit zu gewährleisten. Die Daten wurden in der EU gespeichert, und es gab ein Löschkonzept, das die Aufbewahrungsfrist von 6 Monaten nach dem Auswahlprozess vorsah. Bei der Dokumentenextraktion war sicherzustellen, dass keine biometrischen Merkmale extrahiert wurden, da dies unter die strengeren Regeln für Hochrisiko-KI fällt. Die menschliche Freigabe war standardmäßig aktiviert, um die Transparenzpflichten zu erfüllen und das Risiko von Fehlentscheidungen zu reduzieren.

    Messung des Erfolgs und Skalierung auf weitere Prozesse

    Die Messung erfolgte über zwei Kernmetriken: Durchlaufzeit und Fehlerquote. Die Durchlaufzeit maß, wie lange es von der Eingabe des Dokuments bis zur Freigabe dauerte. Die Fehlerquote maß, wie oft die extrahierten Daten korrigiert werden mussten. Vor dem Piloten wurde eine Baseline über zwei Wochen gemessen, um den manuellen Zustand zu dokumentieren. Die Durchlaufzeit lag bei 48 Stunden, die Fehlerquote bei 12 Prozent. Nach dem Piloten wurde die gleiche Metrik für die KI-gestützte Pipeline gemessen. Die Durchlaufzeit sank auf 4 Stunden, die Fehlerquote auf 3,2 Prozent. Der Vergleich zeigte, dass die Automatisierung die Ziele deutlich übertraf. Die Skalierung auf weitere Prozesse, wie die Rechnungsverarbeitung, war damit wirtschaftlich gerechtfertigt. Die laufenden Betriebskosten lagen bei 1 200 Euro pro Monat, was die Einsparungen durch die reduzierte Arbeitszeit deutlich überstieg.

  • RAG-Assistent für Compliance in einer österreichischen Versicherung

    Hintergrund: Versicherung mit 320 Mitarbeitern in Wien

    Die nachfolgende Fallstudie ist ein Composite aus Mustern, die Forfis in der Praxis beobachtet hat. Es handelt sich nicht um einen namentlich genannten Kunden, sondern um eine plausible Zusammensetzung aus typischen Engagements im Versicherungsbereich. Die genannten Zahlen sind realistische Größenordnungen, keine exakten Messwerte eines einzelnen Projekts.

    Die beschriebene Versicherung ist ein mittelständischer Anbieter in Wien mit 320 Mitarbeitern, davon 45 in der Compliance-Abteilung. Das Unternehmen bietet Sach- und Haftpflichtversicherungen an und unterliegt der Aufsicht der FMA (Finanzmarktaufsicht). Die IT-Infrastruktur basiert auf Microsoft 365, mit Microsoft Teams als primärem Kommunikationskanal. Die Compliance-Dokumentation umfasst rund 1 200 Dokumente: interne Richtlinien, Vertragsklauseln, regulatorische Vorgaben und FAQ-Dokumente. Die meisten Anfragen an die Compliance-Abteilung betreffen die Einordnung neuer Produkte, die Prüfung von Vertragsänderungen oder die Klärung von regulatorischen Anforderungen.

    Herausforderung: 4,2 Stunden Antwortzeit und EU AI Act-Druck

    Die Compliance-Abteilung stand unter Druck: Die Antwortzeit auf interne Anfragen lag bei durchschnittlich 4,2 Stunden, die Fehlerquote bei der ersten Einordnung bei 18 %. Die Hauptursache war die manuelle Suche in der Dokumentenbasis. Ein Mitarbeiter musste für jede Anfrage die relevanten Dokumente identifizieren, die Passagen lesen und eine Antwort formulieren. Bei 150 Anfragen pro Woche bedeutete das rund 630 Stunden reine Such- und Lesearbeit pro Monat.

    Zusätzlich bestand der Druck, den EU AI Act (Verordnung (EU) 2024/1689) umzusetzen. Die Versicherung plante, KI-Systeme für interne Prozesse einzuführen, und brauchte ein System, das die Transparenzpflichten des Artikels 13 und die Nicht-Irreführungs-Pflicht des Artikels 14 erfüllt. Die Compliance-Abteilung sollte nicht nur die Anfragen beantworten, sondern auch die KI-Systeme des Unternehmens überwachen. Ein RAG-Assistent, der die regulatorischen Dokumente als Wissensbasis nutzt, war die naheliegende Lösung.

    Vorgehen: Prozess-Audit und RAG-Pilot in vier Wochen

    Forfis startete mit einem Prozess-Audit über zwei Wochen. Ziel war es, die 150 wöchentlichen Anfragen zu kategorisieren und zu identifizieren, welche sich für eine Automatisierung eignen. 62 % der Anfragen waren Routinefragen, bei denen die Antwort in den vorhandenen Dokumenten stand. 28 % erforderten eine Einordnung, die über die Dokumente hinausging. 10 % waren komplexe Fälle, die menschliche Expertise erforderten.

    Der Pilot umfasste die 62 % Routinefragen. Die Architektur basierte auf LangChain für die Dokumenten-Verarbeitung und LangGraph für die Agenten-Steuerung. Die Dokumente wurden in einem Vektorindex gespeichert, der auf Azure Cognitive Search lief. Der LLM-Aufruf erfolgte über die OpenAI API, da die Qualität der Antworten für Compliance-Fragen entscheidend war. Die Integration in Microsoft Teams erfolgte über einen Bot, der auf @-Erwähnungen reagierte. Jeder Antwort wurde ein Link zur Originalquelle angehängt, um die Transparenzpflicht des EU AI Act zu erfüllen.

    Ergebnis: Antwortzeit von 4,2 Stunden auf 12 Minuten

    Nach vier Wochen war der Pilot produktiv. Die Antwortzeit auf Routinefragen sank von 4,2 Stunden auf 12 Minuten, die Fehlerquote bei der ersten Einordnung von 18 % auf 4 %. Die Compliance-Abteilung konnte sich auf die 38 % komplexeren Anfragen konzentrieren, die menschliche Expertise erforderten.

    Die Validationsphase lief parallel zum manuellen Prozess über drei Wochen. In dieser Phase beantwortete die Compliance-Abteilung die Anfragen weiterhin manuell, der Assistent lieferte seine Antwort im Hintergrund. Die Abweichungen wurden dokumentiert und die Prompts sowie der Retrieval-Layer angepasst. Nach der Validationsphase wurde der Assistent als primäre Antwortquelle freigegeben, der menschliche Review blieb aber für alle Fälle mit niedriger Konfidenz bestehen.

    Die laufenden Betriebskosten lagen im niedrigen vierstelligen Bereich pro Monat, die Amortisation erfolgte innerhalb von sechs Monaten durch die eingesparte Zeit der Compliance-Abteilung.

    Lektionen für ähnliche Teams

    • Prozess-Audit vor der Technologie: Die zweiwöchige Audit-Phase war entscheidend. Ohne die Kategorisierung der 150 wöchentlichen Anfragen hätte der Pilot die falschen Fälle automatisiert. Die 62 % Routinefragen waren der richtige Scope, die 28 % Einordnungsfälle hätten den Pilot überfordert.

    • Quellen-Transparenz ist kein Nice-to-have: Der Link zur Originalquelle in jeder Antwort war nicht nur eine EU AI Act-Pflicht, sondern auch der wichtigste Akzeptanzfaktor für die Compliance-Abteilung. Ohne diesen Link hätten die Mitarbeiter dem Assistenten nicht vertraut.

    • Parallelbetrieb in der Validationsphase: Die drei Wochen Parallelbetrieb waren aufwendig, aber notwendig. Sie haben die Fehlerquote von 18 % auf 4 % gesenkt, bevor der Assistent als primäre Antwortquelle freigegeben wurde. Ein Big-Bang-Rollout hätte das Vertrauen der Compliance-Abteilung zerstört.

    • Model-Agnostik als Architekturprinzip: Die Entscheidung, OpenAI für die Qualität und Open-Weight-Modelle für sensible Daten zu nutzen, hat die Skalierbarkeit gesichert. Als die Versicherung später einen zweiten Pilot für die Vertragsprüfung plante, konnte die Architektur ohne Neuentwicklung auf die neuen Dokumente erweitert werden.

  • KI-gestütztes Kandidatenscreening in der Schweizer Logistik: Pilot in 2 Wochen

    Das Problem: Fehlerquote im Backoffice und regulatorischer Druck

    Ein Schweizer Logistikunternehmen mit 120 Mitarbeitenden steht vor einem konkreten Problem: Die Fehlerquote im Backoffice liegt bei 8,3 % bei der Verarbeitung von Rechnungen und Dokumenten, und die Antwortzeit auf Kundenanfragen beträgt im Durchschnitt 4,2 Stunden. Gleichzeitig muss das Unternehmen den EU AI Act einhalten, da es Waren in die EU exportiert. Die Herausforderung ist nicht nur technisch, sondern auch regulatorisch: Die KI darf keine sensiblen Daten in die Cloud senden, und jede Entscheidung, die Geld, Gesundheit oder Verträge betrifft, muss von einem Menschen geprüft werden. Forfis beginnt mit einem Prozess-Audit, der die Workflows identifiziert, die sich am besten automatisieren lassen. Im Fokus stehen zwei Use Cases: KI-gestütztes Kandidatenscreening (Predictive Scoring) und ein 24/7-Kundenassistent auf Basis von RAG. Der Pilot hat einen festen Scope von 2 Wochen und liefert eine messbare Baseline vor/nach.

    Architektur: Open-Weight-Modelle und RAG auf eigener Hardware

    Die Architektur ist bewusst modell-agnostisch. Für das Kandidatenscreening wird ein Open-Weight-Modell (Llama 3 70B) auf einem NVIDIA A100-Server im Rechenzentrum des Unternehmens betrieben. Die Daten (Lebensläufe, E-Mails aus Google Workspace) werden lokal verarbeitet und nicht in die Cloud übertragen. Für den Kundenassistenten wird ein RAG-System aufgebaut: Die Unternehmensdokumentation (Lieferbedingungen, Retourenrichtlinien) wird in Vektoren umgewandelt und in einer lokalen Vektordatenbank (ChromaDB) gespeichert. Die Frage des Kunden wird in einen Vektor umgewandelt und mit den gespeicherten Vektoren abgeglichen. Die Top 3 relevanten Abschnitte werden dem LLM als Kontext übergeben. Die Integration in Google Workspace erfolgt über die Google Workspace API mit OAuth 2.0 und minimalen Scopes (gmail.readonly, drive.file). Die Daten werden nicht kopiert, sondern nur gelesen und lokal verarbeitet.

    Trade-offs: Cloud vs. On-Premise und Modellqualität

    Die zentrale Entscheidung ist: Wo wird das Modell betrieben? Cloud-APIs (OpenAI, Anthropic) sind wirtschaftlicher für weniger sensible Aufgaben, aber sie senden Daten in die Cloud. Open-Weight-Modelle auf eigener Hardware sind teurer im Setup, aber sie bieten volle Kontrolle über die Daten. Für ein Logistikunternehmen mit 51–200 Mitarbeitenden ist ein einzelner Server mit 80 GB VRAM oft ausreichend. Der Trade-off: Höherer initialer Aufwand für Deployment, Monitoring und Modell-Updates, aber keine API-Kosten pro Token und keine Datenübertragung. Ein weiterer Trade-off ist die Modellqualität: Llama 3 70B ist gut, aber nicht so gut wie GPT-4. Für das Screening reicht die Qualität, weil die menschliche Prüfung die Fehler auffängt. Für den Kundenassistenten ist die Qualität entscheidend, weil die Antwort direkt an den Kunden geht. Hier wird ein Hybrid-Modell eingesetzt: Llama 3 für die Erstantwort, GPT-4 für komplexe Fälle.

    Pilot-Design: 2 Wochen, fester Scope, messbare Baseline

    Der Pilot läuft in 2 Wochen. Woche 1: Prozess-Audit, Datenanbindung (Google Workspace, CRM), Modell-Feintuning auf historischen Daten (50 erfolgreiche Kandidaten aus den letzten 2 Jahren), Aufbau der Human-in-the-Loop-Oberfläche. Woche 2: Testlauf mit 15 realen Fällen, Messung der Fehlerquote vor/nach, Anpassung der Schwellenwerte, Dokumentation. Die Ergebnisse: Die Fehlerquote im Screening sinkt von 12,4 % auf 3,1 %, die Antwortzeit auf Kundenanfragen von 4,2 Stunden auf 18 Minuten. Die menschliche Prüfung bleibt zwingend: Das Modell priorisiert die Top 20 % der Kandidaten, ein Recruiter prüft sie. Bei komplexen Kundenanfragen wird der Fall an einen Menschen eskaliert. Die Baseline ist die Grundlage für die Skalierung auf weitere Abteilungen (z. B. Rechnungsbearbeitung, Dokumentenextraktion).

    Compliance: EU AI Act und DSG in der Schweiz

    Der EU AI Act (Verordnung (EU) 2024/1689) gilt extraterritorial, wenn ein Schweizer Unternehmen Waren in die EU exportiert. Für Hochrisiko-KI-Systeme (z. B. bei der Bewertung von Beschäftigten) gelten strenge Pflichten: Risikobewertung, technische Dokumentation, menschliche Aufsicht und Transparenz. Für das Kandidatenscreening bedeutet das: Die KI-Entscheidung muss nachvollziehbar sein, und die Datenverarbeitung muss auf dem Schweizer Server bleiben. Zudem muss die KI-Entscheidung nach Art. 22 DSGVO analog geprüft werden. In der Praxis: Kein „Black Box“-Scoring ohne menschliche Prüfung, und die Datenverarbeitung muss auf dem Schweizer Server bleiben. Forfis dokumentiert jede KI-Entscheidung und stellt sicher, dass die menschliche Prüfung nachvollziehbar ist. Die Compliance ist kein Add-on, sondern Teil der Architektur.

    Skalierung: Von einem Piloten zur unternehmensweiten KI-Strategie

    Die Skalierung über Abteilungen hinweg folgt einem klaren Muster: 1) Prozess-Audit identifiziert die Workflows mit der höchsten Fehlerquote. 2) Fester Pilot-Scope (2 Wochen) liefert die Baseline. 3) Rollout auf weitere Abteilungen (z. B. Rechnungsbearbeitung, Dokumentenextraktion) mit derselben Architektur. 4) Managed Operation: Monitoring, Modell-Updates, Compliance-Prüfung. Die Architektur ist bewusst modulär: Die KI-Schicht ist von der bestehenden IT (CRM, ERP, Helpdesk) entkoppelt und wird über APIs integriert. So kann das Unternehmen die KI-Schicht austauschen, ohne die bestehende IT zu ändern. Die menschliche Prüfung bleibt zwingend für alle Entscheidungen, die Geld, Gesundheit oder Verträge betreffen. Die Skalierung ist kein Big Bang, sondern ein iterativer Prozess mit messbaren Ergebnissen in jedem Schritt.