Dane wrażliwe w projektach ML: minimalizacja, zgody i ryzyka prawne

Cel przetwarzania danych wrażliwych w ML z perspektywy praktyka

Osoba prowadząca projekt uczenia maszynowego z udziałem danych wrażliwych ma zwykle dwa realne cele: po pierwsze, zbudować model, który faktycznie działa, a po drugie, zrobić to tak, żeby nie wpaść w kłopoty prawne, wizerunkowe i finansowe. Klucz leży w poukładaniu rozsądnego procesu: od wyboru podstawy prawnej i sposobu zbierania zgód, przez minimalizację i pseudonimizację danych, aż po prostą, ale rzetelną dokumentację i plan reagowania na incydenty.

dane wrażliwe w uczeniu maszynowym, RODO a modele ML, minimalizacja danych treningowych, zgoda na przetwarzanie danych w ML, ocena ryzyka DPIA AI, pseudonimizacja i anonimizacja danych, prywatność w projektach sztucznej inteligencji, odpowiedzialność prawna za modele predykcyjne, DPIA dla systemów AI, zgodność z prawem w trenowaniu modeli

Czym są dane wrażliwe w kontekście ML i dlaczego robią kłopot

Podstawowa definicja i przykłady z praktyki

RODO posługuje się pojęciem danych szczególnych kategorii, potocznie nazywanych danymi wrażliwymi. W projektach ML te informacje często pojawiają się nie tylko w oczywistej postaci (np. wyniki badań), ale także jako cechy pochodne, agregaty czy wnioski modelu. Prawo nie interesuje się wyłącznie surowym polem „choroba”, ale też tym, że z innych pól da się wiarygodnie taką chorobę wywnioskować.

Do danych wrażliwych należą w szczególności:

• informacje o zdrowiu (diagnozy, leki, niepełnosprawności, historia wizyt),
• dane biometryczne (np. szablony twarzy używane do rozpoznawania, odciski palców),
• dane genetyczne,
• poglądy polityczne, przekonania religijne lub światopoglądowe,
• przynależność związkowa,
• dane dotyczące życia seksualnego lub orientacji seksualnej.

W uczeniu maszynowym trafiają one do zbiorów treningowych na różne sposoby. W sektorze medycznym modele predykcyjne korzystają z historii chorób i recept. W HR można spotkać się z polami dotyczącymi niepełnosprawności, szczególnych zwolnień czy informacji o związkach zawodowych. W marketingu na bazie deklaracji uczestnictwa w określonych wydarzeniach religijnych lub politycznych da się rekonstruować poglądy. Sam fakt, że dane trafiły do feature store pod mało mówiącą nazwą kolumny, niczego nie zmienia – ich charakter pozostaje wrażliwy.

Istotne jest, że model ML nie „odczarowuje” wrażliwości danych. Nawet jeśli po trenowaniu przechowujesz „tylko wagi”, w wielu projektach regulator potraktuje zbiór treningowy i cały proces jako przetwarzanie danych wrażliwych. W efekcie rośnie zakres obowiązków (DPIA, dodatkowe zabezpieczenia, ograniczenia podstawy prawnej), a każdy błąd może mieć wyższy koszt niż w przypadku danych zwykłych.

Dane wrażliwe vs zwykłe – szara strefa w cechach ML

Czysta teoria dzieli dane na zwykłe i szczególne kategorie. Praktyka ML tworzy szarą strefę: dane, które formalnie są zwykłe, ale pozwalają z wysokim prawdopodobieństwem wywnioskować cechę wrażliwą. Przykładowo:

• kody leków refundowanych wskazują konkretną chorobę przewlekłą,
• uczestnictwo w konkretnym wydarzeniu może ujawniać poglądy polityczne lub religijne,
• liczne wizyty u onkologa lub psychiatry silnie sugerują dane o stanie zdrowia,
• dane o składkach związkowych są pośrednim wskaźnikiem przynależności związkowej.

Dla modeli predykcyjnych takie cechy bywają złotem – niosą dużą informację. Z punktu widzenia RODO pojawia się jednak problem „wnioskowania” danych wrażliwych. Organy nadzorcze coraz częściej uznają, że jeżeli z kombinacji zwykłych danych można w sposób prawdopodobny, systematyczny i przewidywalny odtworzyć cechę wrażliwą, to cały proces zbliża się reżimem do przetwarzania danych wrażliwych.

W praktyce oznacza to konieczność konserwatywnego podejścia. Jeśli projekt HR buduje scoring „stabilności pracownika” w oparciu o dane o zwolnieniach lekarskich, typach wizyt i preferencjach co do grafiku, w pewnym momencie granica między zwykłymi a zdrowotnymi informacjami jest już mocno rozmyta. Regulacyjnie bezpieczniej przyjąć, że projekt dotyka danych wrażliwych – i od razu uwzględnić odpowiednią podstawę prawną, DPIA i środki bezpieczeństwa.

Dane wejściowe, wyjściowe i wnioskowanie – model też może generować wrażliwe informacje

RODO obejmuje nie tylko dane, które trafiają do systemu jako wejście, ale również informacje wyprowadzone z tych danych. Model rekomendujący diagnozę, poziom ryzyka choroby czy prawdopodobieństwo przynależności do określonej grupy religijnej lub etnicznej generuje dane wrażliwe już na poziomie wyniku predykcji. Nie ma znaczenia, że użytkownik nigdy nie zaznaczył wprost „należę do grupy X” – jeżeli model taką cechę wylicza i zapisuje, powstaje zbiór danych wrażliwych.

Warto rozróżnić trzy poziomy:

• dane wejściowe – co trafia do modelu: ankiety, logi systemowe, historia transakcji, dane medyczne,
• cechy przetworzone – feature engineering, agregaty, embeddingi, wskaźniki,
• dane wyjściowe – predykcje, klasyfikacje, rekomendacje, segmentacja użytkowników.

Jeżeli którąś z tych warstw da się bez nadmiernego wysiłku powiązać z konkretną osobą, a sama treść dotyczy zdrowia, poglądów, seksualności czy biometrii, mamy do czynienia z przetwarzaniem danych wrażliwych. Przy dużych modelach (np. LLM) pojawia się jeszcze jedno ryzyko: „wycieku” danych treningowych w odpowiedziach, szczególnie jeśli stosujesz techniki typu fine-tuning na konkretnych danych pacjentów czy klientów.

