Dane treningowe a zgody: kiedy nie potrzebujesz zgody, a kiedy musisz ją mieć

Dlaczego dane treningowe i zgody stały się tak problematyczne

Starcie dwóch logik: „więcej danych” kontra ochrona prywatności

Twórcy modeli AI i zespoły data science wychowali się w kulturze, w której obowiązuje prosta zasada: im więcej danych treningowych, tym lepszy model. Z drugiej strony regulatorzy, prawnicy i użytkownicy stawiają na pierwszym planie prywatność, autonomię decyzji i ograniczenie nadzoru. Zderzają się więc dwie logiki: techniczna, która żąda maksymalnej ilości danych, oraz prawna i społeczna, która nakazuje te dane ograniczać i kontrolować.

W klasycznym projekcie machine learningowym dane traktuje się jak surowiec: gromadzi się je, łączy, wzbogaca, wielokrotnie przetwarza. W prawie ochrony danych każdy taki krok jest osobnym „celem przetwarzania”, dla którego trzeba mieć podstawę prawną, określić zakres, czas przechowywania i sposoby zabezpieczenia. Z perspektywy inżyniera to często hamulec. Z perspektywy osoby, której dane dotyczą – jedyny realny bezpiecznik.

Im bardziej zaawansowany model (szczególnie generatywny), tym trudniej konsekwentnie panować nad tym, jakie dane „zapamiętał” i co może z nich odtworzyć. To sprawia, że decyzja „czy musimy mieć zgodę?” nie jest formalnością, tylko kluczowym wyborem projektowym, wpływającym na ryzyko prawne, reputację i możliwości komercyjne produktu.

Dane treningowe jako surowiec a prawo jako zestaw ograniczeń

Dla zespołów ML dane treningowe są jak paliwo. Dla regulatora to informacje o konkretnych ludziach – czasem bardzo wrażliwe. Model nie przetwarza „liczb i wektorów” w próżni; dla prawa te wektory są pochodną, która może nadal prowadzić do osoby fizycznej. Im więcej takich „pochodnych” się gromadzi i łączy, tym łatwiej o identyfikację.

Prawo ochrony danych, zwłaszcza RODO, wprowadza kilka fundamentalnych zasad, które są w napięciu z „nienasyconym apetytem” AI na dane:

• Minimalizacja danych – używaj tylko takiego zakresu danych, jaki jest konieczny do konkretnego celu.
• Ograniczenie celu – nie wolno swobodnie zmieniać przeznaczenia danych bez odpowiedniej podstawy (w tym czasem bez nowej zgody).
• Ograniczenie przechowywania – dane nie powinny leżeć „na wszelki wypadek”; trzeba określić okres przechowywania.
• Przejrzystość – osoby muszą wiedzieć, co się dzieje z ich danymi, również jako danymi treningowymi.

Trening modelu jest więc postrzegany jako kolejny cel przetwarzania, często odmienny od pierwotnego. Jeżeli dane pierwotnie zebrano np. tylko do realizacji zamówienia, to użycie ich do budowy silnika rekomendacji albo systemu predykcji churnu może już wymagać nowej analizy podstawy prawnej, a czasem uzyskania zgody.

Dwie perspektywy: prawnik kontra data scientist

Różnice sposobu myślenia dobrze widać w prostym przykładzie. Data scientist widzi logi aplikacji:

• timestamp,
• identyfikator urządzenia,
• akcja w aplikacji,
• adres IP,
• ewentualnie ID użytkownika.

Dla niego to po prostu dane telemetryczne, bez których nie da się poprawić produktu. Dla prawnika adres IP, identyfikator urządzenia i ID użytkownika to dane osobowe – informacje pozwalające zidentyfikować konkretną osobę lub przynajmniej jej profil korzystania z usługi. Prawnik zacznie więc zadawać pytania: jaki jest cel? jaka jest podstawa prawna? jak długo te dane się przechowuje? czy użytkownik może sprzeciwić się profilowaniu?

Data scientist skupia się na jakości danych (kompletność, brak biasu, brak szumu), prawnik na legalności i proporcjonalności (czy to, co chcemy zrobić, jest konieczne i mieści się w rozsądnych oczekiwaniach użytkownika). W praktyce oba spojrzenia trzeba połączyć. Bez zrozumienia minimalizacji danych inżynierowie projektują zbyt „łapczywe” pipeline’y. Bez rozumienia, jak działają modele, prawnicy piszą polityki, które są nierealistyczne technologicznie.

Typy danych w AI: osobowe, nieosobowe, wrażliwe

Trening modeli AI może dotyczyć bardzo różnych rodzajów informacji. W uproszczeniu można je podzielić na trzy główne kategorie:

• Dane osobowe – wszystko, co odnosi się do zidentyfikowanej lub możliwej do zidentyfikowania osoby fizycznej.
• Dane nieosobowe – dane, które nie pozwalają powiązać informacji z konkretną osobą, także przy użyciu „rozsądnie dostępnych środków”.
• Dane wrażliwe (szczególne kategorie danych) – m.in. dane o zdrowiu, pochodzeniu rasowym, poglądach politycznych, orientacji seksualnej, przekonaniach religijnych czy przynynależności związkowej.

