← Wszystkie artykuły

RODO a AI w firmie: ocena skutków i decyzje automatyczne

RODO a AI w firmie: ocena skutków i decyzje automatyczne

RODO a AI w firmie: ocena skutków i decyzje automatyczne

Błąd, który przy wdrożeniach AI zauważyłem u siebie najpóźniej, nie dotyczył wyboru modelu ani budżetu. Przez dobre półtora roku uznawałem obecność człowieka w procesie za załatwioną, bo w panelu był przycisk „zatwierdź”. Kierownik klikał, więc formalnie decyzję podejmował człowiek, więc temat zamknięty. Nie był zamknięty, a przepis, który to rozstrzyga, ma osiem lat i numer 22.

Ten tekst jest o RODO przy wdrożeniach AI: kiedy trzeba zrobić ocenę skutków dla ochrony danych, zanim cokolwiek ruszy, co znaczy „decyzja podejmowana wyłącznie automatycznie”, i jakie warunki trzeba spełnić, wprowadzając dane pracowników i klientów do cudzego narzędzia. Piszę go jako piąty odcinek serii o wymaganiach prawnych przy AI; mapa wszystkich aktów jest w artykule otwierającym.

To autorska analiza praktyka wdrożeń AI, który nie jest prawnikiem. Materiał ogólny, nie rozstrzyga zgodności konkretnego wdrożenia. Stan przepisów na 15 września 2026 r. Przed wdrożeniem skonsultuj proces z prawnikiem lub inspektorem ochrony danych.

Spis treści

  1. 1. Dlaczego RODO trzeba uwzględnić już przed pilotażem
  2. 2. Kiedy AI w firmie przetwarza dane osobowe
  3. 3. Podstawa przetwarzania: uzasadniony interes, zgoda, dane wrażliwe
  4. 4. Decyzja podjęta wyłącznie przez algorytm
  5. 5. Ocena skutków dla ochrony danych: kiedy jest obowiązkowa
  6. 6. DPIA dla pilotażu narzędzia AI: co realnie trzeba opisać
  7. 7. Dane pracowników i kandydatów oraz wystąpienie UODO
  8. 8. Powierzenie i transfer: narzędzie AI jako podmiot przetwarzający
  9. 9. Obowiązek informacyjny wobec ludzi, których to dotyczy
  10. 10. Prawa osób a modele AI: opinia EROD 28/2024
  11. 11. Kto to egzekwuje w Polsce
  12. 12. Ścieżka przed pilotażem AI na danych osobowych
  13. 13. Jeden przypadek zamiast listy błędów
  14. 14. Najczęstsze pytania
  15. 15. Źródła

Dlaczego RODO trzeba uwzględnić już przed pilotażem

W rozmowach o zgodności AI firmy pytają najpierw o AI Act, bo to on jest w nagłówkach. Tymczasem przy projekcie, który dotyka ludzi, pierwsze pytania najczęściej stawia co innego: rozporządzenie ogólne o ochronie danych, czyli RODO. Powodów jest kilka i wszystkie są praktyczne.

RODO jest stosowane od 25 maja 2018 r., więc nie ma tu żadnego okresu przygotowawczego, na który dałoby się poczekać. Obowiązki AI Act dotyczące systemów wysokiego ryzyka w zatrudnieniu, czyli rekrutacji, oceny i monitorowania pracy, zaczną być stosowane 2 grudnia 2027 r. po lipcowej zmianie kalendarza. To odroczenie nie dotyka RODO ani o dzień. Narzędzie, które firma uruchamia w październiku 2026 r., podlega RODO od pierwszego rekordu, niezależnie od tego, co AI Act zacznie wymagać za rok z okładem. Kalendarz AI Act rozłożyłem osobno w tekście o samym rozporządzeniu.

Drugi powód to organ i praktyka. Prezes Urzędu Ochrony Danych Osobowych ma wieloletnią praktykę decyzyjną i kontrolną i nie musi czekać na nową ustawę, żeby zająć się AI. Trzeci powód dotyczy skali sankcji. Artykuł 83 RODO przewiduje dwa pułapy administracyjnych kar pieniężnych: do 10 mln euro albo do 2 % całkowitego rocznego światowego obrotu przedsiębiorstwa za naruszenie obowiązków administratora z art. 25–39, w tym obowiązku oceny skutków, oraz do 20 mln euro albo do 4 % za naruszenie podstawowych zasad przetwarzania z art. 5, 6, 7 i 9, praw osób z art. 12–22 oraz przepisów o przekazywaniu danych poza EOG. W obu przypadkach stosuje się kwotę wyższą z tych dwóch. To są ustawowe maksima, nie stawki, a wysokość konkretnej kary zależy od rodzaju naruszenia i okoliczności sprawy, wyliczonych w art. 83 ust. 2.

Jest jeszcze czwarty powód, najmniej widoczny, a moim zdaniem najważniejszy. RODO wymaga myślenia o procesie przed jego uruchomieniem, a firmy planują wdrożenia AI odwrotnie: najpierw pilotaż na prawdziwych danych, potem, jeśli wyszło dobrze, formalności. Przy większości technologii ta kolejność niewiele zmienia. Tutaj wpływa na harmonogram, bo sam pilotaż na danych pracowników jest już przetwarzaniem i podlega tym samym regułom co wdrożenie docelowe.

Kiedy AI w firmie przetwarza dane osobowe

Pierwsze pytanie brzmi prościej, niż się wydaje: czy w ogóle jesteśmy w RODO. Odpowiedź jest twierdząca zaskakująco często, bo dane osobowe to każda informacja o możliwej do zidentyfikowania osobie fizycznej. Imię, nazwisko i PESEL to tylko najbardziej oczywisty przypadek. Nagranie głosu jest informacją o osobie. Transkrypcja spotkania, w której padają imiona i stanowiska, też. Rekord w CRM z historią kontaktu z konkretnym człowiekiem po stronie klienta również.

Weźmy cztery narzędzia, o które pytają mnie najczęściej, i zobaczmy, gdzie w każdym z nich siedzi przetwarzanie.

Transkrypcja i streszczanie spotkań. Do narzędzia trafia nagranie albo zapis rozmowy, w którym rozpoznawalni są uczestnicy. Przetwarzane są dane pracowników i zwykle także osób po drugiej stronie, czyli klientów albo kandydatów. Jeśli narzędzie dopisuje ocenę zaangażowania czy aktywności poszczególnych osób, dokłada do zbioru nową kategorię danych, której wcześniej nie było: własną ocenę człowieka.

Wstępne przeglądanie CV. Dane kandydatów, często z załącznikami, w których bywa znacznie więcej niż katalog danych, jakich pracodawca może żądać. Zdjęcie, data urodzenia, informacje o rodzinie, czasem dane wskazujące na stan zdrowia. Model widzi cały dokument, nie tylko te pola, które zamierzaliśmy mu pokazać.

Chatbot obsługi klienta. Treść rozmowy, adres e-mail, numer zamówienia, czasem dane wrażliwe, jeśli klient sam je poda w opisie problemu. Do tego dochodzą logi, które żyją dłużej, niż ktokolwiek zakłada przy uruchomieniu.

Scoring leadów i klientów. RODO obejmuje go w takim zakresie, w jakim przetwarzane informacje dotyczą zidentyfikowanych lub możliwych do zidentyfikowania osób fizycznych. Ocena spółki sama w sobie tu nie wchodzi; wchodzą dane osób kontaktowych, historia rozmów z konkretnymi ludźmi i wyniki oceny przypisane do nich, bo od nich zależy, jak firma się wobec tych osób zachowa.

Zasady z art. 5 RODO obowiązują w każdym z tych czterech przypadków i w praktyce sprowadzają się do kilku pytań, które warto zadać, zanim narzędzie zobaczy pierwszy prawdziwy rekord.

Zacznijmy od celu. Dane mają być zbierane „w konkretnych, wyraźnych i prawnie uzasadnionych celach”, a „poprawa efektywności” nie jest celem w tym rozumieniu, tylko hasłem z prezentacji. Cel opisany jako „skrócenie czasu obsługi zgłoszenia przez podpowiadanie odpowiedzi konsultantowi” już nim jest, bo da się przy nim sprawdzić, czy dane, które wchodzą do narzędzia, są do tego potrzebne.

Idzie za tym pytanie o zakres. Zasada minimalizacji wymaga danych „adekwatnych, stosownych oraz ograniczonych do tego, co niezbędne”. Praktyczny test, który stosuję: czy potrafię wskazać pole, które narzędzie dostaje, a którego nie użyje do zadania z poprzedniego akapitu. Jeśli tak, to pole nie powinno tam trafić. W pilotażach eksport z systemu bywa robiony metodą „weźmy wszystko, model sobie wybierze”, a to jest dokładnie ten błąd.