Pominięcie tego aspektu bywa najdroższym błędem. Zespół ML potrafi zbudować skuteczny model, a dopiero po wdrożeniu dział prawny orientuje się, że predykcje w praktyce są nową bazą wrażliwych danych. Wtedy zmiana podstawy prawnej, dołożenie informacji dla osób i przeprowadzenie DPIA następują w trybie gaszenia pożaru, pod presją czasu i ryzyka kary.

Branże najbardziej „skażone” danymi wrażliwymi

Nie każda dziedzina ma taki sam profil ryzyka. Są sektory, gdzie dane wrażliwe pojawiają się niemal automatycznie, a każdy projekt ML wymaga szczególnej ostrożności:

• medycyna i zdrowie – systemy wspomagania diagnozy, predykcja rehospitalizacji, optymalizacja terapii, zdalny monitoring stanu zdrowia,
• HR i rekrutacja – dane o niepełnosprawnościach, przynależności do związków zawodowych, szczególnych uprawnieniach pracowniczych,
• ubezpieczenia – modele ryzyka chorób, taryfikacja składek przy ubezpieczeniach zdrowotnych lub na życie,
• finanse – scoring kredytowy oparty na wydatkach mogących ujawniać zdrowie, poglądy, orientację,
• marketing i personalizacja – segmentacja użytkowników pod kątem przekonań, wyznania, preferencji seksualnych.

W tych branżach obowiązek DPIA przy zaawansowanych systemach AI bywa w praktyce normą, a nie wyjątkiem. Każda nowa cecha w modelu może mieć wpływ na krajobraz ryzyka. Im wcześniej w procesie ktoś nazwie rzecz po imieniu („tak, to jest kategoria wrażliwa”), tym mniej kosztownych zmian będzie później.

Ramy prawne: RODO, prawo krajowe i nadchodzące regulacje AI

Najważniejsze artykuły RODO dla danych wrażliwych

RODO opiera się na kilku zasadach, które trzeba przełożyć na cykl życia modelu ML. W praktyce szczególnie istotne są:

• legalność, rzetelność i przejrzystość – każdemu etapowi (zbieranie, trenowanie, wdrożenie) musi towarzyszyć jasna podstawa prawna i informacja dla osoby,
• ograniczenie celu – dane zebrane „do świadczenia usługi” nie mogą automatycznie służyć „do trenowania modelu marketingowego”,
• minimalizacja danych – nie wykorzystuje się danych tylko dlatego, że „są w bazie”,
• prawidłowość – modele nie mogą opierać się na ewidentnie błędnych, przestarzałych informacjach,
• ograniczenie przechowywania – surowe dane treningowe nie powinny żyć wiecznie, tylko dlatego że „może się przydadzą w kolejnej wersji modelu”,
• integralność i poufność – właściwe zabezpieczenia techniczne i organizacyjne.

W kontekście danych wrażliwych kluczowe są art. 9 RODO (zakaz ich przetwarzania i wyjątki) oraz art. 35 dotyczący oceny skutków (DPIA). Zasadą jest zakaz przetwarzania, a wyjątkiem – sytuacje, w których jest to dozwolone, np. gdy:

• osoba wyraziła wyraźną zgodę na konkretne przetwarzanie,
• przetwarzanie jest niezbędne ze względów medycznych (np. leczenie) i odbywa się przez uprawniony podmiot,
• chodzi o ważny interes publiczny, określony w prawie,
• przetwarzanie jest prowadzone w celu badań naukowych lub statystycznych na odpowiednich zabezpieczeniach.

Dla projektów ML oznacza to, że nie wystarczy „ogólna zgoda na marketing”. Trzeba wiedzieć, czy przetwarza się dane wrażliwe, w jakim celu i na jakiej dokładnie podstawie. W wielu przypadkach konieczne jest też rozdzielenie celów: osobno operacyjne świadczenie usługi, osobno rozwój modeli predykcyjnych.

Regulacje sektorowe i AI Act – na co patrzeć bez ton papierów

Poza RODO, projekty z danymi wrażliwymi dotyka gęsta sieć przepisów sektorowych. Przykładowo:

• w zdrowiu – prawo o systemie informacji w ochronie zdrowia, regulacje dotyczące dokumentacji medycznej, tajemnicy zawodowej,
• w finansach – ustawy o kredycie konsumenckim, przeciwdziałaniu praniu pieniędzy, regulacje nadzorców (np. KNF),
• w ubezpieczeniach – szczególne przepisy dot. oceny ryzyka i profilowania,
• w prawie pracy – ograniczenia co do zbierania informacji o zdrowiu, związkach zawodowych, karalności.

Zamiast samodzielnie studiować każdą ustawę, rozsądne jest podejście „filtrujące”: zidentyfikować 2–3 główne akty, które dotyczą branży, i sprawdzić oficjalne komunikaty lokalnego regulatora (np. UODO, KNF, resort zdrowia). Często zawierają one skondensowane wytyczne dotyczące AI, profilowania i danych wrażliwych. Taki przegląd można powtarzać raz na pół roku, zamiast non stop śledzić każdą zmianę.

W perspektywie kilku lat duże znaczenie zyska unijny AI Act. Dla systemów pracujących na danych wrażliwych (szczególnie w obszarach zdrowia, HR, finansów, dostępu do usług) często oznacza kwalifikację jako systemy wysokiego ryzyka. To z kolei pociąga wymogi:

• prowadzenia dokumentacji technicznej i dokumentowania danych treningowych,
• oceny ryzyka i systemu zarządzania ryzykiem,
• monitorowania po wdrożeniu (post-market monitoring),
• zapewnienia nadzoru człowieka i możliwości interwencji,
• transparentności wobec użytkowników.

Na poziomie operacyjnym kluczowe będzie połączenie wymogów RODO (podstawa prawna, DPIA, prawa osób) z wymogami AI Act (zarządzanie ryzykiem, dokumentacja techniczna). Z perspektywy budżetu da się to pogodzić jednym, spójnym zestawem dokumentów zamiast dwóch osobnych biurokratycznych maszyn.