Każda z tych grup podlega innemu reżimowi prawnemu. Dane nieosobowe nie podlegają RODO – zgoda nie jest tu wymagana z perspektywy ochrony danych, choć mogą wystąpić inne ograniczenia (tajemnica przedsiębiorstwa, prawa autorskie, regulaminy serwisów). Dane osobowe wymagają jednej z podstaw prawnych z art. 6 RODO, a w wielu przypadkach dodatkowych mechanizmów przejrzystości i kontroli. Dane wrażliwe to osobna, bardziej restrykcyjna półka, gdzie co do zasady przetwarzanie jest zakazane, chyba że spełniony jest jeden z wąskich wyjątków z art. 9 ust. 2 RODO (np. wyraźna zgoda, cele medyczne, interes publiczny).

W kontekście trenowania modeli AI różnica między tymi trzema grupami to różnica między projektem, w którym można się oprzeć na prawnie uzasadnionym interesie i anonimowych agregatach, a projektem, gdzie bez wyraźnej zgody albo bardzo solidnej podstawy z prawa sektorowego nie da się zgodnie z prawem ruszyć z miejsca.

Co jest danymi osobowymi w AI – granice i szare strefy

Definicja danych osobowych a dane treningowe

RODO definiuje dane osobowe jako każdą informację o zidentyfikowanej lub możliwej do zidentyfikowania osobie fizycznej. Osoba jest możliwa do zidentyfikowania, jeśli można ją bezpośrednio lub pośrednio powiązać z danymi, w szczególności na podstawie identyfikatora (np. imię i nazwisko, numer identyfikacyjny, dane o lokalizacji, identyfikator internetowy) lub jednego bądź kilku czynników określających fizyczną, fizjologiczną, genetyczną, psychiczną, ekonomiczną, kulturową lub społeczną tożsamość tej osoby.

W świecie AI to oznacza, że dane treningowe to dane osobowe, jeżeli:

• zawierają bezpośrednie identyfikatory (imię i nazwisko, PESEL, e-mail w stylu imie.nazwisko@…);
• zawierają identyfikatory pośrednie (ID użytkownika, identyfikator urządzenia, adres IP) pozwalające na powiązanie z osobą w realnym systemie IT;
• są na tyle szczegółowe, że możliwa jest identyfikacja przy połączeniu kilku pól (np. data urodzenia + miejsce + stanowisko w niszowej firmie).

Jeżeli dane treningowe opisują zachowania lub cechy konkretnego użytkownika (np. historię zakupów, wzorce korzystania z aplikacji, ścieżki ruchu na stronie), bardzo często będzie to przetwarzanie danych osobowych, nawet jeśli imię i nazwisko nie występuje wprost. Oceniając, czy zgoda jest potrzebna, nie można więc uciekać w prosty argument: „ale w modelu są tylko liczby”. Dla prawa liczy się możliwość powiązania tych liczb z osobą w praktyce.

Przykłady graniczne: logi, telemetryka, embeddingi, teksty „zanonimizowane”

Trudniej bywa przy danych, które z pozoru są techniczne albo odległe od człowieka. Kilka typowych przykładów granicznych:

• Logi serwerowe – najczęściej zawierają adresy IP, znaczniki czasu, informacje o przeglądarce, czasem identyfikatory sesji. W większości przypadków to dane osobowe, bo przy dostępie do systemu źródłowego można powiązać log z konkretnym kontem lub urządzeniem.
• Dane telemetryczne z aplikacji mobilnych – parametry urządzenia, lokalizacja, zdarzenia w aplikacji. Po połączeniu z kontem użytkownika lub ID reklamowym to dane osobowe; bezpośredni związek z konkretną osobą jest tu zazwyczaj oczywisty.
• Embeddingi (wektory reprezentujące tekst, obraz, dźwięk) – pojedynczy embedding może wydawać się anonimowy, ale jeśli został wygenerowany na podstawie treści opisujących użytkownika (np. CV, czaty z supportem), to wciąż może być traktowany jako dane osobowe, o ile da się powiązać go z osobą w praktyce systemowej.
• „Zanonimizowane” teksty – usunięcie imienia, nazwiska i adresu nie zawsze wystarcza. Jeśli treść pozostaje na tyle szczegółowa („jedyny kardiochirurg w małym mieście, autor konkretnej publikacji”), że identyfikacja jest możliwa, nadal mamy do czynienia z danymi osobowymi.

Kluczowe pytanie brzmi: czy administrator lub inne realistycznie przewidywalne podmioty mają środki, aby z tych danych odtworzyć tożsamość lub powiązać te dane z konkretną osobą? Jeśli tak, mówimy o danych osobowych, nawet jeśli są one „zakodowane” jako wektory lub zbiory cech.

Anonimizacja a pseudonimizacja – co naprawdę wyłącza RODO

Często słyszy się stwierdzenia typu „zrobimy anonimizację, więc RODO nas nie dotyczy”. Problem w tym, że w większości przypadków chodzi raczej o pseudonimizację niż prawdziwą anonimizację.

