Nowe wytyczne UODO i EDPB: jak bezpiecznie używać narzędzi AI i chmury w świetle RODO i transferu danych

Kontekst nowych wytycznych UODO i EDPB – co się zmieniło

Nowe wytyczne UODO i Europejskiej Rady Ochrony Danych (EDPB) znacząco zmieniają praktyczne podejście do korzystania z narzędzi AI i chmury. Organizacje, które do tej pory traktowały chmurę i sztuczną inteligencję jako „zwykłe narzędzia IT”, muszą przejść na tryb: systematyczna ocena ryzyka, rozliczalność i dokumentowanie decyzji. Nie chodzi wyłącznie o formalne zgromadzenie papierów, ale o spójny, udokumentowany proces pokazujący, że administrator danych panuje nad tym, co dzieje się z informacjami osobowymi.

Najważniejsze dokumenty i wytyczne dotyczące AI, chmury i transferów

Z perspektywy administratora, który korzysta z narzędzi AI i rozwiązań chmurowych, kluczowe są przede wszystkim:

• Wytyczne EDPB dotyczące pojęć administratora i podmiotu przetwarzającego – doprecyzowują, kiedy dostawca chmury lub narzędzia AI jest procesorem, współadministratorem, a kiedy samodzielnym administratorem.
• Wytyczne EDPB w zakresie transferu danych do państw trzecich po wyroku Schrems II – określają, jak mapować transfery, jak oceniać prawo państwa trzeciego oraz jakie stosować dodatkowe środki zabezpieczające.
• Standardowe klauzule umowne (SCC) Komisji Europejskiej – nowa generacja wzorców, które muszą być powiązane z realną oceną ryzyka transferu, a nie traktowane jako „magiczny papier” załatwiający wszystko.
• Komunikaty i stanowiska UODO dotyczące:
  • korzystania z narzędzi chmurowych przez administrację publiczną,
  • analizy ryzyka przy powierzaniu danych podmiotom spoza EOG,
  • bezpieczeństwa danych przy stosowaniu nowych technologii (w tym sztucznej inteligencji).
• Wytyczne EDPB dotyczące DPIA i listy operacji wymagających oceny skutków – większość wdrożeń narzędzi AI, zwłaszcza w sektorach wrażliwych, wpada w zakres obowiązkowego DPIA.
• EU AI Act (Akt o sztucznej inteligencji) – formalnie odrębne rozporządzenie, ale mocno wpływa na standard należytej staranności przy projektach AI, szczególnie w przypadku systemów wysokiego ryzyka.

Te dokumenty nie zawsze są bezpośrednio wiążące jak RODO, ale tworzą praktyczny standard staranności. Organy nadzorcze, w tym UODO, odwołują się do nich przy ocenie naruszeń, a sądy przy rozstrzyganiu odpowiedzialności cywilnej.

Nowy kierunek: ryzyko, rozliczalność i dowody działania

Wytyczne UODO i EDPB przesuwają nacisk z formalnej „zgodności z RODO” na realne zarządzanie ryzykiem. W praktyce oznacza to kilka elementów:

• każde wdrożenie systemu AI lub migracja do chmury wymaga oceny ryzyka i uzasadnienia przyjętych środków ochrony,
• administrator powinien być w stanie udokumentować proces decyzyjny: dlaczego wybrano danego dostawcę, jak zbadano jego praktyki, jakie parametry usługi uznano za krytyczne,
• relacja z dostawcą AI/chmury ma być przejrzysta i opisana umownie, z jasno określonym podziałem ról i zakresu odpowiedzialności,
• decyzje dotyczące transferów poza EOG muszą być konkretne i udokumentowane – ogólne stwierdzenie w polityce bezpieczeństwa nie wystarczy.

Rozliczalność w tym ujęciu nie jest wyłącznie „posiadaniem procedur”. Chodzi o to, aby w razie kontroli UODO lub incydentu naruszenia danych dało się krok po kroku odtworzyć, jak organizacja doszła do decyzji, że dane klientów mogą trafiać do konkretnego dostawcy chmurowego czy API AI.

Sektory najbardziej narażone i objęte zwiększoną uwagą

Choć wytyczne UODO i EDPB dotyczą wszystkich administratorów, praktycznie widać wyraźne skupienie na określonych branżach. Podmiotom z tych sektorów organy nadzorcze przyglądają się szczególnie uważnie ze względu na skalę i wrażliwość danych:

• Software house i dostawcy SaaS – często są procesorami dla setek klientów z różnych branż i krajów, przetwarzają duże wolumeny danych, coraz częściej integrują własne lub cudze modele AI.
• E-commerce i marketing – profilowanie użytkowników, personalizacja oferty, analiza zachowań z użyciem AI, integracje z wieloma zewnętrznymi dostawcami analityki i automatyzacji.
• Sektor finansowy (banki, fintechy, ubezpieczenia) – przetwarzanie danych o dużym ryzyku dla praw jednostki, scoring kredytowy, automatyczne decyzje, wymagania regulatorów sektorowych (KNF) oprócz RODO.
• Ochrona zdrowia i medtech – dane wrażliwe, systemy wspierające diagnostykę oparte na AI, chmura do przechowywania dokumentacji medycznej, ryzyko istotnych szkód osobistych przy błędach systemu.
• Administracja publiczna i edukacja – przetwarzanie masowych danych obywateli, e-usługi, rejestry publiczne, rosnące użycie rozwiązań chmurowych i narzędzi AI, w tym w szkołach i na uczelniach.

Organizacje z tych sektorów, które korzystają z rozwiązań chmurowych lub AI „na ogólnych warunkach dostawcy”, bez własnego DPIA i bez doprecyzowania umów, narażają się obecnie na poważne zarzuty naruszenia zasady rozliczalności i bezpieczeństwa danych.

Podstawy prawne przetwarzania danych w narzędziach AI i chmurowych

