Uczenie federacyjne: prywatność z definicji czy marketing? Aspekty prawne i etyczne

Czym jest uczenie federacyjne i skąd tyle obietnic prywatności

Podstawowy mechanizm działania uczenia federacyjnego

Uczenie federacyjne to podejście do trenowania modeli uczenia maszynowego, w którym surowe dane pozostają tam, gdzie powstały: na urządzeniach użytkowników lub w lokalnych silosach danych organizacji. Zamiast kopiować dane do jednego centralnego serwera, centralny komponent (tzw. koordynator) rozsyła do uczestników wstępny model, a ci lokalnie aktualizują jego parametry na swoich danych.

Każdy uczestnik wykonuje kilka kroków treningu na własnym zbiorze danych, a następnie odsyła do koordynatora aktualizacje modelu (np. gradienty, zmienione wagi), a nie same dane. Koordynator agreguje te aktualizacje (np. uśrednia je) i tworzy nową wersję globalnego modelu, którą ponownie rozsyła do uczestników. Proces powtarza się wielokrotnie, aż do osiągnięcia zadowalającej jakości modelu.

Kluczowy element: surowe dane nie opuszczają urządzenia lub infrastruktury właściciela. Dane użytkownika nie są wysyłane do chmury w postaci pełnych rekordów, lecz wpływają na model „pośrednio”, przez modyfikację jego parametrów. W teorii oznacza to mniejsze ryzyko gromadzenia i wycieku ogromnych, scentralizowanych baz danych.

Nie oznacza to jednak, że w systemie nie ma przepływu informacji o użytkowniku. Aktualizacje modelu też mogą nieść informacje o danych wejściowych. Z prawnego i etycznego punktu widzenia istotne jest więc nie tylko to, gdzie leżą dane źródłowe, ale także to, co da się wywnioskować z parametrów modelu i metadanych generowanych w procesie trenowania.

Czym uczenie federacyjne różni się od klasycznego treningu modeli

W klasycznym podejściu do uczenia maszynowego dane z różnych źródeł są kopiowane do jednego centralnego repozytorium (np. hurtownia danych w chmurze). Tam następuje czyszczenie, łączenie, etykietowanie i trening modelu. Architektura jest stosunkowo prosta, ale prowadzi do wysokiej koncentracji danych i związanych z tym ryzyk: wycieków, nieuprawnionego dostępu, wtórnego wykorzystania danych w innych celach.

Uczenie federacyjne zmienia ten układ sił:

• dane pozostają rozproszone (na telefonach, serwerach szpitali, systemach banków),
• centralny element systemu operuje na parametrach modelu, a nie na rekordach danych,
• aktualizacje są przekazywane okresowo i mogą być dodatkowo zabezpieczone (szyfrowanie, secure aggregation, różnicowa prywatność),
• trening jest bliżej krawędzi sieci („edge”), co zmniejsza transfer dużych zbiorów danych.

Od strony organizacyjnej różnice są jeszcze wyraźniejsze. W klasycznym modelu jedna organizacja często staje się „wielkim administratorem danych”, który zbiera informacje od licznych podmiotów. W modelu federacyjnym poszczególne organizacje mogą pozostać administratorami własnych baz, operując tylko nad wspólnym algorytmem. Z prawnego punktu widzenia rodzi to inne relacje: współadministrację, powierzenia, podział odpowiedzialności.

Skąd marketingowa narracja o „prywatności z definicji”

Producenci rozwiązań AI chętnie komunikują uczenie federacyjne jako technikę gwarantującą „prywatność z definicji” (privacy by design). Argumentują, że skoro dane nie są centralizowane, to ryzyko ich naruszenia znacząco spada, a rozwiązanie „z natury” wspiera zgodność z RODO i innymi regulacjami. W broszurach sprzedażowych często widać skróty myślowe: „nie zbieramy danych”, „nie przetwarzamy danych osobowych”, „wszystko dzieje się lokalnie”.

Ta narracja ma w sobie ziarno prawdy. Brak centralnego gromadzenia pełnych rekordów faktycznie redukuje część klasycznych wektorów ataku. Zmniejsza też motywację cyberprzestępców: jedna skompromitowana baza nie odsłania danych milionów użytkowników naraz. Dla regulatorów jest to sygnał, że organizacja próbuje wdrażać zasady minimalizacji i ograniczania ryzyka.

Jednocześnie jest to narracja niebezpiecznie uproszczona. Uczenie federacyjne nie oznacza automatycznie, że dane przestają być danymi osobowymi, ani że modelu nie da się nadużyć. Istnieją ataki rekonstruujące dane treningowe z parametrów modelu, ataki membership inference (wnioskowanie, czy konkretna osoba znajdowała się w zbiorze treningowym), czy ataki na kanały komunikacji. Mówiąc o „prywatności z definicji”, łatwo przejść z uczciwej komunikacji do marketingu, który wprowadza w błąd użytkowników i potencjalnie regulatorów.

Najczęstsze obszary zastosowań i specyfika ryzyka

Uczenie federacyjne bywa wdrażane tam, gdzie dane są szczególnie wrażliwe lub rozproszone:

• zdrowie – konsorcja szpitali trenujące wspólne modele diagnostyczne bez kopiowania dokumentacji pacjentów,
• bankowość i ubezpieczenia – wspólne modele wykrywania fraudów lub oceny ryzyka, przy zachowaniu danych klientów w systemach źródłowych,
• telekomunikacja – optymalizacja sieci, systemy rekomendacji ofert, analiza ruchu przy zachowaniu logów abonentów w lokalnych centrach danych,
• urządzenia mobilne – autokorekta, personalizacja asystentów głosowych, rekomendacje treści trenowane na telefonie użytkownika.

W każdej z tych branż pojawia się silna motywacja, by ograniczyć przepływ wrażliwych danych. Jednocześnie są to obszary objęte szczególnymi regulacjami i wysokimi oczekiwaniami etycznymi. Usprawnienie procesu szkolenia modeli nie zwalnia z obowiązku przejrzystości, rozliczalności, oceny wpływu na prawa i wolności osób, których dane dotyczą.

Jeśli organizacja traktuje „federated learning” wyłącznie jako etykietę marketingową, ignorując specyficzne ryzyka techniczne i prawne, może łatwo wpaść w pułapkę privacy washing – obiecywania prywatności bez realnego pokrycia w architekturze, umowach i procesach.