Pseudonimizacja polega na zastąpieniu bezpośrednich identyfikatorów innymi oznaczeniami (np. numerami, hashami), przy zachowaniu możliwości ponownego powiązania danych z osobą przy użyciu dodatkowego klucza. Przykład: baza użytkowników, gdzie imię, nazwisko i e-mail zostały zastąpione ID, ale w innym systemie klucz łączący ID z kontem nadal istnieje. Pseudonimizacja zmniejsza ryzyko, ale dane nadal są danymi osobowymi i RODO nadal ma zastosowanie.

Anonimizacja to taki proces przekształcenia danych, po którym nie da się – w sposób realistyczny i przy użyciu rozsądnie dostępnych środków – ponownie zidentyfikować osób. Nie ma klucza, nie da się odtworzyć tożsamości z połączenia atrybutów. Przykłady zbliżające się do anonimizacji to:

• silna agregacja (np. statystyki w grupach liczących setki lub tysiące osób, bez możliwości „rozbicia” na jednostki);
• usunięcie lub przekształcenie unikalnych kombinacji cech (kod pocztowy + specyficzne stanowisko + nietypowa data urodzenia);
• stosowanie technik takich jak k-anonimowość, l-diversity, t-closeness, gdzie z góry eliminuje się możliwość wyróżnienia jednostki.

Jeżeli anonimizacja jest solidna, a administrator nie dysponuje (i realistycznie nie może dysponować) danymi referencyjnymi umożliwiającymi reidentyfikację, dane wypadają poza zakres RODO. Wtedy zgoda czy inna podstawa z art. 6 nie są wymagane z perspektywy ochrony danych. Trzeba jednak uczciwie ocenić ryzyko reidentyfikacji – przy dzisiejszej mocy obliczeniowej i ilości danych zewnętrznych udawana „anonimizacja” łatwo okazuje się jedynie cienką zasłoną pseudonimizacji.

Dane wrażliwe w modelach AI – jeszcze ostrzejszy reżim

Szczególne kategorie danych osobowych, wymienione w art. 9 RODO, obejmują m.in. informacje o:

• zdrowiu fizycznym i psychicznym,
• pochodzeniu rasowym lub etnicznym,
• orientacji seksualnej,
• poglądach politycznych,
• przynależności związkowej,
• przekonaniach religijnych lub światopoglądowych,
• dane biometryczne służące do identyfikacji (np. linie papilarne, skany twarzy).

Przetwarzanie takich danych jest co do zasady zabronione, chyba że zachodzi jedna z nielicznych przesłanek: wyraźna zgoda, poważny interes publiczny, medycyna i ochrona zdrowia z odpowiednimi zabezpieczeniami, prawo pracy w określonych sytuacjach i kilka innych wyjątków.

W treningu AI dane wrażliwe pojawiają się częściej, niż się wydaje. Modele medyczne uczą się na opisach przypadków klinicznych, zdjęciach radiologicznych, wynikach badań. Systemy analizy nastrojów lub detekcji mowy nienawiści mogą przetwarzać wypowiedzi zawierające ujawnione poglądy polityczne lub orientację. Modele computer vision trenują na zdjęciach, które pozwalają na identyfikację rasową czy religijną (np. stroje, symbole).

Jeśli takie informacje są obecne w danych treningowych, projekt automatycznie wchodzi w „wyższy poziom trudności” prawny. Bez wyraźnej, celowo zebranej zgody albo bez zakotwiczenia się w jednym z wyjątków z art. 9 ust. 2 RODO (np. badania naukowe z odpowiednimi zabezpieczeniami) ryzyko naruszenia przepisów jest bardzo wysokie. W tego typu projektach sama pseudonimizacja nie wystarcza; trzeba dodatkowo zadbać o celowość, ograniczenie dostępu, DPIA (ocenę skutków dla ochrony danych) i silną transparentność.

Zgoda a inne podstawy prawne – jakie masz opcje

Podstawy prawne z art. 6 RODO w kontekście treningu AI

Porównanie głównych podstaw: zgoda, uzasadniony interes, umowa, obowiązek prawny

W projektach AI zwykle rozważa się cztery podstawy przetwarzania danych z art. 6 RODO:

• zgoda osoby, której dane dotyczą (art. 6 ust. 1 lit. a),
• niezbędność do wykonania umowy (lit. b),
• obowiązek prawny ciążący na administratorze (lit. c),
• prawnie uzasadniony interes administratora lub strony trzeciej (lit. f).

Każda z nich „niesie” inny zestaw konsekwencji, jeśli chodzi o trening modelu:

• Zgoda daje wysoki poziom komfortu co do legalności celu, ale wymaga spełnienia rygorów: dobrowolność, konkretność, świadomość, możliwość łatwego wycofania. Przy masowych modelach generatywnych zebranie ważnej zgody od wszystkich właścicieli treści jest często logistycznie nierealne.
• Umowa sprawdza się, gdy model jest bezpośrednio potrzebny do wykonania usługi, za którą użytkownik „płaci” (np. personalizowany rekomender w serwisie VOD). Gorzej działa, gdy trening ma charakter ogólny, a model będzie wykorzystany przy innych klientach niż ten konkretny użytkownik.
• Obowiązek prawny to raczej domena instytucji publicznych i sektorów regulowanych (bankowość, ubezpieczenia, medycyna). Jeżeli szczególny przepis nakazuje wykorzystanie danych np. dla celów nadzoru, raportowania czy badań epidemiologicznych, może on stać się podstawą do trenowania określonych modeli – ale w bardzo wąsko zdefiniowanych ramach.
• Prawnie uzasadniony interes bywa najbardziej elastyczny w biznesie. Umożliwia trenowanie modeli na danych klientów w celu poprawy bezpieczeństwa, jakości usług czy efektywności. Wymaga jednak rzetelnego testu równowagi oraz możliwości skutecznego sprzeciwu.

