Apetyt sztucznej inteligencji na dane kontra zasada minimalizacji
Sztuczna inteligencja „żywi się” danymi. Im więcej przykładów, historii kontaktu z klientem, dokumentów czy nagrań, tym lepsze wyniki modeli. RODO wymaga jednak, aby zbierać i przetwarzać tylko tyle danych, ile jest niezbędne do konkretnego celu. Te dwa światy ścierają się ze sobą przy każdym projekcie AI.
W praktyce napięcie widać zwłaszcza przy trenowaniu modeli: zespół techniczny chce „zaciągnąć” całe hurtownie danych, bo może się „kiedyś przyda”. Prawnik i inspektor ochrony danych pytają: po co? do jakiego celu? czy naprawdę trzeba znać PESEL, aby klasyfikować typy spraw w zgłoszeniach do helpdesku? Bez odpowiedzi na te pytania nie da się mówić o zgodności ze sztuczną inteligencją a RODO.
Jeżeli AI ma być legalna, konieczne jest wypracowanie nowego kompromisu: modele dostają tylko to, co faktycznie potrzebne, a reszta danych jest usuwana, maskowana lub trzymana w odrębnych systemach z ograniczonym dostępem.
„To tylko testy na danych” i fałszywe poczucie bezpieczeństwa
Bardzo częsty scenariusz: zespół IT dostaje zadanie „przetestowania” nowego silnika AI na danych z CRM. Pada argument: „To tylko środowisko testowe, więc RODO nie obowiązuje tak mocno”. To klasyczny błąd.
RODO nie rozróżnia „produkcyjnych” i „testowych” baz. Jeżeli są tam dane osobowe – a w testach AI najczęściej są – to wszystko, co dotyczy legalności, podstaw prawnych, bezpieczeństwa czy praw osób, działa tak samo. Nie ma zniżki tylko dlatego, że to sandbox.
W testach i pilotażach często panuje najmniejsza dyscyplina: dane z wielu systemów, brak retencji, szeroki dostęp, brak DPIA. To z tej fazy najłatwiej o wyciek lub nieuprawnione wykorzystanie danych. Gdy dochodzi do incydentu, organ nadzorczy nie pyta, czy to było „na próbę”, tylko czy administrator miał kontrolę nad przetwarzaniem.
Gotowe modele vs własne trenowanie – dwa różne światy ryzyka
W projektach z AI są zwykle dwa podejścia. Pierwsze: korzystanie z gotowych modeli (np. API dużych dostawców, SaaS z funkcją AI, wbudowane algorytmy w CRM). Drugie: trenowanie własnych modeli na danych organizacji.
W pierwszym wariancie kluczowe jest zrozumienie, co dzieje się z danymi po stronie dostawcy. Czy wykorzystuje je do trenowania własnych modeli? Gdzie są przechowywane? Jak długo? Kto ma do nich dostęp? Czy dane są wysyłane poza EOG? To temat dla dobrych umów powierzenia i precyzyjnych konfiguracji prywatności.
Przy własnych modelach odpowiedzialność jest jeszcze większa. Administrator faktycznie tworzy system, który może „zapamiętać” dane osobowe, propagować błędy, generować profile. Kontrola jest większa, ale też oczekiwania organu nadzorczego – znacząco wyższe. Wymagana jest pełna dokumentacja procesu, ocena skutków (DPIA), opis parametrów i ryzyk.
Główne ryzyka: niejawne źródła, brak kontroli, przecieki
Sztuczna inteligencja a RODO ścierają się na kilku powtarzalnych polach. Najbardziej problematyczne są:
Niejawne źródła danych – modele budowane na „publicznych” danych z sieci, gdzie nikt nie weryfikuje, czy dane rzeczywiście są wolne od ochrony, a osoby informowane.
Brak kontroli nad modelem – zwłaszcza przy dużych modelach językowych trudno przewidzieć, jak zareagują na nietypowe zapytania i jakie informacje „wydobędą” z danych treningowych.
Przecieki danych – odpowiedzi modelu, które zawierają dane osobowe innych klientów lub użytkowników, albo zbyt bogate logi, które przechowują treść zapytań bez realnej potrzeby.
Rozjechanie celów – system AI wdrażany „do jednego celu”, a po kilku miesiącach wykorzystywany do zupełnie innych operacji na tych samych danych.
Bez rozpoznania tych ryzyk i bez technicznych zabezpieczeń system AI stanie się tykającą bombą, a nie narzędziem bezpiecznej automatyzacji.
Co RODO naprawdę obejmuje w kontekście AI
Definicja danych osobowych przy embeddingach i dużych zbiorach
Kluczem do zrozumienia, kiedy RODO ma zastosowanie, jest pojęcie danych osobowych. To każda informacja o zidentyfikowanej lub możliwej do zidentyfikowania osobie fizycznej. W AI sprawa komplikuje się przy embeddingach, wektorach, skrótach i reprezentacjach cech.
Jeśli wektor można z rozsądnym nakładem środków powiązać z konkretną osobą (bezpośrednio lub przez łączenie z innymi zbiorami), to z perspektywy RODO wciąż mamy przetwarzanie danych osobowych. To, że inżynierowie mówią „to tylko liczby” nie oznacza, że identyfikacja jest niemożliwa.
RODO patrzy na rzecz funkcjonalnie: czy dane mogą prowadzić do osoby, a nie formalnie: czy w polu jest imię i nazwisko. W wielu projektach embeddingi, identyfikatory klienta, odcisk cyfrowy urządzenia czy hash e-maila będą nadal danymi osobowymi.
Kiedy model AI sam staje się nośnikiem danych osobowych
Modele uczenia maszynowego mogą mieć skłonność do memorization – zapamiętywania fragmentów danych treningowych. Przy dużych modelach językowych możliwe jest „wydobycie” części treści, jeśli użytkownik zada odpowiednio spreparowane pytania.
Jeżeli model jest w stanie odtworzyć konkretne dane osobowe z treningu (np. treść maila, imię i nazwisko w specyficznym kontekście, szczegółowy opis sprawy), sam model staje się nośnikiem danych osobowych. W konsekwencji obejmują go wszystkie zasady RODO: bezpieczeństwo, retencja, prawa osób, dokumentacja.
To, czy w danym przypadku model przechowuje dane osobowe, wymaga testów. Warto tworzyć kontrolne zestawy pytań i oceniać, czy model reprodukuje wrażliwe informacje z historii treningu. Jeśli tak, powstaje obowiązek uwzględnienia modelu jako odrębnego zasobu w rejestrze czynności przetwarzania.
Rola administratora, procesora i współadministratora
W projektach AI rzadko jedna organizacja ma pełną kontrolę nad wszystkim. Pojawiają się dostawcy chmury, twórcy algorytmów, integratorzy, partnerzy. Prawidłowe określenie ról z perspektywy RODO jest kluczowe.
Administrator decyduje o celach i sposobach przetwarzania. Jeśli firma ustala, że dane klientów będą wykorzystywane do trenowania modelu rekomendacji produktów, to w tym zakresie jest administratorem.
Procesor (podmiot przetwarzający) działa w imieniu administratora. Typowy przykład: chmurowy dostawca narzędzia AI, który przetwarza dane tylko w zakresie, w jakim wynika to z umowy i poleceń administratora. Między stronami musi istnieć umowa powierzenia.
Współadministratorzy pojawiają się, gdy dwa podmioty wspólnie określają cele i sposoby przetwarzania. Typowa sytuacja: dwie firmy budują wspólny model scoringowy dla swoich klientów, wykorzystując dane obu baz. Wówczas potrzebne jest jasne porozumienie określające zakresy odpowiedzialności.
Przykład: zewnętrzny czat AI zasilany danymi klientów
Wyobraźmy sobie firmę, która wdraża czat AI do obsługi klientów. Czat ma mieć dostęp do historii zgłoszeń, danych kontaktowych i statusu zamówień. Usługa jest dostarczana przez zewnętrznego dostawcę w modelu SaaS.
W tym układzie firma pozostaje administratorem danych klientów, bo to ona decyduje o celu (obsługa klienta, skrócenie czasu odpowiedzi) i sposobie (czat AI powiązany z CRM). Dostawca jest procesorem – przetwarza dane w chmurze na rzecz administratora, zgodnie z jego instrukcjami.
Legalne podstawy przetwarzania danych przez AI – co naprawdę działa
Zgoda, uzasadniony interes, niezbędność do umowy – praktyczne różnice
Podstawy prawne przetwarzania danych przez AI nie różnią się formalnie od „zwykłych” systemów, ale praktyka stosowania jest inna. Najczęściej rozważane są trzy warianty: zgoda, niezbędność do wykonania umowy i uzasadniony interes administratora.
Zgoda sprawdza się w scenariuszach fakultatywnych, np. personalizacja oferty z użyciem AI czy analiza zachowań w aplikacji. Jej wadą jest odwoływalność i wymóg realnej dobrowolności. Jeśli dostęp do usługi jest uwarunkowany zgodą na przetwarzanie w celu trenowania modelu marketingowego, trudno mówić o braku przymusu.
Niezbędność do wykonania umowy działa, gdy bez przetwarzania danych przez AI nie dałoby się świadczyć usługi w przyjętej formie. Przykład: system antyfraudowy w bankowości elektronicznej bazujący na modelach AI, który jest wbudowany w usługę. Nie można jednak pod tę podstawę podciągać dowolnej analityki czy rozwoju produktu.
Uzasadniony interes jest kuszący, bo elastyczny. W AI często pojawia się w kontekście optymalizacji pracy, bezpieczeństwa IT, monitoringu jakości. Warunkiem jest jednak pozytywny test równowagi – interes administratora nie może naruszać praw i wolności osób w sposób nadmierny. To nie jest automatyczny „wytrych” do każdego projektu AI.
Dlaczego uzasadniony interes nie załatwia wszystkiego
Wiele firm próbuje podpierać się uzasadnionym interesem przy trenowaniu modeli na dużych zbiorach danych klientowskich, także do celów marketingowych. Organ nadzorczy jest na takie konstrukcje wyczulony.
Jeżeli system AI prowadzi do rozbudowanego profilowania, skutkuje automatycznymi decyzjami lub znacząco ingeruje w prywatność (np. analiza treści wiadomości, rozmów telefonicznych, aktywności w aplikacji), uzasadniony interes wymaga bardzo solidnego uzasadnienia. Konieczne bywa wprowadzenie mechanizmów opt-out czy ograniczenie zakresu przetwarzania.
Nadużywanie tej podstawy w projektach AI kończy się często zarzutem przetwarzania bez ważnej podstawy prawnej. W razie kontroli trzeba literalnie pokazać test równowagi, a nie tylko ogólny zapis w polityce prywatności.
Przepisy szczególne – prawo pracy, sektor finansowy, administracja
W niektórych branżach projekty AI mogą opierać się także na przepisach szczególnych. W prawie pracy mogą to być regulacje dotyczące monitoringu, bezpieczeństwa i organizacji pracy. W sektorze finansowym – przepisy o przeciwdziałaniu praniu pieniędzy czy obowiązkach nadzorczych.
Jeżeli ustawa nakłada obowiązek analizy transakcji, przeciwdziałania nadużyciom czy udokumentowania określonych działań, wykorzystanie AI może być uzasadnione jako narzędzie realizacji tego obowiązku. Trzeba jednak dokładnie przeanalizować, czy zakres i sposób działania systemu mieszczą się w ramach przewidzianych przepisem.
W administracji publicznej pojawia się dodatkowe ograniczenie: przetwarzanie danych wymaga wyraźnej podstawy w prawie. Użycie AI do profilowania obywateli lub automatycznego podejmowania decyzji administracyjnych bez jasnego oparcia w przepisach jest ryzykowne, nawet jeśli z perspektywy organizacyjnej byłoby wygodne.
Dane szczególnych kategorii w systemach AI
Dane o zdrowiu, poglądach politycznych, przekonaniach religijnych, pochodzeniu etnicznym czy życiu seksualnym to w projektach AI pole minowe. Standardowo ich przetwarzanie jest zakazane, z niewielkimi wyjątkami.
Jeżeli AI ma analizować dokumentację medyczną, akta pracownicze czy treść zgłoszeń, w których użytkownicy opisują swoje problemy osobiste, istnieje duże ryzyko dotknięcia danych szczególnych kategorii. Konieczna jest wtedy szczegółowa analiza wyjątków z art. 9 RODO (np. przetwarzanie do celów medycznych, badań naukowych, na podstawie wyraźnej zgody).
Praktycznym podejściem jest maksymalne ograniczenie styku modelu z takimi danymi. Można wdrażać filtry i preprocesing, które wycinają fragmenty zawierające słowa kluczowe związane z danymi wrażliwymi, lub przetwarzać je w innych, silniej zabezpieczonych kanałach. Im mniej danych szczególnych w pipeline AI, tym mniejsze ryzyko naruszenia zasad ochrony danych.
Minimalizacja, celowość, retencja – zasady RODO w pipeline AI
Minimalizacja danych w treningu i logach
Minimalizacja danych to jedna z najtrudniejszych zasad do wdrożenia przy trenowaniu modeli. Inżynierowie często wychodzą z założenia: „dajmy modelowi wszystko, co mamy, i zobaczmy, co wyciągnie”. Z perspektywy RODO taka strategia jest nie do obrony.
Praktyczne podejście to etapowa selekcja danych: najpierw zdefiniowanie, jakie cechy są kluczowe dla zadania (np. typ zgłoszenia, terminowość płatności, kategorie produktów), a dopiero później decyzja, jakie pola z systemów źródłowych naprawdę trzeba wciągnąć. Dane typu PESEL, NIP, dokładny adres, prywatne numery telefonu często nie wnoszą nic do skuteczności modelu, a generują ryzyko.
Podobnie z logami: rejestrowanie pełnej treści zapytań użytkowników do czatu AI wraz z identyfikatorami sesji powinno być ograniczone czasowo i zakresowo. Do debugowania systemu wystarczą często pseudonimizowane dane, skrócone treści lub zanonimizowane wycinki.
Rozdzielanie celów i unikanie „mieszania kontekstów”
System AI może przetwarzać dane w kilku celach naraz: obsługa bieżących zapytań, poprawa jakości modelu, wykrywanie nadużyć. To nie zwalnia z obowiązku jasnego rozdzielenia tych celów na poziomie dokumentacji i konfiguracji.
Dane zebrane do obsługi klienta nie powinny automatycznie trafiać do puli treningowej dla nowych modeli, jeśli w klauzuli informacyjnej ten cel nie został przewidziany. „Mieszanie” kontekstów to najczęstszy zarzut organów nadzorczych przy projektach AI.
Rozsądne podejście: osobne zbiory danych i osobne polityki retencji dla każdego celu (operacyjny, rozwojowy, bezpieczeństwo), a także oddzielne procesy nadawania dostępu.
Retencja danych i „zapominanie” w środowisku AI
Trzymanie danych „na wszelki wypadek” jest sprzeczne z RODO i trudno je obronić przy trenowaniu modeli. Zasady retencji trzeba zaplanować przed wdrożeniem.
Można wyodrębnić trzy poziomy retencji: dane źródłowe (krótko), dane zanonimizowane/pseudonimizowane (dłużej) oraz parametry modeli (najdłużej, przy dobrze udokumentowanej analizie ryzyka). Każdy poziom powinien mieć własne terminy i uzasadnienie biznesowe.
Problem „prawa do bycia zapomnianym” w modelach rozwiązuje się przez połączenie: kasowania danych źródłowych, wygaszania lub ponownego trenowania modeli na zaktualizowanych zbiorach oraz technik ograniczających możliwość rekonstrukcji danych jednostkowych z parametrów modelu.
Pseudonimizacja i anonimizacja a skuteczność modeli
Pseudonimizacja (np. zamiana ID klienta na losowy identyfikator) często wystarczy, żeby znacząco obniżyć ryzyko, bez istotnej utraty jakości modelu. Takie przekształcenia można wprowadzić na etapie ekstrakcji danych z systemów źródłowych.
Anonimizacja jest trudniejsza, szczególnie gdy model wymaga powtarzalnego rozpoznawania tej samej osoby w różnych punktach procesu (np. analiza historii zakupów). Wówczas celem jest raczej maksymalne zawężenie zakresu danych osobowych niż pełna anonimizacja.
Dobrą praktyką jest przygotowanie „profilu ryzyka cechy” – oceny, które atrybuty są krytyczne pod względem prywatności i czy można je zastąpić mniej wrażliwymi odpowiednikami (np. przedział wiekowy zamiast daty urodzenia).
Źródło: Pexels | Autor: Ron Lach
Profilowanie, automatyczne decyzje i „czarna skrzynka”
Profilowanie według RODO a typowe zastosowania AI
Profilowanie w rozumieniu RODO to każda forma zautomatyzowanego przetwarzania danych osobowych polegająca na wykorzystaniu tych danych do oceny niektórych czynników osoby fizycznej. Nie chodzi tylko o reklamę, ale też o scoring ryzyka, analizę produktywności pracowników czy prognozowanie rotacji.
Modele klasyfikujące klientów na „wysokie ryzyko rezygnacji”, „wartościowi klienci” czy „podwyższone ryzyko nadużyć” wchodzą w zakres profilowania nawet wtedy, gdy decyzję końcową formalnie podejmuje człowiek. To uruchamia dodatkowe obowiązki informacyjne.
Automatyczne decyzje wywołujące skutki prawne
Szczególnie wrażliwy jest art. 22 RODO, który ogranicza podejmowanie decyzji wywołujących skutki prawne lub podobnie istotnie wpływających na osobę, wyłącznie w oparciu o zautomatyzowane przetwarzanie, w tym profilowanie.
Przykłady: automatyczna odmowa udzielenia kredytu, odrzucenie rekrutanta na podstawie algorytmu, automatyczne ograniczenie dostępu do usługi z powodu oceny ryzyka. W takich sytuacjach zazwyczaj konieczne jest zapewnienie interwencji człowieka, prawa do wyrażenia własnego stanowiska i zakwestionowania decyzji.
„Człowiek w pętli” nie może być fikcją. Jeśli analityk tylko klika „zatwierdź” przy decyzjach modelu, bez realnej możliwości ich weryfikacji, organ nadzorczy może uznać, że nadal mamy do czynienia z decyzją w pełni zautomatyzowaną.
Wymogi przejrzystości a modele typu black box
RODO nie wymaga ujawniania kodu źródłowego czy parametrów modeli, ale wymaga zrozumiałego wyjaśnienia głównych przesłanek decyzji. Użytkownik musi wiedzieć, jakie typy danych i jakie logiki biznesowe mają wpływ na ocenę.
Dla modeli złożonych (np. deep learning) potrzebne są warstwy wyjaśnienia: wysokopoziomowy opis dla użytkownika oraz techniczna dokumentacja dla audytu i zespołu compliance. Można korzystać z metod XAI (np. SHAP, LIME), ale ważniejsza bywa przejrzysta konstrukcja procesu decyzyjnego wokół modelu.
W praktyce często skuteczniejszy jest hybrydowy system regułowo-uczący się, w którym kluczowe progi i reguły są zrozumiałe, a model AI wspiera tylko część predykcyjną.
Ocena skutków dla ochrony danych (DPIA) przy profilowaniu
Profilowanie na dużą skalę, szczególnie w sektorach wrażliwych (finanse, zdrowie, HR), z reguły wymaga przeprowadzenia DPIA. Brak DPIA przy projekcie AI jest częstym punktem krytyki nadzorcy.
W DPIA dla systemu AI dobrze jest jasno opisać: typy danych wejściowych, rodzaje wytwarzanych profili, wpływ na osoby (np. odmowa usługi, zaniżenie oferty), mechanizmy kontroli człowieka, ścieżki odwołania się od decyzji oraz plany testów na uprzedzenia i dyskryminację.
Dokument DPIA nie powinien być dokumentem „na półkę”. Wymaga aktualizacji przy każdej istotnej zmianie modelu, zakresu danych lub celu przetwarzania.
Projekt AI krok po kroku z perspektywy RODO
Analiza wstępna: po co AI i jakie dane są naprawdę potrzebne
Start projektu to moment na skonfrontowanie wizji biznesowej z wymaganiami RODO. W pierwszym kroku definiuje się cele biznesowe, mapuje procesy i identyfikuje punkty, w których pojawiają się dane osobowe.
Jeśli okaże się, że do osiągnięcia celu wystarczy praca na danych zagregowanych lub zanonimizowanych, warto z tego skorzystać. W wielu przypadkach algorytmowi nie jest potrzebny identyfikator osoby, lecz wzorzec zachowań w danym segmencie.
Dobór podstawy prawnej i zakresu informacji dla użytkownika
Po zdefiniowaniu celu projektowego dobiera się podstawę prawną. Ten etap dobrze połączyć z opracowaniem treści klauzul informacyjnych i regulaminów. Unika się wtedy sytuacji, w której projekt jest gotowy technicznie, a brakuje akceptowalnej podstawy przetwarzania.
Jeśli podstawą jest zgoda, proces UX musi umożliwiać jej wyrażenie, wycofanie i udokumentowanie. Jeśli uzasadniony interes – trzeba przygotować test równowagi oraz mechanizmy sprzeciwu, które realnie da się wdrożyć w produkcyjnym środowisku.
Projektowanie architektury pod kątem prywatności
Architektura rozwiązania powinna uwzględniać zasadę privacy by design. Obejmuje to zarówno wybór narzędzi, jak i podział odpowiedzialności między systemami.
Typowe decyzje na tym etapie: czy trenowanie odbywa się on-premise czy w chmurze, gdzie przechowywane są logi, czy dane przekazywane do dostawcy są pseudonimizowane, w jaki sposób ograniczany jest dostęp zespołów developerskich do danych rzeczywistych.
Warto też od razu przewidzieć środowiska testowe oparte na danych syntetycznych albo mocno zredukowanych, a z danymi produkcyjnymi pracować tylko tam, gdzie to niezbędne.
Faza trenowania i testów – kontrola nad danymi i eksperymentami
Podczas trenowania modeli łatwo o „pełzający” wzrost zakresu danych. Kolejne iteracje eksperymentów powodują, że do zbioru trafiają nowe cechy, często bez refleksji prawnej. Przydatne jest formalne zatwierdzanie zmian w schemacie danych.
Warto prowadzić katalog eksperymentów: jakie dane, w jakim celu, z jakim wynikiem zostały wykorzystane. Ułatwia to później wykazanie zasady rozliczalności oraz ocenę, czy określone atrybuty są rzeczywiście potrzebne.
Testy pod kątem błędów i uprzedzeń (bias) też mają wymiar RODO: dyskryminujące wzorce mogą prowadzić do naruszenia zasady rzetelności i zgodności z prawem, a w skrajnych przypadkach także przepisów antydyskryminacyjnych.
Wdrożenie produkcyjne i monitoring
Przeniesienie modelu na produkcję wymaga dodatkowych zabezpieczeń. Trzeba określić, jakie logi są zbierane, przez jaki czas, kto ma do nich dostęp i do jakich celów są wykorzystywane (debugowanie, bezpieczeństwo, rozwój modeli).
Monitoring powinien obejmować nie tylko metryki techniczne, lecz także incydenty prywatnościowe: przypadki ujawnienia danych, nieuprawniony dostęp, podejrzenia dyskryminacji. Warto z góry ustalić, jakie sygnały uruchamiają przegląd DPIA i zmianę konfiguracji systemu.
Przy istotnej zmianie modelu (nowa wersja, inny zakres danych, nowy cel) może być konieczne uzyskanie na nowo zgody lub przeprowadzenie aktualizacji testu równowagi dla uzasadnionego interesu.
Współpraca z dostawcą technologii AI – umowy, ryzyka, role
Umowa powierzenia – co musi się znaleźć przy AI
Standardowa umowa powierzenia z art. 28 RODO często nie wystarcza przy złożonych usługach AI. Poza ogólnymi klauzulami potrzebne są szczegółowe zapisy dotyczące celów, zakresu i sposobów przetwarzania danych.
Umowa powinna określać m.in.: czy dostawca może wykorzystywać dane klienta do trenowania własnych modeli, jak długo przechowuje dane i logi, w jakich lokalizacjach (w tym poza EOG), jakie podmioty trzecie uczestniczą w przetwarzaniu, oraz jakie środki bezpieczeństwa są stosowane.
Dobrą praktyką jest rozdzielenie usług „operacyjnych” (obsługa zapytań) od „rozwojowych” (trenowanie modeli na danych klienta) i zastosowanie odrębnych zgód/klauzul kontraktowych dla każdego z tych celów.
Transfery danych poza EOG i standardowe klauzule umowne
W wielu projektach AI dane lub logi są przetwarzane w centrach danych poza EOG. Po wyroku Schrems II oznacza to konieczność stosowania standardowych klauzul umownych oraz przeprowadzenia oceny wpływu transferu.
W praktyce oznacza to analizę: do jakiego państwa trafiają dane, jakie prawo tam obowiązuje (w szczególności dostęp służb), jakie dodatkowe zabezpieczenia techniczne są stosowane (szyfrowanie, pseudonimizacja, podział danych między regiony).
Jeżeli dostawca nie jest w stanie zaoferować realnych zabezpieczeń, rekomendowane jest poszukanie alternatywnych rozwiązań (np. region EOG, lokalne instancje, trenowanie on-premise).
Współadministrowanie z dostawcą AI
Czasem dostawca nie ogranicza się do roli procesora, lecz współkształtuje cel i sposób przetwarzania (np. wspólny model scoringowy używany przez kilku klientów). Wtedy może dojść do współadministrowania.
W takiej relacji strony muszą jasno ustalić, kto odpowiada za realizację praw osób, jakie informacje są przekazywane użytkownikom, kto jest punktem kontaktu dla organu nadzorczego oraz jak dzielone są obowiązki przy naruszeniu ochrony danych.
Jeżeli jednak dostawca przewiduje wykorzystanie danych klientów do trenowania własnych, ogólnych modeli, może w pewnym zakresie stawać się odrębnym administratorem. Wymaga to odrębnej podstawy prawnej i przejrzystych informacji dla osób, których dane dotyczą. Tego typu scenariusze coraz częściej analizuje się w specjalistycznych serwisach opisujących więcej o prawo oraz praktykę stosowania RODO w biznesie.
Brak takiego porozumienia skutkuje stanem „szarej strefy”, w którym użytkownik nie wie, kto faktycznie decyduje o jego danych, a w razie incydentu obie strony przerzucają się odpowiedzialnością.
Due diligence dostawcy technologii
Przed wyborem dostawcy AI warto przeprowadzić weryfikację nie tylko funkcjonalną, lecz także prawną i bezpieczeństwa. W wielu przypadkach to, co jest „domyślne” w usłudze, stoi w sprzeczności z wymogami RODO.
Lista kontrolna może obejmować: lokalizację centrów danych, model trenowania (czy dane klienta są używane do tworzenia modeli ogólnych), dostęp zespołów supportowych do danych, mechanizmy anonimizacji lub pseudonimizacji, certyfikaty i audyty bezpieczeństwa.
Im wcześniej te kwestie zostaną wyjaśnione, tym mniejsze ryzyko, że po wdrożeniu okaże się konieczne kosztowne przebudowanie integracji lub migracja do innego dostawcy.
Typowe błędy przy wdrażaniu AI a RODO
„Pilotaż” bez analizy prawnej
Częstym błędem jest traktowanie pilotażowego wdrożenia jako „poza radarem” RODO. Nawet testowy projekt, jeśli działa na prawdziwych danych osobowych, musi spełniać wymagania prawne.
Brak klauzul informacyjnych, niejasna podstawa przetwarzania czy luźne podejście do retencji danych testowych prowadzą do naruszeń na długo przed formalnym uruchomieniem produkcyjnym.
Zbyt szerokie cele w politykach prywatności
Formuły typu „Twoje dane mogą być wykorzystywane do poprawy naszych usług, w tym systemów opartych na sztucznej inteligencji” są zbyt ogólne, jeśli w praktyce obejmują np. trenowanie modeli marketingowych czy profilowanie pod kątem ryzyka.
Cel musi być na tyle precyzyjny, żeby osoba mogła realnie ocenić, co się będzie działo z jej danymi, i ewentualnie skorzystać z prawa sprzeciwu. Ogólne klauzule są ryzykowne, zwłaszcza przy intensywnych zastosowaniach AI.
Brak rozdzielenia danych operacyjnych i treningowych
Zdarza się, że dane z systemu operacyjnego są bezrefleksyjnie kopiowane do środowiska treningowego. W efekcie w zbiorach treningowych lądują dane, które nie są do tego potrzebne (np. treść reklamacji zawierająca dane wrażliwe, pełne dane kontaktowe, załączniki dokumentów).
Rozwiązaniem jest osobna warstwa przygotowywania danych pod trening (feature store) z klarownymi regułami: jakie pola mogą być użyte, jak są maskowane czy agregowane, jak długo są przechowywane.
Niewystarczająca kontrola nad logami
Niewłaściwa konfiguracja logowania i monitoringu
Logi często zawierają pełne zapytania użytkowników, identyfikatory, dane kontaktowe, a nawet treści wrażliwe. Jeśli system logowania jest skonfigurowany „na maksa”, szybko staje się niekontrolowanym magazynem danych osobowych.
Zakres danych w logach trzeba ograniczyć do tego, co jest niezbędne do bezpieczeństwa i utrzymania usługi. Dobrze działa podejście: najpierw definiujemy przypadki użycia logów, dopiero potem pola, które faktycznie są potrzebne.
Logi powinny mieć krótsze okresy retencji niż dane operacyjne. Przy incydencie łatwiej wtedy wykazać, że dane pomocnicze nie były przechowywane dłużej niż trzeba.
Brak planu obsługi praw osób, których dane dotyczą
System AI wdrożony bez przemyślenia, jak realizować prawa z RODO, szybko prowadzi do „ręcznych” obejść. Każdy wniosek osoby oznacza improwizację po stronie IT i prawników.
Mechanizmy identyfikacji danych danej osoby w logach, modelach czy zbiorach treningowych powinny być zaprojektowane razem z architekturą. Jeśli nie da się ich zlokalizować, trudno realnie zrealizować np. prawo do usunięcia.
Przy modelach wysokiego ryzyka (np. scoring kredytowy) brak procedur obsługi wniosków o sprzeciw czy wyjaśnienie decyzji często jest pierwszym, co zauważy organ nadzorczy.
„Magiczne” pojęcie anonimizacji
Usunięcie imienia, nazwiska czy PESEL-u nie oznacza automatycznie anonimizacji. W wielu zbiorach cechy połączeniowe (wiek, lokalizacja, historia zachowań) nadal pozwalają z dużym prawdopodobieństwem zidentyfikować osobę.
Jeśli dane mają charakter pseudonimizowany, nadal podlegają RODO, nawet gdy klucz znajduje się w innym systemie. Trzeba to odzwierciedlić w dokumentacji i komunikacji z użytkownikami.
Anonimizacja jest procesem, nie jednorazową operacją. Każda zmiana sposobu wykorzystywania zbioru może zwiększyć ryzyko ponownej identyfikacji.
Brak spójności między dokumentacją a rzeczywistością
Polityki prywatności, DPIA i rejestry czynności często opisują model, który istniał w momencie startu projektu, a nie po roku kolejnych iteracji i pivotów.
Każda istotna zmiana celu, zakresu danych czy logiki działania systemu AI powinna wywoływać aktualizację dokumentacji. Jeśli tego zabraknie, organizacja formalnie przetwarza „coś innego”, niż sama deklaruje.
Nie chodzi o to, żeby każdą drobną korektę traktować jak nowy projekt, tylko o wyłapanie momentów, w których zmienia się profil ryzyka lub charakter przetwarzania.
Ignorowanie ryzyka wtórnego wykorzystania danych
Dane zebrane do jednego projektu AI łatwo „pożyczane” są do innych zadań: nowego modelu marketingowego, dodatkowej analityki, segmentacji. Bez formalnej zmiany celu prowadzi to do tzw. function creep.
Jeżeli nowy cel nie mieści się w pierwotnej podstawie prawnej, konieczna jest nowa analiza: czy można oprzeć się na uzasadnionym interesie, czy potrzebna jest zgoda, albo czy dane trzeba wcześniej zanonimizować.
Brak kontroli nad wtórnym wykorzystaniem najczęściej wychodzi na jaw dopiero przy inspekcji lub incydencie, kiedy trzeba opisać pełny „łańcuch życia” danych.
Prawa osób, których dane przetwarzane są przez AI – jak na nie reagować
Prawo do informacji – co trzeba ujawnić przy systemach AI
Informując o przetwarzaniu danych przez AI, nie wystarczy ogólny opis „korzystamy z algorytmów”. Użytkownik powinien rozumieć, jaki jest cel działania systemu i jakie może mieć skutki.
Zakres informacji obejmuje m.in.: kategorie danych wykorzystywanych w modelu, podstawę prawną, okres przechowywania, odbiorców danych, a także informację o profilowaniu lub zautomatyzowanych decyzjach, jeśli występują.
Opis nie musi ujawniać tajemnicy przedsiębiorstwa czy kodu źródłowego, ale powinien w prosty sposób wskazywać, jakie logiki i kryteria wpływają na wynik (np. decyzję o ofercie, priorytecie obsługi, ocenie ryzyka).
Prawo dostępu do danych i „sensowne wyjaśnienia”
Osoba ma prawo wiedzieć, czy jej dane zostały wykorzystane w danym systemie AI oraz jakie kategorie tych danych są przetwarzane. W praktyce trzeba mieć możliwość ich odszukania po identyfikatorze.
Przy zautomatyzowanych decyzjach pojawia się dodatkowy element: wyjaśnienie głównych przesłanek decyzji. Z perspektywy RODO nie jest wymagane pełne ujawnienie modeli, ale opis czynników, które miały największy wpływ na wynik.
W systemach opartych na modelach black-box pomocne są narzędzia wyjaśnialności (np. SHAP, LIME), ale rezultat trzeba przetłumaczyć na język zrozumiały dla osoby, której dotyczy decyzja.
Prawo do sprostowania i aktualizacji danych
Jeśli dane wejściowe modelu są nieprawidłowe, wynik będzie z natury zniekształcony. Organizacja musi więc mieć możliwość korekty błędnych danych źródłowych oraz – w miarę możliwości – aktualizacji ich wpływu na wynik modelu.
W systemach, gdzie dane są często odświeżane (ciągłe trenowanie, retraining), sprostowanie danych źródłowych zwykle wystarcza, aby kolejny cykl wytrenował model na poprawnych informacjach.
Gorsza sytuacja występuje przy modelach statycznych uczonych raz na kilka lat. W takich przypadkach przy istotnym błędzie danych dotyczących konkretnej osoby może być konieczne zastosowanie środków kompensacyjnych (np. ręczna weryfikacja decyzji dla tej osoby).
Prawo do usunięcia danych i „bycia zapomnianym” a modele AI
Usunięcie danych z systemów źródłowych i logów jest stosunkowo proste. Problem pojawia się, gdy dane zostały użyte do trenowania modelu, który nie przechowuje pojedynczych rekordów wprost.
RODO nie narzuca obowiązku „odtrenowania” modelu dla każdej osoby, ale wymaga, by organizacja rozważyła, czy utrzymanie modelu mimo żądania usunięcia nie narusza jej praw. Przy małych, wrażliwych zbiorach ryzyko jest większe.
Rozwiązania organizacyjne to m.in.: ograniczanie czasu życia modeli, częstsze przeuczanie na zaktualizowanych zbiorach, a w szczególnych przypadkach wykluczenie danej osoby z wykorzystania wyniku modelu (np. manualna ścieżka decyzyjna).
Prawo do ograniczenia przetwarzania w kontekście AI
Ograniczenie przetwarzania oznacza, że dane danej osoby nie mogą być dalej aktywnie wykorzystywane, poza kilkoma wyjątkami (np. obrona roszczeń). Przy projektach AI sprowadza się to do zamrożenia użycia danych w modelach.
Technicznie może to oznaczać flagę w systemie źródłowym, która blokuje dalsze wykorzystanie danych tej osoby w pipeline treningowym oraz w niektórych scenariuszach także w systemach scoringowych.
Kluczowe jest, by taki mechanizm nie istniał tylko na papierze. Jeżeli ograniczenie przetwarzania ma działać, musi być rozumiane przez zespół techniczny i zaimplementowane w praktyce.
Prawo do sprzeciwu wobec profilowania i marketingu opartego na AI
Profilowanie na potrzeby marketingu, personalizacji treści czy oceny ryzyka można często oprzeć na uzasadnionym interesie. Osoba ma wtedy prawo sprzeciwić się takiemu przetwarzaniu w dowolnym momencie.
Sprzeciw powinien skutkować rzeczywistą zmianą: wyłączeniem osoby z segmentów marketingowych, modyfikacją logiki rekomendacji lub przełączeniem jej do mniej inwazyjnego trybu działania systemu.
Przy architekturze opartej na eventach i segmentach technicznie jest to wykonalne, o ile już na etapie projektu przewidziano identyfikator pozwalający wykluczyć użytkownika z grupy, a nie „wypaliło” się wszystkiego na stałe w modelu.
Prawo do przenoszenia danych a systemy oparte na AI
Przenoszenie danych polega na udostępnieniu ich w ustrukturyzowanym, powszechnie używanym formacie. RODO obejmuje głównie dane dostarczone przez osobę oraz dane obserwowane, a nie wnioski i profile pochodne.
W projektach AI trzeba więc zdefiniować, co dokładnie będzie przekazywane: surowe dane wejściowe, historia interakcji, ewentualnie uzyskane od innych źródeł dane o osobie, o ile spełniają kryteria z art. 20.
Same parametry modelu, wskaźniki scoringowe czy profile wyprowadzone zazwyczaj nie podlegają przenoszeniu, choć można rozważyć udostępnienie części z nich w formie dodatkowej, jeśli nie narusza to praw innych osób i tajemnicy przedsiębiorstwa.
Prawo do niepodlegania decyzji opierającej się wyłącznie na zautomatyzowanym przetwarzaniu
Jeśli decyzja wywołuje skutki prawne lub w podobnie istotny sposób wpływa na osobę (np. odrzucenie wniosku kredytowego, oferty pracy, znaczące różnicowanie warunków umowy), uruchamia się art. 22 RODO.
W takiej sytuacji organizacja musi co do zasady: umożliwić zakwestionowanie decyzji, umożliwić interwencję człowieka i przedstawić przynajmniej ogólne wyjaśnienie logiki działania systemu.
„Interwencja człowieka” powinna oznaczać realną możliwość zmiany wyniku, a nie jedynie formalne kliknięcie akceptacji. W praktyce wymaga to przeszkolenia osób weryfikujących decyzje i dania im dostępu do odpowiednich informacji.
Procedury obsługi wniosków – jak nie zgubić się w złożonej architekturze
Przy kilku systemach źródłowych, hurtowni danych, feature store i wielu modelach łatwo o sytuację, gdy różne zespoły inaczej rozumieją zakres danych podlegających wnioskowi.
Potrzebna jest centralna procedura, która określa, jakie komponenty systemu obejmuje dany typ żądania (dostęp, usunięcie, ograniczenie, sprzeciw) i w jakiej kolejności są obsługiwane.
Dobrą praktyką jest mapowanie danych (data lineage) między systemami. Dzięki temu zespół odpowiedzialny za RODO nie musi każdorazowo dopytywać programistów, w których pipeline’ach jeszcze znajdują się dane konkretnej osoby.
Komunikacja z osobami, których dane dotyczą, przy incydentach AI
Incydenty w projektach AI rzadko polegają na prostym „wycieku bazy”. Częściej dotyczą ujawnienia danych w logach, nieuprawnionego wykorzystania do trenowania modelu lub dyskryminującej logiki decyzji.
Treść zawiadomień o naruszeniu powinna to odzwierciedlać: wskazywać, w jakiej części systemu doszło do problemu, jakie dane mogły zostać wykorzystane oraz jakie działania naprawcze podjęto (np. wycofanie modelu, zmiana konfiguracji logowania, dodatkowa weryfikacja decyzji).
Przy incydentach związanych z automatycznymi decyzjami jednym z działań naprawczych może być uruchomienie ręcznego przeglądu określonych decyzji historycznych oraz umożliwienie osobom złożenia reklamacji w uproszczonym trybie.
Najczęściej zadawane pytania (FAQ)
Czy RODO ma zastosowanie do sztucznej inteligencji i dużych modeli językowych?
Tak. RODO obowiązuje zawsze, gdy AI przetwarza dane osobowe – niezależnie od tego, czy jest to prosty klasyfikator, czy duży model językowy działający w chmurze. Nie ma znaczenia nazwa technologii, tylko to, czy da się z danej informacji z rozsądnym nakładem środków dojść do konkretnej osoby.
Embeddingi, wektory, hashe czy identyfikatory klienta często nadal są danymi osobowymi, bo można je połączyć z innymi zbiorami i zidentyfikować człowieka. „To tylko liczby” nie jest argumentem, jeśli z punktu widzenia funkcjonalnego system da się wykorzystać do rozpoznania osoby.
Czy można trenować modele AI na danych klientów z CRM zgodnie z RODO?
Można, ale pod warunkiem spełnienia typowych wymogów RODO: właściwej podstawy prawnej, minimalizacji zakresu danych, kontroli celu przetwarzania i zabezpieczeń technicznych. Zaciąganie „całego CRM, bo się przyda” jest ryzykowne, jeśli część pól nie jest potrzebna do danego modelu.
Przed trenowaniem warto przejść po polach i usunąć lub zamaskować wszystko, co nie jest niezbędne (np. PESEL, dokładny adres, jeśli nie wpływają na wynik). Dobrym standardem jest też wykonanie DPIA (oceny skutków) dla większych projektów i opisanie modeli w rejestrze czynności przetwarzania.
Czy testowe środowisko AI podlega RODO tak samo jak produkcyjne?
Tak. RODO nie rozróżnia baz testowych i produkcyjnych. Jeżeli w środowisku testowym znajdują się prawdziwe dane osobowe, to wszystkie obowiązki – legalność, bezpieczeństwo, retencja, prawa osób – działają w pełnym zakresie.
Najwięcej naruszeń pojawia się właśnie w testach: łączenie wielu źródeł, brak ograniczeń dostępu, brak planu usuwania danych. Bezpieczniejszą praktyką jest generowanie lub anonimizacja danych testowych oraz formalne uregulowanie, kto i jak może korzystać z realnych danych w sandboxie.
Kiedy model AI sam w sobie staje się zbiorem danych osobowych?
Model staje się nośnikiem danych osobowych, gdy można z niego wydobyć konkretne informacje o osobie, np. pełne nazwisko w powiązaniu ze sprawą, treść maila czy opis zdarzenia pozwalający na identyfikację. W dużych modelach językowych jest to możliwe z powodu zjawiska „memorization”.
Aby to ocenić, stosuje się testy z kontrolnymi zapytaniami. Jeśli model odtwarza fragmenty danych treningowych, trzeba potraktować sam model jak zasób z danymi osobowymi: uwzględnić go w rejestrze, objąć retencją, zabezpieczeniami i procedurami dostępu.
Jaką podstawę prawną stosować do wykorzystania AI w obsłudze klienta?
Najczęściej stosuje się trzy podstawy: niezbędność do wykonania umowy, uzasadniony interes administratora lub zgodę. W obsłudze klienta (np. czat AI powiązany z CRM) typowe jest powołanie się na niezbędność do umowy albo uzasadniony interes, jeśli funkcja jest „dookoła” usługi głównej.
Zgoda rzadko sprawdza się jako jedyna podstawa dla podstawowej obsługi, bo musi być dobrowolna i odwoływalna. Uzasadniony interes wymaga przeprowadzenia testu równowagi – trzeba pokazać, że korzyści (np. krótszy czas odpowiedzi) nie naruszają nadmiernie prywatności klientów.
Czy dostawca chmurowego narzędzia AI jest administratorem czy procesorem danych?
Co do zasady, jeśli firma decyduje, że dane klientów będą użyte do obsługi przez czat AI, pozostaje administratorem, a dostawca chmurowy działa jako procesor (podmiot przetwarzający). Wymaga to umowy powierzenia przetwarzania danych, która jasno określa zakres, cele i środki.
Sytuacja się komplikuje, gdy dostawca chce używać danych do własnych celów, np. trenowania swoich modeli dla innych klientów. Wtedy może stać się odrębnym administratorem lub współadministratorem, co wymaga innej konstrukcji umownej i osobnego spełnienia obowiązków informacyjnych.
Jak ograniczyć ryzyko wycieku danych osobowych w odpowiedziach modelu AI?
Podstawą jest kontrola tego, co trafia do modelu i co jest logowane. Zakres danych wejściowych należy ograniczyć do niezbędnego minimum, a wrażliwe identyfikatory (PESEL, pełne adresy, numery kont) pseudonimizować lub usuwać przed wysłaniem do silnika AI.
Przydatne są też techniczne zabezpieczenia: filtry po stronie aplikacji, które „wyłapują” wzorce danych osobowych w odpowiedziach, ograniczenie dostępu do logów, krótkie okresy retencji oraz regularne testy, czy model nie generuje danych innych klientów po nietypowych zapytaniach.
Najważniejsze punkty
RODO stoi w napięciu z „głodem danych” AI – projekty muszą restrykcyjnie stosować zasadę minimalizacji, usuwać lub maskować zbędne informacje i jasno określać cel trenowania modeli.
Środowiska testowe i pilotażowe nie są poza RODO – dane osobowe w sandboxie wymagają takich samych podstaw prawnych, zabezpieczeń, retencji i DPIA jak system produkcyjny.
Korzystanie z gotowych modeli (API, SaaS) i trenowanie własnych modeli to dwa różne profile ryzyka: w pierwszym kluczowe są umowy i konfiguracja po stronie dostawcy, w drugim – pełna dokumentacja, DPIA i ścisła kontrola nad procesem uczenia.
Najpoważniejsze ryzyka AI pod kątem RODO to niejawne źródła danych, brak przewidywalnej kontroli nad modelem, przecieki w odpowiedziach i logach oraz „rozjeżdżanie się” pierwotnie zadeklarowanych celów przetwarzania.
Embeddingi, wektory, hashe czy identyfikatory techniczne mogą być danymi osobowymi, jeśli w rozsądny sposób pozwalają wrócić do konkretnej osoby – sam brak imienia i nazwiska nie wyłącza RODO.
Model AI może sam stać się nośnikiem danych osobowych, gdy „zapamiętuje” i jest w stanie odtworzyć fragmenty danych treningowych; wtedy podlega pełnemu reżimowi RODO, łącznie z retencją i prawami osób.
Ocena, czy model ujawnia dane osobowe, wymaga praktycznych testów (kontrolne zapytania, próby wydobycia treści z treningu), a w razie pozytywnego wyniku – ujęcia modelu w rejestrze czynności przetwarzania i objęcia go dodatkowymi zabezpieczeniami.
