Zgoda na dane w AI: kiedy wystarczy anonimizacja, a kiedy nie?

Po co w ogóle zgoda i anonimizacja w projektach AI?

Osoba projektująca rozwiązania AI chce zrozumieć przede wszystkim, na jakiej podstawie prawnej może oprzeć przetwarzanie danych i jak daleko musi posunąć się z anonimizacją, żeby nie narazić się na zarzut naruszenia prywatności. Kluczowe jest rozróżnienie, kiedy można pozostać przy bezpiecznie zanonimizowanych danych, a kiedy konieczna jest zgoda lub inna, mocniejsza podstawa prawna.

Zgoda a inne podstawy z art. 6 RODO w kontekście AI

RODO nie narzuca jednego, uniwersalnego fundamentu przetwarzania danych w AI. Z perspektywy prawa trenowanie, testowanie i wdrażanie modeli to po prostu kolejne formy przetwarzania danych osobowych. Podstawą mogą być w szczególności:

• zgoda osoby (art. 6 ust. 1 lit. a RODO) – gdy użytkownik wyraźnie akceptuje wykorzystanie swoich danych w określonym celu AI,
• wykonanie umowy (lit. b) – gdy usługa AI jest niezbędna do świadczenia zamówionej usługi (np. spersonalizowany asystent w aplikacji),
• obowiązek prawny (lit. c) – rzadziej wprost w AI, ale występuje np. w systemach raportowania do organów nadzoru,
• żywotne interesy (lit. d) – sytuacje wyjątkowe, np. systemy predykcji zagrożeń dla zdrowia i życia,
• zadanie realizowane w interesie publicznym (lit. e) – np. modele wykorzystywane przez administrację publiczną,
• uzasadniony interes administratora (lit. f) – najczęstsza podstawa w komercyjnych projektach AI, o ile nie przeważają interesy lub prawa osób.

Najczęstsza pułapka polega na tym, że zespół AI traktuje zgodę jako „złoty bilet” na wszystko. Tymczasem zgoda bywa chwiejną podstawą: można ją wycofać, bywa nieważna (bo nie była konkretna lub dobrowolna), a w relacjach zależności (np. pracownik–pracodawca) jest wręcz kwestionowana przez organy nadzorcze. Często bezpieczniejszym fundamentem jest uzasadniony interes, pod warunkiem dobrze wykonanej analizy równowagi interesów oraz ograniczenia zakresu danych.

Dlaczego projekty AI są bardziej wrażliwe na prywatność niż klasyczne IT

Systemy AI różnią się od klasycznych systemów IT w kilku kluczowych aspektach, które zwiększają ryzyko naruszenia prywatności:

• Skala danych – modele, zwłaszcza duże modele językowe, „pochłaniają” ogromne ilości informacji z wielu źródeł. Nawet jeśli pojedynczy rekord nie wydaje się wrażliwy, łączenie tysięcy czy milionów rekordów otwiera drogę do profilowania i reidentyfikacji.
• Charakter uczenia – tradycyjna baza danych przechowuje rekordy wprost, podczas gdy model AI „destyluje” wzorce. Jednak w wielu architekturach (np. modele generatywne) wciąż istnieje ryzyko, że model będzie odtwarzał konkretne fragmenty danych treningowych (np. dane osobowe pojawiające się w promptach lub outputach).
• Brak pełnej przewidywalności – trudno z góry określić wszystkie możliwe kombinacje wejść i wyjść modelu. To oznacza, że ryzyko ujawnienia danych osobowych pojawia się nie tylko w momencie trenowania, ale i na etapie używania modelu.
• Łączenie źródeł – projekty AI często integrują dane z różnych systemów (CRM, logi aplikacji, dane behawioralne, dane publiczne), co zwiększa ryzyko, że z pozornie anonimowych fragmentów powstanie profil konkretnej osoby.

Stąd nacisk regulatorów i etyków na privacy by design w AI: ochrona danych musi być wbudowana w architekturę modelu już od etapu projektowania, a nie dokładana na końcu jako „łatka”.

Cele anonimizacji w projektach AI

Anonimizacja w AI nie jest celem samym w sobie. Służy przede wszystkim trzem celom:

• Redukcja ryzyka dla osób – transformacja danych w taki sposób, aby nie można było sensownie powiązać ich z konkretną osobą przy użyciu „rozsądnie dostępnych środków”.
• Zwolnienie spod RODO – jeśli dane zostaną skutecznie zanonimizowane, przestają być danymi osobowymi, a więc przestają podlegać RODO. Otwiera to większą swobodę trenowania i udostępniania modeli.
• Budowanie zaufania – użytkownicy coraz częściej pytają, jak ich dane są wykorzystywane w AI. Pokazanie, że dane są anonimowe, a nie tylko „zaszyte w modelu”, bywa silnym argumentem w transparentnej komunikacji.