Jakie dane i role prawne pojawiają się w uczeniu federacyjnym

Administrator, podmiot przetwarzający i współadministrator w federacji

Uczenie federacyjne nie znosi obowiązków wynikających z RODO. Wymusza jedynie inne, często bardziej złożone przypisanie ról. Trzeba odpowiedzieć na pytanie: kto jest administratorem, kto działa jako podmiot przetwarzający, a kiedy pojawia się współadministracja.

Jeśli jedna organizacja wdraża uczenie federacyjne na własnych danych (np. bank trenuje model ryzyka kredytowego na danych z różnych oddziałów), rola administratora jest stosunkowo prosta: administratorem jest ten sam podmiot, który decyduje o celach i środkach przetwarzania danych w całej infrastrukturze. Dostawca technologii federacyjnej będzie najczęściej podmiotem przetwarzającym lub tylko dostawcą narzędzia, jeśli nie ma dostępu do danych lub parametrów niosących informacje o osobach.

Inaczej wygląda scenariusz, w którym kilka niezależnych organizacji (np. szpitale, banki) trenuje wspólny model na własnych zbiorach. Wtedy często dochodzi do współadministracji: podmioty wspólnie określają cel (stworzenie i utrzymanie modelu), ustalają zasady federacji i w podobnym stopniu wpływają na środki przetwarzania. W praktyce powinna to regulować pisemna umowa współadministracji, opisująca m.in. zakres odpowiedzialności, zasady informowania osób, obsługi ich praw.

Dodatkowo w architekturze pojawia się rola koordynatora lub agregatora. To podmiot (czasem jeden z uczestników, czasem odrębny usługodawca), który obsługuje serwer federacyjny, orchestruje rundy treningowe, przechowuje globalny model, może gromadzić logi techniczne. W zależności od tego, ilu ma faktyczny wpływ na cele i środki przetwarzania, może być on:

• podmiotem przetwarzającym (realizuje wyłącznie instrukcje administratorów),
• współadministratorem (współdecydowanie o architekturze, parametrach, politykach),
• odrębnym administratorem danych dotyczących np. własnego systemu monitoringu i utrzymania.

Bez precyzyjnego uporządkowania tych ról ryzyko konfliktów, luk w odpowiedzialności i sankcji regulacyjnych szybko rośnie. Uczenie federacyjne nie „maskuje” tego problemu – wręcz przeciwnie, uwypukla go.

Dane osobowe, dane zanonimizowane i zbiory pochodne w federated learning

W praktyce najwięcej nieporozumień dotyczy tego, czy w procesie uczenia federacyjnego w ogóle przetwarza się dane osobowe. Skoro dane pozostają na urządzeniu użytkownika, a do centralnego serwera trafiają „tylko gradienty”, wielu inżynierów zakłada, że regulacje o ochronie danych mają tu ograniczone zastosowanie.

RODO definiuje dane osobowe szeroko jako informacje o zidentyfikowanej lub możliwej do zidentyfikowania osobie fizycznej. Jeśli dane znajdują się na urządzeniu użytkownika, powiązane z jego kontem, numerem telefonu, identyfikatorem sprzętowym, to z prawnego punktu widzenia nadal są danymi osobowymi, nawet jeśli nie opuszczają urządzenia. Sam fakt, że przetwarzanie odbywa się lokalnie, nie wyłącza zastosowania przepisów: administrator odpowiada za operacje realizowane na tym urządzeniu w ramach jego usługi.

Osobnym zagadnieniem jest status parametrów modelu i przesyłanych do agregatora aktualizacji. Jeśli z aktualizacji można (bez nieproporcjonalnego wysiłku) odtworzyć dane dotyczące konkretnej osoby, albo przynajmniej potwierdzić jej udział w zbiorze treningowym, to taka aktualizacja może być uznana za dane osobowe. Jeśli natomiast zastosowano skuteczne techniki anonimizacji (np. secure aggregation, różnicowa prywatność), które uniemożliwiają powiązanie informacji z konkretną osobą, można argumentować, że są to dane anonimowe lub zbiory pochodne poza zakresem RODO.

Istnieje jednak duża szara strefa: modele i parametry, które teoretycznie mogą zostać zaatakowane (model inversion, membership inference), ale w praktyce wymaga to znacznych zasobów i wiedzy. Organy nadzorcze i sądy dopiero kształtują podejście do tego rodzaju pośrednich danych. Konserwatywne podejście organizacji polega na tym, aby przyjąć, że dopóki istnieje realistyczne ryzyko reidentyfikacji, należy traktować te informacje jak dane osobowe i zabezpieczyć je odpowiednio.

Ryzyka reidentyfikacji i ataki na aktualizacje modelu

Uczenie federacyjne bywa prezentowane jako naturalna tarcza ochronna przed wyciekiem danych. Tymczasem literatura naukowa pokazuje różne klasy ataków, które mogą w praktyce osłabiać tę narrację. Najważniejsze z perspektywy prawnej są ataki pozwalające:

• odtworzyć przybliżone dane wejściowe na podstawie gradientów lub parametrów modelu (model inversion),
• ustalić, czy dane konkretnej osoby były wykorzystane do treningu (membership inference),
• wydobyć z modelu konkretne rekordy pamięci (np. specyficzne frazy w modelach językowych).

W prostych scenariuszach federacyjnych aktualizacje są wysyłane do serwera w postaci niezaszyfrowanej lub z minimalnymi zabezpieczeniami. Jeśli atakujący (zewnętrzny lub wewnętrzny) uzyska dostęp do tych aktualizacji, może próbować rekonstruować dane osób. W niektórych badaniach pokazywano np. odtwarzanie obrazów twarzy czy zapytań tekstowych na podstawie gradientów pierwszych warstw modelu.

Z punktu widzenia RODO oznacza to, że aktualizacje modelu mogą w określonych warunkach stanowić dane osobowe lub przynajmniej dane pseudonimizowane, które nadal podlegają regulacjom. Projektant systemu nie może więc z góry zakładać, że „gradienty to nie dane osobowe”. Wymagana jest ocena ryzyka, testy podatności, a najlepiej wdrożenie technik ograniczających możliwość takich ataków (secure aggregation, clipping gradientów, różnicowa prywatność).

Telemetria, metadane i logi – często pomijany obszar ryzyka