Dwa podejścia wyraźnie się od siebie odcinają: zgoda i uzasadniony interes. W uproszczeniu: im bardziej trening służy ogólnemu rozwojowi technologii lub usługom dla innych podmiotów, im wyższe ryzyko i szerszy zakres wykorzystania danych – tym bliżej do konieczności zgody albo szczególnej podstawy z przepisów sektorowych. Im bardziej celem jest usprawnienie konkretnej, istniejącej relacji lub zapewnienie bezpieczeństwa – tym częściej można rozważyć uzasadniony interes.

Jak oceniać, czy dana podstawa „udźwignie” trening modelu

Wybór podstawy to nie jest formalność. Kilka praktycznych pytań, które pomagają rozstrzygnąć, co jest realistyczne:

• Jak daleko trening wykracza poza oczekiwania użytkownika? Użytkownik bankowości mobilnej przyjmuje, że jego dane posłużą do wykrywania fraudów; trudniej założyć, że zaakceptował użycie historii transakcji do budowy ogólnego modelu scoringowego sprzedawanego innym instytucjom.
• Czy bez tego treningu jesteś w stanie dostarczyć usługę? Jeżeli model jest rdzeniem usługi (np. automatyczne tłumaczenie w płatnym narzędziu), łatwiej oprzeć się na umowie. Jeśli to poboczny R&D, który przyda się „kiedyś” – zgoda lub uzasadniony interes z testem równowagi.
• Jak wysoki jest wpływ na osoby? Modele oceniające zdolność kredytową, ryzyko zdrowotne czy przydatność do pracy to inna liga niż klasyfikator spamu. Im większy wpływ, tym wyższy próg dla stosowania uzasadnionego interesu i tym częściej wchodzi w grę zgoda albo szczególna regulacja.
• Czy trening obejmuje dane wrażliwe albo dane o dzieciach? Tu uzasadniony interes szybko przestaje wystarczać, a nacisk przesuwa się w kierunku wyraźnej zgody lub przepisów szczególnych (np. badań naukowych, systemu ochrony zdrowia).

Zgoda jako „ostatnia deska ratunku” czy świadomy wybór

Dwa skrajne podejścia pojawiają się w praktyce:

• „Weźmy zgodę na wszystko, będzie bezpieczniej” – kończy się długimi, niezrozumiałymi klauzulami, których nikt nie czyta, a zgoda i tak jest kwestionowana jako niewolna czy niekonkretna.
• „Nigdy nie bierzmy zgody, zawsze da się użyć uzasadnionego interesu” – prowadzi do rozciągania art. 6 ust. 1 lit. f na sytuacje o wysokim ryzyku, gdzie organy nadzorcze spodziewają się albo zgody, albo szczególnej podstawy sektorowej.

Rozsądniejsze podejście jest pośrodku. Zgoda dobrze sprawdza się tam, gdzie:

• trening dotyczy wąskiej grupy osób, z którymi masz realny kontakt (np. panel badawczy, pilotaż modelu dla pracowników firmy),
• dane mają szczególnie wrażliwy charakter, a celem jest eksperymentalny lub badawczy model,
• użytkownik otrzymuje wymierną korzyść z uczestnictwa (np. dostęp do zaawansowanych funkcji beta w zamian za wykorzystanie jego danych w treningu),
• chcesz pozwolić ludziom na realny wybór i testujesz różne warianty wykorzystania ich danych.

Jeśli jednak projekt celuje w masowy, powszechny model oparty na setkach tysięcy użytkowników, a głównym źródłem danych są logi i treści użytkowników w standardowej usłudze – zgoda jako jedyna podstawa bywa iluzją. Zwykle i tak większość danych trafi do modelu bez aktywnego „kliknięcia” przez użytkownika, co prędzej czy później zostanie zakwestionowane.

Uzasadniony interes – kiedy ma sens, a kiedy staje się nadużyciem

Uzasadniony interes jest często pierwszym wyborem w komercyjnych projektach AI, bo pozwala trenować modele bez każdorazowej zgody, ale wymaga trzech elementów:

• rzeczywistego, konkretnego interesu (np. poprawa bezpieczeństwa, optymalizacja działania systemu, rozwój własnych produktów),
• niezbędności – bez danego treningu nie osiągniesz tego celu w praktycznie równoważny sposób,
• przewagi interesu administratora nad interesami i prawami osób – co należy wykazać w testach równowagi (LIA – Legitimate Interest Assessment).

W AI kluczowe jest rozróżnienie dwóch scenariuszy:

• Interes zorientowany na daną relację – np. model antyfraudowy zasilany danymi własnych klientów, usprawnienie wyszukiwarki w serwisie, która ma lepiej rozumieć pytania użytkowników. Tu argument o uzasadnionym interesie jest zwykle mocniejszy, o ile zapewnisz odpowiednią przejrzystość i prawo sprzeciwu.
• Interes zorientowany na ogólny rozwój produktu / rynku – np. trening dużego modelu językowego na prywatnych czatach klientów, aby potem sprzedawać model innym. Tutaj trudno twierdzić, że ten cel był w granicach rozsądnych oczekiwań użytkownika w momencie nawiązywania relacji.

Jeżeli wchodzisz w drugi scenariusz, a dodatkowo pojawiają się dane wrażliwe, profilowanie o poważnych skutkach lub transfery poza EOG – uzasadniony interes staje się bardzo słabą podstawą. W praktyce wymagałby wzmacniających zabezpieczeń: silnej pseudonimizacji, limitowania danych, jasnego prawa sprzeciwu i rzetelnego DPIA.

Kiedy zgoda nie jest potrzebna – typowe scenariusze i granice ryzyka

Modele oparte na danych całkowicie zanonimizowanych lub czysto syntetycznych

Jeżeli trening bazuje na danych, które zostały skutecznie zanonimizowane, albo na danych wygenerowanych syntetycznie bez możliwości powiązania ich z rzeczywistymi osobami, zgoda nie jest potrzebna z punktu widzenia ochrony danych osobowych. Typowe przykłady:

• modele prognozujące obciążenie sieci energetycznej na podstawie silnie zagregowanych danych o zużyciu,
• modele optymalizujące logistykę oparte na symulowanych trasach i ładunkach, tworzonych w oparciu o statystyki, nie o indywidualne kursy kierowców,
• modele językowe uczone na corpora, w których wszelkie elementy umożliwiające identyfikację zostały nieodwracalnie usunięte lub przekształcone (a ryzyko reidentyfikacji zostało oszacowane jako minimalne).

Granica ryzyka pojawia się tam, gdzie „anonimizacja” jest w praktyce odwracalna lub gdy zachowujesz możliwość odniesienia się do oryginalnego źródła. Jeżeli możesz powiedzieć: „to wektor użytkownika X, tylko bez jego imienia”, mówimy o pseudonimizacji, nie o anonimizacji, a RODO wraca do gry.

Trening niezbędny do świadczenia usługi na rzecz użytkownika

W niektórych modelach bezpośredni trening na danych użytkownika jest warunkiem świadczenia usługi, której on oczekuje. Kilka przykładów:

• aplikacja notatek z funkcją inteligentnego wyszukiwania ucząca się na prywatnym zbiorze notatek, ale w ramach konta użytkownika,
• system tłumaczeniowy, który na bieżąco adaptuje się do stylu pisania konkretnego klienta (np. duża kancelaria, która ma określony ton tekstów),
• rekomender treści w serwisie streamingowym, dla którego historia oglądania jest podstawą działania.

Jeżeli trening jest bezpośrednio i ściśle związany z wykonaniem umowy (usługi), a użytkownik może racjonalnie tego oczekiwać, często nie ma potrzeby sięgania po odrębną zgodę. Warunkiem jest jednak, by:

• nie „przeciągać” tej podstawy na inne cele (np. sprzedaż modelu innym firmom),
• zapewnić jasną informację o tym, że system uczy się na danych użytkownika i w jakich granicach,
• przemyśleć opcję ograniczenia personalizacji (np. tryb bez trenowania na danych użytkownika), gdy nie jest to absolutnie kluczowe dla usługi.

Zapewnienie bezpieczeństwa i integralności systemów

Modele AI budowane w celu ochrony bezpieczeństwa systemu IT lub sieci (np. wykrywanie włamań, malware, nieautoryzowanych prób dostępu) zazwyczaj można oprzeć na uzasadnionym interesie lub obowiązku prawnym. Dane treningowe będą obejmować:

• logi dostępu,
• metadane ruchu sieciowego,
• wzorce zachowań mogące sugerować nadużycie.

Organy ochrony danych zwykle uznają bezpieczeństwo informacji i zapobieganie nadużyciom za silny interes administratora, często wspierany dodatkowymi przepisami sektorowymi (np. w finansach, telekomunikacji). Zgoda użytkownika na to, by jego logi posłużyły do trenowania systemu antyfraudowego, jest w takim kontekście zbędna, a nawet problematyczna – umożliwiałaby sprawcy „odmowę” uczestnictwa w mechanizmie bezpieczeństwa.

Granica pojawia się wtedy, gdy pod hasłem „bezpieczeństwa” buduje się modele wykraczające poza ten cel – np. analizujące szczegółowo treści komunikacji w celach marketingowych. Jeśli rzeczywisty cel odrywa się od bezpieczeństwa, nie można dalej powoływać się na tę podstawę.

Ulepszanie istniejącej usługi w rozsądnych oczekiwaniach użytkownika

Wiele przedsięwzięć AI dotyczy „podkręcania” jakości już świadczonych usług: lepszego rankingu wyników, trafniejszych sugestii, automatyzacji procesów obsługi klienta. Użytkownik, korzystając z usługi cyfrowej, często zakłada, że jego dane zostaną użyte do takiego ulepszania, o ile nie wykracza ono poza kontekst relacji.

Przykłady, gdzie uzasadniony interes bywa akceptowalny bez odrębnej zgody:

• trening chatbotów obsługi klienta na zanonimizowanych transkryptach rozmów, aby szybciej odpowiadały na typowe pytania,
• analiza historii wyszukiwań na stronie, by poprawić istotność wyników i układ nawigacji,
• klasyfikacja zgłoszeń serwisowych po to, by szybciej kierować je do odpowiednich zespołów.

Pod warunkiem, że dane nie są później wykorzystywane do nieoczekiwanych celów (np. „podszywany” profil marketingowy w innej usłudze) i że nie obejmuje to systematycznego przetwarzania danych wrażliwych, zgoda nie jest zwykle wymagana. Znaczenie ma też możliwość sprzeciwu – użytkownik powinien móc powiedzieć „nie chcę, żeby moje rozmowy zasilały wasz model”, bez utraty podstawowych funkcji usługi.

Kiedy zgoda jest konieczna lub wysoce rekomendowana

Eksperymentalne projekty o wysokim ryzyku

Trening modeli w eksperymentalnych, wysokoryzykownych obszarach (np. predykcja chorób psychicznych na podstawie wzorców korzystania z telefonu, analiza głosu pod kątem diagnozy medycznej) niemal zawsze powinien opierać się na wyraźnej, świadomej zgodzie. Trudno bowiem uznać, że przeciętny użytkownik oczekuje, iż jego „cyfrowe ślady” posłużą do tak głębokiej analizy.

W takich projektach zgoda jest nie tylko formalnym wymaganiem, ale też elementem etycznym. Osoba powinna:

• znać cel (np. badania naukowe nad określoną chorobą),
• rozumieć rodzaj wykorzystywanych danych (np. treści wiadomości, sygnały z czujników),
• mieć prawo wycofać udział bez konsekwencji w innych obszarach (np. wciąż korzystać ze standardowej wersji aplikacji).

Przetwarzanie danych wrażliwych poza ścisłym reżimem prawnym

Dane wrażliwe (szczególne kategorie danych, o których mowa w art. 9 RODO) zasadniczo wymagają wyraźnej zgody, chyba że przetwarzanie mieści się w jednym z wąskich wyjątków: medycyna, prawo pracy, ochrona socjalna, interes publiczny w dziedzinie zdrowia, badania naukowe w oparciu o krajowy reżim itp. W projektach komercyjnych, nastawionych na rozwój produktów lub usług masowych, te wyjątki rzadko wchodzą w grę.

Typowe obszary, gdzie wyraźna zgoda staje się faktycznie jedyną realną podstawą:

• analiza treści rozmów z psychologiem online w celu trenowania systemu wsparcia emocjonalnego,
• trening modeli rozpoznawania chorób skóry na zdjęciach wysyłanych przez pacjentów poza kontekstem świadczeń zdrowotnych (np. aplikacja „beauty + health”),
• klasyfikacja orientacji seksualnej, przekonań religijnych czy politycznych na podstawie aktywności w serwisie społecznościowym, jeżeli administrator ma świadomość, że takie wnioski są wyprowadzane i wykorzystywane.

W porównaniu z „klasycznymi” danymi osobowymi różnica jest zasadnicza: przy danych wrażliwych pole manewru dla uzasadnionego interesu czy wykonania umowy jest mocno ograniczone. Zgoda powinna być:

• wyraźna – nie wystarczy ogólne zaakceptowanie regulaminu; przydają się oddzielne checkboxy lub logicznie odrębny ekran,
• szczegółowa – wskazująca na trening modeli jako konkretny cel, a nie ogólnik „rozwój usług cyfrowych”,
• odwracalna – z jasną informacją, co dzieje się z danymi już użytymi do treningu (np. brak dalszego użycia w nowych iteracjach modeli, możliwość usunięcia rekordów ze zbiorów treningowych, gdy jest to technicznie wykonalne).

Jeżeli za wszelką cenę chcesz uniknąć oparcia się na zgodzie, równanie jest inne niż przy zwykłych danych. Potrzebny jest albo bardzo konkretny przepis szczególny (np. prawo krajowe wdrażające art. 9 ust. 2 lit. j RODO – badania naukowe), albo tak głęboka pseudonimizacja/anonimizacja, że z projektu de facto znika element przetwarzania danych wrażliwych w rozumieniu RODO.

Modele „ekspansywne”: wyjście poza relację z użytkownikiem

Gdy model przestaje być wewnętrznym narzędziem ulepszającym usługę, a staje się samodzielnym produktem (np. API sprzedawane innym firmom, gotowy model udostępniany na marketplace), relacja prawna istotnie się zmienia. Dane użytkownika nie pracują już tylko „dla niego” ani nawet wyłącznie w relacji B2C, lecz karmią produkt rynkowy.

Można porównać dwa scenariusze:

• Scenariusz zamknięty – operator serwisu e‑commerce trenuje silnik rekomendacji wyłącznie na potrzeby własnej platformy; dane nie wychodzą na zewnątrz, model nie jest licencjonowany innym. Tu uzasadniony interes ma solidne argumenty, o ile użytkownik jest poinformowany i ma prawo sprzeciwu.
• Scenariusz otwarty – ta sama firma buduje „generyczny” silnik rekomendacji i oferuje go jako usługę SaaS dla innych sklepów, a dane dotychczasowych klientów stają się „paliwem” do produktu B2B. W takim wariancie trudno obronić brak zgody, zwłaszcza jeśli trening obejmuje treści, które konsumenci postrzegali jako prywatne (np. wiadomości z supportem, historię zakupów wrażliwych produktów).