Nowe wytyczne UODO i EDPB wymuszają bardziej precyzyjne podejście do roli dostawcy AI/chmury oraz podstaw przetwarzania danych osobowych. Nie wystarczy założyć, że „to tylko narzędzie IT” działające jako podmiot przetwarzający. W wielu konfiguracjach dostawca staje się samodzielnym administratorem lub współadministratorem, zwłaszcza gdy wykorzystuje dane do własnych celów, np. do trenowania modeli.

Administrator, procesor czy współadministrator – jak klasyfikować dostawcę AI i chmury

Wytyczne EDPB wskazują, że o roli decyduje faktyczny wpływ na cele i sposoby przetwarzania, a nie marketingowa etykieta w ofercie:

• Administrator – decyduje o tym, „po co” i „jak” przetwarzane są dane. Typowo jest nim organizacja korzystająca z narzędzia AI/chmury dla własnych procesów (np. bank, sklep internetowy).
• Podmiot przetwarzający (procesor) – działa wyłącznie na udokumentowane polecenie administratora i nie wykorzystuje danych do własnych niezależnych celów. Przykładem może być chmurowa infrastruktura, która wyłącznie hostuje aplikację klienta, bez używania danych do dalszego trenowania modeli.
• Współadministrator – gdy obie strony wspólnie ustalają cele i główne sposoby przetwarzania, np. platforma AI rozwijana wspólnie przez dostawcę i klienta dla ich wspólnego projektu.

W praktyce wiele komercyjnych usług AI deklaruje, że dane użytkownika mogą być używane „do ulepszania usługi, trenowania modeli, analizy jakości”. Taka klauzula zwykle oznacza, że dostawca staje się samodzielnym administratorem w odniesieniu do tego celu. Administrator (klient) nadal odpowiada za przekazanie danych, ale nie może traktować tego przetwarzania jako zwykłego powierzenia z art. 28 RODO.

Najczęstsze podstawy przetwarzania dla narzędzi AI i chmurowych

Dobór podstawy prawnej zależy od roli podmiotu oraz charakteru procesu. Najczęściej spotykane podstawy przy AI i chmurze to:

• Realizacja umowy (art. 6 ust. 1 lit. b RODO) – np. przetwarzanie danych klienta w systemie CRM hostowanym w chmurze, obsługa zamówienia w sklepie internetowym, generowanie faktury.
• Uzasadniony interes administratora (art. 6 ust. 1 lit. f) – analiza logów, optymalizacja i bezpieczeństwo systemów, moderacja treści z użyciem AI, wewnętrzna analityka w chmurze, jeśli nie prowadzi do nadmiernej ingerencji w prywatność.
• Zgoda (art. 6 ust. 1 lit. a) – gdy proces jest dobrowolny, wykracza poza to, co strona mogłaby rozsądnie oczekiwać, albo obejmuje dane szczególnych kategorii bez innej podstawy prawnej (np. eksperymentalne narzędzie AI analizujące nagrania głosu pacjenta).
• Obowiązek prawny (art. 6 ust. 1 lit. c) – szczególnie w sektorze publicznym i regulowanym, np. przechowywanie dokumentacji przez określony czas w bezpiecznej chmurze, spełnienie wymogów nadzorcy finansowego.

Nowe wytyczne akcentują, że przy narzędziach AI nie można automatycznie powoływać się na uzasadniony interes tam, gdzie dane są wykorzystywane wtórnie do trenowania modeli dostawcy. W takim przypadku trzeba osobno przeanalizować cel dostawcy, zakres danych i spodziewania osób, których dane dotyczą.

Dane wejściowe a dane używane do dalszego uczenia modeli

W większości usług AI można wyróżnić dwa poziomy przetwarzania:

• dane wejściowe (input) – to, co użytkownik wysyła do systemu: tekst promptu, plik, nagranie, obraz; te dane są wykorzystywane bezpośrednio do wygenerowania odpowiedzi, realizacji zlecenia;
• dane wtórne – logi, metadane, wyselekcjonowane fragmenty treści, które dostawca zatrzymuje i może wykorzystać do:
  • doskonalenia modelu,
  • szkolenia nowych modeli,
  • tworzenia statystyk i analityki usługi,
  • wykrywania nadużyć i poprawy bezpieczeństwa.

Z perspektywy RODO są to często dwa odrębne cele przetwarzania. Administrator, który wprowadza dane osobowe do narzędzia AI, powinien:

• jasno zidentyfikować, czy dostawca wykorzystuje dane tylko do obsługi zlecenia (procesor), czy również dla własnych celów (administracja danych przez dostawcę);
• odrębnie przeanalizować podstawę prawną i zakres informacji przekazywanych osobom, których dane dotyczą, dla przetwarzania wtórnego.

W praktyce często konieczne staje się wyłączenie w panelu opcji „use data to improve our services” lub zawarcie aneksu, w którym dostawca zobowiązuje się nie wykorzystywać danych klientów do trenowania modeli. To jedno z najprostszych, a jednocześnie najbardziej skutecznych działań ograniczających ryzyko prawne.

Uzasadniony interes a trenowanie modeli – kiedy jest dopuszczalny

Dostawcy AI chętnie powołują się na uzasadniony interes przy trenowaniu modeli na danych klientów. EDPB i krajowe organy nadzorcze wskazują jednak na kilka warunków, które muszą być spełnione, aby taka podstawa była rzeczywiście legalna:

• osoba, której dane dotyczą, realistycznie może się spodziewać takiego wykorzystania jej danych w kontekście relacji z administratorem,
• cel trenowania modeli jest zgodny z pierwotnym celem zbierania danych lub pozostaje z nim w rozsądnym związku,
• przeprowadzono rzetelny test równowagi interesów, z uwzględnieniem ryzyka dla prywatności i możliwości sprzeciwu,
• osoba otrzymuje konkretne informacje o tym, że jej dane mogą być używane do uczenia modeli, oraz o prawie sprzeciwu.