Oprócz właściwych danych treningowych i parametrów modelu w systemach uczenia federacyjnego powstaje ogromna ilość informacji pomocniczych: logów, metadanych, danych telemetrycznych. Zawierają one m.in.: identyfikatory urządzeń, stemple czasowe, informacje o wersji oprogramowania, błędach, aktywności użytkownika, jakości połączenia.

Te dane często są centralnie gromadzone i analizowane przez dostawcę usługi w chmurze lub zespół DevOps. Z technicznego punktu widzenia służą utrzymaniu systemu, ale z prawnego mogą być równie wrażliwe, jak główne dane treningowe. Z ich pomocą da się niekiedy zidentyfikować użytkownika, śledzić jego aktywność, a nawet wnioskować o jego zachowaniach i preferencjach.

W kontekście RODO metadane i logi są więc osobnym strumieniem przetwarzania, który wymaga:

• wyraźnego opisania w rejestrze czynności przetwarzania,
• osobnej oceny podstawy prawnej (np. prawnie uzasadniony interes),
• określenia okresów przechowywania i zasad anonimizacji,
• wdrożenia środków technicznych (maskowanie, pseudonimizacja, ograniczenia dostępu).

Ignorowanie logów i telemetryki w projektach uczenia federacyjnego prowadzi do sytuacji, w której „front” systemu jest projektowany zgodnie z zasadami privacy by design, natomiast „zaplecze operacyjne” działa jak w tradycyjnym, scentralizowanym modelu, z pełną widocznością aktywności użytkownika po stronie dostawcy.

„Prywatność z definicji”: co rzeczywiście wynika z RODO i zasad privacy by design

Artykuł 25 RODO a projektowanie systemów AI

Minimalizacja danych i ograniczenie celu w architekturze federacyjnej

Artykuł 25 RODO łączy się bezpośrednio z zasadami z art. 5, w szczególności z minimalizacją danych i ograniczeniem celu. Uczenie federacyjne bywa przedstawiane jako ich naturalna realizacja, ale w praktyce dużo zależy od konkretnych wyborów projektowych.

Minimalizacja danych oznacza, że administrator nie powinien gromadzić ani przetwarzać więcej informacji, niż jest to niezbędne dla zdefiniowanego celu. W federated learning często jest to spełnione „z definicji” w tym sensie, że dane źródłowe nie są kopiowane na centralny serwer. To jednak tylko część obrazu. Wciąż trzeba rozważyć, czy:

• zakres danych lokalnie używanych do treningu nie jest zbyt szeroki w stosunku do celu (np. zbieranie pełnej historii lokalizacji, gdy wystarczy agregowana aktywność),
• nie dochodzi do wtórnego wykorzystania parametrów modelu lub metadanych w nowych celach, które wykraczają poza pierwotne uzasadnienie (np. profilowanie marketingowe na podstawie modelu opracowanego dla bezpieczeństwa),
• centralnie zbierane logi, statystyki i telemetryka nie stają się de facto pełnym odwzorowaniem zachowań użytkowników, mimo że same dane treningowe pozostają na urządzeniu.

Ograniczenie celu wymaga natomiast, aby już na etapie projektowania federacji precyzyjnie zdefiniować, do czego służy wspólny model i jakie dalsze przetwarzania są dopuszczalne. W razie współadministracji każdy z uczestników powinien wiedzieć, czy może np.:

• wykorzystywać globalny model do własnych, dodatkowych analiz,
• łączeć parametry modelu z innymi, lokalnymi zbiorami, tworząc nowe cele przetwarzania,
• udostępniać model podmiotom trzecim (np. spółkom z grupy kapitałowej, partnerom technologicznym).

Jeśli te kwestie nie zostaną przełożone na konkretne zapisy umowne i dokumentację wewnętrzną, „privacy by design” pozostaje wyłącznie hasłem marketingowym. Z formalnego punktu widzenia łatwo wtedy o naruszenie zasady zgodności z celem i o konieczność poszukiwania nowych podstaw prawnych dla wtórnych zastosowań modelu.

Domyślna ochrona a konfiguracja klienta federacyjnego

Artykuł 25 wymaga także „ochrony danych w ustawieniach domyślnych” (privacy by default). W środowisku federated learning ma to bardzo konkretny wymiar: jak skonfigurowany jest klient na urządzeniu użytkownika lub w systemie uczestniczącej organizacji.

W szczególności chodzi o takie decyzje jak:

• czy udział w federacyjnym treningu jest automatycznie włączony dla wszystkich użytkowników, czy wymaga aktywnego włączenia (opt-in),
• jakie typy połączeń sieciowych są dopuszczone (np. tylko Wi-Fi vs. sieć komórkowa, nocne okna czasowe, aby ograniczyć wpływ na prywatność użytkownika w pracy),
• jakie kategorie danych mogą być wykorzystywane przez klienta (np. tylko dane z określonej aplikacji, a nie z całego urządzenia),
• jak długo przechowywane są lokalne bufory danych treningowych i logi błędów.

Jeżeli klient federacyjny w domyślnej konfiguracji „zasysa” możliwie szeroki zakres informacji, a ograniczenia trzeba samodzielnie aktywować w zaawansowanych ustawieniach, trudno mówić o zgodności z art. 25 ust. 2. Z punktu widzenia regulatora odpowiedzialność za te domyślne parametry spoczywa na administratorze, nawet jeśli są one zaszyte w bibliotekach dostawcy technologii.

Privacy by design a ocena wpływu na ochronę danych

W przypadku większych projektów z wykorzystaniem uczenia federacyjnego zwykle pojawia się obowiązek przeprowadzenia oceny skutków dla ochrony danych (DPIA). Zestawiając art. 25 i art. 35 RODO, efekt powinien być taki, że w dokumentacji DPIA widać przełożenie wymogów privacy by design na konkretne środki techniczne i organizacyjne.

DPIA w kontekście federated learning powinna obejmować m.in.:

• opis przepływów danych: co pozostaje lokalnie, jakie informacje (aktualizacje, metadane, logi) są wysyłane do serwera, w jakiej postaci,
• analizę ryzyka reidentyfikacji po stronie centralnej (w tym ataki na model i aktualizacje),
• identyfikację roli każdego uczestnika (administrator, podmiot przetwarzający, współadministrator) oraz obszarów wspólnej odpowiedzialności,
• wybór środków minimalizacji i kontroli dostępu: secure aggregation, różnicowa prywatność, ograniczenia retencji, izolacja środowisk,
• mechanizmy wykonywania praw osób, w szczególności prawa do sprzeciwu wobec profilowania i prawa do usunięcia danych.