Zgoda jest tutaj mocno rekomendowana nie tylko ze względów prawnych, ale też reputacyjnych. Świadomość, że „moja historia czatów posłużyła do zbudowania komercyjnego bota, z którego korzystają inni”, jest przez wielu użytkowników odbierana jako przekroczenie granicy – nawet jeśli dane zostały zanonimizowane technicznie. Komunikacyjne i etyczne ryzyko bywa wyższe niż ryzyko formalnego naruszenia RODO.

Personalizacja „rozszerzona” i profilowanie o poważnych skutkach

Standardowa personalizacja – dopasowanie kolejności treści, prosty scoring doboru reklam – zwykle da się uzasadnić interesem administratora, o ile w grę nie wchodzą dane wrażliwe i profilowanie nie wywołuje skutków opisanych w art. 22 RODO. Problem zaczyna się wtedy, gdy model zaczyna wpływać na sytuację prawną lub ekonomiczną osoby w sposób trudny do odwrócenia.

Przykłady, przy których zgoda jest co najmniej wskazana, a często konieczna (obok spełnienia dodatkowych wymogów z art. 22):

• system ustalający limity kredytowe w oparciu o szeroką analizę zachowań online (nie tylko danych z wniosku kredytowego),
• algorytm oceniający „wiarygodność najemcy” na podstawie jego aktywności w portalach społecznościowych i serwisach ogłoszeniowych,
• model uczący się z historii czatów i maili w celu oceny „stabilności emocjonalnej” pracownika lub kandydata.

W odróżnieniu od lekkiej personalizacji treści, tutaj konsekwencje mogą być bardzo realne: od odmowy umowy, przez negatywną ocenę w pracy, po nieprzedłużenie współpracy. Uzasadniony interes lub wykonanie umowy są w takich konfiguracjach słabą tarczą, bo trudno przekonująco wykazać, że osoba „mogła racjonalnie oczekiwać” tak głębokiej analizy i że nie narusza to równowagi praw.

Zgoda – o ile nie ma asymetrii uniemożliwiającej jej uznanie za dobrowolną (np. w stosunku pracodawca–pracownik) – pełni tu rolę świadomej zgody na silne, automatyczne oddziaływanie decyzji AI na sytuację osoby. Jeżeli nie możesz realnie zaoferować alternatywy bez profilowania (np. „konto bez algorytmicznego scoringu”), trudno obronić tezę o dobrowolności zgody i trzeba rozważyć inną konstrukcję całego procesu.

Przetwarzanie w kontekście pracy – gdy relacja jest nierówna

Dane pracowników i kandydatów są szczególnie problematyczne z punktu widzenia zgody. RODO w motywie 43 wprost sygnalizuje, że w sytuacjach wyraźnej nierównowagi (jak stosunek pracy) zgoda rzadko jest dobrowolna. Tymczasem projekty AI w HR kuszą wieloma zastosowaniami: analiza CV, scoring kandydatów, monitoring produktywności, predykcja „ryzyka odejścia”.

Można wyróżnić trzy pułki projektów:

• projekty niskiego ryzyka – np. model sortujący CV pod kątem dopasowania do wymogów ogłoszenia, bazujący na danych, które i tak są publicznie przekazywane przez kandydata. Często wystarczy tu uzasadniony interes, o ile nie używasz dodatkowych źródeł typu social media bez informowania osoby,
• projekty średniego ryzyka – np. analiza wewnętrznej komunikacji tekstowej, by identyfikować wąskie gardła w procesach; wymaga bardzo ostrożnej oceny LIA i przejrzystej komunikacji, niekiedy lepiej sięgnąć po dobrowolne opt‑in w określonych modułach,
• projekty wysokiego ryzyka – systemy oceny wydajności, narzędzia przewidujące „skłonność do odejścia” na podstawie wzorców zachowania, analiza nastrojów z kamer; tu zgoda jest z reguły niewystarczająca (bo nie będzie dobrowolna) i projekt wymaga albo silnego umocowania w prawie, albo rezygnacji z najbardziej inwazyjnych funkcji.

Jeżeli mimo wszystko rozważasz zgodę w kontekście pracowniczym (np. w programach pilotażowych, badaniach UX z udziałem pracowników), musi być ona rzeczywiście opcjonalna: brak zgody nie może w praktyce wpływać na ocenę, awanse czy atmosferę w zespole. Lepiej zbudować proces z udziałem ochotników niż pozornie obejmować „zgodą” całą populację pracowników.

Web scraping, serwisy społecznościowe i treści publiczne – zgoda czy nie?

Treści „publiczne” a treści „dostępne publicznie” – istotne rozróżnienie

W kontekście danych treningowych często pada argument: „to jest publiczne w internecie, więc mogę to zebrać i użyć bez zgody”. RODO i orzecznictwo idą tu inną drogą. Co innego treści faktycznie upublicznione z założeniem szerokiego odbioru (np. blog, publiczny profil zawodowy), a co innego treści jedynie technicznie dostępne po zalogowaniu lub w niszowych społecznościach.