W usługach, gdzie dane są szczególnie wrażliwe (zdrowotne, finansowe, dane dzieci) lub skala przetwarzania jest masowa, uzasadniony interes dla trenowania modeli będzie trudny do obrony. Najnowsza linia interpretacyjna skłania się do tego, że takie działania powinny być oparte na wyraźnej zgodzie albo wyłączone dla danych osobowych, chyba że dostawca zastosuje głęboką anonimizację po stronie technicznej.

Powierzenie czy udostępnienie danych – wpływ wytycznych na klasyfikację

Nowe wytyczne EDPB kładą nacisk na odróżnienie:

• powierzenia (przetwarzanie w imieniu administratora, art. 28 RODO) – wymaga umowy powierzenia, odpowiednich gwarancji technicznych i organizacyjnych, braku własnych celów przetwarzania po stronie procesora;
• udostępnienia (przekazania) danych innemu administratorowi – wymaga osobnej podstawy prawnej tego przekazania (np. zgoda, obowiązek prawny, uzasadniony interes), jasnego poinformowania osób, których dane dotyczą, oraz odpowiedniego DPIA, jeśli skala lub charakter są ryzykowne.

W kontekście narzędzi AI i chmury wiele modeli biznesowych, które dotąd klasyfikowano jako „czyste powierzenie”, po analizie okazuje się relacją między dwoma administratorami. Dzieje się tak zwłaszcza wtedy, gdy:

• dostawca ma swobodę decydowania o czasie przechowywania danych,
• samodzielnie ustala zakres i charakter logów,
• wykorzystuje dane do trenowania innych systemów lub analizy biznesowej na własne potrzeby.

Kluczowe wymagania RODO dla narzędzi AI – przejrzystość, minimalizacja, proporcjonalność

Jak mówić o AI i chmurze w klauzulach informacyjnych

EDPB i UODO oczekują, że opisy przetwarzania nie będą ogólnikowe. Jeśli organizacja korzysta z narzędzi AI lub usług chmurowych, powinna to nazwać wprost, zamiast ukrywać się za hasłem „zewnętrzni dostawcy usług IT”.

Klauzule informacyjne oraz polityki prywatności powinny obejmować co najmniej:

• rodzaj narzędzia – np. „system analizy treści oparty na sztucznej inteligencji”, „platforma chmurowa dostawcy X”;
• cele użycia AI/chmury – np. profilowanie marketingowe, moderacja treści, wykrywanie nadużyć, transkrypcja rozmów;
• podstawę prawną dla użycia danego narzędzia, w tym dla ewentualnego trenowania modeli na danych osobowych;
• kluczowe konsekwencje dla osób, których dane dotyczą – czy decyzje są w pełni automatyczne, czy istnieje możliwość weryfikacji przez człowieka, czy oceny mogą wpływać na dostęp do usług;
• informację o transferach – gdy dostawca AI/chmury ma siedzibę poza EOG lub wykorzystuje podwykonawców w krajach trzecich.

W przypadku bardziej złożonych zastosowań (np. scoring klienta za pomocą modelu predykcyjnego) praktycznym rozwiązaniem jest zastosowanie dwóch warstw informacji:

• warstwa skrócona – zrozumiały opis w miejscu zbierania danych,
• warstwa rozszerzona – szczegółowy opis w polityce prywatności lub dedykowanym dokumencie dotyczącym AI.

Minimalizacja danych w projektach AI

Modele AI „lubią” duże zbiory danych, natomiast RODO wymaga ograniczenia danych do niezbędnych. Ten konflikt rozwiązuje się na etapie projektowania:

• odrzucanie pól nadmiarowych – jeśli model klasyfikuje zgłoszenia serwisowe, nie ma powodu, by do modelu trafiały PESEL-e, pełne adresy czy notatki wrażliwe o zdrowiu;
• pseudonimizacja przed wysłaniem do chmury – lokalne zastępowanie identyfikatorów (ID klienta, numeru rejestracyjnego) losowymi kluczami, które tylko administrator może zmapować z powrotem;
• oddzielanie warstw danych – osobno dane operacyjne (potrzebne do świadczenia usługi), osobno dane do analityki i trenowania; nie ma obowiązku używania pełnych rekordów do każdego celu;
• logika „privacy by default” – domyślne ustawienia narzędzia AI/chmury powinny ograniczać zakres zbieranych danych i ich retencję, a dopiero świadome działanie administratora może je rozszerzyć.

W nowych wytycznych pojawia się też oczekiwanie, że administrator będzie potrafił uzasadnić dla każdego pola danych, po co jest wprowadzane do narzędzia AI. Ogólne wyjaśnienie typu „bo tego wymaga model” nie wystarcza bez analizy, czy model można dostroić na mniejszym lub zanonimizowanym zbiorze.

Proporcjonalność i ograniczenie przechowywania

Proporcjonalność oznacza, że intensywność przetwarzania (zakres, czas trwania, liczba odbiorców, stopień automatyzacji) powinna odpowiadać realnej potrzebie biznesowej i ryzyku dla osób. W projektach AI słychać często argument „zbierzmy wszystko, może się przyda”. Organy nadzorcze traktują to jako sygnał braku kontroli nad procesem.

Praktyczne mechanizmy zapewnienia proporcjonalności to m.in.:

• jasne okresy przechowywania dla danych używanych do treningu i do eksploatacji modelu – z reguły krótsze niż archiwizacja danych źródłowych;
• separacja środowisk – inne zasady przechowywania w środowisku developerskim, testowym i produkcyjnym; dane osobowe nie powinny bez potrzeby trafiać do środowisk dev/test;
• cykliczny przegląd przydatności danych – co pewien czas zespół biznes-IT-prawny sprawdza, czy konkretne zbiory są nadal potrzebne dla danego modelu; jeśli model nie jest już rozwijany, dane treningowe zwykle można zanonimizować lub usunąć;
• ograniczenie wglądu – dostęp do surowych danych wejściowych (np. nagrań klientów, treści wiadomości) tylko dla wąskiego grona osób technicznych; pozostali korzystają z zanonimizowanych lub zagregowanych informacji.

Decyzje oparte wyłącznie na zautomatyzowanym przetwarzaniu i profilowaniu