Dobrze przygotowana DPIA nie jest więc „papierową przeszkodą”, ale centralnym elementem implementacji privacy by design. Pozwala także obronić się przed zarzutem, że hasło „danych nie wysyłamy na serwer” wystarczy do wykazania zgodności z RODO.

Techniczne fundamenty a konsekwencje prawne: federacja, agregacja, szyfrowanie

Modele federacji i ich wpływ na odpowiedzialność

Pod pojęciem „uczenie federacyjne” kryje się kilka różnych topologii. W zależności od przyjętej architektury różnie rozkłada się odpowiedzialność prawna i zakres obowiązków.

Najczęstsze scenariusze to:

• federacja scentralizowana – klasyczny serwer-agregator, który inicjuje rundy treningowe, wysyła wstępne wagi i zbiera aktualizacje. To model najbardziej „RODO‑podobny”: istnieje wyraźny punkt centralny, który zwykle jest administratorem lub głównym współadministratorem,
• federacja hierarchiczna – kilka warstw agregatorów (np. oddziały regionalne, następnie centrala). Na każdej warstwie może pojawiać się odrębny administrator lub podmiot przetwarzający, co komplikuje mapę odpowiedzialności oraz obowiązki informacyjne wobec osób,
• federacja peer‑to‑peer – brak stałego serwera centralnego, wagi są wymieniane między węzłami w bardziej rozproszony sposób. Z prawnego punktu widzenia trudniej tu odróżnić administratora od podmiotu przetwarzającego, a konstrukcja współadministracji może być jedynym sensownym rozwiązaniem.

W każdym z tych wariantów kluczowe jest pytanie, kto faktycznie decyduje o parametrach procesu uczenia (hyperparametrach, doborze cech, liczbie epok, kryteriach udziału w treningu). Tam zwykle znajdować się będzie centrum decyzyjne odpowiedzialne jako administrator, nawet jeśli fizycznie nie widzi surowych danych.

Secure aggregation a status danych na poziomie serwera

Jednym z głównych argumentów na rzecz prywatności w uczeniu federacyjnym są protokoły secure aggregation, które sprawiają, że serwer otrzymuje jedynie zagregowane sumy aktualizacji (lub podobną funkcję), bez wglądu w pojedyncze wkłady klientów.

Z perspektywy RODO taka zmiana architektury ma kilka konsekwencji:

• jeśli serwer widzi wyłącznie wyniki agregacji ponad określony próg liczby uczestników, a dodatkowo wprowadzane są losowe zakłócenia (np. mechanizmy różnicowej prywatności), można argumentować, że dane na serwerze są anonimowe lub co najmniej wysoko pseudonimizowane,
• ryzyko identyfikacji konkretnej osoby z poziomu centralnego systemu znacząco maleje – co może wpływać na ocenę obowiązków informacyjnych, analizę transferów danych do państw trzecich czy wymogi dotyczące umów powierzenia,
• ciężar odpowiedzialności za lokalne dane skupia się jeszcze wyraźniej po stronie właścicieli urządzeń/instancji lokalnych (np. operatora aplikacji na telefonie, szpitala zarządzającego własnym serwerem).

Nie oznacza to jednak, że secure aggregation automatycznie „wyłącza” RODO. Dopóki istnieje realistyczna możliwość powiązania wyników federacji z konkretnymi użytkownikami (np. poprzez inne kanały – logi, identyfikatory, dane o partycypacji w rundzie), nadal mówimy o przetwarzaniu danych osobowych. Secure aggregation jest wtedy środkiem bezpieczeństwa i minimalizacji, a nie pełną anonimizacją.

Szyfrowanie, homomorfia i tajemnica przedsiębiorstwa

Niektóre wdrożenia federated learning sięgają po bardziej zaawansowane techniki kryptograficzne, jak homomorficzne szyfrowanie czy protokoły wielostronnego obliczania (MPC). Pozwalają one na dokonanie pewnych obliczeń na zaszyfrowanych danych lub gradientach bez ich odszyfrowywania po stronie agregatora.

Z prawnego punktu widzenia takie rozwiązania:

• mogą istotnie zmniejszać ryzyko naruszenia poufności – w razie nieuprawnionego dostępu do serwera atakujący widzi tylko szyfrogramy,
• jednocześnie komplikują wykonywanie praw osób, np. prawa do usunięcia danych czy korekty – skoro system projektowo nie sięga do konkretnych rekordów, a jedynie do ich zaszyfrowanych reprezentacji, trzeba rozważyć, jak faktycznie zrealizować takie żądanie,
• często są wprowadzane także w celu ochrony tajemnicy przedsiębiorstwa (np. przed konkurencją lub innymi uczestnikami federacji), co może kolidować z przejrzystością wobec osób, których dane dotyczą.

Administrator powinien więc z jednej strony wykazać, że szyfrowanie jest elementem realizacji art. 32 (bezpieczeństwo przetwarzania) i art. 25 (privacy by design), a z drugiej – zapewnić operacyjne procedury obsługi praw jednostki. Sam argument „nie mamy dostępu do danych, bo są zaszyfrowane” rzadko wystarczy, jeśli jednocześnie czerpie się korzyści z przetwarzania informacji pochodzących z tych danych.

Logika modeli a zautomatyzowane podejmowanie decyzji

Federated learning często wykorzystuje się w scenariuszach wysokiego ryzyka: scoring kredytowy na telefonie, personalizacja ofert, filtrowanie treści, przewidywanie zaostrzeń chorób. Decyzje podejmowane na podstawie modeli trenowanych federacyjnie mogą być zautomatyzowanymi decyzjami wywołującymi skutki prawne lub podobnie istotnie wpływającymi na osobę (art. 22 RODO).

Kwestia decentralizacji treningu nie zmienia zasadniczo oceny art. 22. Jeżeli:

• decyzja jest oparta wyłącznie na przetwarzaniu zautomatyzowanym (w tym profilowaniu),
• brak jest istotnej, ludzkiej ingerencji w proces oceny przypadku,
• a skutkiem są poważne konsekwencje (np. odmowa kredytu, zawyżona składka ubezpieczeniowa, zablokowanie konta),