Rola regulatorów i „soft law” – jak łapać esencję

Organy takie jak UODO czy Europejska Rada Ochrony Danych (EROD) wydają wytyczne dotyczące profilowania, DPIA, zgód i przetwarzania danych wrażliwych. Prawo formalnie jest w ustawach i rozporządzeniach, ale praktyka kontroli często opiera się właśnie na tych dokumentach. Nie trzeba czytać wszystkiego; wystarczy skupić się na kilku obszarach:

• profilowanie i zautomatyzowane podejmowanie decyzji (artykuł 22 RODO),
• wytyczne DPIA – przykładowe typy przetwarzania wymagające oceny skutków,
• interpretacje art. 9 RODO (dane wrażliwe) w kontekście innowacji, badań i usług cyfrowych.

Najprostszy „budżetowy” sposób działania to podział zadań: osoba techniczna lub product owner sprawdza wybrane wytyczne raz na kwartał, a kluczowe wnioski przekłada na checklistę dla zespołu ML. Dzięki temu projekt nie utknie w analizach, ale jednocześnie wykorzysta świeże interpretacje przy podjęciu decyzji o tym, jak trenować model i jakie zabezpieczenia wdrożyć.

Minimalizacja danych w praktyce projektów ML

Projektowanie architektury pod minimalizację, a nie odwrotnie

Największy błąd przy danych wrażliwych to traktowanie minimalizacji jako „fazy sprzątania po POC”. Dużo taniej jest wbudować ją w architekturę:

• oddzielne środowisko „surowe” i „modelowe” – osobne bazy / namespace’y na dane identyfikujące i na dane do trenowania, z innymi uprawnieniami dostępu,
• warstwa przetwarzania pośredniego – pipeline, który czyści, pseudonimizuje lub agreguje dane zanim trafią do świata ML,
• „wąskie gardła” dostępu – zamiast pełnego dumpa produkcji, kontrolowane widoki / snapshoty z jasno opisanym celem.

Taki układ wymaga trochę pracy na starcie, ale później każde kolejne use case’y mieszczą się w już bezpiecznej ramie. Zamiast kolejnych indywidualnych uzgodnień z działem prawnym, powtarzasz sprawdzony wzorzec: tu wchodzą dane operacyjne, tu wychodzą bezpieczne featury.

Co tak naprawdę trzeba wyrzucić, a co tylko „oswoić”

Minimalizacja nie znaczy automatycznego wyrzucenia wszystkiego, co delikatne. Część informacji można po prostu przekształcić tak, by nie była już danymi wrażliwymi lub by ryzyko ich ujawnienia dramatycznie spadło. W praktyce chodzi o odpowiedź na trzy pytania:

1. Czy te dane są w ogóle potrzebne do osiągnięcia celu modelu?
2. Czy da się je zastąpić mniej wrażliwą reprezentacją?
3. Czy da się je usunąć po trenowaniu bez rozbijania całego systemu?

Dopiero kiedy odpowiedź na dwa pierwsze pytania brzmi „nie”, wchodzi dyskusja o cięższych środkach – dodatkowych zgodach, DPIA, mocniejszym szyfrowaniu, odseparowanych zespołach.

Praktyczne techniki minimalizacji na danych wejściowych

Najtaniej „minimalizuje się” na wejściu. Im mniej wrażliwej treści wpadnie do pipeline’u, tym mniej kosztownych środków trzeba później.

• Selekcja pól – przy imporcie danych zastanów się, których kolumn z produkcji realnie użyjesz. Jeśli imię, PESEL czy numery dokumentów nigdy nie będą feature’ami, nie kopiuj ich do przestrzeni ML.
• Agregacja zamiast surowych logów – zamiast pełnej historii zdarzeń z timestampami i identyfikatorami, wygodniej jest zbudować agregaty: liczba logowań w okresie, liczba hospitalizacji w ostatnich 12 miesiącach, średnie wydatki w kategoriach, a następnie wyrzucić surowe logi z warstwy modelowej.
• Przycinanie zakresów czasu – pełna historia „od zawsze” rzadko jest potrzebna. Wiele modeli spokojnie pracuje na oknach 3, 6 czy 12 miesięcy, a starsze dane mogą zostać zanonimizowane lub przemielone na statystyki.
• Filtracja treści tekstowych – przy NLP z dokumentów medycznych czy HR-owych da się przed feature engineeringiem usunąć lub zamazać oczywiste identyfikatory i elementy szczególnie wrażliwe (np. opisy życia intymnego, dane o rodzinie, nazwy rzadkich chorób, które de facto identyfikują osobę).

W jednym z projektów klinicznych sporą część ryzyka zdjęto prostą zmianą: zamiast pełnych opisów wizyt lekarz wprowadzał znormalizowane kody zdarzeń i objawów; tekst był dostępny tylko w systemie medycznym, a nie w środowisku ML.

Pseudonimizacja versus anonimizacja – realistyczny kompromis

Większość projektów ML nie jest w stanie pracować na prawdziwie zanonimizowanych danych. Zwykle kończymy na pseudonimizacji, czyli odseparowaniu identyfikatorów od reszty treści przy zachowaniu możliwości powiązania na podstawie klucza.

Przy danych wrażliwych podstawowy „tanio-skuteczny” zestaw wygląda tak:

• osobny słownik identyfikatorów (ID produkcyjne → ID ML), trzymany w bardzo wąsko chronionej bazie, najlepiej pod inną administracją niż zespół ML,
• zamiana wartości oczywiście identyfikujących (PESEL, e-mail, numer telefonu) na ID techniczne lub usunięcie ich z warstwy featurów,
• odcięcie oczywistych quasi-identyfikatorów, gdy nie są krytyczne dla jakości (dokładny adres, numery tablic, bardzo szczegółowe zawody).

Anonimizacja, w rozumieniu braku możliwości powrotu do osoby, zwykle ma sens tylko dla celów badań i statystyk, gdzie nie trzeba później łączyć predykcji z kontem użytkownika. W komercyjnych systemach operacyjnych lepiej uczciwie nazwać rzeczy po imieniu (pseudonimy, nie anonim), opisać to w DPIA i dobrać adekwatne zabezpieczenia.