Narzędzia AI często prowadzą do decyzji, które mają skutki prawne lub podobnie istotne dla osób (odmowa kredytu, ocena ryzyka, selekcja kandydatów). W takich przypadkach wchodzą w grę ograniczenia z art. 22 RODO.

Jeśli w danym procesie występuje wyłącznie zautomatyzowane podejmowanie decyzji z istotnymi skutkami, administrator musi zapewnić:

• prawną podstawę z jednego z trzech wyjątków art. 22 ust. 2 (konieczność do zawarcia/wykonania umowy, prawo UE/państwa członkowskiego, wyraźna zgoda),
• prawo do interwencji człowieka – realne, a nie „na papierze”; osoba powinna móc zwrócić się o ponowne rozpatrzenie sprawy, z udziałem pracownika mającego uprawnienia do zmiany decyzji;
• wyjaśnienie logiki – w stopniu zrozumiałym dla osoby, której dotyczy decyzja; nie chodzi o kod źródłowy, ale o główne kryteria i czynniki, które zadecydowały o wyniku;
• ochronę przed dyskryminacją – testy modeli pod kątem nieuzasadnionych różnic w traktowaniu poszczególnych grup.

EDPB wprost łączy te obowiązki z przejrzystością i minimalizacją: jeśli model jest tak skomplikowany, że nie sposób wyjaśnić jego działania albo usunąć danych na żądanie, organizacja powinna rozważyć inny sposób realizacji celu lub inny typ modelu.

Ocena ryzyka i DPIA dla projektów z AI i chmurą

Kiedy DPIA staje się obowiązkowa przy AI

Wiele projektów AI i chmurowych automatycznie wpada w progi z art. 35 RODO. Typowe przesłanki to:

• systematyczne i szerokie profilowanie osób fizycznych (np. scoring behawioralny, predykcja rotacji pracowników),
• przetwarzanie na dużą skalę szczególnych kategorii danych (zdrowotnych, biometrycznych, dotyczących poglądów politycznych),
• innowacyjne zastosowanie technologii (nowe modele analizy obrazu, rozpoznawanie emocji, zdalna biometria),
• monitorowanie przestrzeni publicznej z użyciem AI, np. rozszerzone systemy CCTV z analizą zachowań.

Jeśli co najmniej jedna z przesłanek wiąże się ze zautomatyzowanymi decyzjami o istotnych skutkach, przyjmuje się, że DPIA powinna być przeprowadzona. Część krajowych organów (w tym UODO) publikuje listy typów przetwarzania, które „z zasady” wymagają DPIA – projekty AI pojawiają się na nich coraz częściej.

Jak strukturyzować DPIA dla narzędzi AI i chmurowych

DPIA dla klasycznego systemu IT nie wystarczy „skopiować i wkleić” dla rozwiązania AI. Potrzebne jest kilka dodatkowych elementów specyficznych dla uczenia maszynowego i chmury:

• opis architektury danych – skąd pochodzą dane treningowe, jakie są zbiory wejściowe, którędy przepływają dane między własnym systemem a chmurą/dostawcą AI;
• analiza cyklu życia modelu – etap trenowania, walidacji, wdrożenia, aktualizacji; każdy z etapów może wiązać się z innym ryzykiem i innymi odbiorcami danych;
• ocena ryzyka błędów modelu – prawdopodobieństwo i skutki błędnej klasyfikacji, fałszywych pozytywów/negatywów; szczególnie ważne w sektorze finansowym, zdrowotnym, HR;
• analiza uprzedzeń (bias) – czy dane treningowe lub architektura modelu mogą prowadzić do systematycznego faworyzowania lub dyskryminacji określonych grup;
• mechanizmy kontroli dostawcy – jakie logi i raporty udostępnia dostawca chmury/AI, czy istnieją audyty, certyfikaty, program bug bounty, jak wygląda zarządzanie incydentami.

W DPIA warto wyraźnie oddzielić ryzyka po stronie administratora (np. błędne dane wejściowe, brak nadzoru człowieka) od ryzyk po stronie dostawcy (np. podatności infrastruktury, wtórne użycie danych). Pozwala to później lepiej negocjować umowy i klauzule podziału odpowiedzialności.

Środki redukcji ryzyka specyficzne dla AI i chmury

Klasyczne środki bezpieczeństwa (szyfrowanie, kontrola dostępu, kopie zapasowe) to za mało, gdy system podejmuje decyzje lub generuje treści. Przy AI pojawiają się dodatkowe możliwości obniżenia ryzyka:

• human-in-the-loop – włączenie człowieka w kluczowe decyzje; w niektórych procesach wystarczy, że pracownik akceptuje wynik modelu przed przekazaniem go klientowi;
• limity i reguły biznesowe – model może proponować wynik, ale decyzja końcowa jest ograniczona dodatkowymi regułami (np. maksymalny zakres podwyżki ceny, minimalne wymagania zdolności kredytowej);
• kontrola jakości danych wejściowych – walidacja, normalizacja, odrzucanie niekompletnych lub sprzecznych danych, które mogłyby „zatruć” model, a przez to zwiększyć ryzyko błędnych decyzji;
• okresowe przetrenowywanie i testy regresji – modele starzeją się; konieczne są regularne testy, czy jakość i bezstronność predykcji nie spadają wraz ze zmianą zachowań użytkowników;
• lokalne przetwarzanie wrażliwych fragmentów – np. anonimizacja lub ekstrakcja tylko potrzebnych cech po stronie klienta, zanim dane trafią do chmury.

Organy nadzorcze patrzą życzliwiej na projekty, w których administrator potrafi pokazać nie tylko DPIA „na start”, ale też mechanizmy regularnego przeglądu ryzyka i kalibracji modeli.

Zaangażowanie inspektora ochrony danych i zespołów technicznych

Wytyczne UODO/EDPB podkreślają rolę inspektora ochrony danych (IOD) w projektach AI/chmurowych. IOD nie ma być jedynie „stemplującym” DPIA, lecz realnym uczestnikiem procesu projektowego. Oznacza to m.in.:

• udział w etapie koncepcyjnym – zanim zostanie wybrany dostawca lub architektura;
• przegląd modeli danych i umów z dostawcami z perspektywy ryzyka prawnego;
• rekomendacje ograniczeń funkcjonalnych – np. wyłączenia automatycznych decyzji w szczególnie wrażliwych scenariuszach;
• pomoc w zaprojektowaniu komunikacji z osobami, których dane dotyczą (klauzule, odpowiedzi na żądania, komunikaty przy błędach modelu).

Przy bardziej złożonych projektach naturalne staje się tworzenie zespołów multidyscyplinarnych, w których obok zespołów IT i data science pracują: prawnicy, IOD, biznes, a czasem przedstawiciele compliance lub etyki AI. EDPB wskazuje, że takie podejście jest jednym z elementów realnego wdrożenia zasady „privacy by design”.

Transfer danych poza EOG – USA, dostawcy globalni i Schrems II

Ocena łańcucha przetwarzania w chmurze

Przy globalnych dostawcach chmury i AI dane rzadko pozostają w jednym kraju. Nawet jeśli centrum danych jest fizycznie w UE, support, zdalna administracja czy backupy mogą obejmować podmioty z państw trzecich. EDPB oczekuje, że administrator zrozumie i udokumentuje cały łańcuch przetwarzania.

Praktycznie oznacza to potrzebę ustalenia:

• gdzie znajdują się główne centra danych, a gdzie kopie zapasowe,
• czy dostawca korzysta z podwykonawców spoza EOG (w tym centrów wsparcia technicznego),
• czy dane są dostępne zdalnie dla personelu z krajów trzecich nawet wtedy, gdy są fizycznie przechowywane w EOG,
• jakie środki techniczne ograniczają możliwość dostępu (np. szyfrowanie end-to-end z kluczami u klienta).

Bez tej mapy przepływów trudno prawidłowo ocenić zgodność z wyrokiem Schrems II i dobrać właściwe zabezpieczenia dla transferów.

Standardowe klauzule umowne i dodatkowe środki

Po Schrems II samo podpisanie standardowych klauzul umownych (SCC) z dostawcą spoza EOG nie wystarcza. Konieczna jest ocena, czy w danym kraju istnieją przepisy umożliwiające nadmierny dostęp władz do danych, oraz czy można temu przeciwdziałać środkami technicznymi lub organizacyjnymi.

Typowe „dodatkowe środki” obejmują:

• szyfrowanie danych w spoczynku i w tranzycie z zarządzaniem kluczami wyłącznie po stronie administratora lub europejskiego podmiotu pośredniczącego;

Ocena prawa państwa trzeciego i realnego ryzyka

EDPB i UODO oczekują, że administrator nie ograniczy się do ogólnej formułki o „podwyższonym ryzyku”, ale przeanalizuje przynajmniej na poziomie wysokiego poziomu otoczenie prawne państwa trzeciego. Nie chodzi o pełną ekspertyzę prawną, ale o odpowiedź na kilka kluczowych pytań:

• czy przepisy o dostępie służb do danych przewidują jakiekolwiek ograniczenia, kontrolę sądową, środki zaskarżenia,
• czy istnieją obowiązki masowej inwigilacji lub szeroko zakrojone programy przechwytywania danych (w tym dotyczące dostawców chmury),
• czy osoby spoza danego kraju – w szczególności obywatele UE – mają realne środki ochrony prawnej,
• czy praktyka organów (raporty NGO, wyroki sądów międzynarodowych) wskazuje na systemowe naruszenia praw do prywatności.

Taką analizę dobrze jest oprzeć na publicznie dostępnych źródłach (raporty instytucji UE, ENISA, EDPB, krajowych organów, renomowanych organizacji pozarządowych). Nawet jeśli jest to opis skrócony, powinien być konkretny, a nie stanowić czystej „kopiuj-wklej” z dokumentacji dostawcy.

Jeżeli ocena wykaże, że ryzyka nie da się ograniczyć (np. z powodu obowiązku udostępniania danych służbom bez kontroli sądowej), należy rozważyć inne opcje: lokalnego dostawcę w EOG, model „sovereign cloud”, pełną pseudonimizację danych lub rezygnację z danej funkcjonalności.

Praktyczne przykłady dodatkowych zabezpieczeń przy transferach

W praktyce projekty AI i chmurowe stosują kombinację środków. Najczęściej spotykane rozwiązania to:

• pseudonimizacja po stronie klienta – dane identyfikujące osoby (imiona, nazwiska, identyfikatory klientów) są zastępowane losowymi tokenami jeszcze przed wysłaniem do chmury; dostawca nie ma możliwości samodzielnej reidentyfikacji;
• separacja ról i funkcji – system w chmurze przetwarza tylko dane niezbędne do trenowania i inferencji, natomiast decyzja końcowa wraz z identyfikacją osoby zapada w systemie lokalnym;
• lokalne przechowywanie najwrażliwszych atrybutów – np. dane medyczne są trzymane w systemie szpitalnym, a do chmury wysyłane są wyłącznie wektory cech lub zanonimizowane obrazy;
• modele „bring your own key” (BYOK) i „hold your own key” (HYOK) – klucze szyfrujące przechowuje i obsługuje wyłącznie administrator lub podmiot z EOG, a dostawca ma dostęp do danych jedynie w formie zaszyfrowanej;
• granulowane logowanie i alerty dostępu – integracja z SIEM/SOC, który monitoruje nietypowe wzorce dostępu administracyjnego u dostawcy (np. logowanie z nowego regionu, nagły wzrost pobierania danych).

Przy większych projektach warto wymusić na dostawcy udział w ćwiczeniach typu „table-top” dotyczących scenariusza żądania dostępu do danych przez władze państwa trzeciego: jakie procedury zostaną uruchomione, kto odpowiada za poinformowanie administratora, czy żądanie może zostać zakwestionowane.

Ocena proporcjonalności transferu a cele biznesowe