Z drugiej strony, nadmierna anonimizacja może obniżyć wartość danych. Kluczowym zadaniem projektanta jest znalezienie punktu równowagi pomiędzy użytecznością a prywatnością.

Porównanie: raportowanie statystyczne vs trenowanie dużego modelu

Dobrym obrazem różnicy jest zestawienie prostego raportowania z trenowaniem dużego modelu językowego:

W raportowaniu można łatwiej zastosować agregację i anonimizację tak, aby dane przestały być osobowe. W modelach językowych lub innych systemach generatywnych samo „przepuszczenie danych przez sieć neuronową” nie czyni ich z automatu anonimowymi.

Dane osobowe w AI – kiedy dane „dotyczą osoby”?

Zanim pojawi się pytanie o zgodę czy anonimizację, trzeba odpowiedzieć na bardziej podstawowe: czy to w ogóle są dane osobowe w rozumieniu RODO? W AI ta granica bywa zaskakująco płynna.

Definicja danych osobowych a dane wejściowe i wyjściowe modeli

Zgodnie z RODO danymi osobowymi są wszelkie informacje o zidentyfikowanej lub możliwej do zidentyfikowania osobie fizycznej. Kluczowy jest tu konkretny kontekst – to, co dla jednego administratora jest anonimową informacją, dla innego może być łatwo łączone z konkretnym użytkownikiem.

W świecie AI dane osobowe mogą pojawiać się na dwóch poziomach:

• Dane wejściowe (input) – np. teksty rozmów z chatbotem, pliki przesyłane do analizy, logi z aplikacji, opisy przypadków medycznych, dane klientów z CRM, komentarze z social mediów.
• Dane wyjściowe (output) – odpowiedzi modelu, wygenerowane raporty, rekomendacje, klasyfikacje (np. „wysokie ryzyko rezygnacji”), nawet jeśli nie zawierają imienia i nazwiska.

Jeżeli na wejściu model otrzymuje dane osobowe, to ich uczenie jest co do zasady przetwarzaniem danych osobowych. Co więcej, jeśli output można odnieść do konkretnej osoby (np. id klienta, login, kombinacja cech opisujących jednostkę), to również stanowi dane osobowe – nawet kiedy sam model wewnętrznie posługuje się abstrakcyjnymi wektorami i wagami.

Granica między danymi osobowymi a informacją ogólną

W praktyce projekty AI często operują na danych, które „na pierwszy rzut oka” nie wyglądają jak dane osobowe. Przykłady:

• imię + miasto + zawód (bez nazwiska),
• id urządzenia + godziny aktywności,
• wynik testu psychometrycznego bez nazwiska, ale z unikalnym identyfikatorem,
• historia kliknięć przypisana do „użytkownika 5278”.

Jeżeli administrator (lub podmiot przetwarzający) ma realną możliwość powiązania tych informacji z konkretną osobą, to są to dane osobowe, nawet jeśli w danym pliku nie pada ani jedno nazwisko. Ryzyko pomyłek rośnie w AI, ponieważ:

• łatwo połączyć dane z wielu źródeł (np. dane z aplikacji + dane z Google Analytics + dane zakupowe),
• nawet unikalna kombinacja cech (wiek, lokalizacja, zachowanie) może umożliwić identyfikację w wąskiej grupie (np. w małej miejscowości),
• często istnieją klucze techniczne (ID, tokeny, identyfikatory sesji), które umożliwiają odtworzenie tożsamości.

Informacja staje się „nieosobowa” dopiero wtedy, gdy nie da się zidentyfikować osoby przy użyciu środków, które można racjonalnie uznać za dostępne dla administratora lub kogokolwiek, komu dane są lub mogą być przekazane.

Dane osobowe ukryte pośrednio: embeddingi, logi, metadane

Nowe architektury AI wprowadzają typy danych, które na poziomie technicznym wyglądają neutralnie, ale mogą nieść w sobie treść osobową:

• Embeddingi – wektory liczb reprezentujące treści tekstowe, obrazy czy dźwięk. Choć same wektory nie zawierają „słowa po słowie” danych osobowych, przy odpowiedniej wiedzy o architekturze i parametrach modelu można z nich czasem wydobyć informacje o osobach, zwłaszcza gdy embedding reprezentuje krótkie, unikalne frazy.
• Logi techniczne – adresy IP, znaczniki czasu, identyfikatory sesji, parametry żądań. W połączeniu z innymi źródłami często pozwalają odtworzyć aktywność konkretnego użytkownika.
• Dane telemetryczne – np. jak często użytkownik korzysta z danej funkcji AI, jakie komendy wpisuje, z jakiej lokalizacji. Takie strumienie danych mogą służyć profilowaniu zachowań.

Jeśli zespół AI traktuje te zasoby jako „czysto techniczne” i wyłącza je z reżimu ochrony danych, powstaje realne ryzyko naruszenia RODO. W praktyce wiele projektów wymaga podejścia, w którym embeddingi, logi i metadane są traktowane co najmniej jako dane pseudonimizowane, dopóki nie zostanie wykazane coś przeciwnego.