Feature engineering a „ukryte” dane wrażliwe

Nawet jeśli nie używasz pól wprost wskazujących na zdrowie czy przekonania, część cech pochodnych może te kategorie zdradzać. Dla regulatora nie ma znaczenia, że model widzi tylko liczby od 0 do 1 – liczy się, co z nich wynika w praktyce.

Zwykle problematyczne są:

• wydatki i lokalizacja – często pozwalają odtworzyć informacje o wyznaniu, orientacji, stanie zdrowia (np. regularne płatności w klinice niepłodności czy w konkretnych organizacjach wyznaniowych),
• historia urlopów i absencji – połączenie częstych, długich nieobecności z HR-owymi metadanymi bywa de facto danymi o chorobach przewlekłych,
• logi aplikacji mobilnych – dane o aktywnościach, ćwiczeniach czy medytacji mogą sugerować stan zdrowia psychicznego lub fizycznego.

Budżetowe rozwiązanie to krótka, cykliczna „revi ew featurów” z kimś od ochrony danych lub prawnikiem technicznym: lista top N cech używanych w modelu i dyskusja, które z nich mogą podciągać się pod kategorie wrażliwe. Nie chodzi o rozprawę doktorską, tylko o 1–2 godziny raz na kilka miesięcy.

Minimalizacja w cyklu życia modelu – nie tylko na etapie trenowania

Dane wrażliwe „krążą” w systemie dużo dłużej niż trwa budowa modelu. Minimalizacja powinna być widoczna na kilku etapach:

• trenowanie – możliwie mały, adekwatny do celu zbiór; wersjonowanie z informacją, jakie klasy danych zawiera,
• walidacja i testy – osobne, mniejsze próbki; gdy tylko się da, pseudonimizowane jeszcze mocniej niż zbiór treningowy,
• monitoring produkcyjny – zbieranie metryk bez pełnych logów z treścią; gdy konieczne są próbki requestów, trzymanie ich bardzo krótko i pod dodatkowymi ograniczeniami,
• retencja i usuwanie – jasny harmonogram kasowania lub dalszego przetwarzania w formie zanonimizowanej.

Dużo projektów przegrywa właśnie na logach i backupach: oficjalny zbiór treningowy jest dopieszczony, ale pełne logi requestów z polami medycznymi lecą do wspólnego narzędzia obserwowalności, z którego korzysta pół firmy. To dokładnie ten poziom, na którym inspektor ochrony danych zacznie zadawać pytania.

Minimalizacja przy LLM i generatywnym AI

Przy dużych modelach językowych dochodzi jeszcze jeden wymiar: dane wrażliwe nie tylko są przetwarzane, ale mogą zostać „odtworzone” w odpowiedziach. Tu minimalizacja ma trzy warstwy:

• kontrola tego, co idzie do treningu / fine-tuningu – filtrowanie danych wejściowych, anonimizacja transkryptów, wycinanie fragmentów zawierających kategorie wrażliwe, jeśli nie są niezbędne do celu,
• RAG zamiast pełnego treningu – w wielu zastosowaniach bardziej rozsądne jest trzymanie wrażliwych dokumentów w wyszukiwarce (wektorowej lub klasycznej) i podpinanie ich dynamicznie niż „wypalanie” ich w wagach modelu,
• filtry na wyjściu – mechanizmy, które wykrywają i blokują odpowiedzi ujawniające dane osobowe lub zbyt szczegółowe informacje o konkretnych osobach, jeśli model takowe generuje.

Rozwiązanie typu RAG z dobrym kontrolowanym indeksem bywa paradoksalnie tańsze w utrzymaniu niż ciągłe gaszenie pożarów po niefortunnym fine-tuningu na realnych danych pacjentów czy klientów.

Dokumentowanie minimalizacji – tyle, ile trzeba, nie więcej

Z punktu widzenia RODO i AI Act nie wystarczy „robić dobrze” – trzeba to jeszcze pokazać w dokumentacji. Da się to zorganizować w lekkiej, powtarzalnej formie:

• jednostronicowy opis źródeł danych – skąd pochodzą dane, czy zawierają kategorie wrażliwe, jak są pseudonimizowane,
• lista „wyciętych” pól – które kolumny / typy informacji świadomie wyłączono i dlaczego (np. brak wpływu na jakość, zbyt duże ryzyko),
• zasady retencji – prosta tabela: surowe dane, dane modelowe, logi, backupy – jak długo żyją i gdzie są kasowane.

Z taką bazą dokumentów DPIA przestaje być kilkumiesięcznym projektem – staje się rozszerzeniem tego, co i tak już przygotowano dla zespołu ML.

Zgoda, prawnie uzasadniony interes i inne podstawy przetwarzania

Dlaczego sama „zgoda na marketing” nie wystarczy

Przy danych wrażliwych magiczne zdanie „użytkownik wyraził zgodę” rzadko rozwiązuje problem. Zgoda musi być:

• konkretna – opisuje konkretny cel, a nie „wszystkie działania rozwojowe firmy”,
• dobrowolna – brak zgody nie może oznaczać, że klient w ogóle nie dostanie podstawowej usługi, jeśli dane wrażliwe nie są do niej niezbędne,
• świadoma – osoba rozumie, że w grę wchodzi np. predykcja zdrowia czy preferencji, a nie tylko zwykły newsletter.

Dla danych z art. 9 RODO dochodzi jeszcze jedno: zgoda musi być wyraźna. W praktyce oznacza to osobny checkbox lub inną aktywną akcję, a nie ukrycie kluczowej informacji w długim regulaminie.

Kiedy zgoda ma sens, a kiedy tylko komplikuje życie

Zgoda bywa kusząca („dajmy checkbox i mamy spokój”), ale w wielu projektach jest najbardziej kłopotliwą podstawą przetwarzania. Główne problemy:

• osoba może cofnąć zgodę – trzeba umieć usunąć lub wyłączyć z przetwarzania jej dane z całego pipeline’u ML,
• zbyt szeroko opisana zgoda może zostać uznana za nieważną – wracamy do punktu wyjścia,
• przy relacji pracodawca–pracownik dobrowolność jest często iluzoryczna, więc regulator może ją zakwestionować.

