Kiedy Twój ATS staje się wyciekiem: jak chronić dane osobowe kandydatów

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. 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; SecurityWeek). 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). 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).

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; ComplianceHub). 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ę:

Źródła: National Law Review; evidenced.app.

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.

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). 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, a o presji zgodności, która spada teraz na małe zespoły, w terminie ujawniania z unijnego Cyber Resilience Act. 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 i skonfiguruj proces rekrutacyjny w duchu privacy-by-design jeszcze dziś.