Wytyczne EDPB kładą nacisk na to, aby transfer danych poza EOG był nie tylko formalnie zabezpieczony, ale też proporcjonalny wobec realizowanego celu. Oznacza to obowiązek zadania kilku pytań:

• czy ten sam rezultat można osiągnąć, korzystając z infrastruktury wyłącznie w EOG lub on-premise,
• czy rzeczywiście konieczne jest przesyłanie danych osobowych, czy wystarczy ich zanonimizowana lub zsyntetyzowana postać,
• czy zakres danych przekazywanych dostawcy jest zawężony do tego, co niezbędne – czy nie trafiają tam dane „na zapas”,
• czy czas retencji w infrastrukturze poza EOG jest skrócony do minimum technicznie możliwego.

Jeżeli analiza prowadzi do wniosku, że transfer jest nadmierny, organy nadzorcze mogą zakwestionować nie tylko sam mechanizm prawny (SCC), lecz także wybór rozwiązania z punktu widzenia zasady minimalizacji i privacy by design.

Umowy z dostawcami chmury i AI – co zmienić po wytycznych

Precyzyjne określenie ról: administrator, procesor, współadministrator

Przy złożonych rozwiązaniach AI rola stron nie zawsze jest oczywista. Dostawca zwykle twierdzi, że działa wyłącznie jako procesor (podmiot przetwarzający), ale w praktyce może wykorzystywać dane klienta do własnych celów – np. trenowania uniwersalnych modeli. W świetle nowych wytycznych wymaga to klarownego uporządkowania.

Umowa powinna jednoznacznie określać:

• czy i w jakim zakresie dostawca może samodzielnie decydować o celach i sposobach przetwarzania danych (wtedy jest współadministratorem lub odrębnym administratorem w tym zakresie),
• jakie kategorie danych są przetwarzane wyłącznie w imieniu klienta, a jakie – jeśli w ogóle – mogą być wykorzystywane przez dostawcę we własnym interesie (np. do poprawy bezpieczeństwa usług),
• czy dane wykorzystywane do trenowania modeli są anonimizowane, czy pozostają danymi osobowymi,
• w jakim zakresie dostawca może samodzielnie angażować podprocesorów oraz na jakich warunkach klient ma prawo sprzeciwu.

Jeżeli dostawca zastrzega sobie szerokie, nieograniczone prawo do „wykorzystywania danych klienta dla dowolnych celów rozwoju usług”, z perspektywy RODO jest to sygnał ostrzegawczy. Taka klauzula utrudnia wykazanie zgodności z zasadami ograniczenia celu i przejrzystości.

Kluczowe postanowienia umowy powierzenia przetwarzania

Standardowy „załącznik RODO” dostawcy chmury rzadko wystarcza, jeśli mówimy o generatywnym AI, trenowaniu modeli czy globalnej infrastrukturze. Warto domagać się doprecyzowania kilku obszarów:

• instrukcje administratora – katalog czynności, które dostawca może wykonywać na danych; należy wyraźnie wskazać, które operacje są zakazane (np. użycie danych do budowy modeli ogólnych);
• logi i mechanizmy nadzoru – prawo administratora do otrzymywania logów dostępu, raportów bezpieczeństwa, wyników audytów czy certyfikatów (ISO, SOC 2, własne programy compliance),
• współpraca przy realizacji praw osób – praktyczny opis tego, jak dostawca pomaga w realizacji prawa do usunięcia, sprostowania, ograniczenia, sprzeciwu czy przenoszenia danych, w tym w kontekście modeli AI;
• testy i audyty – czy klient ma prawo przeprowadzić audyt (samodzielnie lub przez zewnętrzny podmiot), jak często, w jakim zakresie i na jakich zasadach kosztowych;
• incydenty i naruszenia – czas reakcji, sposób powiadomienia, zakres udostępnianych informacji (np. logi, przyczyny incydentu, podjęte środki naprawcze),
• lokalizacja danych – zobowiązanie do przechowywania i przetwarzania danych w określonych regionach, warunki ewentualnego ich przeniesienia, informowanie o zmianach infrastruktury.

Dla wielu organizacji kluczowa będzie też klauzula o odpowiedzialności kontraktowej – czy dostawca bierze na siebie choćby część ryzyka finansowego za naruszenia, które powstaną z jego winy (np. rażące zaniedbania bezpieczeństwa).

Specyficzne klauzule dla modeli trenowanych na danych klienta

Coraz więcej dostawców oferuje trenowanie lub dostrajanie modeli na danych dostarczonych przez klienta. Z perspektywy RODO i wytycznych EDPB takie usługi generują kilka dodatkowych wymogów umownych:

• zakres wykorzystania danych treningowych – czy dane klienta służą wyłącznie do stworzenia modelu „dedykowanego”, czy też zasila się nimi modele ogólne, dostępne dla innych klientów;
• własność i kontrola nad modelem – kto jest właścicielem modelu wytrenowanego na danych klienta, kto decyduje o sposobie jego dalszego wykorzystania oraz czy model może być „wywieziony” poza infrastrukturę dostawcy;
• retencja danych treningowych i checkpointów – jak długo przechowywane są dane wejściowe, pośrednie zbiory treningowe oraz checkpointy modelu, czy klient może zażądać ich usunięcia;
• ochrona przed „wyciekiem” informacji z modelu – czy dostawca stosuje techniki ograniczające ryzyko odtwarzania danych treningowych z zapytań do modelu (np. regularizacja, testy odporności na ataki inference).

W praktyce dobrze sprawdza się zasada: jeżeli dane klienta są szczególnie wrażliwe (np. medyczne, HR, dane dzieci), domyślnym założeniem powinno być brak wykorzystywania ich do trenowania modeli ogólnych, chyba że klient po analizie ryzyka wyrazi na to wyraźną, odrębną zgodę umowną.

Zapisy dotyczące transferów i dostępu z państw trzecich

