Open-Source-KI im HR ist rechtlich nicht leichter als proprietäre KI. Sobald ein System Bewerbungen filtert, Kandidaten bewertet, Beförderungen vorbereitet oder Leistungsmuster von Beschäftigten auswertet, greift regelmäßig der Hochrisiko-Rahmen aus Anhang III Nr. 4 der EU-VO 2024/1689. Wer die Grundpflichten für HR-Teams zuerst einordnen will, sollte parallel unsere Beiträge zu HR und Personalwesen, zum EU AI Act für HR-Abteilungen und zu Artikel 4 lesen.
Letzte Aktualisierung: 23. März 2026
Die entscheidende Frage lautet deshalb nicht, ob ein Modell offen ist. Entscheidend ist, ob Ihr HR-System Menschen bei Einstellung, Beförderung, Aufgabenverteilung oder Leistungsbewertung beeinflusst. Genau dort endet die Open-Source-Romantik und beginnt die Betreiberverantwortung.
HR-KI = fast immer HOCHRISIKO
HR-KI ist im Recruiting und in der Mitarbeitersteuerung fast immer Hochrisiko. Anhang III Nr. 4 erfasst KI-Systeme für Recruiting, Auswahlentscheidungen, Beförderung, Kündigung, Aufgabenverteilung und Leistungsbewertung, sobald das System für diese Zwecke bestimmt ist.
Für die Praxis heißt das: Ein Open-Source-Modell wie Mistral 7B, Llama oder Qwen bleibt rechtlich irrelevant, wenn es in ein HR-Produkt eingebettet wird, das über Menschen urteilt. Die Risikoklasse hängt am Einsatzkontext, nicht an der Lizenz.
| HR-Anwendung | Typische Einordnung | Warum | | --- | --- | --- | | CV-Screening | Hochrisiko | Bewerber werden analysiert oder gefiltert | | Ranking von Kandidaten | Hochrisiko | KI beeinflusst Auswahl und Priorisierung | | Tool für zielgerichtete Stellenanzeigen | Hochrisiko | Anhang III Nr. 4 nennt gezielte Jobanzeigen ausdrücklich | | KI-gestützte Leistungsbewertung | Hochrisiko | Entscheidungen über Beschäftigte werden vorbereitet | | KI für Schicht- oder Aufgabenverteilung | Hochrisiko | Arbeitsbedingungen und Karrierechancen werden beeinflusst | | Generische Textassistenz ohne Personenbewertung | Meist nicht Hochrisiko | Kein individuelles Scoring oder Ranking von Personen |
- Prüfen Sie zuerst den Zweck des Systems, nicht den Modellnamen.
- Dokumentieren Sie jede HR-KI in einem KI-Inventar mit Zweck, Datenarten und betroffener Personengruppe.
- Eskalieren Sie jede Funktion, die Personen sortiert, bewertet oder prognostiziert, direkt an Compliance und Datenschutz.
Wer HR-KI als bloßes Produktivitätswerkzeug einstuft, übersieht den Kern des AI Act. Im Personalwesen führt schon eine scheinbar harmlose Vorselektion schnell in den Hochrisiko-Bereich.
Annex III Kategorie 4 im Detail
Annex III Kategorie 4 deckt mehr ab als klassisches CV-Screening. Der Gesetzestext nennt vier Gruppen: Recruiting und Auswahl, Entscheidungen über Arbeitsverhältnisse, Aufgabenverteilung auf Basis individuellen Verhaltens oder Eigenschaften sowie Überwachung und Bewertung von Leistung und Verhalten.
Diese Breite ist der Grund, warum viele HR-Tools falsch klassifiziert werden. Ein Anbieter verkauft oft “Assistenz”, obwohl das System faktisch Wahrscheinlichkeiten, Rankings oder Warnhinweise über einzelne Personen erzeugt.
| Teilbereich in Anhang III Nr. 4 | Typische HR-Tools | | --- | --- | | 4(a) Recruiting oder Auswahl natürlicher Personen | ATS mit Auto-Ranking, CV-Parser, Matching-Engines | | 4(a) Zielgerichtete Stellenanzeigen | Ad-Targeting für bestimmte Kandidatenprofile | | 4(b) Entscheidungen über Arbeitsverhältnis, Beförderung, Kündigung | Promotion-Scoring, Exit-Risk-Modelle, interne Talentfilter | | 4(c) Aufgabenverteilung nach Verhalten oder persönlichen Merkmalen | Schicht-Optimierung, Case-Zuteilung, Workforce-Management | | 4(d) Monitoring und Bewertung von Leistung und Verhalten | Productivity-Scoring, Mitarbeitermonitoring, Verhaltensanalysen |
Die operative Folge ist klar: Nicht nur Recruiting-Startups, sondern auch interne HR-Analytics-Projekte können unter Kategorie 4 fallen. Das gilt ebenso für Eigenentwicklungen auf Basis offener Modelle wie für eingekaufte SaaS-Produkte.
Für die Klassifizierung helfen drei Kontrollfragen:
- Bewertet das System einzelne Bewerber oder Beschäftigte?
- Beeinflusst das Ergebnis Einstellung, Beförderung, Vergütung, Kündigung oder Aufgabenzuteilung?
- Erzeugt das System Scores, Rankings, Empfehlungen oder Warnhinweise über Personen?
Wenn Sie zwei dieser Fragen mit Ja beantworten, sollten Sie den Einsatz als Hochrisiko-Fall behandeln, bis eine belastbare Gegenprüfung vorliegt. Diese Schlussfolgerung ist eine juristisch-konservative Inferenz aus Art. 6 und Anhang III, keine ausdrückliche Safe-Harbor-Regel.
Bias-Testing: Pflicht, nicht Kür
Bias-Testing ist bei HR-KI keine optionale Ethikmaßnahme, sondern ein Nachweisbaustein für rechtmäßigen Betrieb. Der AI Act verlangt für Hochrisiko-Systeme Daten- und Qualitätskontrollen nach Art. 10, menschliche Aufsicht nach Art. 14 und für Betreiber relevante, hinreichend repräsentative Eingabedaten nach Art. 26 Abs. 4, soweit sie die Kontrolle über diese Daten ausüben.
Im HR-Kontext ist Bias-Testing der praktisch belastbarste Weg, diese Pflichten zu belegen. Wer keine Vergleichswerte nach Geschlecht, Alter, Behinderung, Herkunft oder Beschäftigungsgruppe prüft, kann im Audit kaum erklären, warum ein Recruiting-Modell fair genug sein soll.
| Testfeld | Mindestfrage | Typischer Nachweis | | --- | --- | --- | | Datenbasis | Sind Trainings-, Validierungs- oder Eingabedaten verzerrt? | Datenprofil, Gruppenverteilung, Missing-Value-Analyse | | Auswahlquote | Weichen Erfolgsquoten je Gruppe stark ab? | Ratio-Analyse, Vier-Fünftel-Regel als Screening-Indikator | | Fehlerraten | Haben einzelne Gruppen mehr False Positives oder False Negatives? | Konfusionsmatrix je Gruppe | | Stabilität | Ändern sich Ergebnisse stark nach Standort, Sprache oder Jobfamilie? | Segmenttests, Drift-Berichte | | Menschliche Kontrolle | Kann HR problematische Ergebnisse stoppen oder korrigieren? | Freigabeprozess, Vier-Augen-Prinzip, Eskalationsprotokoll |
- Führen Sie Bias-Tests vor dem Go-live, nach jedem Modellupdate und mindestens quartalsweise im Betrieb durch.
- Testen Sie nicht nur das Basismodell, sondern die komplette Anwendung mit Prompts, Regeln, Schwellenwerten und HR-Daten.
- Halten Sie Abbruchkriterien fest, etwa wenn Auswahlquoten oder Fehlerraten definierte Schwellen überschreiten.
Die Vier-Fünftel-Regel ist dabei nur ein Frühwarnsignal, kein AI-Act-Grenzwert. Für deutsche Unternehmen kommt zusätzlich regelmäßig eine Datenschutz-Folgenabschätzung nach Art. 35 DSGVO in Betracht, wenn sensible oder umfangreiche Personaldaten verarbeitet werden.
Mistral 7B für HR-Anwendungen
Mistral 7B wird durch den Einsatz im HR nicht legaler oder riskanter als andere Modelle, sondern nur transparenter. Das Modell ist unter Apache 2.0 veröffentlicht und eignet sich technisch für Self-Hosting, Retrieval, interne Anpassungen und kontrollierte Deployments, aber die Hochrisiko-Einstufung bleibt bestehen, sobald es in Recruiting oder Mitarbeiterbewertung eingesetzt wird.
Gerade deshalb ist Mistral 7B für HR ein gutes Beispiel für einen verbreiteten Denkfehler. Viele Teams glauben, Open Source senke die AI-Act-Pflichten, obwohl der Deployer bei einem HR-System dieselben organisatorischen Anforderungen erfüllen muss wie bei proprietären Lösungen.
| Frage zu Mistral 7B im HR | Sachliche Antwort | | --- | --- | | Darf das Modell lokal betrieben werden? | Ja, das reduziert Vendor-Lock-in und kann Datenschutzrisiken senken. | | Fällt ein Recruiting-Tool auf Mistral-Basis unter Hochrisiko? | Ja, wenn der Zweck unter Anhang III Nr. 4 fällt. | | Entfällt Bias-Testing wegen Open Source? | Nein, der Betreiber muss faire Nutzung und Datenkontrolle nachweisen. | | Ist Self-Hosting automatisch compliant? | Nein, Self-Hosting ersetzt weder Governance noch Dokumentation. | | Ist Mistral 7B für jede HR-Aufgabe geeignet? | Nein, kleine offene Modelle brauchen klare Grenzen, Human Review und Fachtests. |
Für mittelständische HR-Teams ist Mistral 7B nur dann sinnvoll, wenn der Zweck eng begrenzt ist. Gute Einsatzfelder sind interne Entwürfe für Stellenanzeigen, FAQ-Unterstützung für Recruiter oder Vorlagen für Interviewleitfäden, solange keine automatische Personenauswahl erfolgt.
Nicht sinnvoll ist Mistral 7B als stiller Entscheider im Hintergrund. Sobald das Modell Bewerber sortiert, Ablehnungen vorbereitet oder Mitarbeiterleistungen bewertet, brauchen Sie denselben Compliance-Apparat wie bei jedem anderen Hochrisiko-System.
Art. 26 Pflichten für Betreiber
Art. 26 ist für HR-Abteilungen die zentrale Betreiberpflicht. Ab dem 2. August 2026 müssen Deployers von Hochrisiko-KI-Systemen diese Systeme gemäß Anleitung verwenden, menschliche Aufsicht sicherstellen, Eingabedaten kontrollieren, Vorfälle melden und automatisch erzeugte Logs mindestens sechs Monate aufbewahren, sofern solche Logs unter ihrer Kontrolle stehen.
Gerade im Personalwesen ist zusätzlich arbeitsrechtliche Kommunikation relevant. Beschäftigte und ihre Vertretungen müssen vor Inbetriebnahme informiert werden, wenn ein Hochrisiko-System am Arbeitsplatz genutzt wird.
| Pflicht nach Art. 26 | Was HR konkret tun muss | | --- | --- | | Nutzung gemäß Instructions for Use | Anbieterunterlagen prüfen, Zweckgrenzen schriftlich festlegen | | Menschliche Aufsicht | Fachliche Letztentscheidung bei HR oder Führungskraft verankern | | Relevante und repräsentative Eingabedaten | Datenfelder minimieren, Plausibilitätsprüfungen und Bias-Checks dokumentieren | | Monitoring und Incident Handling | Beschwerden, Fehlentscheidungen und auffällige Muster an Provider und intern an Compliance melden | | Log-Aufbewahrung mindestens 6 Monate | Scoring-Ergebnisse, Freigaben und Eingaben revisionssicher speichern | | Information von Beschäftigten | Betriebsrat, HR und betroffene Teams vor Nutzung einbinden |
Setzen Sie diese Pflichten in einer klaren Betreiberakte um:
- Systembeschreibung mit Zweck, Anbieter, Modell und Datenquellen.
- Freigabevermerk mit Rollen nach HR, IT, Datenschutz und Compliance.
- Testprotokolle für Qualität, Bias, menschliche Aufsicht und Failover.
- Betriebsdokumentation mit Logs, Beschwerden, Korrekturen und Review-Terminen.
Wer nur einen Lizenzvertrag unterschreibt, erfüllt Art. 26 nicht. Die Betreiberpflicht lebt im Prozess, nicht im Einkaufsordner.
Checkliste: OS-KI im Personalwesen
Open-Source-KI im Personalwesen ist nur dann vertretbar, wenn Sie den Betrieb wie ein Hochrisiko-Projekt steuern. Die folgende Checkliste deckt die Punkte ab, die vor Go-live und im laufenden Betrieb dokumentiert sein sollten.
| Prüffeld | Erledigt, wenn | | --- | --- | | Zweckklassifizierung | Der HR-Anwendungsfall ist gegen Anhang III Nr. 4 geprüft und freigegeben. | | Rollenklärung | Betreiber, IT, Datenschutz, Compliance und HR-Fachverantwortung sind benannt. | | Modellwahl | Lizenz, Hosting, Update-Prozess und Anbieterabhängigkeiten sind dokumentiert. | | Bias-Testing | Gruppenvergleiche, Fehlerraten und Abbruchschwellen sind festgelegt. | | Human Oversight | Keine Entscheidung über Personen läuft ohne qualifizierte menschliche Prüfung. | | Logging | Ergebnisse und Eingriffe werden mindestens sechs Monate aufbewahrt. | | Schulung | Betroffene Teams haben nachweisbar Artikel 4 verstanden. | | Interne Kommunikation | Betriebsrat, Fachbereich und Führungskräfte sind vor Start eingebunden. |
- Stoppen Sie jedes HR-KI-Projekt, das keine dokumentierte Zweckbeschreibung hat.
- Verbieten Sie automatische Ablehnungen ohne menschliche Zweitprüfung.
- Planen Sie vierteljährliche Re-Validierung bei neuen Daten, neuen Stellenprofilen oder Modellupdates.
- Verlinken Sie jedes HR-KI-System intern mit Richtlinie, DPIA, Bias-Protokoll und Incident-Prozess.
- Schulen Sie Recruiter und HR-Leitung separat, weil sie andere Risiken tragen als reine Endnutzer.
Wenn Sie Open-Source-KI im HR einsetzen wollen, brauchen Sie kein größeres Modell, sondern bessere Governance. Unsere EU-AI-Act-Schulung hilft HR-, Compliance- und Führungsteams dabei, Art. 4, Hochrisiko-Einstufung und Betreiberpflichten sauber nachweisbar umzusetzen.