Dane wrażliwe w rekrutacji a AI Act: kiedy pracodawca może zbierać dane o płci kandydatów

Dostajemy w kancelarii ostatnio serię pytań od klientów z HR-techu, która sprowadza się do tej samej sprzeczności.

Klient kupił narzędzie AI do wstępnego scoringu CV. Wdrożył je do procesu rekrutacyjnego. Po kilku miesiącach zauważył, że model częściej odrzuca aplikacje kobiet niż mężczyzn na te same role.

Chciałby to sprawdzić. Statystycznie, formalnie, na danych. Tyle że żeby zaudytować model pod kątem stronniczości względem płci, musi mieć w zbiorze testowym dane o płci kandydatów. A te dane RODO klasyfikuje jako szczególne kategorie danych, i co do zasady zakazuje ich przetwarzania (art. 9 ust. 1 RODO).

Sprzeczność, która w pierwszej chwili wygląda na ślepy zaułek: prawo nakazuje audytować model pod kątem dyskryminacji (Załącznik III pkt 4 AI Act traktuje rekrutację jako system AI wysokiego ryzyka), a jednocześnie zakazuje zbierania danych, bez których audyt jest niemożliwy.

Wyjątek z AI Act, którego mało kto się spodziewa

AI Act robi w tym miejscu coś, czego nie spotykaliśmy w samym RODO: tworzy lex specialis, który dopuszcza przetwarzanie danych szczególnych kategorii wyłącznie w celu wykrywania i korygowania uprzedzeń systemu AI wysokiego ryzyka.

Art. 10 ust. 5 Rozporządzenia (UE) 2024/1689 (AI Act):

W zakresie, w jakim jest to absolutnie konieczne do celów zapewnienia wykrywania i korygowania uprzedzeń w odniesieniu do systemów AI wysokiego ryzyka, dostawcy takich systemów mogą wyjątkowo przetwarzać szczególne kategorie danych osobowych, […] z zastrzeżeniem odpowiednich zabezpieczeń.

Pierwszy raz unijny prawodawca formalnie uznaje, że bez danych o atrybucie chronionym nie da się sprawdzić, czy algorytm dyskryminuje ze względu na ten właśnie atrybut, i że odmowa zbierania tych danych zostawia bias w ukryciu, zamiast chronić jednostkę.

Czyli: 7 warunków przetwarzania danych wrażliwych w audycie biasu

Wyjątek z art. 10 ust. 5 AI Act nie jest blankietowy. Otwiera ścieżkę, ale przepis stawia siedem warunków, które trzeba spełnić łącznie:

1. Brak alternatywy. Audyt biasu nie jest możliwy na danych syntetycznych lub anonimowych, czyli zanim sięgniesz po dane wrażliwe, musisz wykazać, że nie ma innej drogi.
2. Pseudonimizacja. Klucz oddzielony od zbioru, dostęp tylko dla osób upoważnionych do audytu.
3. Środki techniczno-organizacyjne. Zgodnie z RODO i obowiązującymi standardami bezpieczeństwa danych, ten warunek brzmi miękko, ale w praktyce kontroli weryfikowany jest twardo.
4. Brak udostępniania. Dane nie mogą trafić do stron trzecich, także do grupy kapitałowej, dostawcy modelu czy podmiotów przetwarzających poza zakresem samego audytu.
5. Usunięcie po wykorzystaniu. Dane są usuwane po skorygowaniu błędu lub po upływie okresu retencji (pierwsze z tych zdarzeń).
6. Dostępność, bezpieczeństwo, odporność. W zakresie zgodnym z DORA dla podmiotów objętych tym rozporządzeniem; dla pozostałych, w zakresie RODO i standardów branżowych.
7. Bezpieczeństwo fizyczne i ochrona. Bezpieczeństwo miejsc przechowywania i rygorystyczne kontrolowanie i dokumentowanie przetwarzania danych, aby uniknąć ich niewłaściwego wykorzystania.

Plus obowiązek dokumentacji wyjaśniającej, dlaczego przetwarzanie było konieczne i jakie środki zaradcze zostały zastosowane. Ta dokumentacja jest weryfikowana podczas kontroli organu nadzoru (w polskim kontekście: UODO + KNF dla podmiotów sektorowych + po wejściu w życie w pełnym zakresie AI Act organów nadzoru w tym zakresie).

Co z tego wynika dla działu HR i compliance

Trzy konkrety na koniec:

• Audyt biasu modelu AI w rekrutacji to nie luksus. Załącznik III pkt 4 AI Act traktuje rekrutację jako system wysokiego ryzyka, a wraz z tym idą obowiązki dokumentacyjne i kontrolne. Brak audytu jest ryzykiem regulacyjnym.
• Audyt wymaga danych o atrybutach chronionych: płci, wieku, pochodzeniu etnicznym, niepełnosprawności, orientacji seksualnej w zakresie istotnym dla danej roli. Bez tych danych formalnie audytujesz, ale niczego nie zaudytujesz.
• Zbieranie tych danych w celu audytu jest legalne pod warunkiem spełnienia kryteriów z art. 10 ust. 5 AI Act oraz właściwej dokumentacji ścieżki.

Krótko: niemożność audytu z powodu braku danych przestała być wymówką. W zamian wchodzą konkretne warunki, dokumentacja procesu i pełna odpowiedzialność po stronie wdrażającego.