Ograniczenie przechowywania mówi, że dane mają być trzymane nie dłużej, niż to niezbędne. Przy narzędziach AI pytanie trzeba zadać dwa razy: raz o dane w systemie firmy, drugi raz o dane u dostawcy narzędzia, bo to dwa różne miejsca z dwoma różnymi ustawieniami.

Na końcu stoi pytanie o dowód. Artykuł 5 ust. 2 wprowadza rozliczalność: administrator jest odpowiedzialny za przestrzeganie zasad i „musi być w stanie wykazać ich przestrzeganie”. To zdanie zmienia charakter całej reszty tego tekstu, bo poprawne działanie trzeba jeszcze umieć pokazać, a pokazuje się je dokumentem, nie wspomnieniem.

Techniczną stronę tego, jak zbudować wdrożenie tak, żeby dane nie wyciekały do modelu i żeby minimalizacja nie była deklaracją, opisałem wcześniej w tekście o wdrażaniu AI zgodnie z RODO: architektura z osobną bazą wiedzy, separacja danych od modelu, wybór między chmurą publiczną, prywatną i instalacją na własnym sprzęcie. Tutaj zajmuję się warstwą wyżej, czyli decyzjami i dokumentami, które muszą powstać, zanim ta architektura zacznie przetwarzać czyjekolwiek dane.

Podstawa przetwarzania: uzasadniony interes, zgoda, dane wrażliwe

Przetwarzanie jest zgodne z prawem tylko wtedy, gdy spełniony jest co najmniej jeden z warunków z art. 6 ust. 1. Przy wdrożeniach AI najczęściej rozważa się podstawy opisane niżej, ale właściwą ustala się dla konkretnej operacji, nie dla narzędzia jako całości ani dla technologii.

Wykonanie umowy, gdy przetwarzanie jest niezbędne do wykonania umowy, której stroną jest osoba, której dane dotyczą. Przy obsłudze klienta bywa to podstawa rozważana jako pierwsza, ale niezbędność ocenia się wobec konkretnej operacji, nie wobec całego procesu. Przy reklamacji podstawa zależy od rodzaju obowiązku: część czynności wynika z umowy, część z przepisów o rękojmi i o prawach konsumenta, więc kwalifikacja bywa różna dla różnych kroków tego samego procesu. Analiza emocji klienta w tej rozmowie to już osobna operacja z własną podstawą i własnymi ograniczeniami.

Obowiązek prawny, gdy przepis nakazuje coś przetwarzać. Przy AI zdarza się rzadko i zwykle dotyczy warstwy pod spodem, na przykład dokumentacji pracowniczej.

Prawnie uzasadniony interes administratora albo strony trzeciej, „z wyjątkiem sytuacji, w których nadrzędny charakter wobec tych interesów mają interesy lub podstawowe prawa i wolności osoby, której dane dotyczą”. To najczęstsza podstawa przy narzędziach AI i jednocześnie ta, przy której najłatwiej o skrót myślowy. Powołanie się na uzasadniony interes nie jest oświadczeniem, tylko wynikiem oceny, którą trzeba przeprowadzić i zapisać. Europejska Rada Ochrony Danych opisuje ją jako test trójstopniowy: najpierw nazwanie interesu, który musi być zgodny z prawem, jasno sformułowany oraz rzeczywisty i aktualny, a nie spekulacyjny; potem sprawdzenie, czy przetwarzanie pozwoli ten interes zrealizować i czy nie ma mniej ingerującego sposobu; na końcu porównanie interesu firmy z interesami i prawami osób, których dane dotyczą.

Trzeci etap jest tym, który w firmowych dokumentach zwykle wypada najsłabiej, bo wymaga przyznania, że druga strona ma coś do stracenia. W teście równowagi liczą się między innymi rozsądne oczekiwania tych osób: czy człowiek, podając dane w danym kontekście, mógł się spodziewać, że trafią do takiego zastosowania. Kandydat wysyłający CV spodziewa się, że ktoś je przeczyta. Czy spodziewa się, że model oceni go w skali punktowej i że ta ocena zostanie w bazie na dwa lata, to już zupełnie inne pytanie.

Zgoda jest czwartą możliwością i akurat w zatrudnieniu bywa pułapką. RODO wymaga, żeby zgoda była dobrowolna, a przy ocenie dobrowolności uwzględnia się między innymi zależność między stronami. W relacji pracodawca–pracownik trudno wykazać, że zgoda była swobodna, skoro jedna strona decyduje o wynagrodzeniu i dalszym zatrudnieniu drugiej. Do tego zgodę można wycofać w dowolnym momencie „równie łatwo jak jej wyrażenie”, co dla systemu obejmującego cały zespół oznacza, że proces musi działać także wtedy, gdy trzy osoby na dziesięć się wypiszą. Podpisana zgoda na nagrywanie nie zastępuje też wymogów Kodeksu pracy dotyczących monitoringu, o czym piszę w tekście o monitoringu pracowników.

Osobno trzeba potraktować dane szczególnych kategorii z art. 9 ust. 1: te ujawniające pochodzenie rasowe lub etniczne, poglądy polityczne, przekonania religijne lub światopoglądowe, przynależność do związków zawodowych, a także dane genetyczne, dane biometryczne przetwarzane w celu jednoznacznego zidentyfikowania osoby oraz dane dotyczące zdrowia, seksualności lub orientacji seksualnej. Ich przetwarzanie jest co do zasady zakazane i wymaga osobnej przesłanki z art. 9 ust. 2, na przykład wyraźna zgoda albo niezbędność do wykonania obowiązków w dziedzinie prawa pracy dozwolona przepisami.

Dane biometryczne są w tym katalogu wtedy, gdy są przetwarzane w celu jednoznacznego zidentyfikowania osoby, więc sam fakt, że narzędzie dotyka głosu albo twarzy, nie przesądza o zastosowaniu art. 9; przesądza cel i sposób przetwarzania, ustalone dla konkretnego systemu. Osobna sprawa jest mniej oczywista: dane wrażliwe potrafią wejść do narzędzia bez niczyjej decyzji. Klient opisuje w czacie swoją chorobę, żeby uzasadnić zwrot towaru. Kandydat wpisuje w CV orzeczenie o niepełnosprawności. Handlowiec wspomina w rozmowie, że klient jest po operacji. Żadnego z tych zdarzeń nie da się przewidzieć w harmonogramie wdrożenia, a każde z nich zmienia obraz przetwarzania.

Przy funkcjach, które mają mierzyć nastrój, zaangażowanie albo „poziom energii” pracownika, obok RODO stoi jeszcze jeden przepis, i jest to zakaz, nie wymóg do spełnienia. Artykuł 5 ust. 1 lit. f AI Act zakazuje od 2 lutego 2025 r. wykorzystywania systemów do wyciągania wniosków o emocjach osoby fizycznej w miejscu pracy i w instytucjach edukacyjnych, z wyjątkiem systemów wdrażanych ze względów medycznych lub bezpieczeństwa. Definicja z art. 3 pkt 39 wiąże ten zakaz z wnioskowaniem na podstawie danych biometrycznych, więc kwalifikacja zależy od tego, z czego liczony jest wskaźnik: barwa i tempo głosu prowadzą w stronę zakazu, sam zapis tekstowy rozmowy niekoniecznie, a i tak zostaje wtedy ocena na gruncie RODO i prawa pracy. Zakazy i pozostałe obowiązki AI Act rozłożyłem w tekście o samym rozporządzeniu.

Decyzja podjęta wyłącznie przez algorytm

Artykuł 22 ust. 1 RODO daje człowiekowi prawo do tego, by nie podlegać decyzji, która „opiera się wyłącznie na zautomatyzowanym przetwarzaniu, w tym profilowaniu, i wywołuje wobec tej osoby skutki prawne lub w podobny sposób istotnie na nią wpływa”. Każdy człon tej definicji trzeba czytać osobno, bo każdy potrafi samodzielnie wyprowadzić proces poza zakres przepisu albo go w nim utrzymać.

„Wyłącznie” nie znaczy „bez udziału jakiegokolwiek człowieka w okolicy”. Znaczy, że w procesie nie ma realnej ludzkiej oceny. Kierownik zatwierdzający ranking, którego nie potrafi zakwestionować, bo nie ma dostępu do danych źródłowych, nie zna kryteriów oceny, dostaje dwieście pozycji tygodniowo i nie ma czasu ani mandatu, żeby zmienić wynik, jest elementem interfejsu, a nie ogniwem decyzyjnym. Nadzór człowieka jest funkcją procesu i da się go sprawdzić pytaniami: ile razy w ostatnim kwartale człowiek zmienił wynik zaproponowany przez system, co się wtedy stało, i czy ktokolwiek to odnotował. Jeśli odpowiedź brzmi „nigdy”, warto potraktować to jako sygnał. Bezbłędność modelu jest wtedy najmniej prawdopodobnym z wyjaśnień.