Zgoda ma sens tam, gdzie:

• przetwarzanie nie jest niezbędne do świadczenia usługi (np. dodatkowy moduł profilowania zdrowotnego w aplikacji fitness),
• dane są szczególnie delikatne i nie podpadają pod inne wyjątki z art. 9 (np. badania poza typową opieką medyczną),
• chcemy dać użytkownikowi realny wybór co do zaawansowanej analityki czy personalizacji.

Z perspektywy kosztów odzyskiwanie danych z historycznych zbiorów treningowych po cofnięciu zgody jest jednym z najtrudniejszych tematów. Jeśli system nie jest do tego przygotowany od początku, dochodzimy do konfliktu między prawami osoby a realnymi możliwościami technicznymi.

Prawnie uzasadniony interes a dane wrażliwe

Podstawa „prawnie uzasadnionego interesu” (legitimate interest) często sprawdza się przy zwykłych danych (np. podstawowy scoring ryzyka w sklepie internetowym). Przy danych wrażliwych sprawa jest jednak bardziej ograniczona – art. 9 wprowadza zasadę zakazu i katalog wyjątków, w którym czysty interes administratora się nie pojawia.

Można spotkać kombinacje, w których:

• dla zwykłych danych (np. historia transakcji bez ujawniania zdrowia) używany jest uzasadniony interes,
• a dla warstwy, która faktycznie dotyczy zdrowia czy przekonań – inna podstawa z art. 9 (np. zgoda, medycyna, badania naukowe).

Taki miks wymaga dobrego opisania w rejestrze czynności przetwarzania i DPIA, ale bywa bardziej stabilny niż powoływanie się wyłącznie na zgody, które później trudno obsłużyć operacyjnie.

Umowa, obowiązek prawny i interes publiczny – gdzie mieszczą się projekty ML

Przy projektach ML łatwo zapomnieć o mniej „sexy” podstawach przetwarzania, takich jak:

• niezbędność do wykonania umowy – np. model, który ocenia zasadność świadczeń zdrowotnych w ramach ubezpieczenia, gdy analiza jest częścią świadczenia usługi,
• obowiązek prawny – np. modele AML do wykrywania prania pieniędzy, gdzie część analiz jest wręcz wymagana,
• ważny interes publiczny lub zdrowia publicznego – systemy epidemiologiczne, priorytetyzacja pacjentów, nadzór nad bezpieczeństwem leków.

Dane do trenowania vs. dane do produkcji – inna podstawa, inne ryzyka

Jedno źródło danych może zasilać kilka procesów, a każdy z nich mieć inną podstawę prawną. To szczególnie widoczne przy większych organizacjach, gdzie:

• warstwa operacyjna (świadczenie usługi) jedzie na umowie lub obowiązku prawnym,
• profilowanie, scoring czy rekomendacje bazują na uzasadnionym interesie albo zgodzie,
• trenowanie nowych modeli podpada pod badania lub rozwój produktu.

Technicznie to bywa ten sam magazyn danych, te same logi, tylko pipeline’y mają inne etykiety. Z prawnego punktu widzenia to odrębne operacje i trzeba je tak traktować. Budżetowy sposób na utrzymanie porządku:

• prosty katalog procesów ML – arkusz z kolumnami: „cel”, „model / feature store”, „podstawa prawna”, „czy są dane z art. 9?”,
• oznaczanie w repozytorium lub w narzędziu MLOps, który pipeline pracuje na jakiej podstawie (np. tagiem lub nazwą joba),
• podlinkowanie do konkretnej klauzuli informacyjnej, z której „wychodzi” dany proces.

Przy cofnięciu zgody albo zmianie celu nie trzeba wtedy przeszukiwać całego środowiska, tylko filtruje się po tagu i widać, które modele i zbiory trzeba dotknąć.

Badania naukowe i „research ML” w firmie – co da się podciągnąć pod wyjątki

Wielu data scientistów używa słowa „research” bardzo szeroko. Dla RODO to ma znaczenie: wyjątki dla badań naukowych czy historycznych są opisane dość konkretnie, a dodatkowo uzupełniane przez prawo krajowe.

Typowy wewnętrzny eksperyment „zobaczmy, czy nowa architektura lepiej przewiduje rotację” nie staje się automatycznie badaniem naukowym tylko dlatego, że trafi do slajdu z tytułem „research results”. Żeby powołać się na tę podstawę przy danych wrażliwych, zwykle trzeba spełnić kilka warunków:

• mieć jasno opisany projekt badawczy (choćby 2–3 strony, ale konkretnie: hipoteza, metody, planowane rezultaty),
• wdrożyć dodatkowe zabezpieczenia – mocniejsza pseudonimizacja, ograniczenia dostępu, brak użycia danych do indywidualnych decyzji,
• w wielu krajach – mieć podstawę w prawie krajowym lub zgodę odpowiedniej komisji/instytucji.

Dla firm produktowych częściej sens ma scenariusz hybrydowy: dane wrażliwe są przetwarzane na podstawie umowy / zgody / interesu publicznego, a komponent „badawczy” ogranicza się do takiej formy, w której zbiory są już mocno zanonimizowane i nie da się wrócić do konkretnej osoby.

Jak nie „przeklikać” zgód – minimalny design informacyjny

Zgody i klauzule można zamienić w wielostronicowy projekt UX-owo–prawny. Można też zbudować lekki, ale sensowny mechanizm, który realnie redukuje ryzyko. Kilka chwytów, które da się wdrożyć małym kosztem:

• rozdzielenie checkboxów – osobno zgoda na komunikację marketingową, osobno na zaawansowane profilowanie/ML na danych wrażliwych,
• mini-opisy przy checkboxie – jedno zdanie „co to znaczy?” w języku człowieka, a dopiero potem link „szczegóły”,
• panel preferencji w aplikacji lub na koncie użytkownika – bez pisania do supportu, kliknięciem da się wyłączyć profilowanie lub wykorzystanie danych do trenowania nowych modeli,
• loga zmian zgód – prosty rejestr: kto, kiedy, jaki przełącznik przestawił (wystarczy na poziomie ID użytkownika, bez detali medycznych).

