Wyciek danych z platformy rekrutacyjnej to dziś jeden z najcenniejszych celów w całym Twoim stacku, bo system ATS (applicant tracking system) gromadzi najgęstszą koncentrację regulowanych danych osobowych, z jakimi styka się Twoja firma: imiona i nazwiska, adresy, oczekiwania płacowe, CV, a coraz częściej także dokumenty tożsamości, nagrania wideo z rozmów i dane biometryczne generowane przez AI. Kiedy taki system zostaje złamany, atakujący nie dostają listy mailingowej. Dostają gotowy zestaw do kradzieży tożsamości i tworzenia deepfake'ów. Lekarstwem nie jest „wybierz dostawcę, który obiecuje bezpieczeństwo". Jest nim privacy-by-design: zbieraj mniej, szyfruj to, co zostaje, kasuj według harmonogramu i traktuj ATS jako system, który Twój plan reagowania na incydenty faktycznie obejmuje.

Jeśli odpowiadasz za stack rekrutacyjny, a Twój CISO albo zarząd zaczął pytać „czy to, co spotkało Mercor, może spotkać i nas?", ten tekst jest dla Ciebie. Oto co się naprawdę wydarzyło, dlaczego platformy rekrutacyjne nagle znalazły się na celowniku, jaka odpowiedzialność prawna za tym idzie i konkretna lista kontrolna zabezpieczeń, których możesz wymagać od każdego dostawcy.

## Co przydarzyło się Mercor (i dlaczego powinno przestraszyć każdy zespół rekrutacyjny)

Pod koniec marca 2026 roku platforma rekrutacyjna Mercor, działająca w branży AI, padła ofiarą włamania, w wyniku którego wyprowadzono około 4 TB danych — w tym numery ubezpieczenia społecznego (SSN) kandydatów, skany paszportów i praw jazdy, biometryczne dane twarzy oraz nagrania wideo z rozmów w jakości HD. Mercor, używany podobno do pozyskiwania kontraktorów trenujących modele dla dużych laboratoriów AI, nie został zaatakowany głównym wejściem. Włamano się przez zależność.