„Skutki prawne lub w podobny sposób istotnie wpływające” wymagają oceny konkretnej decyzji, nie kategorii narzędzia. Odrzucenie kandydatury, ustalenie wysokości premii, rozwiązanie umowy czy zablokowanie konta klienta mogą wywoływać takie skutki. Podpowiedź dla konsultanta, którą może zignorować, zwykle nie. Między tymi biegunami jest szeroki pas przypadków granicznych: ranking handlowców, który formalnie jest informacją, a realnie decyduje o przydziale leadów; automatyczna kwalifikacja zgłoszenia do wolniejszej ścieżki obsługi; scoring klienta wpływający na warunki płatności. Każdy z nich wymaga własnej oceny i żadnego nie rozstrzygnę z góry w artykule.

Zostają wyjątki z ust. 2. Zakaz z ust. 1 nie ma zastosowania, gdy decyzja jest niezbędna do zawarcia lub wykonania umowy, gdy jest dozwolona prawem Unii lub prawem krajowym przewidującym właściwe środki ochrony, albo gdy opiera się na wyraźnej zgodzie. Tu jest haczyk, który umyka najczęściej: w dwóch z tych trzech przypadków, czyli przy umowie i przy wyraźnej zgodzie, administrator i tak wdraża właściwe środki ochrony, „a co najmniej prawa do uzyskania interwencji ludzkiej ze strony administratora, do wyrażenia własnego stanowiska i do zakwestionowania tej decyzji”. Czyli skorzystanie z wyjątku nie zwalnia z zapewnienia człowieka po drugiej stronie, tylko przenosi go z etapu decyzji na etap odwołania. W praktyce oznacza to kanał, którym można się odwołać, osobę, która to rozpatrzy, i termin.

Ustęp 4 dokłada ograniczenie, o którym warto pamiętać przy rekrutacji: decyzje z ust. 2 co do zasady nie mogą opierać się na szczególnych kategoriach danych z art. 9 ust. 1, chyba że zastosowanie ma art. 9 ust. 2 lit. a) albo g) i istnieją właściwe środki ochrony.

Zanim ktoś uzna, że przy jego narzędziu ten przepis nie wchodzi w grę, bo „przecież decyduje człowiek”, warto zrobić wstępne ćwiczenie. Bierzemy dziesięć ostatnich decyzji podjętych z udziałem systemu i przy każdej sprawdzamy trzy rzeczy: czy człowiek miał dostęp do danych, na których oparł się model; ile czasu upłynęło między pokazaniem wyniku a zatwierdzeniem; czy istnieje zapis, że ktoś rozważał inny wynik. To ćwiczenie pokazuje sygnały pozornego nadzoru i nie zastępuje kwalifikacji procesu na gruncie art. 22. U siebie zrobiłem je o półtora roku za późno.

Ocena skutków dla ochrony danych: kiedy jest obowiązkowa

Ocena skutków dla ochrony danych, w skrócie DPIA od angielskiego data protection impact assessment, to dokument i proces opisany w art. 35 RODO. Zasada ogólna z ust. 1 brzmi tak: jeżeli dany rodzaj przetwarzania, „w szczególności z użyciem nowych technologii”, ze względu na swój charakter, zakres, kontekst i cele z dużym prawdopodobieństwem może powodować wysokie ryzyko naruszenia praw lub wolności osób fizycznych, administrator przed rozpoczęciem przetwarzania dokonuje oceny skutków planowanych operacji.

Zwrot „w szczególności z użyciem nowych technologii” jest w tekście przepisu od 2016 r. i to nie jest przypadek. Ustęp 3 wymienia trzy przypadki, w których ocena jest wymagana w szczególności, a pierwszy z nich został napisany tak, jakby ktoś przewidział dzisiejsze wdrożenia: „systematycznej, kompleksowej oceny czynników osobowych odnoszących się do osób fizycznych, która opiera się na zautomatyzowanym przetwarzaniu, w tym profilowaniu, i jest podstawą decyzji wywołujących skutki prawne wobec osoby fizycznej lub w podobny sposób znacząco wpływających na osobę fizyczną”. Dwa pozostałe to przetwarzanie na dużą skalę szczególnych kategorii danych oraz systematyczne monitorowanie na dużą skalę miejsc dostępnych publicznie.

Do tego dochodzi wykaz krajowy. Artykuł 35 ust. 4 nakazuje organowi nadzorczemu ustanowić i podać do publicznej wiadomości wykaz rodzajów operacji podlegających obowiązkowi DPIA. Prezes UODO zrobił to komunikatem z 17 czerwca 2019 r., ogłoszonym w Monitorze Polskim z 8 lipca 2019 r. pod pozycją 666 (link do skanu z Monitora w źródłach na końcu). Załącznik do komunikatu wymienia dwanaście kryteriów i jedną regułę, którą warto zapamiętać dosłownie: „Co do zasady, przetwarzanie spełniające przynajmniej dwa z niżej wymienionych kryteriów będzie wymagać oceny skutków dla ochrony danych”. Zdanie dalej pada zastrzeżenie, że w niektórych przypadkach administrator może uznać, iż wystarczy jedno kryterium. To reguła pomocnicza organu, nie próg ustawowy. Obowiązek z art. 35 ust. 1 wynika z wysokiego ryzyka i trzeba go ocenić niezależnie od tego, ile pozycji z wykazu uda się policzyć.

Kryteria warto przejść pod kątem typowego wdrożenia AI, bo kilka z nich dotyka go bez żadnej egzotyki po stronie firmy.

Kryterium pierwsze to „ewaluacja lub ocena, w tym profilowanie i przewidywanie (analiza behawioralna) w celach wywołujących negatywne skutki prawne, fizyczne, finansowe lub inne niedogodności dla osób fizycznych”. Narzędzie oceniające rozmowy handlowców albo filtrujące CV mieści się tu wprost. W kolumnie przykładów wykaz wymienia zresztą ocenę zdolności kredytowej „przy użyciu algorytmów sztucznej inteligencji”, więc to nie jest interpretacja naciągana pod dzisiejsze technologie.

Kryterium drugie to „zautomatyzowane podejmowanie decyzji wywołujących skutki prawne, finansowe lub podobne istotne skutki”. Wynik systemu przekładający się na premię, kolejność obsługi albo warunki oferty może spełniać to kryterium, ale rozstrzyga sposób podejmowania decyzji i waga jej skutków, nie sama obecność wyniku w procesie.

Kryterium trzecie dotyczy systematycznego monitorowania na dużą skalę miejsc dostępnych publicznie, ale w kolumnie obszarów zastosowań wykaz wymienia „zakłady pracy (monitoring systemów informatycznych poczty elektronicznej, używanego oprogramowania, kart dostępowych itp.)”, a w kolumnie przykładów „systemy monitorowania czasu pracy pracowników oraz przepływu informacji w wykorzystywanych przez nich narzędziach” z adnotacją o systematycznym monitorowaniu i wrażliwych podmiotach danych.

Kryterium czwarte to przetwarzanie szczególnych kategorii danych. Wraca tu wątek z poprzedniej sekcji: dane wrażliwe wchodzą do narzędzi AI bocznymi drzwiami.

Kryterium ósme to „przeprowadzanie porównań, ocena lub wnioskowanie na podstawie analizy danych pozyskanych z różnych źródeł”. Wdrożenie łączące CRM z pocztą, kalendarzem i nagraniami może je spełniać, choć wymaga to oceny konkretnego zakresu, celu i skali; sama integracja jest dziś normą i o niczym jeszcze nie przesądza.

Kryterium dziewiąte opisuje „przetwarzanie danych dotyczących osób, których ocena i świadczone im usługi są uzależnione od podmiotów lub osób, które dysponują uprawnieniami nadzorczymi i/lub ocennymi”, a w przykładach pojawiają się serwisy dopasowujące oferty pracy do preferencji pracodawców oraz systemy zgłaszania nieprawidłowości przetwarzające dane pracowników.

Kryterium dziesiąte to „innowacyjne wykorzystanie lub zastosowanie rozwiązań technologicznych lub organizacyjnych”. Użycie dużego modelu językowego bywa tu wskazywane, ale samo w sobie nie zastępuje analizy: liczy się, co konkretnie system robi z danymi i jakie ryzyko z tego wynika.

