KI im Recruiting: Wann HR-Systeme nach dem AI Act hochriskant sind

Use Case statt Etikett HR-KI

Die Hochrisikoeinstufung knüpft nicht an die Abteilung oder die Bezeichnung des Produkts an, sondern an Zweckbestimmung und tatsächliche Verwendung. Anhang III Nummer 4 nennt unter anderem zielgerichtete Stellenanzeigen, Analyse und Filterung von Bewerbungen sowie die Bewertung von Kandidatinnen und Kandidaten. Ebenfalls erfasst werden bestimmte Systeme für Entscheidungen über Arbeitsbedingungen, Beförderung und Beendigung sowie leistungs- oder verhaltensbezogenes Monitoring in Beschäftigungsverhältnissen.

Terminplanung, Raumbuchung, Rechtschreibkorrektur oder die rein technische Ablage von Bewerbungsunterlagen sind daher nicht allein wegen ihres HR-Kontexts hochriskant. Die Grenze kann sich jedoch verschieben, wenn eine administrative Funktion Merkmale ableitet, Rankings erzeugt oder Empfehlungen liefert, die das Ergebnis wesentlich beeinflussen. Unternehmen sollten nicht nur die Produktbeschreibung, sondern Konfiguration, Datenflüsse, Ausgaben und den realen Arbeitsablauf erfassen.

• Konkreten Verwendungszweck und tatsächlichen Einsatz beschreiben
• Entscheidungseinfluss statt Produktetikett bewerten
• Konfiguration und eingebettete Funktionen in die Prüfung einbeziehen

Quellen: [1] [3]

Ausnahme nach Art. 6 Absatz 3 sorgfältig prüfen

Ein System aus einem gelisteten Anwendungsbereich kann ausnahmsweise nicht als hochriskant gelten, wenn es kein erhebliches Risiko für Gesundheit, Sicherheit oder Grundrechte begründet und das Ergebnis einer Entscheidung nicht wesentlich beeinflusst. Genannt werden enge Verfahrensaufgaben, Verbesserungen bereits abgeschlossener menschlicher Tätigkeiten, Mustererkennung ohne Ersetzung oder Beeinflussung der menschlichen Bewertung sowie vorbereitende Aufgaben. Diese Kriterien sind am konkreten Prozess und nicht abstrakt am Anbieterprospekt zu prüfen.

Profiling natürlicher Personen innerhalb eines gelisteten Anwendungsfalls bleibt in diesem Prüfungsrahmen stets hochriskant. Anbieter, die sich auf die Ausnahme stützen, müssen ihre Beurteilung vor dem Inverkehrbringen oder der Inbetriebnahme dokumentieren und das System nach Artikel 49 Absatz 2 registrieren. Eine menschliche Unterschrift allein beseitigt wesentlichen Einfluss nicht, wenn Rankings faktisch übernommen werden, Zeitdruck eine echte Prüfung verhindert oder abweichende Entscheidungen organisatorisch unerwünscht sind. Der tatsächliche Human Override ist deshalb zu testen.

• Ausnahmekriterium und fehlenden wesentlichen Einfluss belegen
• Profiling als besondere Grenze erkennen
• Formale und tatsächliche menschliche Kontrolle unterscheiden

Quellen: [1] [3]

Anbieter und Betreiber trennen

Ein österreichischer Arbeitgeber ist beim Einsatz eines fremden Recruiting-Tools typischerweise Betreiber. Anbieter ist, wer das KI-System entwickelt oder entwickeln lässt und es unter eigenem Namen oder eigener Marke in Verkehr bringt oder in Betrieb nimmt. Diese Ausgangslage kann sich ändern, wenn das Unternehmen ein System unter eigenem Namen in Verkehr bringt, eine relevante Zweckänderung vornimmt oder eine wesentliche Änderung verantwortet. Eigenentwicklung kann ebenfalls Anbieterpflichten auslösen. Die Rollen sind für jede Systemversion und jede organisationsübergreifende Konstellation gesondert festzuhalten.

Im Vertrag müssen daher mehr als allgemeine Datenschutzklauseln stehen. Benötigt werden belastbare Informationen zu Zweckbestimmung, Trainings- und Eingabedaten, Leistungsgrenzen, Protokollen, menschlicher Aufsicht, Änderungen und Vorfällen. Weisungs- und Informationsrechte sollten ermöglichen, neue Modelle oder Funktionen vor produktiver Aktivierung zu bewerten. Ein White-Label-Auftritt darf nicht ungeprüft bleiben, weil Markenauftritt und tatsächliche Verantwortlichkeit die Rollenbewertung beeinflussen können.