To później ratuje projekt ML: wiadomo, od jakiej daty nie wolno dokładać danych użytkownika do kolejnych wersji zbioru treningowego, a stare wersje datasetu można trzymać pod inną podstawą (np. badania, interes publiczny), jeśli prawo na to pozwala i zostało to uczciwie opisane.

Operacjonalizacja cofania zgody i sprzeciwu – wersjonowanie zbiorów w praktyce

Cofnięcie zgody lub sprzeciw wobec przetwarzania danych wrażliwych teoretycznie działa „na przyszłość”, ale w ML pojawia się pytanie: co z już wytrenowanymi modelami i historycznymi zbiorami?

Minimalny, ale działający schemat na start:

1. Wersjonowanie datasetów – każdy zbiór treningowy ma swój identyfikator i daty „zamrożenia”. Przy cofnięciu zgody loguje się datę – użytkownik nie trafia do kolejnych wersji.
2. Okres „karencji” modeli – zakłada się rozsądny okres życia modelu (np. 6–12 miesięcy) i zapisuje w DPIA, że wcześniejsze dane nie są „wyciągane” z wag, o ile nie przechowuje się surowych cech w łatwo odwracalnej formie.
3. Techniczne „no re-train” – ID użytkownika ląduje na liście, którą filtruje się przy generowaniu nowych datasetów. To prosta lista w bazie lub feature store, nie trzeba wymyślać niczego bardziej zaawansowanego.

W droższej wersji można próbować dekontrybuować pojedynczego użytkownika z modelu (unlearning), ale w większości biznesowych projektów to nadal science fiction operacyjnie. Realny kompromis to: nie dorzucać nowych danych, a stare wygasić wraz z cyklem życia modeli, zamiast obiecywać klientom coś, czego zespół techniczny nie dowiezie.

Pseudonimizacja a anonimizacja – na czym faktycznie można oprzeć podstawę prawną

Przy danych wrażliwych granica między „już anonimowe” a „jeszcze osobowe” decyduje o tym, czy w ogóle trzeba szukać podstawy z art. 6 i 9. W praktyce większość firm działa na pseudonimizacji, a nie prawdziwej anonimizacji. Kilka punktów, które pomagają postawić stopklatkę:

• jeśli ktokolwiek w organizacji (lub w podmiocie przetwarzającym) ma dostęp do klucza odwracającego – to nadal dane osobowe,
• jeśli zbiory są na tyle bogate, że połączenie kilku cech (np. rok urodzenia + rzadki zawód + miasto) pozwala zidentyfikować osobę – regulator raczej uzna je za dane osobowe, niezależnie od braku imienia i nazwiska,
• anonimizacja powinna być nieodwracalna i udokumentowana – opis metody, parametry (np. progi agregacji, poziom szumów), testy ryzyka reidentyfikacji.

To nie musi być pełny privacy research. Często wystarczy krótki protokół techniczny z kilkoma eksperymentami reidentyfikacji. Bez tego trudno uczciwie twierdzić, że model pracuje na danych „już poza RODO”.

Dane wrażliwe w feature store – jak nie zrobić z niego „bomby prawnej”

Feature store kusi tym, że „wrzucamy raz, używamy wszędzie”. Przy danych wrażliwych to prosta droga do sytuacji, w której cecha przygotowana pod jeden, dobrze opisany projekt nagle ląduje w zupełnie innym modelu, bez odpowiedniej podstawy.

Da się wprowadzić kilka tanich, ale skutecznych bezpieczników:

• etykiety czułości przy cechach – np. „normal”, „high-risk”, „art9-like”; nie trzeba ISO, wystarczy rozsądna kategoryzacja uzgodniona z inspektorem,
• proste reguły użycia – cechy z flagą „art9-like” mogą być użyte tylko w projektach z konkretną, zatwierdzoną podstawą (np. medycyna, badania),
• review pull requestów dodających nowe featury – ktoś z prywatności lub security robi szybki przegląd opisu cechy i źródła danych; 10–15 minut na PR, a oszczędza tygodni tłumaczeń przy kontroli,
• krótki opis celu przy tworzeniu nowego modelu – w metadanych modelu: które featury i w jakim celu, z linkiem do DPIA lub notatki ryzyka.

Feature store zamienia się wtedy z „czarnej skrzynki pełnej pól o nieznanym pochodzeniu” w katalog, w którym od razu widać, które dane są wrażliwe i czym można je legalnie karmić.

Decyzje oparte wyłącznie na przetwarzaniu zautomatyzowanym a ML na danych wrażliwych

ML bardzo łatwo wypycha człowieka z procesu decyzyjnego, zwłaszcza przy dużych wolumenach spraw. Dla danych wrażliwych automatyczne decyzje to jednak osobna kopalnia min – wchodzą w grę art. 22 RODO i regulacje sektorowe.

Nie każda rekomendacja to decyzja, ale jeżeli:

• wynik modelu bezpośrednio wpływa na dostęp do świadczenia, produktu lub usługi,
• brakuje realnej ludzkiej kontroli (przegląd jest iluzoryczny, a człowiek tylko klika „zatwierdź”),
• model operuje na danych wrażliwych – np. historia leczenia, przynależność związkowa, religia,

– to potrzeba znacznie więcej niż tylko dobrze skonstruowanej podstawy przetwarzania. W grę wchodzi m.in. obowiązek umożliwienia zakwestionowania decyzji, ręcznego przeglądu, dodatkowe przejrzyste objaśnienia. Wszystko to trzeba spiąć z minimalizacją: nie przewiduje się czegoś tylko dlatego, że „model potrafi”, jeśli nie da się tego sensownie wyjaśnić i obronić.

Prosty workflow współpracy: zespół ML + prawnik + IOD

Przy danych wrażliwych największy zysk daje zgranie ludzi technicznych i osób od ochrony danych. Nie chodzi o rozbudowane komitety, tylko o prosty rytm kilku spotkań i szablonów.

Praktyczny wariant „na start”:

1. Kick-off projektu (30–60 minut) – zespół ML tłumaczy cel, dane, pomysł na architekturę; prawnik/IOD zaznacza czerwone flagi: kategorie wrażliwe, możliwe podstawy, konieczność DPIA.
2. Przegląd featurów (po PoC) – krótka sesja z listą głównych cech i źródeł, decyzja: które pola wycinamy, co trzeba dodatkowo pseudonimizować.
3. Odbiór przed produkcją – checklist: dane, retencja, logi, monitoring, opis w rejestrze czynności, aktualizacja klauzul / zgód, jeśli trzeba.