Atak dostał się do środka przez [kompromitację łańcucha dostaw LiteLLM](https://docs.litellm.ai/blog/security-update-march-2026). Grupa śledzona jako TeamPCP przejęła dane uwierzytelniające LiteLLM do publikacji w PyPI i opublikowała dwie spreparowane wersje pakietu z koniem trojańskim — v1.82.7 i v1.82.8. Według samego wpisu bezpieczeństwa LiteLLM złośliwe pakiety były dostępne w PyPI przez około 40 minut 24 marca 2026 roku, zanim trafiły do kwarantanny. Czterdzieści minut wystarczyło. Ładunek zbierał zmienne środowiskowe, klucze SSH, poświadczenia chmurowe, tokeny Kubernetes i hasła do baz danych. Następnie grupa wymuszeniowa Lapsus$ wystawiła Mercor na swojej stronie z wyciekami około 31 marca i wystawiła dane na licytację; Mercor ujawnił skutki na początku kwietnia, opisując siebie jako „jedną z tysięcy dotkniętych firm".

Dane, do których przyznał się Lapsus$, dzielą się na mniej więcej 939 GB kodu źródłowego, bazę kandydatów o rozmiarze 211 GB i około 3 TB przechowywanych plików ([Repello AI](https://repello.ai/blog/mercor-lapsus-litellm-breach); [SecurityWeek](https://www.securityweek.com/mercor-hit-by-litellm-supply-chain-attack/)). Baza kandydatów zawierała podobno CV, zweryfikowane dane kontaktowe i numery SSN. Najbardziej niepokojące były jednak przechowywane pliki: nagrania wideo kandydatów w HD, skany dokumentów tożsamości i biometryczne dane twarzy używane do dopasowywania twarzy do dokumentów.

Wniosek nie brzmi „LiteLLM był zły". LiteLLM jest szeroko używany — Wiz znalazł go w 36% przeanalizowanych środowisk chmurowych ([Wiz](https://www.wiz.io/blog/threes-a-crowd-teampcp-trojanizes-litellm-in-continuation-of-campaign)). Wniosek jest taki, że zasięg rażenia danych Twoich kandydatów obejmuje także dostawców Twoich dostawców, a najwrażliwszy zbiór, jaki masz, może siedzieć w systemie, o którym nikt w Twoim zespole bezpieczeństwa nawet nie myśli.

## Dlaczego platformy rekrutacyjne są dziś łakomym celem

Platformy rekrutacyjne to cenne cele, bo lejek rekrutacyjny zbiera więcej wrażliwych danych niż niemal każdy inny system zaplecza, a mimo to rzadko trafia w zakres programu bezpieczeństwa firmy. Pomyśl, co przepływa przez ATS przy jednym zatrudnieniu: imię i nazwisko, adres domowy, telefon, e-mail, pełna historia zatrudnienia, oczekiwania płacowe, CV, referencje, a w wielu nowoczesnych stackach jeszcze nagranie wideo z rozmowy, dokument tożsamości do weryfikacji prawa do pracy oraz transkrypcje i oceny wygenerowane przez AI. To bogatszy profil niż ten, który trzyma większość CRM-ów, systemów rozliczeniowych czy wewnętrznych wiki.

Dwie strukturalne zmiany pogorszyły sytuację w ostatnich latach.

**Narzędzia rekrutacyjne oparte na AI domyślnie zbierają dane zbliżone do biometrycznych.** Rozmowy wideo, analiza głosu i dopasowywanie twarzy do dokumentu to dziś standardowe funkcje. Każda z nich zamienia krok rekrutacyjny w trwały zapis biometryczny.

**Bramki i proxy do AI koncentrują poświadczenia.** Narzędzia takie jak LiteLLM stoją przed API modeli i kumulują klucze API oraz poświadczenia chmurowe. Każda platforma, która je wdroży, dziedziczy ryzyko ich łańcucha dostaw — i to właśnie była droga do Mercor.

Złóż to razem, a dostaniesz system trzymający dane klasy „klejnoty koronne", rozszerzony przez funkcje AI, wystawiony przez zależności i niemal nigdy nieujęty w planie reagowania na incydenty. Atakujący zauważyli to wcześniej niż większość zespołów rekrutacyjnych.

## Dane, których nie da się zrotować

Powód, dla którego wyciek z rekrutacji jest gorszy niż typowy wyciek danych osobowych, jest prosty: identyfikatorów biometrycznych nie da się zresetować. Jak ujęła to jedna z analiz wycieku z Mercor: „nie ma przycisku »rotuj« dla Twojej twarzy" ([IQ Source](https://www.iqsource.ai/en/blog/mercor-breach-biometric-data-cant-rotate/)).

Skradzione hasło wystawia się na nowo w kilka sekund. Wyciekniętą kartę kredytową się anuluje i drukuje od nowa. Ale skradziony skan twarzy plus nagranie głosu są trwałe — i to dokładnie surowiec potrzebny do generowania przekonujących deepfake'ów. W przypadku Mercor oznacza to podszywanie się pod kontraktorów mających dostęp do laboratoriów AI — łańcuch konsekwencji, który przeżyje każdy e-mail o resecie hasła. Nagrania wideo z rozmów i transkrypcje głosu z AI należą do tej samej kategorii. Są zbliżone do biometrycznych, po wycieku są praktycznie nieodwracalne, a większość firm przechowuje je w ogóle bez polityki retencji czy kasowania.

To jest sedno argumentu za minimalizacją danych w rekrutacji. Dane, których nigdy nie zebrałeś, nie mogą wyciec. Dane, które skasowałeś według harmonogramu, nie mogą trafić do następnego zrzutu. Każde nagranie wideo, które trzymasz „na wszelki wypadek", to trwałe obciążenie leżące w czyimś kubełku S3.

## Prawny zasięg rażenia

Wyciek danych kandydatów to nie tylko incydent bezpieczeństwa — to zdarzenie regulacyjne i procesowe, a rachunki przychodzą szybko. W ciągu pierwszego tygodnia kwietnia 2026 roku przeciwko Mercor złożono co najmniej cztery pozwy zbiorowe, w większości w Sądzie Okręgowym USA dla Północnego Dystryktu Kalifornii, a późniejsze doniesienia podnosiły liczbę do pięciu–sześciu ([HR Dive](https://www.hrdive.com/news/ai-industry-recruiting-platform-faces-multiple-lawsuits-data-breach/817319/); [ComplianceHub](https://compliancehub.wiki/five-lawsuits-mercor-data-breach-litigation-breakdown/)). Jeden z pozwów proponuje ogólnokrajową grupę liczącą ponad 40 000 osób, z roszczeniami obejmującymi zaniedbanie, naruszenie dorozumianej umowy, naruszenie prywatności oraz kalifornijską ustawę o nieuczciwej konkurencji. Osobny pozew z Teksasu wskazuje podwykonawców niżej w łańcuchu, zamieniając problem trzeciej strony w problem strony czwartej.

Obowiązujące reżimy regulacyjne jeszcze podnoszą stawkę:

| Ramy prawne | Czego wymagają wobec danych rekrutacyjnych | Ryzyko |
|---|---|---|
| **RODO** | Podstawa prawna, informacja dla kandydata oraz określona polityka retencji/kasowania dla każdego nagrania rozmowy lub przechowywanych danych osobowych | Kary do 4% globalnego rocznego obrotu |
| **AI Act (UE)** | AI analizujące głos lub sygnały mimiczne w zatrudnieniu jest klasyfikowane jako wysokiego ryzyka, z surowymi wymogami dokumentacji i nadzoru | Wnioskowanie cech osobowości z analizy twarzy wkracza na obszar zakazany |
| **CCPA / CPRA** | Mieszkańcy Kalifornii mogą poznać, usunąć i sprzeciwić się sprzedaży swoich danych | Ryzyko ustawowych odszkodowań i pozwów zbiorowych |
| **Zasady zgody typu BIPA** | Informacja i zgoda przed oceną AI lub przetwarzaniem biometrycznym kandydatów | Ustawowe odszkodowania za każde naruszenie |

Źródła: [National Law Review](https://natlawreview.com/article/5-key-data-privacy-and-security-risks-arise-when-organizations-record-job-interviews); [evidenced.app](https://www.evidenced.app/blog/gdpr-requirements-for-video-interviews-hr-guide-2026).

Wzorzec we wszystkich tych przypadkach jest ten sam: regulatorzy nagradzają minimalizację, udokumentowaną retencję, zgodę i zdolność do usunięcia danych na żądanie. To nie są tylko punkty na liście zgodności. To dokładnie te same mechanizmy, które zmniejszają skutki wycieku.

## Jak chronić dane kandydatów w ATS: lista kontrolna

Żeby chronić dane kandydatów w ATS, zastosuj privacy-by-design: zbieraj minimum, szyfruj na poziomie kolumny, ustaw domyślną retencję kasującą dane według harmonogramu, loguj dostęp, prześwietl podwykonawców swojego dostawcy, realizuj żądania usunięcia danych i włącz ATS do planu reagowania na incydenty. Oto skrócona wersja, którą możesz przekazać dostawcy albo własnemu zespołowi:

1. **Minimalizuj zbieranie.** Nie gromadź numerów SSN, pełnych dokumentów tożsamości ani nagrań wideo, chyba że konkretny etap naprawdę tego wymaga. Najtańsze do ochrony są dane, których nigdy nie wziąłeś.
2. **Szyfruj dane osobowe na poziomie kolumny.** Wrażliwe pola powinny być szyfrowane w spoczynku w warstwie aplikacji, a nie zbywane machnięciem ręki w stylu „dysk jest zaszyfrowany".
3. **Ustaw domyślną retencję.** Każdy rekord kandydata, nagranie i transkrypcja potrzebują domyślnego zegara kasowania liczonego w miesiącach, a nie „na zawsze".
4. **Loguj dostęp.** To, kto i kiedy zaglądał do którego CV, powinno być zapisem nadającym się do audytu.
5. **Prześwietlaj dostawców i ich dostawców.** Zapytaj, jakie zależności i bramki AI stoją za Twoim ATS. Zasięg rażenia w Mercor przeszedł przez pakiet, którego większość zespołu nigdy bezpośrednio nie wybrała.
6. **Realizuj usunięcie na żądanie.** RODO i CCPA dają kandydatom prawo do bycia zapomnianym; Twój stack musi je wykonać czysto — w nagraniach, transkrypcjach i danych pochodnych.
7. **Wpisz ATS do planu reagowania na incydenty.** System trzymający numery SSN, paszporty i wideo biometryczne to zasób klasy „klejnoty koronne" i należy do zakresu, a nie do martwego pola.

<div class="blog-inline-cta">
  <p><strong>Audytujesz w tym kwartale swój stack rekrutacyjny?</strong> Kit szyfruje wrażliwe pola kandydatów na poziomie kolumny, dostarcza konfigurowalne domyślne ustawienia retencji i loguje dostęp do CV — minimalizacja i kasowanie są wbudowane, a nie doczepione na siłę.</p>
  <p><a href="/users/sign_up">Rozpocznij darmowy okres próbny</a></p>
</div>

## Twój ATS należy do planu reagowania na incydenty

Najczęstsza luka jest strukturalna: plany reagowania na incydenty obejmują infrastrukturę „produkcyjną" i po cichu wykluczają system rekrutacyjny, choć to właśnie ATS często trzyma najwrażliwsze dane w firmie. Nowoczesny zakres CSIRT wprost obejmuje systemy przechowujące najwrażliwsze dane oraz funkcje prawne i HR potrzebne do obsługi powiadomień o naruszeniu ([FIRST CSIRT Services Framework](https://www.first.org/standards/frameworks/csirts/FIRST_CSIRT_Services_Framework_v2.1.0_bugfix1.pdf)). ATS trzymający numery SSN, paszporty i wideo biometryczne to dokładnie taki system.

Traktowanie ATS jako powierzchni bezpieczeństwa oznacza trzy konkretne rzeczy. Po pierwsze, pojawia się on w Twoim inwentarzu zasobów i mapach przepływu danych z oznaczoną klasyfikacją danych. Po drugie, ryzyko jego dostawcy i podwykonawców jest przeglądane w tym samym rytmie co reszta łańcucha dostaw. Po trzecie, kiedy uderza incydent, osoby, które potrafią odpowiedzieć na pytanie „jakie dane kandydatów tam były i kogo musimy powiadomić", są już na liście reagowania, a nie miotają się w panice. Większość firm prowadzi rekrutację i bezpieczeństwo jako dwa odłączone od siebie światy. Pozwy przeciwko Mercor to właśnie to, co dzieje się, gdy szew między nimi okazuje się miejscem, w którym mieszkają dane.

## Jak podchodzi do tego Kit

Kit to połączona platforma rekrutacyjna i bezpieczeństwa, a porażki Mercor mapują się na mechanizmy, które Kit już wdraża — dlatego to argument o postawie, a nie o marketingu. Nic z tego nie czyni żadnego dostawcy odpornym na wyciek; ataki na łańcuch dostaw mogą dosięgnąć każdego, ale właściwe domyślne ustawienia zmniejszają zarówno zasięg rażenia, jak i ryzyko regulacyjne, gdy coś pójdzie nie tak.

- **Szyfrowanie danych osobowych kandydatów na poziomie kolumny.** Kit szyfruje najwrażliwsze pola kandydatów w spoczynku przy użyciu Active Record Encryption. E-mail jest szyfrowany deterministycznie, więc pozostaje przeszukiwalny na potrzeby deduplikacji, podczas gdy pola niewymagające wyszukiwania są szyfrowane niedeterministycznie. Lekcja „trzymaj dane osobowe zaszyfrowane, nie w postaci jawnej" — wcielona w życie.
- **Retencja jako ustawienie pierwszej klasy.** Zgoda kandydata niesie ze sobą konfigurowalne okno retencji z rozsądną wartością domyślną liczoną w miesiącach, a sama zgoda może być odnawiana, odrzucana i wygaszana, zamiast być przechowywana w nieskończoność. Dane, które kasujesz według harmonogramu, nie mogą trafić do następnego zrzutu.
- **Zdyscyplinowana obsługa wideo i transkrypcji.** Nagrania rozmów i transkrypcje AI są traktowane jak to, czym są — zasoby zbliżone do biometrycznych i objęte retencją, z logowanym dla potrzeb audit trail dostępem do CV kandydatów.
- **Izolacja wielonajemcza i uzasadniona kasacja danych.** Dane kandydatów są zawężone do konta, a soft-delete plus logowanie dostępu wspierają „prawo do usunięcia", którego wymagają RODO i CCPA.
- **Wbudowany pion CSIRT.** Ponieważ Kit dostarcza pełny moduł ujawniania podatności i reagowania na incydenty obok rekrutacji, ta sama dyscyplina reagowania, którą stosujesz wobec produkcji, może objąć ATS. Dwa światy, które Mercor trzymał osobno, są tu jedną powierzchnią.

O postawieniu strony reagowania pisaliśmy w tekście [jak uruchomić program ujawniania podatności](/blog/how-to-set-up-vulnerability-disclosure-program), a o presji zgodności, która spada teraz na małe zespoły, w [terminie ujawniania z unijnego Cyber Resilience Act](/blog/eu-cyber-resilience-act-mandatory-vulnerability-disclosure). Ten artykuł to warstwa danych kandydatów leżąca pod jednym i drugim.

## FAQ

### Czy mój system ATS to ryzyko wycieku danych?

Tak — domyślnie jest to jeden z Twoich systemów najwyższego ryzyka, bo koncentruje regulowane dane osobowe (imiona i nazwiska, adresy, numery SSN, dokumenty tożsamości, dane płacowe), a coraz częściej także dane biometryczne z rozmów wideo, jednocześnie rzadko trafiając do programów bezpieczeństwa. Ryzyko da się ograniczyć: minimalizuj to, co zbierasz, szyfruj to, ustaw limity retencji i włącz ATS do zakresu reagowania na incydenty. Wyciek z Mercor pokazał, że dane tam są — niezależnie od tego, czy je chronisz, czy nie.

### Które dane kandydatów są najgroźniejsze w razie wycieku?

Dane biometryczne i tożsamościowe: skany twarzy, nagrania głosu, rozmowy wideo i zdjęcia dokumentów tożsamości. W odróżnieniu od hasła czy karty kredytowej nie da się ich zrotować ani wystawić na nowo, a są surowcem do deepfake'ów i kradzieży tożsamości. Numery SSN także są dotkliwie groźne. Najbezpieczniejsza postawa to w ogóle nie zbierać tych danych, chyba że konkretny etap tego wymaga, a gdy już je zbierzesz — kasować je według stałego harmonogramu.

### Jak długo ATS powinien przechowywać dane kandydatów?

Wystarczająco długo, by spełnić cel rekrutacyjny i obowiązki prawne, a potem je skasować. Pod RODO potrzebujesz określonego, udokumentowanego okresu retencji zamiast przechowywania w nieskończoność, a wiele zespołów przyjmuje domyślnie około dwóch lat dla niewybranych kandydatów, z jasnym zegarem kasowania. Rozmowy wideo i transkrypcje zasługują na najwęższe okno, bo to dane, których przechowywanie najtrudniej obronić. Retencja powinna być skonfigurowaną wartością domyślną, a nie ręcznym sprzątaniem, którego nikt nie robi.

## Podsumowanie

Wyciek z Mercor to podręcznikowy przypadek tego, jak ATS staje się wyciekiem: 4 TB za drzwiami przez jedną zależność, w tym jedyna kategoria danych — Twoja twarz i głos — której nikt nigdy nie zresetuje. Możliwą do obrony odpowiedzią nie jest kupienie dostawcy obiecującego bezpieczeństwo. Jest nią privacy-by-design jako postawa, którą możesz zweryfikować: zbieraj mniej, szyfruj na poziomie kolumny, ustaw domyślną retencję kasującą według harmonogramu, loguj dostęp, prześwietlaj dostawców swoich dostawców i wciągnij system rekrutacyjny do planu reagowania na incydenty — tam, gdzie zawsze powinien był być.

Jeśli audytujesz swój stack rekrutacyjny i chcesz mieć minimalizację, szyfrowanie, retencję i dyscyplinę reagowania na incydenty wbudowane od samego początku, [rozpocznij darmowy okres próbny Kit](/users/sign_up) i skonfiguruj proces rekrutacyjny w duchu privacy-by-design jeszcze dziś.