Formularze online vs masowe scrapowanie Internetu

Różnicę dobrze ilustruje porównanie dwóch sytuacji:

• Prosty formularz na stronie, w którym użytkownik wpisuje imię, nazwisko, e-mail i udziela zgody na „otrzymywanie newslettera”. Dane trafiają do bazy mailingowej, z której czasem korzysta prosty model rekomendujący treść newsletterów.
• Masowe scrapowanie Internetu na potrzeby trenowania dużego modelu językowego, obejmujące komentarze na forach, wpisy w social media, treści blogów i artykułów, gdzie pojawiają się imiona, nazwiska, dane kontaktowe, konteksty zdrowotne, poglądy polityczne.

W pierwszym przypadku zakres danych, cel przetwarzania i obszar działania modelu są stosunkowo łatwe do kontrolowania. Można przeprowadzić anonimizację (np. pozostawić jedynie metadane o otwieraniu newsletterów) i stosunkowo prosto wyjaśnić użytkownikowi, co dzieje się z jego danymi.

W drugim przypadku ogromna skala i różnorodność danych sprawia, że niemal na pewno w zbiorze treningowym znajdą się dane osobowe i dane szczególnych kategorii. Anonimizacja jest trudna i kosztowna, bo wymaga zaawansowanych technik (filtry NER, rozpoznawanie nazw własnych, klasyfikacja wrażliwości treści) i ciągłego monitorowania wyników. Często pojawia się też pytanie, czy samo masowe scrapowanie jest legalne bez wyraźnej zgody lub innej, bardzo dobrze uzasadnionej podstawy prawnej.

Anonimizacja, pseudonimizacja, agregacja – co czym jest i co daje?

Przy planowaniu zgody na przetwarzanie danych w AI trzeba jasno rozróżnić trzy pojęcia, które w języku potocznym bywają mylone: anonimizacja, pseudonimizacja, agregacja. Od ich prawidłowego zrozumienia zależy, czy projekt rzeczywiście wychodzi spod RODO, czy tylko sprawia takie wrażenie.

Anonimizacja – kiedy dane przestają być osobowe

Anonimizacja to proces przekształcenia danych w taki sposób, aby osoby fizyczne nie były możliwe do zidentyfikowania w sposób bezpośredni ani pośredni, przy użyciu „wszelkich prawdopodobnie wykorzystanych środków”. Oznacza to, że:

• nie ma już bezpośrednich identyfikatorów (imienia, nazwiska, PESEL, numeru telefonu itd.),

Typowe techniki anonimizacji stosowane w projektach AI

W praktyce zespoły AI korzystają z mieszanki kilku mechanizmów, które różnią się skutkami prawnymi i ryzykiem reidentyfikacji. Kluczowe jest nie tylko „wycięcie nazwisk”, ale też ocena, czy po transformacji nadal można odtworzyć konkretne osoby.

• Maskowanie i redakcja (redaction) – usunięcie lub zamiana wrażliwych fragmentów (np. „Jan Kowalski” na „[OSOBA]”). Dobrze działa na tekstach, ale przy zbyt dosłownej zamianie model może nadal „nauczyć się” kontekstu pozwalającego na zidentyfikowanie osoby (np. unikalnych historii przypadków).
• Generalizacja – zmiana poziomu szczegółowości (wiek 37 → „35–40”, miasto → „województwo”). Ogranicza ryzyko, ale w małych populacjach (np. niszowe specjalizacje lekarskie w małym mieście) nadal może prowadzić do rozpoznania jednostek.
• Usuwanie rzadkich wartości – eliminacja rekordów o niestandardowych kombinacjach cech, które „wyróżniają” daną osobę (np. bardzo rzadki zawód + wyjątkowa choroba + mała miejscowość).
• Dodawanie szumu – drobne zniekształcanie liczb (np. wynagrodzenia, czasów trwania sesji), tak aby utrzymać przydatność statystyczną przy obniżeniu dokładności na poziomie jednostki.

Prosty filtr nazw własnych i PESEL-u zazwyczaj nie wystarczy, gdy mówimy o trenowaniu złożonych modeli. W wielu zastosowaniach trzeba łączyć kilka technik i oceniać ich skuteczność testami próbującymi „odgadnąć” konkretną osobę na podstawie pozostałych cech.

Pseudonimizacja – zmiana identyfikatora, nie charakteru danych

Pseudonimizacja to zastąpienie bezpośrednich identyfikatorów (imię, nazwisko, email) innymi znacznikami (np. losowym ID). Dla RODO to nadal dane osobowe, bo administrator lub procesor zwykle przechowuje klucz, który pozwala cofnąć operację.

W projektach AI pseudonimizacja jest często pierwszym krokiem „higienicznym”:

• w logach i zbiorach treningowych nie pojawiają się jawne nazwiska czy adresy e‑mail,
• łatwiej ograniczyć wgląd do powiązań „ID → osoba” tylko do wąskiego grona (np. zespołu data governance),
• można częściowo zredukować skutki ewentualnego wycieku (atakujący nie zna mapowania ID).