Zobaczmy to na przykładzie, który znam najlepiej: narzędzie analizujące nagrania rozmów handlowców i wystawiające im ocenę braną pod uwagę przy premii. Operacje są tu trzy i każda niesie własne ryzyko. Nagrywanie i transkrypcja rozmowy to stałe zbieranie danych o pracy konkretnych osób. Ocena punktowa to ewaluacja osoby o skutku finansowym, a jeśli przekłada się na premię bez realnej weryfikacji, dochodzi do tego automatyzm decyzji. Ranking zespołu porównuje ludzi między sobą i wzmacnia skutki błędnej oceny. Do tego dane zwykle pochodzą z kilku systemów naraz. Przesłanki silnie przemawiają więc za obowiązkiem oceny skutków, ale uzasadnienie musi odnosić się do tych konkretnych operacji i do ryzyka, jakie z nich wynika. Liczba odhaczonych pozycji wykazu go nie zastąpi. Sam wykaz wprost zastrzega, że nie jest wyczerpujący i nie zwalnia administratora z własnej oceny na podstawie art. 35 ust. 1.

Słowo „przed” w art. 35 ust. 1 dotyczy rozpoczęcia przetwarzania, a nie podjęcia decyzji o zakupie. Miesięczny pilotaż na jednym zespole, prowadzony na prawdziwych nagraniach prawdziwych ludzi, jest przetwarzaniem danych osobowych. Jeśli planowane przetwarzanie wymaga DPIA, ocena ma powstać przed pilotażem, nie po nim. Ten jeden wniosek zmienia harmonogram większości projektów, które widuję.

DPIA dla pilotażu narzędzia AI: co realnie trzeba opisać

Reputacja DPIA jest gorsza, niż na to zasługuje, bo kojarzy się z grubym dokumentem kupowanym na zewnątrz. Artykuł 35 ust. 7 wymienia natomiast cztery elementy, które ocena zawiera co najmniej, i to jest minimum jej treści. Nie wyczerpuje to obowiązków proceduralnych: dochodzą konsultacja z inspektorem (ust. 2), zasięgnięcie opinii osób, których dane dotyczą, w stosownych przypadkach (ust. 9), przegląd przy zmianie ryzyka (ust. 11) oraz uprzednie konsultacje z organem z art. 36.

Po pierwsze, systematyczny opis planowanych operacji przetwarzania i celów, w tym, gdy ma to zastosowanie, prawnie uzasadnionych interesów realizowanych przez administratora. Po drugie, ocenę, czy operacje są niezbędne oraz proporcjonalne w stosunku do celów. Po trzecie, ocenę ryzyka naruszenia praw lub wolności osób. Po czwarte, środki planowane w celu zaradzenia ryzyku, w tym zabezpieczenia oraz mechanizmy mające zapewnić ochronę danych i wykazać przestrzeganie rozporządzenia.

W praktyce przy narzędziu AI najwięcej pracy jest w pierwszym punkcie i to dobra wiadomość, bo tę pracę i tak trzeba wykonać, żeby wdrożenie w ogóle działało. Opis operacji wymaga rozpisania narzędzia na pojedyncze funkcje, zamiast traktowania go jako jednego bytu o nazwie handlowej. Transkrypcja to jedna operacja. Streszczenie to druga. Podpowiedź w trakcie rozmowy trzecia. Ocena punktowa czwarta. Ranking piąty. Przy każdej trzeba odpowiedzieć, jakie dane wchodzą, kto widzi wynik i jaka decyzja od niego zależy. W projektach, które prowadziłem, to ćwiczenie zwykle pokazywało, że firmie potrzebne są dwie albo trzy pierwsze funkcje, a cała trudność prawna siedzi w dwóch ostatnich, których nikt świadomie nie zamawiał.

Ocena niezbędności i proporcjonalności jest miejscem na uczciwą odpowiedź, czy da się osiągnąć ten sam cel mniej ingerującym sposobem. Czasem da się: analiza na transkrypcji zamiast na nagraniu, dane zagregowane zamiast indywidualnych, ocena zespołu zamiast oceny osoby, próbka rozmów zamiast wszystkich. Jeśli mniej ingerujący wariant realizuje cel, trudno uzasadnić wybór bardziej ingerującego.

Ocena ryzyka dotyczy ryzyka dla ludzi, nie dla firmy, i to jest rozróżnienie, na którym wykłada się większość pierwszych podejść. Ryzykiem dla firmy jest kara. Ryzykiem dla pracownika jest niesłuszna ocena wpływająca na wynagrodzenie, ryzykiem dla kandydata odrzucenie na podstawie cechy, która nie ma związku z pracą, ryzykiem dla klienta gorsza obsługa wynikająca z błędnej klasyfikacji. Modele przenoszą uprzedzenia obecne w danych treningowych, więc ryzyko nierównego traktowania nie jest teoretyczne i trzeba je w tym dokumencie nazwać.

Środki zaradcze to lista rzeczy, które firma faktycznie zrobi. Ograniczenie zakresu danych, pseudonimizacja tam, gdzie jest możliwa, określony czas przechowywania z mechanizmem usuwania, kontrola dostępu do wyników, ścieżka odwoławcza dla ocenianych, okresowy przegląd trafności modelu, zapis przypadków, w których człowiek zmienił wynik. Każdy z nich ma mieć właściciela i termin, bo środek bez właściciela jest deklaracją.

Kto to robi i ile trwa. Nie podam liczby godzin, bo zależy od liczby funkcji narzędzia i od tego, czy firma ma opisane procesy. Podam za to skład, który sprawdza się u mnie: osoba odpowiedzialna za proces biznesowy, ktoś z IT albo ze strony wdrożeniowej, kto zna przepływ danych, oraz inspektor ochrony danych, jeśli firma go wyznaczyła. Artykuł 35 ust. 2 wprost nakazuje konsultację z inspektorem, jeżeli został wyznaczony. Warto też znać art. 35 ust. 9: w stosownych przypadkach administrator zasięga opinii osób, których dane dotyczą, lub ich przedstawicieli. To nie jest powszechny obowiązek konsultowania każdego wdrożenia, a ocena „stosownego przypadku” należy do administratora. Przy projektach dotyczących pracowników rozmowa z ich przedstawicielami bywa mimo to najlepszą rzeczą, jaką da się zrobić dla powodzenia całego przedsięwzięcia.

Kiedy trzeba mieć inspektora ochrony danych. Artykuł 37 ust. 1 wymaga wyznaczenia go między innymi wtedy, gdy główna działalność administratora polega na operacjach przetwarzania, które ze względu na charakter, zakres lub cele wymagają regularnego i systematycznego monitorowania osób na dużą skalę, a także gdy główna działalność polega na przetwarzaniu na dużą skalę szczególnych kategorii danych. Typowa firma produkcyjna albo usługowa, która używa AI wewnętrznie, nie spełnia tych przesłanek samym wdrożeniem narzędzia, bo to nie jest jej główna działalność. Ocena należy jednak do konkretnego przypadku i nie warto jej rozstrzygać hasłem.

Bywa i tak, że po ocenie ryzyko nadal jest wysokie. Artykuł 36 ust. 1 mówi wtedy jasno: jeżeli ocena wskaże, że przetwarzanie powodowałoby wysokie ryzyko, gdyby administrator nie zastosował środków w celu jego zminimalizowania, to przed rozpoczęciem przetwarzania administrator konsultuje się z organem nadzorczym. Czyli konsultacja dotyczy ryzyka, którego nie udało się dostatecznie ograniczyć planowanymi środkami. Każda ocena zakończona wynikiem „ryzyko istnieje” jeszcze jej nie uruchamia. Organ ma osiem tygodni na pisemne zalecenie, z możliwością przedłużenia o sześć tygodni ze względu na złożony charakter przetwarzania, przy czym bieg tych terminów można zawiesić do czasu uzyskania przez organ informacji, których zażądał. Przy planowaniu harmonogramu warto liczyć się z tym, że realny czas bywa dłuższy niż suma tych dwóch okresów.

Jedna rzecz z tej sekcji bywa mylona z inną. AI Act przewiduje własną ocenę, nazwaną oceną skutków dla praw podstawowych, w art. 27. Nie jest ona jednak obowiązkiem każdego pracodawcy: przepis kieruje ją do podmiotów stosujących będących podmiotami prawa publicznego lub podmiotami prywatnymi świadczącymi usługi publiczne oraz do podmiotów stosujących systemy z załącznika III pkt 5 lit. b) i c), czyli w obszarze zdolności kredytowej oraz ryzyka i cen w ubezpieczeniach na życie i zdrowotnych. Gdy oba obowiązki się spotykają, art. 27 ust. 4 przesądza kierunek: ocena skutków dla praw podstawowych stanowi uzupełnienie oceny skutków dla ochrony danych, a nie jej zamiennik. Prezes UODO powtórzył to zresztą wprost w swoim wystąpieniu z lipca 2026 r.

Dane pracowników i kandydatów oraz wystąpienie UODO