Umowy z dostawcami globalnymi muszą odzwierciedlać nie tylko ogólną klauzulę o „zgodności z RODO”, lecz także szczegółowe wymogi dotyczące transferów. Istotne są zwłaszcza:

• wykaz lokalizacji, w których dane mogą być przetwarzane lub z których możliwy jest dostęp administracyjny, wraz z informacją o podprocesorach;
• zobowiązanie dostawcy do stosowania standardowych klauzul umownych w relacjach z podmiotami z państw trzecich i umożliwienia administratorowi zapoznania się z ich treścią (co najmniej w zakresie istotnych postanowień);
• klauzule „warrant canary” lub ich odpowiedniki – mechanizm informowania klienta o otrzymaniu przez dostawcę prawnie wiążącego żądania udostępnienia danych lub niemożności udzielania takich informacji;
• procedura kwestionowania żądań władz – obowiązek weryfikacji, czy żądanie jest legalne, czy istnieje podstawa do jego zaskarżenia, oraz informowania administratora o podjętych działaniach;
• warunki czasowego zawieszenia przetwarzania lub rozwiązania umowy przez administratora, jeżeli ryzyko transferu wzrośnie (np. w wyniku zmian prawa państwa trzeciego).

Coraz częściej pojawiają się również klauzule wymagające od dostawcy prowadzenia regularnych ocen wpływu transferu na prywatność (Transfer Impact Assessment) i udostępniania ich wyników klientom, choćby w formie zanonimizowanych raportów.

Mechanizmy kontroli i egzekwowania wymogów

Sama treść umowy to jedno; drugim elementem są narzędzia jej egzekwowania. Administracja, która z góry zakłada, że „duży dostawca i tak nic nie zmieni”, jest w gorszej pozycji negocjacyjnej. Nawet w relacjach z hyperscalerami można jednak uzyskać pewne ustępstwa, szczególnie przy większej skali projektu.

W praktyce sprawdzają się m.in.:

• aneksy branżowe – np. dla sektora finansowego, zdrowotnego, publicznego; często zawierają surowsze wymogi co do lokalizacji danych, audytów, raportowania;
• klauzule warunkowe – w razie zmiany istotnych okoliczności (np. wyroku sądu krajowego lub TSUE wpływającego na legalność transferów) dostawca zobowiązuje się do wdrożenia dodatkowych środków technicznych albo umożliwia migrację bez kar umownych;
• wskaźniki jakości (KPI) i kary umowne – związane nie tylko z dostępnością usługi, lecz także z czasem reakcji na incydent, terminowością realizacji żądań osób, dostępnością logów;
• programy współpracy regulacyjnej – w sektorach silnie regulowanych (bankowość, ubezpieczenia) część dostawców zgadza się na udział w spotkaniach z organem nadzorczym klienta i udzielanie odpowiedzi na pytania regulatora.

Przy projektach AI szczególnie istotne jest, aby umowa nie blokowała niezależnej weryfikacji działania modelu, np. przez zewnętrznych audytorów lub zespoły badawcze. Jeżeli dostawca zastrzega, że klient nie może publikować żadnych wyników testów (np. dotyczących biasu, halucynacji czy podatności na ataki), może to zostać uznane za utrudnianie realizacji zasad przejrzystości i rozliczalności.

Równowaga między elastycznością a bezpieczeństwem prawnym

Rozwiązania chmurowe i AI często wymagają szybkiej ewolucji – dostawcy wprowadzają nowe funkcje, modele i integracje. Nowe wytyczne UODO i EDPB nie blokują tej dynamiki, ale przesuwają środek ciężkości na zarządzanie zmianą.

W praktyce oznacza to m.in. konieczność uzgodnienia w umowie:

• jak klient jest informowany o istotnych zmianach usługi (np. nowym typie modelu, zmianie lokalizacji danych, nowym podprocesorze),
• z jakim wyprzedzeniem może zareagować – przeprowadzić aktualizację DPIA, przejrzeć podstawy prawne, przygotować komunikację dla osób, których dane dotyczą,
• czy ma prawo wyłączyć określone funkcje (np. automatyczne uczenie się na danych produkcyjnych) bez rezygnacji z całej usługi,

Najczęściej zadawane pytania (FAQ)

Jak nowe wytyczne UODO i EDPB wpływają na korzystanie z narzędzi AI i chmury w mojej firmie?

Nowe wytyczne przesuwają akcent z „odhaczania RODO” na realne zarządzanie ryzykiem. Każde wdrożenie narzędzia AI lub migracja do chmury powinny być poprzedzone oceną ryzyka, a kluczowe decyzje – udokumentowane. Chodzi o to, by móc pokazać, dlaczego wybrano danego dostawcę, jakie zabezpieczenia przyjęto i jak oceniono ryzyko dla osób, których dane są przetwarzane.

Dla większości organizacji oznacza to konieczność uporządkowania relacji z dostawcami (umowy, role, transfery danych poza EOG) oraz przygotowania spójnego zestawu dowodów: DPIA, analiz transferów, notatek z wyboru dostawcy, polityk bezpieczeństwa i rejestrów czynności.

Czy dostawca narzędzia AI lub chmury zawsze jest podmiotem przetwarzającym (procesorem)?

Nie. Zgodnie z wytycznymi EDPB rola dostawcy zależy od faktycznego wpływu na cele i sposoby przetwarzania, a nie od tego, jak sam się nazywa w ofercie. Jeśli dostawca realizuje wyłącznie Twoje polecenia i nie wykorzystuje danych do własnych celów, najczęściej jest procesorem.

Jeżeli jednak wykorzystuje dane do „ulepszania usługi”, trenowania własnych modeli czy analiz wewnętrznych, zwykle staje się samodzielnym administratorem w zakresie tych dodatkowych celów. W projektach partnerskich, gdzie razem definiujecie cel i główne zasady przetwarzania, może powstać współadministracja – wtedy konieczna jest umowa określająca podział obowiązków.

Kiedy wdrożenie AI lub chmury wymaga przeprowadzenia DPIA (oceny skutków dla ochrony danych)?