Wsad dokumentacyjny może być bardzo lekki: jeden repozytorium lub folder z trzema–czterema plikami Markdown, do których zespół ML dopisuje techniczne szczegóły, a IOD dorzuca komentarze. Z czasem część treści da się skopiować między projektami, zamiast za każdym razem wymyślać koło na nowo.

Minimalizacja i podstawy przetwarzania w środowiskach chmurowych

Przy chmurze wątek podstawy prawnej komplikuje się o kolejny element: kto jest administratorem, kto procesorem i gdzie faktycznie lądują dane. Dla projektów ML z danymi wrażliwymi oznacza to kilka dodatkowych decyzji:

• wybór regionu – nie tylko z powodów wydajności, ale też reżimu prawnego (transfer poza EOG wciąż jest czułym punktem przy kontrolach),
• konfiguracja logów i snapshotów – ograniczenie pól wrażliwych w logach chmurowych, wyłączenie automatycznych snapshotów baz z pełnymi danymi medycznymi, jeśli nie ma na nie jasnej podstawy,
• rola dostawcy – doprecyzowanie w umowie i DPIA, w jakim zakresie dostawca chmury może mieć dostęp do danych (support, monitoring) i co z tym wynika dla podstawy przetwarzania.

Ta sama logika dotyczy usług typu „managed ML”. Jeżeli dostawca zastrzega sobie prawo użycia danych do własnego trenowania, a w grze są dane z art. 9, to robi się z tego osobny projekt prawny, a nie tylko tick w konsoli. Często taniej wychodzi ograniczyć się do konfiguracji, w której dane wrażliwe nie opuszczają kontrolowanego środowiska, a chmurowe usługi pracują na zanonimizowanych embeddingach lub precomputed features.

Najczęściej zadawane pytania (FAQ)

1. Co to są dane wrażliwe w projektach ML i jak je rozpoznać?

Dane wrażliwe (szczególne kategorie danych z RODO) to m.in. informacje o zdrowiu, biometrii, genetyce, poglądach politycznych, religii, przynależności związkowej oraz życiu i orientacji seksualnej. W ML pojawiają się nie tylko jako „gołe” pola (np. diagnoza), lecz także jako cechy pochodne, agregaty czy wyniki modelu.

Przykład: w systemie medycznym diagnoza, lista leków, historia wizyt czy dane z monitoringu zdalnego stanu zdrowia – wszystko to będzie traktowane jak dane wrażliwe. W projekcie HR informacja o szczególnych uprawnieniach pracowniczych czy niektórych typach zwolnień także może wejść w tę kategorię.

Kluczowa zasada: jeżeli z danej cechy da się z rozsądną pewnością odtworzyć zdrowie, poglądy, religię czy seksualność konkretnej osoby, trzeba założyć, że dotykasz danych wrażliwych, nawet jeśli kolumna nazywa się niewinnie.

2. Czy sam fakt trenowania modelu na danych wrażliwych podlega RODO?

Tak. Trenowanie modelu na danych wrażliwych to pełnoprawne „przetwarzanie danych osobowych” w rozumieniu RODO. To, że po treningu przechowujesz „tylko wagi”, nie zwalnia z obowiązków – urząd patrzy na cały proces, w tym dostęp do zbioru treningowego, feature store i logów.

W praktyce oznacza to konieczność:

• posiadania odpowiedniej podstawy prawnej (np. wyraźna zgoda, szczególny przepis prawa, ważny interes publiczny),
• przeprowadzenia DPIA/oceny ryzyka, jeśli model jest istotny dla praw lub wolności osób (co przy danych zdrowotnych czy HR jest niemal standardem),
• dodatkowych zabezpieczeń technicznych i organizacyjnych (ograniczenia dostępu, szyfrowanie, pseudonimizacja).

Najtańszy błąd to założyć „to tylko R&D, RODO nas nie dotyczy” – poprawki po fakcie zwykle kosztują znacznie więcej niż minimalne uporządkowanie procesu na starcie.

3. Jak zminimalizować zakres danych wrażliwych w modelu ML w praktyce?

Najprostszy i najtańszy krok to przejrzeć każdą kolumnę pod kątem: „Czy bez niej model jeszcze działa sensownie?”. Wszystko, co niewiele wnosi do jakości predykcji, a jest wrażliwe lub quasi-wrażliwe, opłaca się usunąć już na etapie przygotowania danych.

W praktyce pomocne są:

• wstępne analizy wpływu cech (feature importance, SHAP) na małej próbce – łatwiej wtedy uciąć „drogie” prawnie cechy, które dają marginalny zysk,
• agregacja tam, gdzie to możliwe – zamiast pełnej historii wizyt u lekarza, np. liczba wizyt w kwartale; zamiast dokładnej diagnozy – szeroka kategoria ryzyka.

Lepszy model o 2–3% gorszym wyniku, ale bez najbardziej wrażliwych pól, bywa znacznie tańszy w utrzymaniu prawno-kompliance niż „rakieta” oparta na wszystkim, co wpadło do bazy.

4. Kiedy potrzebna jest zgoda na przetwarzanie danych wrażliwych do ML i jak ją zbierać?

Zgoda jest potrzebna, gdy nie ma innej wyraźnej podstawy prawnej z art. 9 RODO (np. obowiązek ustawowy, interes publiczny w zdrowiu publicznym). W wielu komercyjnych projektach (marketing, personalizacja, część zastosowań HR) wyraźna, dobrowolna zgoda jest w praktyce jedyną realną opcją.

Efektywny, „budżetowy” sposób zbierania zgód:

• jasne rozdzielenie zgody na świadczenie usługi od zgody na użycie danych w trenowaniu modeli,
• krótki, konkretny opis celu: „ulepszanie algorytmu rekomendacji”, „budowa modelu oceny ryzyka chorób na podstawie historii leczenia”,
• łatwa możliwość wycofania zgody – najlepiej w tym samym kanale, w którym była udzielona.