RODO zostawia państwom członkowskim miejsce na własne przepisy o danych w zatrudnieniu. Artykuł 88 ust. 1 pozwala zawrzeć w przepisach krajowych lub w porozumieniach zbiorowych bardziej szczegółowe regulacje chroniące prawa i wolności przy przetwarzaniu danych pracowników, a ust. 2 wymaga, żeby takie przepisy obejmowały odpowiednie i szczegółowe środki zapewniające poszanowanie godności, prawnie uzasadnionych interesów i praw podstawowych, „w szczególności pod względem przejrzystości przetwarzania, przekazywania danych osobowych w ramach grupy przedsiębiorstw (…) oraz systemów monitorujących w miejscu pracy”.

W Polsce te szczegółowe przepisy to przede wszystkim Kodeks pracy: katalog danych, których pracodawca może żądać od kandydata i pracownika, oraz przepisy o monitoringu. Rozbieram je osobno w tekście o monitoringu pracowników, bo to materiał na własny artykuł, ale minimum trzeba mieć już przy lekturze tego. Artykuł 22² pozwala na szczególny nadzór nad terenem zakładu pracy „w postaci środków technicznych umożliwiających rejestrację obrazu” i tylko dla wymienionych tam celów, więc monitoring wizyjny obejmuje obraz, nie dźwięk, a mikrofon w kamerze niczego nie rozszerza. Artykuł 22³ § 4 nakazuje stosować odpowiednio zasady kontroli poczty służbowej do innych form monitoringu, jeśli są konieczne do tych samych celów; w praktyce oznacza to dopuszczalny cel z przepisu, zapis celów, zakresu i sposobu w układzie zbiorowym, regulaminie pracy albo obwieszczeniu, poinformowanie pracowników nie później niż dwa tygodnie przed uruchomieniem oraz informację na piśmie przed dopuszczeniem do pracy. Granica między tymi porządkami jest prosta: Kodeks pracy rozstrzyga, czy wolno prowadzić monitoring i na jakich warunkach formalnych, a RODO, na jakiej podstawie i w jakim zakresie wolno przetwarzać zebrane w ten sposób dane, co trzeba ludziom powiedzieć i czy potrzebna jest ocena skutków. W praktyce firmy robią najpierw to, co łatwiejsze, czyli zapis w regulaminie, i uznają temat za zamknięty.

16 lipca 2026 r. Prezes UODO Mirosław Wróblewski skierował do ministry pracy, rodziny i polityki społecznej wniosek o podjęcie prac nad przepisami zapewniającymi dodatkową ochronę przed dyskryminacją kandydatów i pracowników na skutek stosowania systemów AI (sygnatura DPNT.0623.18.2026). To wystąpienie o zmianę prawa, nie nowy obowiązek, i tak trzeba je czytać. Warto je jednak znać, bo pokazuje, na co organ patrzy.

Prezes UODO wskazał, że dociera do niego coraz więcej sygnałów o stosowaniu narzędzi opartych na AI w procesach rekrutacyjnych i że pozwalają one przetwarzać dane na dużą skalę, w tym nieraz dane szczególnych kategorii. Zwrócił uwagę, że systemy AI „rodzą poważne ryzyko powielania uprzedzeń istniejących w danych treningowych” oraz że mogą analizować znacznie więcej informacji, niż przewiduje katalog danych, których pracodawca może żądać od kandydata. Przypomniał prawo do niepodlegania decyzji opartej wyłącznie na zautomatyzowanym przetwarzaniu i zastrzegł, że jeśli profilowanie miałoby być dopuszczone przepisami krajowymi, przepisy te powinny gwarantować właściwe środki ochrony. Wskazał wreszcie na ocenę skutków dla ochrony danych, i to w dwóch rolach naraz. Postulował, żeby poprzedzić nią samo wprowadzenie przepisów dopuszczających takie systemy w zatrudnieniu, bo pozwoli to zidentyfikować ryzyka i ułatwi podmiotom korzystającym z narzędzi AI wykazanie zgodności przetwarzania z RODO. Osobno stwierdził, że dopuszczenie AI w zatrudnieniu powinno być poprzedzone taką oceną po stronie tego, kto z niej korzysta. Pierwsze jest postulatem wobec ustawodawcy, drugie odsyła do obowiązku, który firmę i tak wiąże, jeżeli spełnione są przesłanki art. 35.

W tym samym piśmie pojawia się przepis AI Act, o którym w rozmowach o rekrutacji prawie się nie mówi. Artykuł 86 ust. 1 przyznaje osobie, wobec której podjęto decyzję na podstawie wyników systemu wysokiego ryzyka z załącznika III, wywołującą skutki prawne lub podobnie znacząco na nią oddziałującą, prawo „uzyskania od podmiotu stosującego jasnego i merytorycznego wyjaśnienia roli tego systemu AI w procedurze podejmowania decyzji oraz głównych elementów podjętej decyzji”. Termin jest tu inny, niż podpowiada intuicja, i sam poprawiałem to sobie w trakcie pisania. Artykuł 86 leży w rozdziale IX, którego lipcowa zmiana kalendarza nie objęła, więc stosuje się go od ogólnej daty, czyli od 2 sierpnia 2026 r., a nie od 2 grudnia 2027 r. razem z obowiązkami dla systemów wysokiego ryzyka. Prawo to ma przy tym granice zapisane w samym przepisie: nie obejmuje systemów z pkt 2 załącznika III, nie stosuje się tam, gdzie prawo unijne lub krajowe przewiduje wyjątki albo ograniczenia, i działa tylko w zakresie, w jakim takie prawo do wyjaśnienia nie zostało już ustanowione w prawie Unii. Praktyczny wniosek dla kupującego: jeśli firma bierze teraz narzędzie do rekrutacji, warto sprawdzić, czy dostawca w ogóle potrafi wyjaśnić, dlaczego system wskazał taki wynik.

Dwa obowiązki AI Act wobec własnych ludzi warto znać przy tej okazji, bo mają różne daty. Artykuł 4 wymaga od 2 lutego 2025 r. podejmowania środków wspierających kompetencje AI u personelu pracującego z tymi systemami; nie ma dla niego odrębnej administracyjnej kary pieniężnej w art. 99, co nie czyni go ozdobą, bo stan kompetencji waży przy ocenie innych naruszeń. Artykuł 26 ust. 7 nakazuje pracodawcy poinformować przedstawicieli pracowników i samych pracowników, zanim system wysokiego ryzyka zostanie wobec nich użyty, i ten obowiązek przesunął się razem z całym rozdziałem III na 2 grudnia 2027 r.

Powierzenie i transfer: rola dostawcy narzędzia

Firma, która wprowadza dane swoich pracowników i klientów do cudzego narzędzia, zwykle pozostaje administratorem własnych celów. Rola dostawcy nie wynika przy tym ani z nazwy usługi, ani z samego faktu, że dane do niego trafiają: trzeba ją ustalić funkcjonalnie, patrząc, kto decyduje o celach i sposobach konkretnego przetwarzania. Dostawca bywa podmiotem przetwarzającym, potocznie procesorem, ale bywa też odrębnym administratorem albo współadministratorem, a przy jednej usłudze potrafi mieć różne role dla różnych operacji: procesora dla obsługi zapytań klienta i administratora dla własnych statystyk czy rozwoju produktu. Ustalenie roli poprzedza wybór instrumentu, nie odwrotnie.

Jeżeli ustalenie wypadnie na powierzenie, wchodzi art. 28 ust. 1 z obowiązkiem, o którym łatwo zapomnieć przy zakupie: administrator może korzystać wyłącznie z usług takich podmiotów przetwarzających, „które zapewniają wystarczające gwarancje wdrożenia odpowiednich środków technicznych i organizacyjnych”. Odpowiedzialność za wybór dostawcy jest więc po stronie firmy, zanim jeszcze zacznie się mówić o umowie.

Umowa powierzenia jest wtedy wymagana przez art. 28 ust. 3 i ma określać przedmiot i czas trwania przetwarzania, charakter i cel, rodzaj danych oraz kategorie osób, których dane dotyczą, a także obowiązki i prawa administratora. Wśród warunków, które umowa ma zawierać, pierwszy jest ten najważniejszy przy narzędziach AI: podmiot przetwarzający przetwarza dane osobowe wyłącznie na udokumentowane polecenie administratora, co dotyczy też przekazywania danych do państwa trzeciego. Przekładając to na język zakupów: gdy dostawca zastrzega sobie prawo do wykorzystania danych klienta do trenowania albo ulepszania modelu, trzeba najpierw rozdzielić dwa różne scenariusze. Trenowanie na zlecenie i na potrzeby klienta, na przykład dostrojenie modelu do jego danych, mieści się w poleceniu administratora, o ile zostało udokumentowane i objęte umową. Trenowanie na własne cele dostawcy, czyli ulepszanie produktu sprzedawanego wszystkim, oznacza, że dostawca przetwarza te dane jako odrębny administrator i musi mieć własną podstawę prawną, własny zakres i własne obowiązki informacyjne wobec osób, których dane dotyczą. Sama klauzula w umowie niczego tu nie legalizuje: przesądza rzeczywisty cel i rola, a klauzula jedynie je opisuje albo, co gorsza, ukrywa.

