In der deutschen Versicherungsbranche st\u00f6\u00dft das Recruiting an physikalische Grenzen. Eine mittelst\u00e4ndische Insurtech-Firma mit 120 Mitarbeitern erh\u00e4lt monatlich \u00fcber 400 Bewerbungen f\u00fcr technische und beratende Positionen. Die manuelle Sichtung durch zwei Recruiter bindet 60 Prozent ihrer Kapazit\u00e4t. 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\u00fchren zu Inkonsistenzen. Ein strukturierter Ansatz, der die harten Filter automatisiert und die weiche Bewertung unterst\u00fctzt, ist die einzige skalierbare L\u00f6sung, ohne die HR-Abteilung aufzubl\u00e4hen.<\/p>\n
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 \u00fcbergibt den Text an das LLM. Das Modell, ein offenes Gewicht-Modell wie Llama 3 70B, l\u00e4uft auf einer NVIDIA A100 GPU im Rechenzentrum des Kunden. Die Inferenz erfolgt \u00fcber die vLLM-API, die eine Batch-Verarbeitung mit einer Latenz von unter 300 ms erm\u00f6glicht. Die Antwort des LLMs ist ein JSON-Objekt mit den Feldern \u2018seniority\u2019, \u2018skill_match\u2019 und \u2018risk_flags\u2019. Der Orchestrator validiert dieses Schema und schreibt die Daten zur\u00fcck in das ATS. Diese Trennung von Orchestrierung und Inferenz erlaubt es, das Modell jederzeit zu tauschen, ohne die Integrationslogik anzufassen.<\/p>\n
Die Entscheidung f\u00fcr offene Modelle auf eigener Hardware ist ein bewusster Trade-off. Cloud-APIs wie GPT-4 bieten h\u00f6here Genauigkeit bei der semantischen Analyse, erfordern aber den Datentransfer in externe Rechenzentren. F\u00fcr 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\u00e4llig f\u00fcr Halluzinationen. Dies wird durch eine strenge Prompt-Engineerung und eine menschliche Freigabeschleife (Human-in-the-Loop) kompensiert. Der Recruiter sieht immer die Begr\u00fcndung des Modells und kann sie mit einem Klick \u00fcberstimmen.<\/p>\n
Der Pilotbetrieb startet mit einer einzigen Stellenkategorie, z. B. \u2018Softwareentwickler Backend\u2019. Das System l\u00e4uft parallel zur manuellen Arbeit. Die Metriken werden t\u00e4glich verglichen: Wie viele Kandidaten hat das Modell als \u2018Top Match\u2019 markiert, die der Recruiter abgelehnt hat? Und umgekehrt? Nach vier Wochen wird die Genauigkeit auf \u00fcber 90 Prozent bei den harten Kriterien stabilisiert. Die Skalierung erfolgt dann auf weitere Profile. Der entscheidende Hebel ist die Reduktion der Datenpflege: Statt manuell \u2018Python\u2019 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\u00fcr die pers\u00f6nliche Ansprache genutzt werden. Die Skalierung gelingt ohne neue Einstellungen, weil die Kapazit\u00e4t der bestehenden Recruiter durch die Automatisierung der Routineaufgaben multipliziert wird.<\/p>\n
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 \u00dcbergabe 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\u00e4nenlogik der Versicherung zu verstehen. Die Kosten liegen bei ca. 15.000 EUR pro Monat f\u00fcr das Team plus 800 EUR f\u00fcr die GPU-Infrastruktur. Die Amortisation erfolgt durch die eingesparte Recruiter-Zeit innerhalb der ersten zwei Monate nach Go-Live.<\/p>\n","protected":false},"excerpt":{"rendered":"
Wie Forfis mit lokalen LLMs und Workflow-Orchestrierung die manuelle Kandidatensichtung in der Versicherung ersetzt. Ein technischer Leitfaden f\u00fcr die Skalierung von HR-Prozessen ohne neue Einstellungen.<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"rank_math_title":"Kandidatensichtung in der Versicherung: Lokale LLMs statt manueller Datenpflege","rank_math_description":"Wie Forfis mit lokalen LLMs und Workflow-Orchestrierung die manuelle Kandidatensichtung in der Versicherung ersetzt. Ein technischer Leitfaden f\u00fcr die Skalierung von HR-Prozessen ohne neue Einstellungen.","rank_math_focus_keyword":"replace manual data entry candidate screening","_yoast_wpseo_title":"","_yoast_wpseo_metadesc":"","_yoast_wpseo_focuskw":"","pll_lang":"de","geo_jsonld":"{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@id\":\"https:\/\/blog.forfis.com\/blog\/ai-kandidatensichtung-versicherung-lokale-llms\/#article\",\"@type\":\"Article\",\"author\":{\"@id\":\"https:\/\/blog.forfis.com#org\"},\"dateModified\":\"2026-10-06T00:06:36.860871467+00:00\",\"datePublished\":\"2026-10-06T00:06:36.860871467+00:00\",\"description\":\"Wie Forfis mit lokalen LLMs und Workflow-Orchestrierung die manuelle Kandidatensichtung in der Versicherung ersetzt. Ein technischer Leitfaden f\u00fcr die Skalierung von HR-Prozessen ohne neue Einstellungen.\",\"headline\":\"Kandidatensichtung in der Versicherung: Lokale LLMs statt manueller Datenpflege\",\"inLanguage\":\"en\",\"keywords\":[\"One Process Automated\",\"Open-Weight Models On-Premise\",\"Workflow Orchestration\",\"HR and Recruiting\",\"51-200\",\"None\",\"Dedicated AI Team\",\"Insurance and Insurtech\",\"Custom REST API and Webhooks\",\"German\",\"Replace Manual Data Entry\",\"Germany\",\"6 months\",\"Candidate Screening\"],\"mainEntityOfPage\":\"https:\/\/blog.forfis.com\/blog\/ai-kandidatensichtung-versicherung-lokale-llms\/\",\"publisher\":{\"@id\":\"https:\/\/blog.forfis.com#org\"}},{\"@id\":\"https:\/\/blog.forfis.com\/blog\/ai-kandidatensichtung-versicherung-lokale-llms\/#faq\",\"@type\":\"FAQPage\",\"mainEntity\":[{\"@type\":\"Question\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"Ein dediziertes Team besteht aus einem Tech Lead, einem ML-Engineer und einem Product Owner, die ausschlie\u00dflich f\u00fcr das Projekt verf\u00fcgbar sind. Im Vergleich zu einer Agentur, die Ressourcen teilt, erm\u00f6glicht dies eine kontinuierliche Iteration ohne \u00dcbergabeverluste. Bei Forfis kostet diese Konstellation in der Regel 12.000 bis 15.000 EUR pro Monat. Der Vorteil liegt in der Kontinuit\u00e4t: Das Team kennt die internen Datenstrukturen und kann auf \u00c4nderungen im Recruiting-Prozess innerhalb von 48 Stunden reagieren, statt neue Anforderungen \u00fcber ein Ticket-System zu kl\u00e4ren.\"},\"name\":\"Was versteht man unter einem dedizierten AI-Team im Kontext von Forfis?\"},{\"@type\":\"Question\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"Die Skalierung gelingt, weil die automatische Vorqualifizierung die Kapazit\u00e4t der Recruiter freisetzt. Statt 200 Lebensl\u00e4ufe manuell zu sichten, pr\u00fcfen sie nur die 20 Kandidaten, die die harten Kriterien erf\u00fcllen. Die verbleibende Zeit flie\u00dft in die pers\u00f6nliche Ansprache und die Verhandlung. Bei einer 100-Personen-Firma bedeutet das, dass zwei Recruiter den Ansturm von 500 neuen Bewerbern pro Monat bew\u00e4ltigen k\u00f6nnen, ohne dass die Reaktionszeit \u00fcber 24 Stunden steigt.\"},\"name\":\"Wie skaliert man Recruiting-Operationen ohne zus\u00e4tzliche Einstellungen?\"},{\"@type\":\"Question\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"Die Latenz liegt bei 150 bis 300 ms f\u00fcr die Klassifizierung eines Lebenslaufs. Die Genauigkeit der harten Filter (z. B. 'hat 3 Jahre Java-Erfahrung') liegt bei \u00fcber 95 %. Die weiche Bewertung (Kulturell Fit) ist weniger pr\u00e4zise, daher erfolgt hier immer eine menschliche Gegenpr\u00fcfung. Die Fehlerquote bei der Datenextraktion in das ATS sinkt von 12 % auf unter 1 %, was die manuelle Nacharbeit drastisch reduziert.\"},\"name\":\"Welche Latenz und Genauigkeit sind bei der automatischen Kandidatensichtung zu erwarten?\"},{\"@type\":\"Question\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"Nein, die Integration erfolgt \u00fcber die bestehende REST-API des ATS. Das System liest neue Bewerbungen per Webhook ab, verarbeitet sie lokal und schreibt die angereicherten Daten (z. B. 'Seniority: Mid-Level', 'Skills: Python, SQL') zur\u00fcck in die ATS-Datenbank. Es findet kein Datenabfluss in externe Cloud-Dienste statt, was die Datensouver\u00e4nit\u00e4t vollst\u00e4ndig wahrt und die IT-Abteilung entlastet.\"},\"name\":\"Muss das bestehende ATS-System durch eine neue Software ersetzt werden?\"},{\"@type\":\"Question\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"Die Kosten setzen sich aus der Infrastruktur (GPU-Server, ca. 800 EUR\/Monat) und dem dedizierten Team (ca. 13.000 EUR\/Monat) zusammen. Im Vergleich zur manuellen Arbeit spart man pro verarbeiteter Bewerbung ca. 15 Minuten Recruiter-Zeit. Bei 500 Bewerbungen\/Monat sind das 125 Stunden, die bei einem Stundensatz von 50 EUR 6.250 EUR wert sind. Die Amortisation erfolgt also innerhalb der ersten zwei Monate, da die Investition in die Modell-Feinabstimmung einmalig ist.\"},\"name\":\"Wie hoch sind die laufenden Kosten f\u00fcr den Betrieb eines lokalen LLM-Stacks?\"},{\"@type\":\"Question\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"Das Modell wird auf den historischen Daten der letzten 12 Monate trainiert. Dabei werden die Entscheidungen der Recruiter (angenommen\/abgelehnt) als Label verwendet. Durch diese Feinabstimmung lernt das Modell die spezifischen Pr\u00e4ferenzen des Unternehmens, z. B. dass 'Projektverantwortung' bei Forfis-Kunden h\u00f6her gewichtet wird als 'Teamgr\u00f6\u00dfe'. Die Validierung erfolgt auf einem separaten Testdatensatz, um Overfitting zu vermeiden.\"},\"name\":\"Wie wird das offene Modell auf die spezifischen Anforderungen des Unternehmens angepasst?\"},{\"@type\":\"Question\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"Die Compliance-Last ist minimal, da keine personenbezogenen Daten das Geb\u00e4ude verlassen. Es gelten die allgemeinen Vorgaben des BDSG und der DSGVO. Da keine externe Cloud genutzt wird, entfallen die komplexen Auftragsverarbeitungsvertr\u00e4ge (AVV) mit Drittanbietern. Die Datenverarbeitung ist vollst\u00e4ndig nachvollziehbar, da die Logik im eigenen Code liegt und nicht in einer Blackbox-API. Dies vereinfacht Audits und Datenschutz-Folgenabsch\u00e4tzungen erheblich.\"},\"name\":\"Welche Compliance-Vorgaben gelten bei der Verarbeitung von Bewerberdaten mit lokalen Modellen?\"},{\"@type\":\"Question\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"Der Prozess beginnt mit einem Audit der bestehenden Workflows (Woche 1-2). Danach folgt die Einrichtung der GPU-Infrastruktur und die Anbindung an das ATS via API (Woche 3-4). In Woche 5-8 wird das Modell auf historischen Daten trainiert und validiert. Woche 9-12 ist der Pilotbetrieb, bei dem das System parallel zur manuellen Arbeit l\u00e4uft. Ab Woche 13 \u00fcbernimmt das System die Erstfilterung, w\u00e4hrend Recruiter nur noch die finalen Entscheidungen treffen. Monat 4-6 dient der Optimierung und Skalierung auf weitere Stellenprofile.\"},\"name\":\"Wie sieht der typische Zeitplan f\u00fcr die Implementierung eines solchen Systems aus?\"}]},{\"@id\":\"https:\/\/blog.forfis.com\/blog\/ai-kandidatensichtung-versicherung-lokale-llms\/#breadcrumbs\",\"@type\":\"BreadcrumbList\",\"itemListElement\":[{\"@type\":\"ListItem\",\"item\":\"https:\/\/blog.forfis.com\",\"name\":\"Home\",\"position\":1},{\"@type\":\"ListItem\",\"item\":\"https:\/\/blog.forfis.com\/blog\/\",\"name\":\"Blog\",\"position\":2},{\"@type\":\"ListItem\",\"item\":\"https:\/\/blog.forfis.com\/blog\/ai-kandidatensichtung-versicherung-lokale-llms\/\",\"name\":\"Kandidatensichtung in der Versicherung: Lokale LLMs statt manueller Datenpflege\",\"position\":3}]},{\"@id\":\"https:\/\/blog.forfis.com#org\",\"@type\":\"Organization\",\"name\":\"Forfis\",\"url\":\"https:\/\/blog.forfis.com\"}]}","geo_content_hash":"d65f99fb9bc1159d7ee4da2d9330cea6640c74549b1c91e2ac195f4a62288c9c","footnotes":""},"categories":[57],"tags":[71,27,73],"class_list":["post-504","post","type-post","status-publish","format-standard","hentry","category-insurance-and-insurtech","tag-candidate-screening","tag-germany","tag-replace-manual-data-entry"],"_links":{"self":[{"href":"https:\/\/blog.forfis.com\/blog\/wp-json\/wp\/v2\/posts\/504","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.forfis.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.forfis.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.forfis.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.forfis.com\/blog\/wp-json\/wp\/v2\/comments?post=504"}],"version-history":[{"count":0,"href":"https:\/\/blog.forfis.com\/blog\/wp-json\/wp\/v2\/posts\/504\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.forfis.com\/blog\/wp-json\/wp\/v2\/media?parent=504"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.forfis.com\/blog\/wp-json\/wp\/v2\/categories?post=504"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.forfis.com\/blog\/wp-json\/wp\/v2\/tags?post=504"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}