DPIA jest wymagane, gdy przetwarzanie może powodować wysokie ryzyko dla praw i wolności osób fizycznych. Wytyczne EDPB i krajowe listy operacji wskazują, że wiele wdrożeń AI (np. profilowanie, automatyczne decyzje, analiza zachowań) oraz projekty w sektorach wrażliwych (zdrowie, finanse, administracja publiczna) często spełniają ten próg.

Jeżeli system AI przetwarza dane wrażliwe, masowe zbiory klientów, dane dzieci albo prowadzi do istotnych konsekwencji dla osób (odmowa świadczenia, ocena ryzyka, dostęp do usług) – DPIA jest w praktyce obowiązkowe. Brak DPIA przy takim projekcie organ może potraktować jako istotne naruszenie zasady rozliczalności.

Jak legalnie transferować dane osobowe do dostawców AI i chmury poza EOG po wyroku Schrems II?

Po Schrems II samo podpisanie standardowych klauzul umownych (SCC) nie wystarcza. Trzeba najpierw zmapować transfery, sprawdzić, czy dane faktycznie trafiają poza EOG (np. do USA), a następnie ocenić prawo kraju odbiorcy oraz praktyki dostawcy pod kątem dostępu służb i realnego poziomu ochrony.

Jeśli z analizy wynika podwyższone ryzyko, konieczne są dodatkowe środki – techniczne, organizacyjne lub umowne. W praktyce chodzi najczęściej o silne szyfrowanie (z kluczami po stronie EOG), ograniczenie zakresu danych, pseudonimizację, a także precyzyjne, „usztywnione” zapisy umowne dotyczące podwykonawców, lokalizacji danych i obowiązku informowania o żądaniach organów publicznych.

Jak dobrać właściwą podstawę prawną przetwarzania danych przy korzystaniu z AI i usług chmurowych?

Podstawa zależy od celu i kontekstu przetwarzania. Dla typowych procesów operacyjnych (obsługa zamówień, CRM, fakturowanie w chmurze) często wystarcza realizacja umowy. Dla wewnętrznej analityki, optymalizacji serwisu, monitoringu bezpieczeństwa czy moderacji treści z użyciem AI często stosuje się uzasadniony interes, po wcześniejszej analizie równowagi (LIA).

Zgoda jest potrzebna przede wszystkim wtedy, gdy przetwarzanie jest dodatkowe, niekonieczne do wykonania usługi, zaskakujące dla użytkownika lub obejmuje dane szczególnych kategorii bez innej wyraźnej podstawy (np. eksperymentalna diagnostyka AI). Przy obowiązkach wynikających z prawa (np. raportowanie do regulatora, przechowywanie dokumentacji medycznej) podstawą będzie realizacja obowiązku prawnego.

Jakie sektory są najbardziej narażone na kontrolę UODO przy używaniu AI i chmury?

Pod szczególną lupą znajdują się podmioty z branż, które przetwarzają duże wolumeny danych lub dane wrażliwe: software house’y i dostawcy SaaS, e‑commerce i marketing, sektor finansowy, ochrona zdrowia i medtech, a także administracja publiczna i edukacja.

W tych sektorach organy nadzorcze zwracają uwagę na to, czy wdrożeniom AI i chmury towarzyszą: rzetelne DPIA, jasne umowy z dostawcami, realna kontrola nad transferami oraz adekwatne środki techniczne i organizacyjne. Korzystanie z usług „na domyślnych warunkach” dostawcy, bez własnych analiz i doprecyzowania umów, jest obecnie jednym z najczęściej punktowanych problemów.

Czy EU AI Act zmienia coś w moich obowiązkach z perspektywy RODO przy projektach AI?

EU AI Act formalnie nie jest częścią RODO, ale podnosi poprzeczkę należytej staranności przy systemach AI, zwłaszcza wysokiego ryzyka (np. scoring kredytowy, systemy rekrutacyjne, narzędzia diagnozujące w medycynie). Dla takich rozwiązań oczekiwane są bardziej rozbudowane analizy ryzyka, dokumentacja, testy i mechanizmy nadzoru.

W praktyce oznacza to, że dla projektów AI trzeba spiąć wymagania obu regulacji: DPIA i podstawy prawne z RODO oraz klasyfikację ryzyka, wymogi transparentności i zarządzania cyklem życia systemu z AI Act. Brak synchronizacji tych dwóch perspektyw będzie coraz częściej wychwytywany przy kontrolach i audytach zgodności.

Najważniejsze punkty

• Nowe wytyczne UODO i EDPB przesuwają ciężar z „odhaczania RODO” na realne zarządzanie ryzykiem – przy AI i chmurze liczy się spójny, udokumentowany proces, a nie sam zestaw procedur.
• Każde wdrożenie narzędzia AI lub migracja do chmury wymaga oceny ryzyka (często formalnej DPIA), jasnego uzasadnienia doboru środków bezpieczeństwa oraz możliwości odtworzenia całego procesu decyzyjnego przy kontroli lub incydencie.
• Relacja z dostawcą AI/chmury musi być precyzyjnie opisana umownie: jasno zdefiniowana rola (administrator, procesor, współadministrator), podział odpowiedzialności, zasady transferów poza EOG oraz konkretne wymagania bezpieczeństwa.
• Standardowe klauzule umowne i pozostałe narzędzia transferu danych do państw trzecich nie działają „automatycznie” – trzeba realnie ocenić prawo państwa odbiorcy, dobrać dodatkowe zabezpieczenia i wszystko udokumentować.
• Nowe wytyczne tworzą praktyczny standard należytej staranności: korzystanie z AI i chmury bez własnej analizy ryzyka, DPIA i doprecyzowanych umów jest dziś traktowane jako poważne naruszenie zasady rozliczalności.
• Największą ekspozycję na ryzyko mają software house’y, SaaS, e‑commerce/marketing, sektor finansowy, zdrowie oraz administracja i edukacja – masowe, wrażliwe dane w połączeniu z chmurą i AI oznaczają wzmożoną uwagę organów nadzorczych.