Drugi wątek to podprocesorzy. Artykuł 28 ust. 2 mówi, że podmiot przetwarzający nie korzysta z usług innego podmiotu przetwarzającego bez uprzedniej szczegółowej lub ogólnej pisemnej zgody administratora, a przy zgodzie ogólnej informuje o zamierzonych zmianach, dając możliwość wyrażenia sprzeciwu. Przy narzędziach AI łańcuch bywa długi: dostawca interfejsu korzysta z dostawcy modelu, ten z dostawcy infrastruktury, a do tego dochodzą usługi pomocnicze. Lista podprocesorów i tryb powiadamiania o zmianach to jeden z niewielu zapisów umownych, które realnie zmieniają obraz ryzyka, a jednocześnie jeden z tych, o które przy zakupie pyta się najrzadziej.

Trzeci wątek to transfery poza Europejski Obszar Gospodarczy. Zasada ogólna z art. 44 jest taka, że przekazanie danych do państwa trzeciego następuje tylko wtedy, gdy spełnione są warunki z rozdziału V, tak aby nie został naruszony stopień ochrony zagwarantowany rozporządzeniem. Najprostsza droga to decyzja Komisji Europejskiej stwierdzająca odpowiedni stopień ochrony na podstawie art. 45; takie przekazanie nie wymaga specjalnego zezwolenia. Komisja uznała za zapewniające odpowiednią ochronę między innymi Zjednoczone Królestwo, Szwajcarię, Japonię, Koreę Południową, Kanadę w zakresie organizacji komercyjnych oraz Stany Zjednoczone w odniesieniu do organizacji komercyjnych uczestniczących w ramach ochrony danych UE–USA, czyli Data Privacy Framework. Ta ostatnia decyzja obowiązuje na dzień pisania tego tekstu, ale ma charakter decyzji podlegającej okresowemu przeglądowi i bywa przedmiotem sporów prawnych, więc przy dłuższych kontraktach warto założyć, że stan może się zmienić, i przewidzieć w umowie, co wtedy.

Gdy decyzji o odpowiednim stopniu ochrony nie ma, art. 46 pozwala przekazywać dane przy zapewnieniu odpowiednich zabezpieczeń, spośród których w praktyce biznesowej liczą się dwa: standardowe klauzule umowne przyjęte przez Komisję oraz wiążące reguły korporacyjne w grupach kapitałowych. Same klauzule to jednak dokument, nie rozwiązanie; trzeba jeszcze ocenić, czy w państwie odbiorcy zapewniają realną ochronę, i ewentualnie dołożyć środki uzupełniające.

Najczęstsze nieporozumienie w tej części brzmi: „serwer jest w Europie, więc transferu nie ma”. Lokalizacja serwera jest jednym z elementów obrazu, ale nie całym obrazem. Liczy się także to, kto ma dostęp do danych: zespół wsparcia technicznego pracujący z innego kontynentu, dostęp administracyjny spółki matki, procedura obsługi zgłoszeń awaryjnych. Pytanie, które zadaję dostawcom, brzmi nie „gdzie stoją serwery”, tylko „kto i skąd może zobaczyć te dane, i w jakich okolicznościach”. Odpowiedź bywa dłuższa, niż sugeruje strona produktowa.

Najtańszym środkiem organizacyjnym w całej tej sekcji, dającym najwięcej porządku za najmniejsze pieniądze, jest wewnętrzna zasada korzystania z AI: co wolno wkleić, czego nie wolno, w których narzędziach, i do kogo się zgłosić przy wątpliwości. Trzy akapity prostym językiem, zatwierdzone przez zarząd, rozesłane do wszystkich. Ta kartka nie załatwia zgodności z RODO i nie zastępuje żadnego z dokumentów opisanych wyżej. Rozwiązuje za to problem wcześniejszy: ludzie przestają zgadywać. Jasne zasady, szkolenie i odpowiednie ustawienia narzędzi ograniczają ryzyko przypadkowego ujawnienia danych, choć go nie eliminują.

Obowiązek informacyjny wobec ludzi, których to dotyczy

Artykuł 13 dotyczy sytuacji, w której dane zbieramy od samej osoby, artykuł 14 sytuacji, w której pozyskujemy je skądinąd. Oba wymagają podania między innymi celów przetwarzania i podstawy prawnej, informacji o odbiorcach danych, okresu przechowywania albo kryteriów jego ustalania, praw przysługujących osobie oraz prawa wniesienia skargi do organu nadzorczego. Jeżeli przetwarzanie opiera się na prawnie uzasadnionym interesie, trzeba ten interes wskazać. Jeżeli dane mają trafić poza EOG, trzeba poinformować o zamiarze przekazania i o tym, czy Komisja stwierdziła odpowiedni stopień ochrony, a przy przekazaniu na podstawie art. 46 wspomnieć o odpowiednich zabezpieczeniach.

Dla tego tekstu najważniejszy jest art. 13 ust. 2 lit. f. Administrator podaje informacje o zautomatyzowanym podejmowaniu decyzji, w tym o profilowaniu, o którym mowa w art. 22 ust. 1 i 4, oraz, przynajmniej w tych przypadkach, „istotne informacje o zasadach ich podejmowania, a także o znaczeniu i przewidywanych konsekwencjach takiego przetwarzania”. W praktyce oznacza to, że klauzula informacyjna napisana trzy lata temu prawie na pewno nie opisuje tego, co firma zaczyna robić dzisiaj. Uruchomienie narzędzia oceniającego ludzi to moment na przegląd klauzul dla pracowników, kandydatów i klientów. Dopisanie zdania o AI na końcu istniejącego dokumentu rzadko wystarcza.

Drugi przepis, o którym zapomina się przy pilotażach, to art. 13 ust. 3: jeżeli administrator planuje przetwarzać dane w celu innym niż ten, w którym zostały zebrane, przed takim dalszym przetwarzaniem informuje o tym innym celu. Nagrania rozmów zbierane „dla celów dowodowych i szkoleniowych” mają cel zapisany w dokumentach sprzed lat. Analiza tych samych nagrań przez model wystawiający oceny może oznaczać nowy cel, choć samo użycie innej technologii jeszcze o tym nie przesądza. Trzeba ustalić rzeczywisty cel nowej operacji, a jeśli różni się od pierwotnego, ocenić zgodność dalszego przetwarzania według kryteriów z art. 6 ust. 4 i wykonać obowiązek informacyjny.

Warstwa trzecia dotyczy klienta rozmawiającego z botem i wynika już nie z RODO, tylko z AI Act. Artykuł 50 tego rozporządzenia obowiązuje od 2 sierpnia 2026 r. i nakłada obowiązki przejrzystości przy określonych funkcjach, rozdzielone między role. Po stronie dostawcy jest zaprojektowanie systemu tak, żeby rozmówca wiedział, że rozmawia z AI, oraz oznaczanie treści syntetycznych w formacie nadającym się do odczytu maszynowego; dostawcy systemów generujących takie treści, wprowadzonych do obrotu przed 2 sierpnia 2026 r., mają na dostosowanie oznaczania czas do 2 grudnia 2026 r. Po stronie firmy używającej narzędzia są własne obowiązki ujawnienia, między innymi przy treściach typu deepfake. Rozłożyłem go na role dostawcy i podmiotu stosującego w tekście o AI Act. Tutaj wystarczy zapamiętać, że są to dwa niezależne obowiązki: informacja, że rozmówcą jest AI, wynika z AI Act, a informacja o tym, co dzieje się z danymi z tej rozmowy, z RODO. Wykonanie jednego nie zwalnia z drugiego. Sama wzmianka w regulaminie może przy tym nie zapewnić wymaganej treści, widoczności ani terminowości informacji, bo oba przepisy pytają nie o to, czy informacja gdzieś istnieje, tylko czy dotarła do człowieka i kiedy.

Prawa osób a modele AI: opinia EROD 28/2024

Firmy pytają czasem o coś, co brzmi jak zagadka: skoro model uczył się na danych, a ja mam prawo do usunięcia moich danych, to czy mogę żądać usunięcia siebie z modelu. To pytanie wykracza poza typowe wdrożenie, ale warto znać kierunek, w którym idzie odpowiedź, bo wpływa on na to, o co pytać dostawcę.

Europejska Rada Ochrony Danych przyjęła 17 grudnia 2024 r. opinię 28/2024 w sprawie niektórych aspektów ochrony danych związanych z przetwarzaniem danych osobowych w kontekście modeli AI. Powstała na wniosek irlandzkiego organu nadzorczego i odpowiada na cztery pytania: kiedy model AI można uznać za anonimowy, jak wykazać uzasadniony interes w fazie rozwoju modelu, jak w fazie wdrożenia, oraz jakie są konsekwencje niezgodnego z prawem przetwarzania w fazie rozwoju dla późniejszego działania modelu.