Między anonimizacją a pseudonimizacją różnica jest zasadnicza: pseudonimizacja nie wyłącza RODO. Wymagane są podstawy prawne, obowiązki informacyjne, analizy ryzyka, a przy bardziej wrażliwych projektach – ocena skutków (DPIA).

Agregacja – dane o grupach zamiast danych o jednostkach

Agregacja polega na takim przetwarzaniu, aby wynik dotyczył grupy osób, a nie konkretnej jednostki. Przykłady to: średnie, sumy, rozkłady procentowe, rozbicia na segmenty.

Najczęściej wykorzystuje się trzy formy agregacji:

• Agregacja prosta – np. „średnia liczba zamówień na użytkownika w danym mieście”. Jeśli liczba użytkowników jest wysoka, zwykle nie ma ryzyka identyfikacji.
• Agregacja z progami minimalnymi – publikacja statystyk tylko dla grup o liczebności co najmniej N (np. ≥ 20 osób). To redukuje ryzyko, że ktoś rozpozna konkretną osobę w „wąskim” segmencie.
• Agregacja wielowymiarowa – łączenie kilku cech (wiek, region, typ produktu). Im więcej wymiarów, tym większe ryzyko, że część kombinacji będzie unikalna i znów zacznie „dotyczyć osoby”, a nie grupy.

W kontekście AI agregację stosuje się głównie po stronie raportowania i ewaluacji modelu (np. wyniki według segmentów klientów). Rzadziej nadaje się ona jako wejście do sama w sobie „inteligentnego” modelu, który musi znać zachowania na poziomie jednostek, aby dobrze rekomendować lub prognozować.

Gdzie przebiega granica: agregacja a pozorna anonimizacja

Częsta pułapka polega na zakładaniu, że „skoro raport jest zbiorczy, to nie ma tam danych osobowych”. Problem pojawia się, gdy:

• segmenty są bardzo małe (np. 3 osoby w danej kombinacji cech),
• dostęp do raportu ma ktoś, kto zna otoczenie (np. lokalny menedżer wie, że w jego zespole tylko jedna osoba pasuje do opisu „powyżej 60 lat, praca zdalna, niepełny etat”).

Efekt: raport formalnie jest zagregowany, lecz w praktyce ujawnia dane o konkretnych osobach. Taki materiał nadal może być traktowany jako zawierający dane osobowe, a więc wymaga odpowiedniej podstawy prawnej i ochrony.

Kiedy anonimizacja wystarczy: sytuacje o niskim ryzyku i danych niewrażliwych

W niektórych projektach można faktycznie oprzeć się wyłącznie na porządnej anonimizacji i nie angażować zgody czy innych podstaw z art. 6 RODO. Warunkiem jest jednak kombinacja kilku czynników: rodzaj danych, cele, architektura systemu i kontrola nad dostępem.

Proste analizy statystyczne i raportowanie biznesowe

Najbliżej „bezpiecznej strefy” są klasyczne przypadki analityczne:

• modele prognozujące na poziomie produktu, regionu, kanału sprzedaży, gdzie dane szkoleniowe są przed użyciem zanonimizowane i zagregowane,
• systemy monitoringu jakości, które liczą wskaźniki globalne (np. czas odpowiedzi chatbotów, średni czas realizacji zgłoszeń) bez przechowywania identyfikatorów osób.

Jeżeli w zbiorze treningowym i w wynikach nie da się wyróżnić jednostki i nie ma żadnego „tylnego wejścia” (np. klucza pozwalającego cofnąć transformacje), to z perspektywy RODO przestajemy mieć do czynienia z danymi osobowymi. Wówczas nie jest wymagana osobna zgoda, bo regulacja po prostu nie ma zastosowania.

Modele uczone na danych zanonimizowanych ex ante

Inny scenariusz to projekty, w których dane są anonimizowane jeszcze przed przekazaniem ich zespołowi AI. Przykładowo:

• dział HR generuje tablice z informacjami o wynagrodzeniach i awansach, usuwając wszelkie identyfikatory i redukując liczebność w małych grupach,
• szpital przekazuje firmie technologicznej dane o skuteczności terapii w postaci zbiorczych statystyk, bez możliwości odtworzenia historii pojedynczego pacjenta.

Jeżeli dostawca AI nie posiada i nie może uzyskać kluczy pozwalających połączyć rekordy z konkretnymi osobami, a dane są odpowiednio „rozmyte”, to ich przetwarzanie może być kwalifikowane jako operowanie na danych anonimowych. W takiej konfiguracji to na stronie pierwotnego administratora leży obowiązek zapewnienia, że proces anonimizacji był rzetelny.

Modele na danych syntetycznych z kontrolą jakości anonimizacji

