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

Zwei Ansätze zur Automatisierung des Candidate Screenings

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

Kriterien für die Bewertung

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

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

Vergleichstabelle: Lokal vs. Cloud

Szenario-spezifische Bewertung

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

Empfehlung für die Schweizer Versicherungswirtschaft

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