Dla firmy, która modelu nie buduje, tylko go używa, praktyczne znaczenie ma przede wszystkim to, co opinia mówi o anonimowości. EROD uważa, że modele trenowane przy użyciu danych osobowych nie we wszystkich przypadkach można uznać za anonimowe, a twierdzenia o anonimowości organy nadzorcze powinny oceniać indywidualnie. Żeby model uznać za anonimowy, znikome ma być zarówno prawdopodobieństwo bezpośredniej ekstrakcji danych osobowych osób, których dane wykorzystano do jego opracowania, jak i prawdopodobieństwo uzyskania takich danych z zapytań. Deklaracja dostawcy, że „model jest anonimowy”, nie jest więc rozstrzygnięciem, tylko twierdzeniem, które powinno dać się udokumentować.

Stąd bierze się odpowiedzialność kupującego. W scenariuszu, w którym dane osobowe są przechowywane w modelu i przetwarzane przez innego administratora przy jego wdrażaniu, EROD wskazuje, że organy nadzorcze powinny brać pod uwagę, czy administrator wdrażający model przeprowadził odpowiednią ocenę w ramach swoich obowiązków w zakresie rozliczalności, aby upewnić się, że model nie został opracowany w drodze niezgodnego z prawem przetwarzania. Ocena ta ma uwzględniać między innymi źródło danych osobowych oraz to, czy przetwarzanie w fazie rozwoju było przedmiotem stwierdzenia naruszenia, w szczególności przez organ nadzorczy lub sąd, i ma być mniej lub bardziej szczegółowa zależnie od ryzyka.

Przekładam to na jedno pytanie zakupowe, które od przeczytania tej opinii zadaję przy każdym narzędziu opartym na cudzym modelu: skąd pochodzą dane treningowe i czy wobec dostawcy albo wobec twórcy modelu toczyło się postępowanie zakończone stwierdzeniem naruszenia. Nie zawsze dostaję odpowiedź. Sam fakt jej braku też jest informacją, którą warto zapisać w dokumentacji wyboru dostawcy.

Kto to egzekwuje w Polsce

Podział kompetencji bywa mylący, bo od sierpnia 2026 r. mamy w Polsce nowy organ do spraw AI, co część firm czyta jako przeniesienie całego tematu w jedno miejsce. Tak się nie stało.

Za RODO odpowiada Prezes Urzędu Ochrony Danych Osobowych i to się nie zmieniło. Jeżeli firma uruchomi narzędzie oceniające ludzi bez podstawy prawnej, bez oceny skutków tam, gdzie była wymagana, albo bez poinformowania osób, których dane dotyczą, sprawa należy do UODO, niezależnie od tego, czy narzędzie jest systemem AI w rozumieniu AI Act.

Za AI Act odpowiada Komisja Rozwoju i Bezpieczeństwa Sztucznej Inteligencji, powołana ustawą z 3 lipca 2026 r. o systemach sztucznej inteligencji (Dz.U. 2026 poz. 1003, ogłoszona 27 lipca 2026 r., w życie 11 sierpnia 2026 r.). Przepisy o kontroli, postępowaniu i karach zaczynają być stosowane 28 października 2026 r. Kompetencje Komisji, przebieg kontroli i tryb opinii indywidualnej rozłożyłem w tekście o samej ustawie. Jedna rzecz z tamtego materiału jest tutaj istotna: Komisja nie wypowie się za pracodawcę ani za inspektora ochrony danych o RODO i Kodeksie pracy, bo jej opinia dotyczy spraw objętych AI Act i tą ustawą.

Za przepisy o monitoringu w miejscu pracy odpowiada Państwowa Inspekcja Pracy. To trzeci adres i trzeci tryb.

Uczciwa informacja na koniec tej sekcji: kar nałożonych w Polsce za użycie AI wobec pracowników jeszcze nie było i nie zamierzam sugerować, że jest inaczej. Punkt odniesienia, jaki mam, jest skromniejszy, niż chciałyby nagłówki: 22 maja 2026 r. Prezes UODO nałożył karę 26 711 zł w sprawie dotyczącej monitoringu (decyzja o sygnaturze DKE.561.4.2026). Nie dotyczy ona systemu AI. Zakresu samej sprawy nie czytałem w treści decyzji, więc nie wyprowadzam z niej żadnego wniosku o wdrożeniach w zatrudnieniu; podaję ją wyłącznie jako dowód, że obszar ochrony danych bywa przedmiotem rozstrzygnięć organu.

Ścieżka przed pilotażem AI na danych osobowych

Poniżej kolejność, w której układam pracę, gdy firma chce uruchomić narzędzie dotykające ludzi. Lista ma charakter orientacyjny: konkretne działania i ich zakres zależą od roli firmy, przebiegu procesu, dostawcy i wyniku oceny ryzyka, a część z nich w danym przypadku może w ogóle nie wystąpić. Punkty różnią się objętością, bo różnią się ciężarem: dwa z nich zajmują popołudnie, dwa potrafią zająć kilka tygodni, jeśli trzeba czekać na dostawcę.

  1. 1. Rozpisz narzędzie na pojedyncze funkcje i przy każdej zapisz, jakie dane wchodzą, skąd pochodzą, kto zobaczy wynik i jaka decyzja od niego zależy. To fundament wszystkiego, co dalej, i jednocześnie jedyny punkt, którego nie da się zlecić na zewnątrz, bo tylko wewnątrz firmy wiadomo, do czego wynik naprawdę posłuży.
  2. 2. Dla każdej funkcji wskaż przesłankę z art. 6, a przy danych szczególnych kategorii dodatkowo przesłankę z art. 9 ust. 2. Jeśli podstawą jest prawnie uzasadniony interes, przeprowadź i zapisz test równowagi, zamiast go deklarować.
  3. 3. Oceń ryzyko według art. 35 ust. 1, pomagając sobie trzema przypadkami z ust. 3 i wykazem Prezesa UODO. Dwa albo więcej kryteriów z wykazu to wskazówka organu, że ocena będzie potrzebna, ale rozstrzyga charakter operacji i waga ryzyka, nie arytmetyka. Uzasadnienie zapisz także wtedy, gdy wyjdzie, że oceny nie robimy.
  4. 4. Jeżeli ocena jest wymagana, zrób ją przed uruchomieniem, także przed pilotażem na prawdziwych danych. Cztery elementy z art. 35 ust. 7 wyznaczają minimum treści, a art. 35 ust. 2, 9 i 11 oraz art. 36 dokładają obowiązki proceduralne.
  5. 5. Ustal rolę dostawcy dla każdej operacji i dobierz do niej właściwy instrument; przy powierzeniu umowa zgodna z art. 28 ust. 3, do tego lista podprocesorów i tryb powiadamiania o ich zmianach, rozstrzygnij kwestię wykorzystania danych do trenowania modelu, ustal podstawę transferu poza EOG i to, kto faktycznie ma dostęp do danych.
  6. 6. Zaktualizuj klauzule informacyjne dla pracowników, kandydatów i klientów, w tym o zautomatyzowanym podejmowaniu decyzji tam, gdzie art. 13 ust. 2 lit. f tego wymaga.
  7. 7. Jeżeli decyzje dotyczą ludzi, rozstrzygnij najpierw, czy zachodzą przesłanki art. 22, bo od tego zależy, co jest obowiązkiem ustawowym. Prawo do interwencji człowieka, wyrażenia stanowiska i zakwestionowania decyzji wynika z art. 22 ust. 3 w opisanych tam przypadkach. Niezależnie od kwalifikacji polecam ten sam standard wdrożeniowy: wskazana osoba z mandatem do zmiany wyniku, dostęp do danych źródłowych, czas na ocenę, kanał odwoławczy i zapis przypadków, w których wynik zmieniono.
  8. 8. Ustal okresy przechowywania po obu stronach, czyli u siebie i u dostawcy, oraz mechanizm, który je realizuje. Po zakończonym pilotażu trzeba umieć wykazać wykonanie ustalonej, uzasadnionej retencji: usunięcie, anonimizację albo dopuszczalne dalsze przechowywanie ze wskazaną podstawą.
  9. 9. Ustal, czy prowadzicie rejestr czynności przetwarzania, i odpowiednio uzupełnij albo zaktualizuj czynność, której wdrożenie dotyczy; rejestr obejmuje czynności, nie narzędzia, więc nowe narzędzie w istniejącym procesie bywa aktualizacją wpisu. Artykuł 30 wymaga w nim celów przetwarzania, kategorii osób i danych, kategorii odbiorców oraz informacji o przekazaniach do państw trzecich, a jego ust. 5 przewiduje wyłączenie dla podmiotów zatrudniających mniej niż 250 osób, z wyjątkami, które przy AI oceniającej ludzi zwykle i tak się ziszczają.
  10. 10. Wpisz do kalendarza datę przeglądu. Artykuł 35 ust. 11 nakazuje, przynajmniej gdy zmienia się ryzyko, sprawdzić, czy przetwarzanie odbywa się zgodnie z oceną skutków.