Dane syntetyczne to atrakcyjna droga pośrednia między pełnym dostępem do danych osobowych a całkowitym ich brakiem. Powstają poprzez generowanie „sztucznych” rekordów na podstawie rozkładów i korelacji z danych źródłowych.

Jako podstawa do uniknięcia zgody sprawdzają się wtedy, gdy:

• istnieją procedury testowania, że żadna wygenerowana próbka nie jest zbyt podobna do realnej (np. odległość w przestrzeni cech, testy k-anonimowości),
• dostawca AI nie przechowuje oryginalnych danych osobowych lub ma do nich bardzo ograniczony, ściśle kontrolowany dostęp,
• modele końcowe nie umożliwiają inferencji zwrotnej, czyli „odgadnięcia” cech realnych osób na podstawie syntetycznych wyników.

Plus syntetycznych danych to mniejsze obciążenie formalne (często brak konieczności zgody), ale minus – ryzyko utraty części niuansów występujących w danych realnych, co może obniżać jakość modelu.

Systemy o ograniczonym interfejsie i nadzorowanym dostępie

Anonimizacja lepiej spełnia swoje zadanie tam, gdzie użytkownik systemu AI nie ma swobody zadawania dowolnych pytań:

• pulpity menedżerskie z predefiniowanymi widokami (np. tylko dane zagregowane, bez drill‑downu do poziomu klienta),
• modele scoringowe, które zwracają jedynie klasy ryzyka dla anonimowych przypadków, bez możliwości „podglądu” pełnego rekordu.

Im mniej elastyczny interfejs, tym łatwiej zagwarantować, że nawet jeśli w tle działa skomplikowany model, na zewnątrz nie „wypłyną” informacje, które można przypisać konkretnym osobom. W takich konstrukcjach często da się oprzeć projekt w całości na danych zanonimizowanych lub zagregowanych, bez sięgania po zgody.

Kiedy anonimizacja nie wystarczy: zgoda lub inna podstawa prawna

Wiele zastosowań AI dotyka obszarów, w których całkowita anonimizacja byłaby sprzeczna z celem systemu albo po prostu niewykonalna na rozsądnym poziomie kosztów. Wtedy nie da się „uciec” przed reżimem RODO i trzeba oprzeć się na jednej z podstaw prawnych, często z silną rolą zgody.

Personalizacja, rekomendacje i profilowanie użytkowników

Systemy, które mają personalizować doświadczenie użytkownika, z definicji operują na poziomie jednostki:

• rekomendacje produktów, treści, kursów,
• dynamiczne ustalanie cen lub ofert (np. zniżki, pakiety),
• segmentacja klientów na potrzeby kampanii marketingowych.

Anonimizacja zabijałaby w nich podstawowy sens – model musi znać historię zachowań, preferencje i czasem dane demograficzne konkretnego użytkownika, aby działać efektywnie. W takich scenariuszach trzeba oprzeć się na:

• zgodzie marketingowej (szczególnie dla kanałów elektronicznych) – bardziej w relacji do prawa telekomunikacyjnego i ustawy o świadczeniu usług,
• uzasadnionym interesie administratora, przy zbalansowaniu interesów i danych niewrażliwych,
• w niektórych przypadkach – dodatkowej, wyraźnej zgodzie na profilowanie, jeśli jego skutkiem są istotne decyzje wobec osoby.

Sam fakt wykorzystania AI nie zmienia reguł gry – jeśli wcześniej klasyczny system rekomendacyjny opierał się na uzasadnionym interesie i dawał użytkownikowi sprzeciw, to przejście na bardziej zaawansowany model nie legitymizuje „doklejenia” nowych, szerszych celów bez analizy podstawy prawnej.

AI w HR, rekrutacji i ocenie pracowników

Automatyczna selekcja CV, scoring kandydatów, monitoring aktywności pracowników, systemy wspierające decyzje o awansach – to obszary, gdzie:

• przetwarzane są dane szczególnie wrażliwe z perspektywy praw i wolności (ryzyko dyskryminacji, błędnych decyzji),
• osoby fizyczne znajdują się często w relacji zależności (pracownik–pracodawca),
• konsekwencje decyzji mogą być daleko idące: zatrudnienie, zwolnienie, brak podwyżki.

W takich przypadkach samo „zmaskowanie nazwisk” w danych treningowych nie wystarczy. Projekt zazwyczaj wymaga:

• solidnej oceny skutków dla ochrony danych (DPIA),
• zastanowienia się, czy opieranie się na uzasadnionym interesie jest w ogóle możliwe, czy raczej potrzebna jest zgoda (choć w relacji pracodawca–pracownik zgoda jest problematyczna z uwagi na brak pełnej dobrowolności),
• mechanizmów umożliwiających zakwestionowanie wyniku modelu i udział człowieka w ostatecznej decyzji.

Jeśli model wpływa na ocenę konkretnej osoby, dane pozostają personalne nawet wtedy, gdy sam algorytm „nie zna” jej imienia. Wynik przypisany do ID pracownika to nadal dane osobowe.