Prosty podział wygląda tak:

• treści intencjonalnie publiczne – np. artykuły prasowe, wpisy na otwartych blogach, publiczne repozytoria kodu z licencjami zezwalającymi na ponowne wykorzystanie. Tu podstawą może być uzasadniony interes, o ile respektujesz warunki licencyjne i prawa autorskie,
• treści quasi‑publiczne – np. posty w otwartych grupach na platformach społecznościowych, komentarze pod artykułami, które w praktyce są indeksowane w wyszukiwarkach. Uzasadniony interes bywa tu obroniony, ale wymaga lepszego ważenia interesów i oceny oczekiwań użytkowników,
• treści dostępne pośrednio – np. posty widoczne tylko dla „znajomych”, treści na forach wymagających członkostwa, prywatne kanały komunikacji. Tutaj korzystanie z web scrapingu jako podstawy treningu modeli bez zgody staje się wysoce ryzykowne.

Kluczowe pytanie nie brzmi: „czy mogę to technicznie pobrać?”, lecz: „jak osoba rozsądna oceniłaby zakres audytorium i cel publikacji?”. Jeżeli profil na portalu społecznościowym ma ustawienie „publiczny”, ale jest wyraźnie prywatny (zdjęcia dzieci, problemy zdrowotne), argument, że właściciel „musiał się liczyć” z treningiem modeli reklamowych czy rozpoznawania twarzy, jest co najmniej dyskusyjny.

Podstawy prawne przy web scrapingu – zgoda, uzasadniony interes, licencje

W praktyce projekty korzystające z web scrapingu balansują między trzema filarami: RODO, prawem autorskim i warunkami korzystania (ToS) danej platformy. Zgoda osoby, której dane dotyczą, rzadko jest realnie uzyskiwalna w skali masowej, więc administratorzy próbują oprzeć się na innych podstawach.

Porównując podejścia:

• zgoda jednostkowa – w przypadku scrapowania jest prawie niewykonalna operacyjnie (trudno zebrać zgody od tysięcy autorów wpisów), ale bywa stosowana w niszowych projektach, np. z ograniczoną społecznością, gdzie użytkownicy akceptują osobny regulamin „treningowy”,
• uzasadniony interes – najczęstszy wybór przy trenowaniu modeli na dużych zbiorach danych publicznych. Wymaga jednak:
  • jasnego określenia celu (np. badawczy vs. komercyjny),
  • realnego testu równowagi – czy trening nie narusza nadmiernie prywatności,
  • wdrożenia mechanizmów opt‑out (np. usuwanie danych na żądanie, blokowanie określonych domen),
  • poszanowania ustawień prywatności i sygnałów typu robots.txt (przynajmniej jako wskaźnika intencji właściciela treści).
• licencje i zgody kontraktowe – osobna, ale kluczowa oś: zgoda właściciela serwisu (B2B) na użycie treści do celów treningowych. Nawet jeśli z punktu widzenia RODO uzasadniony interes jest poprawny, naruszenie regulaminu platformy może oznaczać odpowiedzialność kontraktową, a w skrajnych przypadkach także delikt.

Zgoda osoby, której dane dotyczą, jest więc w scrapingowych projektach raczej wyjątkiem niż regułą. Tam, gdzie jednak dane są szczególnie wrażliwe albo ich skala przetwarzania jest ekstremalnie szeroka (np. masowe scrapowanie profili osobistych, by uczyć model rozpoznawania orientacji seksualnej lub poglądów politycznych), brak zgody przenosi projekt w strefę wysokiego ryzyka prawnego i etycznego.

Serwisy społecznościowe a „akceptacja regulaminu” – czy to już zgoda?

Często spotykany argument: skoro użytkownik zaakceptował regulamin platformy społecznościowej, w którym zapisano możliwość udostępniania danych partnerom, to partnerzy mogą wykorzystywać te dane do trenowania swoich modeli bez odrębnej zgody. Z perspektywy RODO taki wniosek jest zbyt daleko idący.

Różnica między tymi sytuacjami jest istotna:

• zgoda na warunki korzystania z usługi – dotyczy przede wszystkim relacji użytkownik–platforma i pozwala na określone przetwarzanie w kontekście tej usługi,
• zgoda na cele treningowe partnerów – to osobny cel przetwarzania, często różny od pierwotnego powodu korzystania z platformy (utrzymywanie kontaktu, dzielenie się treściami).

Jeżeli chcesz bazować na danych pozyskanych z serwisu społecznościowego, a opierasz się wyłącznie na „szerokiej” zgodzie udzielonej platformie, z punktu widzenia RODO to ciągle twoje własne przetwarzanie, dla którego musisz wskazać autonomiczną podstawę prawną. Uzasadniony interes może być do obrony, ale tylko wtedy, gdy:

• cel treningu pozostaje w sensownym związku z oczekiwaniami użytkowników (np. analiza publicznych profili zawodowych w serwisie stricte biznesowym pod kątem rekrutacji),
• nie dochodzi do dalszej, zaskakującej segmentacji (np. profilowanie polityczne na podstawie „lajków” w serwisie o lekkim charakterze rozrywkowym),