to niezależnie od tego, czy model był trenowany centralnie, czy federacyjnie, stosuje się ograniczenia z art. 22 oraz obowiązki informacyjne co do „istotnej informacji o logice” podejmowania decyzji. Uczenie federacyjne nie jest tu tarczą ochronną. Można wręcz powiedzieć, że utrudniona audytowalność i złożone łańcuchy odpowiedzialności (kilku współadministratorów, dostawcy technologii) zwiększają ciężar rzetelnego wyjaśnienia, jak działa system i kto za niego odpowiada.

Federated learning a RODO: podstawy prawne, obowiązki, dokumentacja

Dobór podstawy prawnej dla federacyjnego treningu

W praktyce wdrożeń podstawowym wyzwaniem jest ustalenie, na jakiej podstawie prawnej oprzeć samo uczestnictwo danych użytkownika w procesie federacyjnego uczenia. Najczęściej rozważane są:

• zgoda (art. 6 ust. 1 lit. a) – atrakcyjna marketingowo („uczestnicz w poprawianiu jakości usługi”), ale obarczona wymogiem dobrowolności, możliwości wycofania oraz zakazem łączenia z warunkiem świadczenia usługi,
• niezbędność do wykonania umowy (art. 6 ust. 1 lit. b) – jeśli poprawa modeli jest integralną częścią świadczonej usługi (np. personalizacja kluczowych funkcji aplikacji),
• prawnie uzasadniony interes administratora (art. 6 ust. 1 lit. f) – gdy celem jest rozwój i bezpieczeństwo produktu, ale można wykazać, że interes ten nie przeważa nad prawami i wolnościami użytkownika.

Zgoda jest szczególnie problematyczna w scenariuszach, w których uczenie federacyjne dotyczy funkcji „krytycznych” (np. wykrywanie nadużyć, bezpieczeństwo logowania). Trudno wówczas uznać, że odmowa udziału w treningu nie ma negatywnych konsekwencji. Często lepszym rozwiązaniem jest oparcie się na art. 6 ust. 1 lit. b lub f, przy jednoczesnym zapewnieniu prostego mechanizmu sprzeciwu wobec przetwarzania w celach rozwojowych (tam, gdzie nie jest ono niezbędne dla świadczenia usługi).

Obowiązki informacyjne w modelu rozproszonym

Informowanie osób, których dane dotyczą, w kontekście federated learning wymaga innego akcentu niż w tradycyjnych politykach prywatności. Poza klasycznym opisem kategorii danych i celów przetwarzania potrzebne są jasne wyjaśnienia:

• że część przetwarzania odbywa się lokalnie na urządzeniu lub w instancji kontrolowanej przez innego administratora (np. szpital, bank regionalny),
• jaką rolę pełni centralny agregator i jakie informacje otrzymuje (parametry modelu, statystyki, logi),
• czy i w jaki sposób uczestnictwo w federacji można wyłączyć, oraz jaki będzie to miało wpływ na jakość/zakres usługi,
• jakie środki techniczne wprowadzono w celu ograniczenia ryzyka reidentyfikacji (bez przesadnych szczegółów kryptograficznych, ale w sposób zrozumiały dla laika).

W projektach z wieloma współadministratorami dochodzi pytanie, który z nich odpowiada za przekazanie informacji i obsługę praw. W praktyce często przyjmuje się, że „pierwszy kontakt” użytkownika (np. szpital, który go przyjmuje, bank prowadzący jego konto) pełni główną rolę informacyjną, natomiast szczegółowe ustalenia trafiają do umowy współadministracji zgodnie z art. 26 RODO.

Realizacja praw osób, których dane dotyczą, w środowisku federacyjnym

Klasyczne prawa z rozdziału III RODO (dostęp, sprostowanie, usunięcie, ograniczenie, sprzeciw, przenoszenie danych) w architekturze federacyjnej stają się bardziej „rozproszone”. Trzeba odpowiedzieć nie tylko na pytanie, czy dane można usunąć lub poprawić, lecz także gdzie to zrobić i jak poinformować o tym wszystkie istotne podmioty.

Praktyczne problemy, które ujawniają się najczęściej:

• dostęp i informacja – użytkownik pyta, jakie dane są „w modelu”. W ujęciu stricte technicznym model przechowuje parametry, a nie rekordy danych, co utrudnia przedstawienie sensownego wyciągu. Trzeba więc przełożyć ten stan na język zrozumiały: „Twoje dane były użyte do trenowania modelu predykcyjnego służącego do X; nie przechowujemy w nim Twoich surowych danych, lecz wyłącznie parametry statystyczne”.
• prawo do usunięcia („bycia zapomnianym”) – organom ochrony danych coraz częściej prezentowane są argumenty, że „nie da się” usunąć wkładu konkretnej osoby z trenowanego modelu. Z punktu widzenia RODO jest to jednak kwestia projektowa i dokumentacyjna, a nie wygodny pretekst. Jeśli usunięcie wpływu jest nierealne w rozsądnych kosztach, trzeba przekonująco wykazać, czemu taki kompromis jest proporcjonalny do celu.
• ograniczenie przetwarzania i sprzeciw – użytkownik może żądać, aby jego dane nie brały udziału w kolejnych rundach treningu lub aby były wykorzystywane tylko w celach świadczenia usługi, a nie rozwoju produktu jako takiego. W uczeniu federacyjnym to w praktyce wymaga flag po stronie klienta oraz odpowiedniej logiki schedulerów po stronie serwera.

Na poziomie operacyjnym dobrze sprawdza się podejście, w którym żądania są obsługiwane w miejscu „najbliższym” użytkownikowi (np. w aplikacji banku, systemie szpitalnym), ale umowy wewnątrz federacji jasno zobowiązują pozostałych administratorów do synchronizacji efektów (np. wyłączenia danego identyfikatora z kolejnych rund).

DPIA dla projektów federacyjnych

Uczenie federacyjne z definicji dotyczy scenariuszy wykorzystania danych na dużą skalę i często wiąże się z wysokim ryzykiem. W wielu przypadkach konieczna będzie zatem ocena skutków dla ochrony danych (DPIA) zgodnie z art. 35 RODO.

Standardowe szablony DPIA trzeba rozszerzyć o aspekty charakterystyczne dla federacji, w szczególności:

• opis przepływu danych i ról – kto zbiera dane, kto uruchamia lokalne treningi, kto agreguje aktualizacje, kto dystrybuuje globalny model, jak wygląda cykl życia modelu (wersjonowanie, retrening, archiwizacja),
• analiza ryzyk specyficznych dla modeli – możliwość reidentyfikacji z gradientów lub parametrów, ataki typu model inversion i membership inference, ryzyko nadmiernego dopasowania do małych grup,
• interakcja z innymi systemami – logi błędów, systemy monitoringu i telemetryczne, które mogą okazać się „tylnymi drzwiami” dla danych osobowych, nawet jeśli sama federacja jest projektowana minimalistycznie,
• scenariusze awaryjne – co się dzieje, gdy jedna z instancji lokalnych zostanie przejęta, gdy wystąpi rozbieżność między konfiguracjami uczestników, gdy błąd w kodzie klienta spowoduje wysyłanie zbyt obszernych danych.

Dobrze przygotowana DPIA powinna też zawierać rozróżnienie pomiędzy ryzykami lokalnymi (u szpitala, banku, w aplikacji użytkownika) i centralnymi (na serwerze agregującym). Federated learning bywa przedstawiany jako rozwiązanie „niwelujące” ryzyka centralne, ale często prowadzi do koncentracji innych ryzyk – np. trudności w wykrywaniu nadużyć przez brak wglądu w dane surowe.

Rejestrowanie czynności przetwarzania i dokumentacja techniczna

Federacyjny trening zwykle wymaga odrębnego rejestru czynności przetwarzania, a przynajmniej wyraźnej pozycji w już istniejących rejestrach. Nie powinno to być dopisane jako jedno zdanie typu „rozwój modeli na danych klientów”.

W rejestrze warto odzwierciedlić m.in.:

• cel: rozwój/utrzymanie konkretnego modelu lub rodziny modeli (z odniesieniem do funkcji biznesowej – np. rekomendacje, wykrywanie nadużyć),
• kategorie danych: przybliżony opis tego, co trafia do procesów lokalnych (np. historia transakcji, logi zachowań w aplikacji), oraz tego, co jest wysyłane do agregatora (aktualizacje wag, gradienty, metadane o treningu),
• kategorie odbiorców: dostawca platformy federacyjnej, inni współadministratorzy, podmioty przetwarzające w zakresie utrzymania infrastruktury,
• okresy przechowywania: jak długo utrzymywane są lokalne dane treningowe, jak długo przechowywane są logi z procesu federacji, jak zarządza się kolejnymi wersjami modelu,
• opis środków bezpieczeństwa: nie tylko szyfrowanie, lecz także mechanizmy ograniczania udziału pojedynczych klientów, progi minimalnej liczby uczestników rundy, procedury aktualizacji oprogramowania klienckiego.

Niezależnie od formalnego rejestru, zespoły techniczne powinny utrzymywać dokumentację architektury na poziomie, który pozwala inspektorowi ochrony danych (DPO) i audytorom zrozumieć, co się faktycznie dzieje. Schemat przepływu, opis API, parametry secure aggregation, procedury rotacji kluczy – to materiały, które przy pierwszym pytaniu organu nadzorczego mogą okazać się kluczowe.

Transgraniczne transfery danych i miejsce agregatora

Uczenie federacyjne bywa przedstawiane jako sposób na ograniczenie transferów danych osobowych do państw trzecich. W praktyce sytuacja jest bardziej złożona.

Jeśli lokalne instancje (np. szpitale w UE) przetwarzają dane pacjentów wyłącznie na własnej infrastrukturze, a do podmiotu spoza EOG przesyłane są wyłącznie zaszyfrowane, zagregowane aktualizacje, można argumentować, że nie dochodzi do transferu danych osobowych w rozumieniu RODO. Warunkiem jest jednak bardzo rygorystyczna analiza ryzyka reidentyfikacji na poziomie serwera i powiązanie tego z realnymi możliwościami technicznymi odbiorcy.

W wielu projektach sytuacja jest mniej idealna:

• serwer agregujący działa w chmurze globalnego dostawcy, który ma dostęp administracyjny do infrastruktury,
• w protokołach pojawiają się identyfikatory klientów lub ich pseudonimy, które można zlinkować z innymi danymi,
• telemetria, logi błędów czy mechanizmy monitoringu trafiają poza EOG w formie mniej przetworzonej niż główny strumień uczenia.

W takich przypadkach transfer danych osobowych jest realny i trzeba go oprzeć na standardowych narzędziach (decyzja stwierdzająca odpowiedni stopień ochrony, standardowe klauzule umowne, ewentualnie wiążące reguły korporacyjne). Narracja „to tylko parametry modelu” nie zwalnia z oceny, czy odbiorca nie jest w stanie – samodzielnie lub z innymi danymi – odtworzyć informacji o osobach.

Warto też rozważyć, czy w ramach federacji da się „zlokalizować” agregację – np. poprzez regionalne serwery działające w EOG, a jedynie wymianę wysoce zanonimizowanych modeli między regionami. Takie podejście zmniejsza nie tylko ryzyka prawne, lecz także wrażliwość systemu na różnice regulacyjne między jurysdykcjami.

Relacja z regulacją AI (w szczególności EU AI Act)

Federated learning musi być analizowany nie tylko przez pryzmat RODO, lecz także nadchodzących i obowiązujących przepisów sektorowych dotyczących sztucznej inteligencji. W przypadku podmiotów działających w UE kluczowe znaczenie będzie mieć AI Act, który wprowadza kategorie systemów wysokiego ryzyka i szczególne obowiązki w obszarach takich jak dokumentacja techniczna, zarządzanie danymi treningowymi, nadzór ludzki oraz bezpieczeństwo.

Jeżeli federacyjnie trenowany system należy do kategorii wysokiego ryzyka (np. dotyczy oceny zdolności kredytowej lub dostępu do usług podstawowych), to:

• producenci systemu muszą udokumentować pochodzenie danych treningowych, ich jakość i reprezentatywność, nawet jeśli nie posiadają centralnego zbioru. Oznacza to w praktyce konieczność uzgodnienia standardów danych u wszystkich uczestników federacji oraz procesów walidacji lokalnej,
• architektura federacyjna powinna uwzględniać wymogi nadzoru ludzkiego – łatwiejsze wyjaśnienie działania systemu, możliwość audytu lokalnych i globalnych modeli, ścieżki eskalacji w przypadku błędów predykcji,
• konieczne jest prowadzenie rejestrów treningów (kiedy, na jakich danych, w jakich konfiguracjach odbywały się kolejne rundy federacyjne) oraz identyfikowanie wersji modeli wdrażanych u użytkowników końcowych.