Systemy decyzji oparte na danych wrażliwych

Szczególnie restrykcyjnie traktowane są projekty AI przetwarzające dane wrażliwe (szczególne kategorie z art. 9 RODO): zdrowie, poglądy polityczne, przekonania religijne, seksualność, przynależność związkową itd. Przykłady:

• modele wspierające diagnozę medyczną,
• systemy analizujące zachowania wyborców na podstawie aktywności w sieci,
• narzędzia monitorujące wypalenie zawodowe czy zdrowie psychiczne pracowników.

W takich zastosowaniach zwykła anonimizacja jest technicznie trudna (bo kontekst tekstowy mocno „zdradza” osoby), a ryzyko reidentyfikacji – wysokie. Zwykle trzeba oprzeć się na:

• jednym z wyjątków z art. 9 ust. 2 (np. przetwarzanie w celu świadczenia usług medycznych, badań naukowych),
• wyraźnej zgodzie osoby, jeśli nie ma innej mocnej podstawy (np. w prywatnych aplikacjach zdrowotnych),
• dodatkowych środkach zabezpieczeń (szyfrowanie, ścisła kontrola dostępu, minimalizacja zakresu danych).

Maskowanie imion w opisach przypadków medycznych nie rozwiązuje problemu, gdy opis zawiera unikalne kombinacje chorób, dat i zabiegów, które lokalna społeczność może łatwo powiązać z konkretnym pacjentem.

Modele ogólne trenowane na masowych zbiorach z Internetu

Uczenie na treściach z sieci a „zgoda domniemana” użytkowników

W przypadku dużych modeli językowych i systemów generatywnych punkt ciężkości przesuwa się z klasycznego „czy mamy zgodę konkretnej osoby X?” na pytanie: „czy w ogóle istnieje obowiązek uzyskania zgody, skoro dane są publicznie dostępne?”.

Pełzające założenie bywa takie: jeśli ktoś coś opublikował w internecie, to zgodził się na dowolne wykorzystanie treści. Z perspektywy RODO to stanowisko jest zbyt daleko idące. Publiczna dostępność to co innego niż brak ochrony danych. Kluczowe jest:

• kto publikuje dane (osoba prywatna, organ władzy, firma),
• w jakim celu treści zostały upublicznione (komunikacja ze znajomymi, działalność zawodowa, publikacja naukowa),
• jakie informacje zawiera treść: kontaktowe, biograficzne, poglądy polityczne, zdrowotne, dane o dzieciach.

Serwis społecznościowy może w regulaminie przewidzieć szeroką licencję na wykorzystanie treści, lecz nie „anuluje” to RODO. Operator platformy nadal musi mieć podstawę prawną dla przekazania danych dalej, a kolejni odbiorcy – dla własnego przetwarzania. „Zgoda na regulamin” nie zawsze równa się „zgoda na trening modeli AI”, szczególnie jeśli pierwotnie nie było o tym mowy lub informacje były niejasno sformułowane.

Różne role w łańcuchu przetwarzania: wydawca, crawler, twórca modelu

Masowe zbiory z internetu powstają zazwyczaj w kilku krokach i na styku różnych podmiotów. Inne obowiązki będzie miał:

• wydawca treści (np. portal, forum) – zbierający dane bezpośrednio od użytkowników,
• podmiot scrapujący/crawlujący – technicznie pozyskujący treści z wielu serwisów,
• twórca modelu – wykorzystujący dane do trenowania systemu AI.

Jeśli te role są rozdzielone, trudno oprzeć się na jednym, uniwersalnym mechanizmie zgody. Wydawca może mieć zgody użytkowników na publikację i określone formy dalszego udostępniania, ale:

• scraper często nie ma bezpośredniego kontaktu z osobą, której dane dotyczą,
• twórca modelu przetwarza już „drugi raz” dane zebrane wcześniej w innym celu,
• granica między „analizą statystyczną treści” a budowaniem modelu odwzorowującego styl, poglądy czy preferencje konkretnych osób jest płynna.

Z punktu widzenia zgodności łatwiejsza jest sytuacja, gdy ten sam podmiot jest zarówno wydawcą, jak i twórcą modelu (np. duża platforma społecznościowa rozwijająca własne systemy AI) – wtedy można „domknąć” temat zgód i obowiązków informacyjnych w jednym łańcuchu. Jeżeli jednak dane są masowo zaciągane z różnych źródeł, trudno poważnie mówić o indywidualnej zgodzie każdej osoby; w praktyce główną rolę przejmują inne podstawy prawne (interes prawny, badania naukowe, wykonanie umowy) i silna anonimizacja wyników.

Granica między „danymi treningowymi” a „odpowiedziami modelu”

W modelach generatywnych klasyczne rozróżnienie na „etap przetwarzania danych” i „etap udzielania odpowiedzi” zaciera się. Problem pojawia się w dwóch punktach:

1. Ryzyko odtworzenia fragmentów danych źródłowych – model może „wypluć” pełne cytaty, adresy, numery telefonów czy pseudonimy rzadkich użytkowników, jeśli trenował się na stosunkowo małych, specyficznych zbiorach.
2. Inferencja wrażliwych cech – nawet jeśli dane wejściowe nie zawierają wprost informacji o zdrowiu czy poglądach, model może na ich podstawie generować przewidywania, które w efekcie stanowią nową daną osobową.

Anonimizacja na poziomie surowych danych nie rozwiązuje w pełni tego napięcia, jeśli:

• architektura modelu i sposób trenowania sprzyjają „zapamiętywaniu” przykładów,
• udostępniane są narzędzia pozwalające „wydobywać” z modelu treści specyficzne dla danej osoby,
• system służy do celów, w których pojedyncza odpowiedź może istotnie wpływać na prawa lub reputację jednostki (np. generowanie opisów osób, podpowiedzi diagnoz).

Im większe ryzyko takich przecieków, tym słabsza jest linia obrony, że „to przecież tylko zanonimizowane dane treningowe”. W praktyce oznacza to konieczność stosowania ograniczeń w projektowaniu interfejsu, testów regresyjnych pod kątem wycieków danych oraz środków organizacyjnych (np. zakaz używania modelu do wyszukiwania informacji o konkretnych osobach).

Uczenie w trybie „continuous learning” a ponowne wykorzystanie danych

Coraz więcej systemów AI uczy się nie tylko na danych historycznych, ale także na bieżących interakcjach z użytkownikami. W takiej konfiguracji pytanie o zgodę staje się bardziej zniuansowane:

• jednorazowa zgoda „na zawsze” – daje szerokie możliwości rozwoju modelu, ale jest ryzykowna z punktu widzenia transparentności i kontroli użytkownika,
• zgoda warunkowa, kontekstowa – pozwala użytkownikowi zdecydować, czy dana kategoria danych (np. czat z lekarzem online) może być wykorzystana treningowo,
• brak zgody i twarde rozdzielenie – dane bieżące służą tylko do obsługi sesji, a do trenowania wykorzystuje się osobne, odpowiednio przygotowane zbiory.

W praktyce wybór zależy od rodzaju usługi:

• w aplikacjach rozrywkowych lub narzędziach biurowych częściej dopuszczalny jest model „opt‑out” – domyślne użycie danych do doskonalenia, z możliwością wyłączenia,
• w usługach medycznych, psychologicznych, prawniczych oraz w relacjach pracodawca–pracownik bezpieczniejsze jest podejście „opt‑in” – brak uczenia na bieżących rozmowach bez wyraźnej zgody.

Technicznie można też rozdzielić poziomy:

• na poziomie treści – czaty nie są nigdy używane wprost do treningu,
• na poziomie telemetrii – do doskonalenia używa się wyłącznie zanonimizowanych statystyk (np. czas odpowiedzi, wskaźnik satysfakcji),
• na poziomie feedbacku – tylko jawnie udzielone oceny („ta odpowiedź była pomocna”) z wyciętą treścią rozmowy.

Im bliżej przetwarzania sensytywnych treści i zindywidualizowanych decyzji, tym bardziej uzasadnione staje się formalne oparcie takiego „ciągłego uczenia” na zgodzie – albo całkowita rezygnacja z uczenia na danych indywidualnych.

Zgoda na dane w AI – warunki ważności, plusy i pułapki

Kiedy anonimizacja nie jest możliwa lub wypacza sens projektu, zgoda staje się jednym z głównych narzędzi legalizowania przetwarzania. W obszarze AI standardowe wymogi RODO zyskują jednak kilka dodatkowych „warstw” praktycznych.

Elementy ważnej zgody w kontekście systemów AI

Zgoda pozostaje ważna tylko wtedy, gdy jest:

• dobrowolna – brak realnego przymusu, szantażu funkcjonalnego („bez zgody nie możesz korzystać z aplikacji w podstawowym zakresie”),
• konkretna – opisuje jasno cele przetwarzania, a nie ogólny „rozwój sztucznej inteligencji”,
• świadoma – użytkownik rozumie, jakie kategorie danych będą wykorzystywane i do czego,
• jednoznaczna – wyrażona przez aktywne działanie (zaznaczenie checkboxa, kliknięcie przycisku, podpis), a nie domniemana z milczenia.

AI wprowadza dwa dodatkowe wyzwania: złożoność celu i zmienność projektu. Użytkownik musi mieć minimalne pojęcie o tym, że jego dane posłużą nie tylko do „świadczenia usługi”, ale także do:

• trenowania nowych wersji modeli,
• walidacji i testowania jakości,
• ewentualnego dzielenia się modelami lub ich komponentami z innymi podmiotami (np. partnerami technologicznymi).