Przeprowadźmy przez to jeden przykład, ten sam, który wraca w całej serii: firma chce, żeby AI analizowała nagrania rozmów handlowców. W spisie funkcji wychodzi pięć pozycji: transkrypcja, streszczenie, podpowiedź w trakcie rozmowy, ocena punktowa rozmowy, ranking zespołu. Przy podstawie przetwarzania dla pierwszych trzech można rozważyć prawnie uzasadniony interes, po analizie niezbędności, równowagi i ograniczeń prawa pracy; czwarta i piąta wymagają znacznie mocniejszego uzasadnienia, bo to one wpływają na sytuację pracownika. Przy pełnym zakresie przesłanki silnie przemawiają za obowiązkiem oceny skutków. W ocenie skutków wychodzi, że dwie pierwsze funkcje realizują cel biznesowy, czyli skrócenie czasu na raportowanie i lepsze przygotowanie do kolejnych rozmów, a dwie ostatnie dokładają największe ryzyko dla ludzi przy najmniejszym przyroście wartości. Decyzja, która z tego wynika w większości firm, które przez to przeszły: uruchamiamy transkrypcję i streszczenie, ocenę punktową odkładamy albo projektujemy inaczej, ranking zostaje wyłączony. Wcześniejsze uporządkowanie zakresu może ograniczyć opóźnienia, choć nie daje gwarancji żadnego konkretnego terminu; przy okazji temat premii nie wraca do zespołu jako powód do konfliktu.

W tej ścieżce celowo nie ma kupowania oprogramowania do zarządzania zgodnością, powoływania inspektora ochrony danych „na wszelki wypadek” ani pisania polityki na trzydzieści stron. Znam firmy, które zaczęły od takiej polityki i skończyły na tym, że nikt jej nie przeczytał, a pilotaż i tak ruszył wcześniej, obok dokumentu.

Jeden przypadek zamiast listy błędów

Zamiast wyliczać typowe potknięcia, opiszę jedno wdrożenie, w którym zeszły się prawie wszystkie. Firma usługowa uruchomiła narzędzie streszczające spotkania z klientami. Pilotaż ruszył na prawdziwych nagraniach, „bo to przecież tylko test”, i trwał sześć tygodni, zanim ktokolwiek zapytał o ocenę skutków. Eksport do narzędzia zrobiono metodą „weźmy wszystko, model sobie wybierze”, więc razem z transkrypcjami poszły notatki handlowców z uwagami o zdrowiu i sytuacji rodzinnej klientów. Klauzula informacyjna dla klientów pochodziła sprzed trzech lat i mówiła o nagrywaniu „w celach dowodowych i szkoleniowych”, nie o analizie przez model. Pracownikom pokazano zgodę do podpisania, w przekonaniu, że to załatwia stronę kadrową. Retencji nikt nie ustalił, więc po zakończonym pilotażu w narzędziu zostało wszystko, a nikt nie wiedział, kto ma to usunąć ani na jakiej podstawie cokolwiek miałoby zostać.

Żaden z tych kroków nie był złą wolą. Każdy wynikał z tej samej kolejności: najpierw sprawdzamy, czy narzędzie działa, potem pytamy, czy wolno. Odwrócenie tej kolejności kosztuje kilka dni pracy przed startem i tyle; próba odkręcenia jej po sześciu tygodniach oznacza ustalanie po fakcie, czyje dane gdzie trafiły, i rozmowę z zespołem, która idzie znacznie gorzej niż ta sama rozmowa przed pilotażem.

Jeżeli chcesz przejść przez tę ścieżkę z zespołem, prowadzę bezpłatne szkolenie online „AI w firmie zgodnie z prawem”. Na przykładzie z Twojej branży rozkładamy wdrożenie na funkcje i przepływy danych oraz układamy listę pytań do prawnika albo inspektora ochrony danych; szkolenie ma charakter edukacyjny i nie rozstrzyga legalności konkretnego wdrożenia. Zapisy przez formularz kontaktowy; wystarczy napisać „szkolenie AI” w wiadomości.

Najczęstsze pytania

Czy każde wdrożenie AI w firmie wymaga oceny skutków dla ochrony danych?

Nie. Ocena skutków jest wymagana wtedy, gdy przetwarzanie z dużym prawdopodobieństwem może powodować wysokie ryzyko naruszenia praw lub wolności osób fizycznych, a w szczególności w trzech przypadkach z art. 35 ust. 3 RODO. Praktycznym narzędziem rozstrzygającym jest wykaz Prezesa UODO z 17 czerwca 2019 r. (M.P. 2019 poz. 666): co do zasady przetwarzanie spełniające przynajmniej dwa z dwunastu wymienionych tam kryteriów wymaga oceny, choć w niektórych przypadkach administrator może uznać, że wystarczy jedno. Narzędzie, które nie dotyka danych osobowych, na przykład generator opisów produktów, zwykle nie wchodzi w ten obszar. Przy narzędziu oceniającym ludzi przesłanki zwykle silnie przemawiają za obowiązkiem oceny, ale ustala się to dla konkretnego przetwarzania, nie dla kategorii produktu. Wynik sprawdzenia warto zapisać niezależnie od tego, jaki jest.

Czy kierownik zatwierdzający wynik systemu wystarczy, żeby decyzja nie była „wyłącznie automatyczna”?

Zależy od tego, czym to zatwierdzenie faktycznie jest. Jeżeli osoba zatwierdzająca nie ma dostępu do danych źródłowych, nie zna kryteriów oceny, nie ma czasu na weryfikację ani realnej możliwości zmiany wyniku, trudno uznać taki udział za ludzką ocenę, a proces pozostaje w obszarze art. 22. Przy dwóch z trzech wyjątków z art. 22 ust. 2, czyli przy niezbędności do umowy i przy wyraźnej zgodzie, administrator i tak zapewnia co najmniej prawo do interwencji człowieka, do wyrażenia własnego stanowiska i do zakwestionowania decyzji. Kwalifikacji konkretnego procesu nie da się przesądzić bez jego zbadania.

Czy mogę wprowadzać dane klientów do publicznego narzędzia AI, jeśli mam z nim umowę?

Sama umowa nie wystarczy i nie zawsze jest to umowa powierzenia. Najpierw ustala się rolę dostawcy dla każdej operacji, bo może on być procesorem, odrębnym administratorem albo współadministratorem; dopiero potem dobiera się właściwy instrument. Do tego dochodzi podstawa przetwarzania dla konkretnego celu, ocena gwarancji dostawcy w rozumieniu art. 28 ust. 1, lista podprocesorów, ustalenie, czy dane opuszczają Europejski Obszar Gospodarczy i na jakiej podstawie, oraz obowiązek informacyjny. Osobno trzeba rozstrzygnąć, czy dostawca wykorzystuje dane wyłącznie na polecenie firmy, czy także do własnych celów, na przykład rozwoju produktu; w drugim wariancie działa jako odrębny administrator i potrzebuje własnej podstawy, a klauzula umowna sama tego nie legalizuje. Techniczne warianty ograniczające ten problem, w tym oddzielenie bazy wiedzy od modelu, opisałem w tekście o wdrażaniu AI zgodnie z RODO.

Czy AI Act zastępuje RODO, skoro oba dotyczą systemów AI?

Nie, to dwa niezależne reżimy o różnym przedmiocie. AI Act reguluje systemy AI jako produkty i zastosowania, dzieląc je według ryzyka. RODO reguluje przetwarzanie danych osobowych, niezależnie od użytej technologii. Widać to na przykładzie oceny: AI Act przewiduje własną ocenę skutków dla praw podstawowych w art. 27, ale kieruje ją do wąskiej grupy podmiotów stosujących, a jej ust. 4 wprost przesądza, że stanowi ona uzupełnienie oceny skutków dla ochrony danych z art. 35 RODO. Bywa i odwrotnie: część obowiązków AI Act, jak zakaz wnioskowania o emocjach w miejscu pracy czy wsparcie kompetencji AI, działa od lutego 2025 r. i RODO ich nie zastępuje. Kolejność w czasie też jest odwrotna, niż sugerują nagłówki: RODO obowiązuje od 2018 r., a obowiązki AI Act dla systemów wysokiego ryzyka w zatrudnieniu zaczną być stosowane 2 grudnia 2027 r.

Źródła

Materiał ma charakter ogólny i nie rozstrzyga zgodności konkretnego wdrożenia; stan przepisów na 15 września 2026 r.