Interesujące napięcie pojawia się między obowiązkiem przejrzystości i audytowalności a ochroną tajemnicy przedsiębiorstwa oraz prywatności. Im bardziej rozproszony i „zakryty” jest proces treningu, tym trudniej wykazać zgodność z wymogami AI Act dotyczącymi jakości datasetów, zarządzania ryzykiem czy wyjaśnialności. Z punktu widzenia compliance lepiej mieć mniej efektowną, ale dobrze audytowalną architekturę, niż skomplikowany system, którego działania nie potrafi wytłumaczyć ani zespół prawny, ani techniczny.

Etyczne napięcia: autonomia użytkownika, sprawiedliwość, przejrzystość

Uczenie federacyjne bywa sprzedawane jako rozwiązanie, które „oddaje dane użytkownikowi”, bo nie opuszczają one jego urządzenia czy placówki. Z perspektywy etyki danych takie hasło wymaga doprecyzowania.

Autonomia użytkownika nie sprowadza się wyłącznie do informacji, że dane nie opuszczają jego telefonu. Kluczowe pytania brzmią:

• czy użytkownik ma realny wpływ na to, czy jego dane biorą udział w treningu (granularne zgody, ustawienia prywatności, tryb „tylko lokalne przetwarzanie”),
• czy zrozumiale wyjaśniono, jakie konsekwencje ma wyłączenie udziału (gorsza personalizacja, dłuższy czas odpowiedzi, brak pewnych funkcji),
• czy nie dochodzi do ukrytego „karania” za większą prywatność – np. ograniczania funkcjonalności w sposób niewspółmierny do udziału danych w uczeniu.

Po drugie, sprawiedliwość i brak dyskryminacji. W federacji każdy uczestnik (np. szpital, region, segment użytkowników) ma własny rozkład danych. Jeśli dane z niektórych grup trafiają do treningu rzadziej (bo mają słabszą infrastrukturę, starsze urządzenia lub gorszą łączność), ich reprezentacja w modelu będzie niższa. Federated learning może w takim scenariuszu utrwalać istniejące nierówności, choć na papierze „wszyscy uczestniczą na równych zasadach”.

Wreszcie przejrzystość. Nawet jeśli system spełnia formalne wymogi RODO i AI Act, zaufanie społeczne wymaga dodatkowego wysiłku komunikacyjnego. Zamiast ogólników typu „twoje dane uczą nasz model w bezpieczny sposób”, lepiej działają proste, konkretne komunikaty:

• „Twoje dane finansowe nie są wysyłane na serwer. Zamiast tego na Twoim telefonie powstaje mała porcja zmian modelu, które potem łączymy z podobnymi zmianami tysięcy innych użytkowników”.
• „Możesz wyłączyć udział w uczeniu, ale model będzie wtedy uczył się na danych innych osób, co może nieco obniżyć dopasowanie rekomendacji do Twojej sytuacji”.

Etycznie wątpliwe są scenariusze, w których federated learning jest wykorzystywany jako narzędzie „etycznego greenwashingu” – czyli jedynie kosmetyczne przeprojektowanie architektury, bez realnej zmiany w zakresie kontroli użytkownika, transparentności celów czy ograniczenia poboru danych. Sama decentralizacja nie rozwiązuje problemu nadmiernego gromadzenia informacji ani nie likwiduje asymetrii sił między dużym dostawcą technologii a pojedynczym użytkownikiem.

Minimalizacja danych i ograniczenie celu w praktyce federacji

Art. 5 RODO wprowadza zasady minimalizacji danych i ograniczenia celu. W federated learning ich realizacja wygląda nieco inaczej niż w modelach scentralizowanych.

Po stronie lokalnej minimum to:

• wyraźne ograniczenie, które pola trafiają do procesu treningu – nie każdy atrybut użyteczny z perspektywy analitycznej jest zgodny z zasadą minimalizacji; przykładowo, dane lokalizacji o wysokiej rozdzielczości często można zastąpić informacją o regionie lub typie miejsca,
• separacja danych operacyjnych od danych treningowych – to, że aplikacja przetwarza dane w celu świadczenia usługi (np. bieżące transakcje), nie oznacza, że wszystkie te dane automatycznie mogą służyć do treningu modelu; osobne flagowanie i przepływy minimalizują ryzyko „pełzającego” rozszerzania celu,
• lokalne czyszczenie i retencja – decyzja, jak długo dane mogą być używane do kolejnych iteracji treningu, powinna być jasno określona; inaczej łatwo powstaje niejawne archiwum zachowań użytkownika w pamięci urządzenia lub serwera lokalnego.

Po stronie centralnej minimalizacja sprowadza się do rygorystycznego projektowania interfejsu federacyjnego: jakie metadane są przesyłane wraz z gradientami (np. informacja o typie urządzenia, wersji aplikacji, regionie), czy są one rzeczywiście niezbędne i czy nie prowadzą do niezamierzonej segmentacji użytkowników.

Najczęściej zadawane pytania (FAQ)

Czym dokładnie jest uczenie federacyjne i jak działa w praktyce?

Uczenie federacyjne to sposób trenowania modeli AI, w którym surowe dane pozostają tam, gdzie powstały – na telefonach użytkowników, w systemach szpitali czy banków – i nie są kopiowane do jednej, centralnej bazy. Zamiast tego centralny koordynator wysyła do uczestników wstępny model, a oni lokalnie uczą go na własnych danych.

Po kilku krokach treningu uczestnicy odsyłają do koordynatora tylko zaktualizowane parametry modelu (np. gradienty, wagi), bez samych rekordów danych. Koordynator je agreguje (np. uśrednia) i z tego tworzy nową wersję globalnego modelu, którą znów rozsyła dalej. Cykl powtarza się wielokrotnie, aż model osiągnie oczekiwaną jakość.

Czy uczenie federacyjne automatycznie spełnia wymagania RODO?

Nie. Uczenie federacyjne może ułatwiać zgodność z RODO, bo ogranicza centralne gromadzenie danych, ale samo w sobie nie „magicznie” spełnia wszystkich wymogów. RODO obowiązuje tak samo, jeśli z parametrów modelu lub metadanych da się zidentyfikować osobę lub wywnioskować o niej informacje.