Jeśli te elementy są zamknięte w jednym, ogólnym zdaniu, zgoda może zostać uznana za zbyt mało konkretną. Rozsądnym kompromisem jest rozbicie jej na kilka bloków, np.: „zgoda na personalizację”, „zgoda na uczenie modeli na Twoich danych”, „zgoda na udostępnianie modelu partnerom”.

Osobna zgoda na funkcje zaawansowane vs. minimalny pakiet usług

Z punktu widzenia projektowania produktu ciekawym rozwiązaniem jest porównanie dwóch podejść:

1. Monolityczna zgoda: „Akceptuję regulamin, politykę prywatności i wykorzystanie moich danych do AI”.
   Plus: prostota procesu rejestracji.
   Minus: ryzyko zakwestionowania dobrowolności (brak alternatywy) i brak przejrzystości co do rzeczywistego zakresu przetwarzania.
2. Warstwowy model zgód: użytkownik ma dostęp do podstawowej funkcjonalności bez zgody na AI, a dodatkowe funkcje (personalizacja, inteligentne rekomendacje, automatyczna analiza dokumentów) włączane są po udzieleniu odrębnych zgód.
   Plus: lepsza pozycja prawna administratora, większe poczucie kontroli po stronie użytkownika.
   Minus: większa złożoność interfejsu, potencjalnie niższa adopcja funkcji AI.

Drugi wariant jest bardziej zgodny z duchem RODO, szczególnie w usługach, w których użytkownik może z nich korzystać w trybie „bez AI”. W systemach, gdzie inteligentne przetwarzanie jest integralną częścią usługi (np. asystent pisania, automatyczny tłumacz), należy wyraźnie oddzielić:

• przetwarzanie niezbędne do działania usługi (podstawa: umowa lub uzasadniony interes),
• przetwarzanie ponad to, np. uczenie modeli ogólnych na treści użytkownika (podstawa: zgoda).

Odwołanie zgody i „cofam, ale co się stało z moimi danymi?”

RODO wymaga, by odwołanie zgody było równie łatwe jak jej udzielenie i nie niosło ze sobą negatywnych konsekwencji wykraczających poza to, co konieczne. W AI napięcie pojawia się w dwóch miejscach:

• bieżące dane użytkownika – da się je zwykle usunąć względnie prosto (rekordy w bazach, logi, archiwa),
• wpływ na już wytrenowany model – „wyjęcie” pojedynczego wkładu z dużego modelu jest technicznie bardzo trudne, a często praktycznie niewykonalne.

Obowiązki prawne spotykają się tu z ograniczeniami technicznymi. Można rozważyć kilka strategii:

• Okresy buforowe: dane użytkownika wykorzystywane są do trenowania dopiero po upływie określonego czasu (np. 30 dni), co pozwala na skuteczniejsze wdrożenie cofnięcia zgody zanim trafią do pipeline’u treningowego.
• Segmentacja modeli: zamiast jednego, ogromnego modelu trenowanego na wszystkim, projektuje się mniejsze, wyspecjalizowane moduły, gdzie łatwiej wyłączyć określone kategorie danych.
• Ograniczenie do statystyk: nawet przy zgodzie używa się raczej zagregowanych cech niż pełnych treści, co zmniejsza indywidualny ślad.

W każdym z tych podejść ważna jest jasna komunikacja: użytkownik powinien wiedzieć, że odwołanie zgody zadziała na przyszłość i może nie odwrócić skutków treningu sprzed dnia X, choć administrator ma obowiązek ograniczyć dalsze wykorzystanie danych źródłowych.

Zgoda w badaniach i pilotażach AI: inna dynamika ryzyka

W fazach pilotażowych i badawczych często sięga się po zgodę, bo inne podstawy prawne są mniej oczywiste. Tu widać różnicę między dwoma scenariuszami:

• badanie naukowe lub kliniczne – zwykle podlega dodatkowym regulacjom, komisjom bioetycznym, ma precyzyjnie opisany protokół; zgoda bywa szczegółowa, wielostronicowa, a projekt objęty dodatkowymi zabezpieczeniami,
• pilotaż biznesowy – test nowej funkcji rekomendacyjnej, oceny ryzyka kredytowego czy analizy zachowań użytkowników w aplikacji.

W pierwszym przypadku główną oś stanowi wyraźna zgoda i dodatkowe przesłanki z art. 9 RODO (jeżeli są dane wrażliwe). W drugim – istotna jest raczej:

• dokładna definicja celu pilotażu („sprawdzenie, czy model X poprawia trafność rekomendacji o Y%”) i czasu jego trwania,
• odrębna, dobrze opisana zgoda pilotażowa, która nie „rozlewa się” automatycznie na przyszłe komercyjne wykorzystanie wyników,
• możliwość udziału w usłudze bez brania udziału w pilotażu (brak dyskryminacji użytkowników, którzy nie chcą eksperymentować).

Dwa identyczne co do techniki projekty (np. test scoringu zachowań) mogą więc wymagać innego podejścia do zgody, w zależności od kontekstu: naukowego, medycznego, biznesowego czy pracowniczego.