Im prostszy komunikat i mechanizm, tym mniej pytań do działu prawnego i mniejsza szansa na „masowe” wycofanie zgód pod wpływem nieufności użytkowników.

5. Czym różni się pseudonimizacja od anonimizacji w ML i co daje w kontekście danych wrażliwych?

Pseudonimizacja to zastąpienie bezpośrednich identyfikatorów (imię, PESEL, e‑mail) identyfikatorami technicznymi (ID, hash). Nadal da się powiązać dane z konkretną osobą, jeśli ma się dodatkowe informacje – więc RODO wciąż obowiązuje, ale ryzyko i odpowiedzialność są mniejsze.

Anonimizacja to taki poziom przetworzenia, przy którym praktycznie nie da się już związać danych z konkretną osobą. W większości realistycznych projektów ML z wysoką granularnością danych zdrowotnych czy transakcyjnych pełna anonimizacja nie jest osiągalna bez zabicia użyteczności modelu.

Minimalny standard „na start”, który realnie obniża ryzyko:

• pseudonimizacja całego zbioru treningowego,
• trzymanie klucza do reidentyfikacji osobno i z ograniczonym dostępem,
• usuwanie oczywistych identyfikatorów i rzadkich kombinacji cech, które mogą ujawnić konkretną osobę.

To nie zdejmie z ciebie wymogów dla danych wrażliwych, ale znacząco obniży potencjalne skutki wycieku.

6. Czy predykcje modelu (np. ryzyko choroby) też są danymi wrażliwymi?

Tak. Jeżeli model przewiduje lub etykietuje cechę z katalogu danych wrażliwych (np. „wysokie ryzyko depresji”, „prawdopodobna przynależność do określonej grupy wyznaniowej”), to wynik predykcji sam w sobie jest daną wrażliwą. Nie ma znaczenia, że użytkownik takich danych nigdy nie podał wprost.

W praktyce trzeba więc:

• traktować zbiory wyników/model output jak osobne bazy wrażliwych danych, a nie jak „logi techniczne”,
• objąć je tym samym reżimem bezpieczeństwa i podstawy prawnej, co dane wejściowe,
• uwzględnić ten etap w DPIA – wiele zespołów o nim „zapomina” i wraca do tematu dopiero przy kontroli lub incydencie.

Najtańsze rozwiązanie organizacyjne: od razu w projektowej dokumentacji opisać, jakie nowe dane wrażliwe powstają w wyniku działania modelu i kto ma do nich dostęp.

7. Kiedy trzeba robić DPIA (ocenę skutków) dla systemu AI z danymi wrażliwymi?

DPIA jest potrzebna, gdy przetwarzanie może powodować wysokie ryzyko naruszenia praw lub wolności osób. W praktyce przy danych wrażliwych plus zautomatyzowane profilowanie lub podejmowanie decyzji (np. ocena zdolności kredytowej, kwalifikacja do terapii, scoring pracownika) odpowiedź zwykle brzmi: „tak, DPIA jest konieczna”.

Najważniejsze wnioski

• W projektach ML z danymi wrażliwymi cel jest podwójny: skuteczny model i jednocześnie ograniczenie ryzyka prawnego, wizerunkowego i finansowego – bez sensu optymalizować tylko jakość predykcji, jeśli później projekt zablokuje prawnik lub regulator.
• Dane wrażliwe to nie tylko oczywiste pola jak „choroba” czy „religia”, ale też cechy pochodne, agregaty i wnioski modelu; to, że kolumna nazywa się neutralnie, nie usuwa jej wrażliwego charakteru.
• „Zwykłe” dane mogą praktycznie stać się danymi wrażliwymi, gdy pozwalają z dużym prawdopodobieństwem odtworzyć np. stan zdrowia lub poglądy – wtedy cały projekt powinien być traktowany jak przetwarzanie danych wrażliwych, z pełnym reżimem RODO.
• Sam fakt, że po trenowaniu zostają „tylko wagi modelu”, nie zwalnia z obowiązków – regulator patrzy na cały proces, od zbioru treningowego po predykcje, jako na przetwarzanie danych wrażliwych, co oznacza dodatkowe zabezpieczenia, DPIA i ograniczenia podstawy prawnej.
• Modele mogą generować nowe dane wrażliwe w wynikach (np. prawdopodobieństwo choroby, orientacji czy przynależności związkowej); te predykcje stają się osobnym zbiorem danych wrażliwych, który trzeba objąć zgodami, podstawą prawną i zabezpieczeniami.
• Przetwarzanie danych wrażliwych obejmuje trzy poziomy: dane wejściowe, cechy przetworzone (feature engineering, embeddingi) i dane wyjściowe – jeśli którykolwiek z nich można powiązać z osobą i dotyczy sfer chronionych, projekt wymaga podejścia „high‑risk” z punktu widzenia RODO.

Bibliografia

• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO). Dziennik Urzędowy Unii Europejskiej (2016) – Definicje danych szczególnych kategorii, podstawy prawne, DPIA
• Wytyczne dotyczące oceny skutków dla ochrony danych (DPIA) i ustalania prawdopodobieństwa wysokiego ryzyka. Europejska Rada Ochrony Danych (2017) – Kryteria DPIA, wysokie ryzyko, przykłady systemów z danymi wrażliwymi
• Opinia 03/2013 w sprawie ograniczenia celu. Grupa Robocza Art. 29 (2013) – Zasada ograniczenia celu, ponowne wykorzystanie danych, w tym w ML
• Raport roczny Prezesa UODO – wybrane zagadnienia sektorowe. Urząd Ochrony Danych Osobowych – Praktyka organu w sprawach zdrowia, HR, marketingu i danych wrażliwych
• Artificial Intelligence and Data Protection. European Data Protection Supervisor (2020) – Analiza ryzyk AI dla prywatności, w tym profilowanie i dane wrażliwe
• OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data. OECD (2013) – Zasady minimalizacji, ograniczenia celu i bezpieczeństwa danych
• ISO/IEC 27701:2019 Security techniques – Extension to ISO/IEC 27001 and 27002 for privacy information management. ISO (2019) – Wymagania zarządzania informacjami prywatnymi, pseudonimizacja, DPIA