W każdym projekcie trzeba osobno ustalić role prawne (administrator, podmiot przetwarzający, współadministrator), cele i podstawy prawne przetwarzania, przejrzystą informację dla osób, ocenę ryzyka oraz środki bezpieczeństwa (np. szyfrowanie, secure aggregation, różnicowa prywatność). Uczenie federacyjne jest tylko elementem architektury, a nie „tarczą ochronną” przed RODO.

Czy w uczeniu federacyjnym w ogóle przetwarza się dane osobowe?

W wielu wdrożeniach – tak. Dane osobowe są przetwarzane lokalnie, na urządzeniach lub w systemach źródłowych. To, że nie są wysyłane do chmury jako pełne rekordy, nie oznacza, że przestają być danymi osobowymi ani że RODO przestaje obowiązywać.

Co więcej, aktualizacje modelu (gradienty, wagi) oraz logi techniczne mogą zawierać informacje pozwalające na wnioskowanie o osobach, np. wrażliwość modelu na określone dane. Dlatego ocena, czy mamy do czynienia z danymi osobowymi, powinna obejmować nie tylko surowe rekordy, ale także parametry modelu i metadane generowane w trakcie treningu.

Na czym polega ryzyko „privacy washing” przy uczeniu federacyjnym?

„Privacy washing” to sytuacja, w której uczenie federacyjne jest wykorzystywane głównie jako hasło marketingowe. Organizacja chwali się „prywatnością z definicji”, twierdzi, że „nie zbiera danych” czy „nie przetwarza danych osobowych”, choć w rzeczywistości model nadal może ujawniać informacje o użytkownikach, a procesy i umowy nie nadążają za technologią.

Ryzyko pojawia się wtedy, gdy komunikaty marketingowe ignorują znane wektory ataku (rekonstrukcja danych treningowych z modelu, membership inference, ataki na kanał komunikacji) oraz pomijają obowiązki prawne. W efekcie użytkownicy i regulatorzy mogą zostać wprowadzeni w błąd co do faktycznego poziomu ochrony prywatności.

Jakie ataki na prywatność są możliwe mimo zastosowania uczenia federacyjnego?

Nawet jeśli surowe dane nie opuszczają urządzenia, możliwe są ataki na sam model i infrastrukturę. W praktyce mówi się m.in. o:

• atakach rekonstrukcji danych treningowych z parametrów modelu,
• atakach membership inference – próbie ustalenia, czy konkretna osoba była w zbiorze treningowym,
• atakach na kanały komunikacji, jeśli aktualizacje modelu lub metadane nie są odpowiednio szyfrowane i agregowane.

Dlatego w poważnych wdrożeniach łączy się uczenie federacyjne z dodatkowymi technikami ochrony: secure aggregation, różnicową prywatnością, ścisłą kontrolą dostępu do logów oraz monitoringiem nadużyć.

Kto jest administratorem danych w projekcie uczenia federacyjnego?

To zależy od modelu współpracy. Jeśli jedna organizacja trenuje model na własnych, rozproszonych danych (np. różne oddziały tego samego banku), zazwyczaj to ona pozostaje administratorem, bo decyduje o celach i środkach przetwarzania. Dostawca technologii federacyjnej bywa wtedy podmiotem przetwarzającym albo jedynie dostawcą narzędzia, jeśli nie ma dostępu do danych ani parametrów niosących informacje o osobach.

W konsorcjach kilku niezależnych podmiotów (np. szpitale, banki) często dochodzi do współadministracji – strony wspólnie decydują o celu (stworzenie i utrzymanie modelu) i architekturze federacji. Dodatkowo pojawia się rola koordynatora/agregatora, który może być podmiotem przetwarzającym, współadministratorem lub odrębnym administratorem niektórych danych technicznych, w zależności od zakresu faktycznej kontroli i decyzji.

W jakich branżach uczenie federacyjne ma największy sens z perspektywy prawa i etyki?

Szczególnie dużo zyskują sektory z danymi bardzo wrażliwymi lub silnie rozproszonymi. Chodzi przede wszystkim o:

• ochronę zdrowia – wspólne modele diagnostyczne trenowane na danych szpitali bez centralnego kopiowania dokumentacji pacjentów,
• bankowość i ubezpieczenia – modele wykrywania fraudów i oceny ryzyka przy zachowaniu danych klientów w systemach źródłowych,
• telekomunikację oraz urządzenia mobilne – personalizacja usług (np. autokorekta, rekomendacje) trenowana lokalnie na telefonie.

W tych sektorach uczenie federacyjne może realnie ograniczyć przepływ wrażliwych danych, ale nie zastępuje obowiązków związanych z przejrzystością, rozliczalnością oraz oceną wpływu na prawa i wolności osób. Technika jest tylko jednym z elementów odpowiedzialnego projektu AI.

Najważniejsze wnioski

• Uczenie federacyjne ogranicza centralizację danych, bo surowe dane pozostają na urządzeniach lub w lokalnych systemach, a do koordynatora trafiają tylko aktualizacje modelu, nie pełne rekordy.
• Brak transferu surowych danych nie oznacza braku przetwarzania informacji o użytkownikach – z parametrów modelu i metadanych można wciąż wywnioskować cechy danych wejściowych, a nawet zrekonstruować fragmenty zbioru treningowego.
• Model federacyjny zmienia układ odpowiedzialności prawnych: zamiast jednego „wielkiego administratora danych” pojawia się sieć podmiotów z własnymi bazami i wspólnym algorytmem, co rodzi kwestie współadministracji, powierzeń i podziału ryzyka.
• Marketingowe hasła „prywatność z definicji” są tylko częściowo prawdziwe – federated learning redukuje część klasycznych wektorów ataku, ale nie eliminuje zagrożeń takich jak membership inference, rekonstrukcja danych czy ataki na kanały komunikacji.
• W sektorach wysokiego zaufania (zdrowie, bankowość, telekomunikacja, urządzenia mobilne) uczenie federacyjne może realnie zmniejszać ekspozycję wrażliwych danych, jednak nie zwalnia z obowiązków przejrzystości, rozliczalności i oceny wpływu na prawa osób.
• Stosowanie uczenia federacyjnego wyłącznie jako etykiety marketingowej, bez adekwatnych zabezpieczeń technicznych, umów i procedur, prowadzi do privacy washing – deklarowana ochrona prywatności nie ma wtedy pokrycia w praktyce.