• Rollen pro Use Case und Version dokumentieren
• Zweckänderung und wesentliche Änderung als Trigger festlegen
• Vertragliche Nachweise und Änderungsinformationen sichern

Quellen: [1] [2]

Verbote und Parallelrecht gelten schon heute

Biometrisch gestützte Emotionserkennung am Arbeitsplatz ist grundsätzlich verboten, sofern nicht ein medizinischer oder sicherheitsbezogener Zweck unter den gesetzlichen Voraussetzungen greift. Systeme, die aus Stimme, Gesicht oder Video vermeintliche Emotionen, Persönlichkeit oder Eignung ableiten, erfordern deshalb eine gesonderte Prüfung; Marketingbegriffe wie Engagement oder Cultural Fit ändern den Tatbestand nicht. Andere Verbote des Artikels 5 können je nach Gestaltung ebenfalls relevant sein.

Daneben bleiben DSGVO, österreichisches Gleichbehandlungsrecht, Arbeitsrecht und betriebliche Mitwirkungsrechte eigenständig anwendbar. Automatisierte Entscheidungen können Artikel 22 DSGVO berühren; umfangreiche Bewertungen oder neue Technologien können eine Datenschutz-Folgenabschätzung erfordern. Transparenz nach dem AI Act ersetzt weder eine datenschutzrechtliche Rechtsgrundlage noch die Prüfung mittelbarer Diskriminierung. Auch zulässige, nicht hochriskante Systeme brauchen daher einen rechtmäßigen und fairen Prozess.

• Emotionserkennung nicht mit allgemeiner Videoanalyse gleichsetzen
• DSGVO und Gleichbehandlungsrecht separat prüfen
• Mitwirkungs- und Informationsrechte frühzeitig einplanen

Quellen: [1] [4] [5]

Governance bis 2. Dezember 2027 aufbauen

Die spezifischen Anforderungen der Abschnitte 1 bis 3 des Kapitels III für Anhang-III-Systeme gelten nach dem Digital Omnibus ab 2. Dezember 2027. Das ist keine allgemeine Schonfrist für HR-KI. Bereits anwendbare Verbote, Art. 4 und andere Rechtsgebiete gelten unabhängig davon. Arbeitgeber sollten die verbleibende Zeit nutzen, um Inventar, Rollen, Datenqualität, menschliche Aufsicht und Lieferantennachweise systematisch aufzubauen, statt nur auf spätere Dokumente zu warten.

Für jeden Use Case sollten Zweck, betroffene Personen, Kriterien, Output und Entscheidungspfad dokumentiert sein. Bias-Tests müssen zur Zielgruppe und zum vorgesehenen Einsatz passen; sie ersetzen keine rechtliche Gleichbehandlungsprüfung. Zugriffe, Logs, Beschwerden, Übersteuerungen und Modelländerungen gehören in die laufende Kontrolle. Die zum Stichtag vorliegenden Kommissionsleitlinien zur Hochrisikoklassifizierung sind eine nicht bindende Auslegungshilfe und vor Veröffentlichung auf ihren finalen Status zu prüfen.

• Inventar und Klassifikationsakte je Use Case anlegen
• Human Override und Bias-Kontrollen praktisch testen
• Finalen Status der Kommissionsleitlinien erneut prüfen

Quellen: [2] [3]

Beschaffung mit klaren Stoppschwellen

Vor Vertragsschluss sollte der Fachbereich anhand realistischer Demonstrationen prüfen, welche Daten das System verarbeitet und wie Empfehlungen zustande kommen. Kritische Fragen betreffen Fehlerraten, Gruppenunterschiede, erklärbare Kriterien, Barrierefreiheit, Kandidateninformation und die Möglichkeit, Ergebnisse zu korrigieren. Fehlen notwendige Nachweise oder verhindert der Anbieter eine sinnvolle menschliche Kontrolle, ist der Einsatz zu begrenzen, zu verschieben oder abzulehnen.

Stoppschwellen sind vorab festzulegen: unerwartete Benachteiligungen, erhebliche Abweichungen zwischen Gruppen, nicht angekündigte Modellwechsel, Datenabfluss oder faktisch nicht übersteuerbare Rankings können eine Aussetzung auslösen. Wiederfreigabe setzt Ursachenanalyse und dokumentierte Abhilfe voraus. Ein geordneter Beschaffungsprozess unterstützt die Prüfung, bietet aber keine Garantie, dass der konkrete Einsatz rechtmäßig oder fehlerfrei bleibt.

• Nachweise vor Beschaffung statt nach dem Rollout verlangen
• Kandidateninformation und Beschwerdeweg gestalten
• Aussetzung und Wiederfreigabe mit Kriterien regeln

Quellen: [1] [4] [5]

Häufige Fragen