Dlaczego AI miesza w dotychczasowym podejściu do danych osobowych
Od Excela do modelu językowego – skok jakościowy, nie tylko ilościowy
Przez lata zarządzanie danymi osobowymi w firmach kojarzyło się z tabelami Excela, raportami z CRM i prostymi systemami, które „robiły dokładnie to, co im kazano”. Dane płynęły w dość przewidywalny sposób: formularz – baza – raport – eksport. Kontrola polegała głównie na tym, by nie wysłać przypadkiem całej bazy newslettera do jednego klienta.
Sztuczna inteligencja zmienia ten obraz w dwóch wymiarach. Po pierwsze, przetwarza dane na znacznie wyższym poziomie abstrakcji – nie tylko zapisuje i filtruje, ale interpretuje, wnioskuje i generuje nowe treści. Po drugie, modele AI „lubią” duże zbiory danych, z wielu źródeł, łączone w sposób, który z perspektywy RODO oznacza bardzo szeroki zakres i cele przetwarzania.
System raportowy na SQL zwróci dokładnie to, o co go poprosisz. Model językowy zaproponuje rozwiązanie, zasugeruje decyzję, stworzy podsumowanie danych klienta czy prognozę jego zachowania. Z punktu widzenia ochrony danych osobowych fundamentalna różnica polega na tym, że ta sama porcja danych może być użyta do wielu różnych celów, często trudnych do przewidzenia na etapie projektowania.
To właśnie dlatego klasyczne podejście „spiszmy proces w RCP i zamknijmy temat” zaczyna pękać. Tam, gdzie kiedyś był jeden stabilny proces, teraz jest system uczący się na danych, reagujący na nowe informacje i coraz silniej połączony z innymi narzędziami w organizacji.
Gdzie AI dotyka danych osobowych w typowej firmie
W części firm AI jest już obecna, ale pod innymi nazwami: „inteligentny scoring”, „smart routing”, „rekomendacje”, „system antyfraudowy”. W innych wchodzi tylnymi drzwiami jako abonament na narzędzie SaaS, które ktoś z działu operacyjnego „po prostu włączył”, bo usprawniało pracę.
Najczęstsze obszary styku AI z danymi osobowymi w realnej firmie to między innymi:
Obsługa klienta: chatboty na stronie, asystenci głosowi, automatyczne systemy odpowiedzi na maile, klasyfikacja zgłoszeń w helpdesku.
HR: systemy ATS filtrujące CV, automatyczna selekcja kandydatów, narzędzia do analizy zaangażowania pracowników, planowania grafików.
Bezpieczeństwo: systemy wykrywania nadużyć i wycieków, analiza logów, monitoring aktywności użytkowników, systemy DLP.
Każdy z tych obszarów może legalnie przetwarzać dane, ale łączenie ich w jeden „inteligentny ekosystem” rodzi ryzyko rozszerzenia celu przetwarzania i zacierania granic między procesami. Dla klienta czy pracownika wszystko wygląda jak jedna usługa, ale pod spodem potrafi pracować kilka różnych modeli AI na różnych zestawach danych.
W praktyce oznacza to, że dział prawny, IOD i IT muszą nauczyć się patrzeć na AI przekrojowo, a nie tylko przez pryzmat pojedynczego systemu czy modułu.
Historia „sprytnego chatbota”, który zapamiętywał za dużo
Dobrym przykładem jest mała firma usługowa, która wdrożyła chatbot do obsługi klientów na stronie. Początkowo chatbot prosił jedynie o ogólny opis problemu. Po kilku tygodniach dział sprzedaży poprosił jednak, by chatbot również „zapisywał” numer telefonu i e-mail, bo ułatwi to późniejsze kontakty.
Chatbot zaczął więc gromadzić komplet danych: imię, kontakt, opis sprawy, czasem numer umowy, a w rozmowach pojawiały się też dane wrażliwe (np. informacje o zdrowiu związane z usługą). Dopiero po tygodniu ktoś z IT zauważył, że narzędzie SaaS domyślnie zapisuje wszystkie rozmowy do treningu modelu i backupów w chmurze dostawcy, a dostęp do nich ma także zespół wsparcia technicznego spoza UE.
Formalnie zadziało się tu kilka rzeczy naraz: zmiana celu przetwarzania (obsługa zapytania → marketing), przekazanie danych do nowego podmiotu przetwarzającego, transfer poza EOG i przetwarzanie szczególnych kategorii danych. Wszystko „przy okazji”, jednym kliknięciem aktywującym dodatkową funkcję narzędzia. Tak właśnie AI „miesza” w starym, liniowym podejściu do danych osobowych.
Dobrą praktyką staje się traktowanie każdej nowej funkcji AI jak mini-projektu RODO: z krótkim opisem celu, przepływu danych, ryzyk i środków zabezpieczających – nawet jeśli na końcu okaże się, że zmiany są minimalne.
Podstawy prawne: jak RODO patrzy na AI
Definicja danych osobowych w kontekście AI
RODO nie zna pojęcia „danych nieistotnych dla AI”. Dane osobowe to wszelkie informacje o zidentyfikowanej lub możliwej do zidentyfikowania osobie fizycznej. W praktyce oznacza to, że:
dane kontaktowe, numer PESEL, NIP osoby fizycznej – to oczywistość,
adres IP, identyfikator urządzenia, identyfikator użytkownika w systemie – mogą być danymi osobowymi, jeśli pozwalają na powiązanie z konkretną osobą,
dane tekstowe w promptach i logach modeli mogą zawierać imiona, opisy sytuacji, stanowiska, a czasem informacje wrażliwe.
AI wprowadza tu dwa dodatkowe napięcia. Po pierwsze, modele przetwarzają dane wewnętrznie w postaci wektorów, embeddingów, parametrów – z perspektywy inżyniera to liczby, ale z perspektywy prawa liczy się, że wciąż odnoszą się do konkretnej osoby lub jej zachowania. Po drugie, pojawia się problem danych pochodnych: profil, predykcja czy „podobieństwo” do innych użytkowników mogą również stanowić dane osobowe.
Dyskusje o tym, czy sama struktura modelu zawierająca „ślady” danych treningowych to jeszcze dane osobowe, są nadal otwarte. Z praktycznego punktu widzenia rozsądniej jest przyjąć konserwatywne podejście: jeśli z działania modelu można wydobyć informację o konkretnej osobie (np. przez odtworzenie fragmentu CV czy e-maila), mówimy o przetwarzaniu danych osobowych.
Role: administrator, podmiot przetwarzający i dostawca modelu
Kluczową kwestią dla zgodności z RODO jest określenie, kto w ekosystemie AI pełni rolę administratora danych (ADO), kto jest podmiotem przetwarzającym (procesorem), a kto może być odrębnym administratorem. Przy tradycyjnym systemie on-premise zwykle jest to proste – firma jest ADO, a dostawca oprogramowania nie dotyka danych. W modelach chmurowych i API AI sytuacja bywa bardziej złożona.
Typowy scenariusz:
Twoja firma pozostaje administratorem danych klientów i pracowników – to Ty decydujesz o celach i sposobach przetwarzania, w tym o wyborze narzędzi AI.
Dostawca platformy AI (np. system czatbotowy w chmurze) jest procesorem, jeśli przetwarza dane wyłącznie w Twoim imieniu i na podstawie Twoich instrukcji.
Jeśli jednak dostawca używa danych do własnych celów (np. treningu globalnego modelu, analityki, ulepszania algorytmów), może być odrębnym administratorem dla tej części przetwarzania.
Dlatego tak ważne jest, aby przy wyborze rozwiązań AI nie ograniczać się do marketingowego opisu funkcji, ale zejść poziom niżej – do polityk prywatności i zapisów umowy powierzenia danych. Krótkie „akceptuję regulamin” potrafi przerzucić odpowiedzialność i ryzyko w najmniej oczekiwanym momencie.
Legalne podstawy przetwarzania i wtórne wykorzystanie danych
RODO nie tworzy osobnej „podstawy” dla AI. Stosuje się te same przesłanki przetwarzania, ale muszą one faktycznie pasować do skali i charakteru systemu. W praktyce najczęściej spotykane są:
Uzasadniony interes administratora – np. poprawa jakości obsługi, bezpieczeństwa systemów, optymalizacja procesów. Wymaga przeprowadzenia testu równowagi i uwzględnienia oczekiwań osób, których dane dotyczą.
Zgoda osoby – np. na profilowanie marketingowe czy personalizację oferty. Musi być dobrowolna, konkretna, świadoma i odwoływalna.
Umowa – jeśli przetwarzanie jest niezbędne do jej wykonania, np. analiza zgłoszeń serwisowych klienta.
Obowiązek prawny – rzadziej wprost dotyczy AI, ale może wspierać np. systemy monitorujące zgodność.
Przy AI szczególnie problematyczne bywa wtórne wykorzystanie danych: dane zebrane w jednym celu (np. obsługa reklamacji) są później używane do treningu modelu rekomendującego nowe produkty. Taki zabieg wymaga oceny zgodności celów oraz transparentnego poinformowania osób. Jeśli nowy cel jest nie do pogodzenia z pierwotnym, może być potrzebna nowa podstawa prawna, np. zgoda.
Transparentność w kontekście AI powinna wykraczać poza lakoniczne „Twoje dane są przetwarzane z użyciem narzędzi automatycznych”. Użytkownik ma prawo rozumieć, że np. „Twoje zgłoszenia są analizowane przez system uczący się, który pomaga przypisać sprawę do właściwego konsultanta; decyzję końcową wciąż podejmuje człowiek”. To często drobna zmiana języka, ale duża zmiana w postrzeganiu ryzyka i zaufaniu.
Dobrą praktyką jest włączenie do procesu zakupowego IT/IOD zestawu prostych, ale konkretnych pytań do dostawcy, podobnych do tych, które często porusza się w serwisach takich jak praktyczne wskazówki: informatyka: gdzie są przechowywane dane, jak długo, kto ma do nich dostęp, czy są używane do treningu i jakie mechanizmy usuwania przewidziano.
Źródło: Pexels | Autor: Markus Winkler
Zastosowania AI w zarządzaniu danymi osobowymi – od teorii do realnych scenariuszy
Automatyzacja obowiązków RODO w codziennej praktyce
Dobrze zaprojektowane systemy AI potrafią odciążyć IOD i działy operacyjne w kilku kluczowych obszarach. Najbardziej „wdzięczne” zastosowania to te, w których AI pomaga w porządkowaniu i klasyfikacji danych, a decyzja końcowa należy do człowieka.
Przykładowe zastosowania:
Klasyfikacja dokumentów pod kątem RODO: model analizuje pliki na współdzielonych dyskach i wskazuje, które zawierają dane osobowe, które dane wrażliwe, a które można zanonimizować lub usunąć.
Wsparcie rejestru czynności przetwarzania: narzędzie analizuje opisy procesów biznesowych (np. w Confluence, Word) i zasugeruje, jakie pola powinny znaleźć się w RCP dla danego procesu.
Wykrywanie danych w nieuporządkowanych źródłach: przeszukiwanie korespondencji e-mail, notatek CRM, załączników w poszukiwaniu danych danej osoby – przydatne szczególnie przy realizacji praw dostępu (DSAR).
W praktyce wygląda to tak, że zamiast ręcznie przeglądać setki plików, IOD używa narzędzia, które „podświetla” najbardziej ryzykowne pozycje i sugeruje działania: archiwizację, anonimizację, usunięcie, skrócenie okresu retencji. Człowiek weryfikuje, ale nie zaczyna od pustej kartki.
Kluczem do legalności jest tu rozdzielenie roli pomocniczej AI od podejmowania wiążących decyzji. Model może napisać w notatce: „Dokument prawdopodobnie zawiera PESEL i dane zdrowotne”, ale decyzja o sposobie przetwarzania i retencji pozostaje po stronie człowieka, który zna szerszy kontekst.
AI przy obsłudze żądań osób, których dane dotyczą (DSAR)
Jednym z najbardziej czasochłonnych obowiązków pod RODO jest obsługa żądań dostępu do danych, ich sprostowania czy usunięcia. W złożonych środowiskach IT dane są rozproszone po wielu systemach, a ręczne ich wyszukiwanie bywa niemal archeologią cyfrową.
AI może tu pomóc w kilku krokach:
Identyfikacja osoby w wielu systemach: na podstawie podanych identyfikatorów (e-mail, numer klienta, imię i nazwisko) system wyszukuje odpowiadające rekordy w bazach, CRM, helpdesku, narzędziach marketing automation.
Agregacja wyników: zebrane dane są grupowane tematycznie (zakupy, reklamacje, logi bezpieczeństwa, preferencje marketingowe) i przedstawiane operatorowi.
Wstępne opracowanie odpowiedzi: model językowy może przygotować szkic odpowiedzi dla osoby, opisujący kategorie danych, cele przetwarzania i okresy przechowywania.
Taki system musi jednak mieć wbudowane bezpieczniki: wyraźne oznaczanie elementów wymagających weryfikacji, mechanizm „double check” przy usuwaniu danych oraz logowanie wszystkich działań w celu audytu. DSAR to obszar, gdzie błąd AI może prowadzić do poważnych naruszeń: ujawnienia danych niewłaściwej osobie lub niewykonania obowiązku w pełnym zakresie.
Warto też zaprojektować interfejs narzędzia tak, aby pracownik wyraźnie widział, które fragmenty są wynikiem automatycznej analizy, a które pochodzą z systemów źródłowych. Przezroczystość wobec użytkownika wewnętrznego często decyduje o tym, czy AI będzie traktowana jako wsparcie, czy jako nieprzewidywalne „czarne pudełko”.
Gdy taki system zaczyna działać w większej skali, dochodzi jeszcze jeden element: priorytetyzacja żądań. Algorytm może podpowiadać, które wnioski są pilne (krótki termin, ryzyko sporu, skomplikowany zakres danych), a które można obsłużyć w standardowym trybie. Dla zespołu to realna różnica – zamiast tonąć w skrzynce mailowej, pracownicy widzą uporządkowaną kolejkę z sensownymi podpowiedziami, od czego zacząć.
Technologia kusi, żeby jak najwięcej robiło się „samo”. Przy DSAR granica jest jednak dość wyraźna: AI może pomagać szukać, porządkować i tłumaczyć na ludzki język, ale nie powinna samodzielnie rozstrzygać, czy dane usunąć, ograniczyć, czy zachować z uwagi na inne obowiązki prawne. Tu potrzebna jest decyzja człowieka, najlepiej udokumentowana w systemie – z krótkim uzasadnieniem w logach, czyli: kto, co, kiedy i dlaczego zatwierdził.
Dobre efekty daje połączenie AI z prostymi workflow: po wygenerowaniu paczki danych i szkicu odpowiedzi narzędzie kieruje sprawę do konkretnej osoby (np. prawnika, IOD czy właściciela systemu), a ich poprawki służą jako materiał treningowy. System z czasem „uczy się” stylu firmy, powtarzających się wyjątków i charakterystycznych pułapek. Przypomina to współpracę z nowym pracownikiem – na początku wymaga dużo nadzoru, ale po kilku miesiącach sam wie, na co uważać.
Sprawnie wdrożona AI w obszarze RODO nie jest cudowną różdżką, tylko kolejnym narzędziem w warsztacie. Daje przewagę tym organizacjom, które potrafią połączyć technologię z rozsądnymi procedurami i jasnym podziałem odpowiedzialności – tak, aby maszyna robiła to, w czym jest dobra (przeszukiwanie, klasyfikacja, podpowiedzi), a człowiek zachował kontrolę nad tym, co najważniejsze: oceną ryzyka, relacją z klientem i ostateczną decyzją o losie danych.
AI w bezpieczeństwie danych: od monitoringu logów do reagowania na incydenty
Obszar bezpieczeństwa to miejsce, gdzie AI naturalnie wchodzi w świat danych osobowych. Systemy monitorujące logi, nietypowe logowania czy anomalie w ruchu sieciowym niemal zawsze przetwarzają identyfikatory użytkowników, adresy IP, czasem szczegółowe informacje o działaniach w systemie. To dane osobowe w czystej postaci, choć często traktowane jak „techniczne tło”.
Typowy scenariusz wygląda tak: narzędzie SI analizuje miliony zdarzeń z różnych systemów – logowania do VPN, ruch w aplikacjach, próby odczytu wielu rekordów bazy. Model uczy się, co jest normalne dla danej organizacji, a co przypomina przygotowanie do wycieku danych. Kiedy wykryje podejrzany wzorzec, podnosi alarm, klasyfikuje zdarzenie i proponuje pierwsze kroki reakcji (zablokuj konto, ogranicz dostęp, wymuś reset hasła).
Z prawniczego punktu widzenia oznacza to kilka konkretnych pytań:
Jak długo przechowywane są logi, na podstawie których działa system AI?
Czy zakres monitoringu jest proporcjonalny, czy zamienia się w stałą inwigilację pracowników?
Czy system nie wykorzystuje tych samych danych do zupełnie innych, „przyklejonych” później celów (np. ocena wydajności pracownika na podstawie logów bezpieczeństwa)?
Jeżeli system bezpieczeństwa zaczyna „wychodzić” poza czysto techniczną analizę i np. ocenia wiarygodność konkretnych użytkowników, bardzo szybko dochodzi się do profilu zachowania. Wtedy trzeba myśleć nie tylko o art. 32 RODO (bezpieczeństwo przetwarzania), ale także o zasadach profilowania i potencjalnego zautomatyzowanego podejmowania decyzji.
Bezpieczną praktyką jest wyraźne oddzielenie: mechanizmy AI wykrywają anomalie i tworzą raporty, natomiast decyzje o sankcjach wobec pracowników, blokadach kont czy zawiadomieniach do organów podejmują ludzie, na podstawie szerszego kontekstu. Dobrze, jeśli system umożliwia przejrzenie dowodów – logów, alertów, poprzednich zdarzeń – a nie jedynie suchy komunikat: „ryzyko wysokie, zablokuj użytkownika”.
Przy incydentach bezpieczeństwa dochodzi jeszcze jeden wątek: AI może pomagać w identyfikacji, czyj wyciek nastąpił i jak szeroki jest zakres naruszenia. Modele potrafią automatycznie kategoryzować wykradzione pliki, wychwycić w nich dane szczególnych kategorii oraz zasugerować, które osoby trzeba zawiadomić. Przy setkach czy tysiącach rekordów różnica między ręcznym przeglądem a wsparciem AI to czas liczony w dniach. A przecież zegar 72 godzin z RODO tyka nieubłaganie.
Uczenie modeli na danych osobowych: anonimizacja, pseudonimizacja i „przecieki” kontekstowe
Trening modeli na danych osobowych to często największa mina ukryta pod projektami AI. Z punktu widzenia biznesu to idealny zasób – realne dane, realne błędy, realne scenariusze. Z punktu widzenia prawa i etyki – ryzyko „odtworzenia” tych danych przez model albo ujawnienia ich w odpowiedziach.
Na poziomie technicznym pojawiają się trzy podejścia:
Uczenie na danych jawnych (niezabezpieczonych): szybkie i skuteczne, ale trudne do pogodzenia z zasadą minimalizacji i ograniczenia celu. Wymaga bardzo mocnego uzasadnienia i rygorystycznych zabezpieczeń.
Pseudonimizacja: zastąpienie identyfikatorów (np. imion, PESEL) losowymi wartościami, ale z możliwością odwrócenia procesu przez uprawnione osoby. Dla modelu to nadal cenne dane, bo struktura zachowań i zdarzeń pozostaje prawdziwa.
Anonimizacja: przekształcenie danych tak, aby nie dało się przypisać ich do konkretnej osoby, nawet przy użyciu dodatkowych informacji. Prawnie brzmi idealnie, ale w praktyce jest trudne i łatwo przesadzić w obie strony: albo dane wciąż pozwalają na reidentyfikację, albo stają się bezużyteczne.
Przykładowo: firma chce wytrenować model do automatycznego kategoryzowania zapytań klientów. Jeżeli podmieni imię i nazwisko na „Klient 123”, ale pozostawi bardzo charakterystyczny opis sytuacji („miałem wypadek na skrzyżowaniu X z Y, jechałem czerwonym autem marki Z”), ryzyko reidentyfikacji wciąż istnieje. Model może „zapamiętać” taką historię i odtworzyć ją w innym kontekście.
Dlatego przy projektowaniu treningu przydaje się coś na kształt „mapy wrażliwości”: lista pól i fragmentów treści, które wymagają agresywniejszego przetworzenia, skrócenia lub agregacji. Czasem wystarczy skrócić dane czasowe (tylko miesiąc zamiast pełnej daty i godziny), usunąć nazwy własne z opisów czy zamienić bardzo szczegółowe informacje o lokalizacji na szersze kategorie. Model straci trochę „koloru”, ale za to nie będzie niósł w sobie pełnych historii życiowych klientów czy pracowników.
Osobny problem to tzw. „przecieki kontekstowe”. Nawet jeśli pola typu „imię”, „e‑mail” znikną, treść opisu sprawy potrafi zawierać tyle szczegółów, że przy małej populacji osób z danym problemem łatwo odgadnąć, o kogo chodzi. Dotyczy to zwłaszcza danych zdrowotnych, sporów pracowniczych, spraw karnych. Tu nie wystarczy automatyczna maska – często potrzebna jest kombinacja reguł, modeli NER (rozpoznawanie jednostek nazewniczych) i zdrowego rozsądku prawnika czy IOD, który określa, jakie ryzyko jest akceptowalne.
Jeżeli firma decyduje się na uczenie modeli na danych nieanonimowych, musi mieć jasną historię: jaka jest podstawa prawna, jak długo dane będą używane w tym celu, czy model po treningu nie pozwala na „wyciągnięcie” konkretnych rekordów oraz czy dostawca technologii nie ma własnych, sprzecznych interesów (np. dokarmianie swojego ogólnego modelu danymi klienta).
Wymagania prawne krok po kroku przy wdrażaniu AI
Analiza celu i zakresu – zanim pojawi się linijka kodu
Przy projektach AI pokusa jest silna: „najpierw zobaczmy, co technologia potrafi, a potem pomyślimy, do czego ją wykorzystać”. Pod RODO to prosta droga do problemów. Logika powinna być odwrotna – najpierw precyzyjny cel, potem dobór danych i mechanizmów.
Na starcie zadaje się kilka prostych, ale twardych pytań:
Jaki konkretny problem biznesowy ma rozwiązać system AI (np. skrócenie czasu obsługi reklamacji o X, zmniejszenie liczby błędnie wysłanych faktur)?
Czy do tego celu konieczne jest użycie danych osobowych, czy wystarczy agregacja lub dane syntetyczne?
Jakie kategorie osób będą objęte systemem – klienci, pracownicy, kandydaci do pracy, podwykonawcy?
Czy AI będzie jedynie wsparciem człowieka, czy też jej wyniki będą miały realny wpływ na prawa i obowiązki osób (np. odmowa świadczenia, odrzucenie wniosku)?
Dopiero po odpowiedzi na te pytania można sensownie wybrać podstawę prawną, ocenić, czy potrzebna jest ocena skutków (DPIA), oraz zaplanować, jakie informacje trzeba przekazać osobom, których dane dotyczą. W przeciwnym razie powstaje klasyczne „narzędzie w poszukiwaniu problemu”, które z czasem zaczyna być używane do wszystkiego – a wtedy żadne klauzule informacyjne nie nadążają za rzeczywistością.
Ocena skutków (DPIA) dla systemów AI – co dorzucić ponad standard
Przy bardziej zaawansowanych zastosowaniach AI ocena skutków dla ochrony danych przestaje być dodatkiem „dla świętego spokoju” i staje się realnym narzędziem zarządzania ryzykiem. W przypadku modeli uczących się trzeba do klasycznego DPIA dołożyć kilka specyficznych klocków.
Po pierwsze – źródła treningowe. W DPIA warto jasno rozpisać:
z jakich systemów pochodzą dane treningowe (CRM, system kadrowy, helpdesk, monitoring bezpieczeństwa),
czy obejmują dane szczególnych kategorii (zdrowie, przekonania, dane biometryczne),
czy istnieje ryzyko, że model będzie odtwarzał fragmenty tych danych w odpowiedziach lub rekomendacjach.
Po drugie – mechanizmy kontroli jakości i błędów. Modele AI z natury są probabilistyczne. Nigdy nie działają w 100% poprawnie. W DPIA trzeba więc odpowiedzieć na pytania: jak firma wykrywa błędy, czy istnieje proces korekty, jak często następuje przegląd działania systemu i kto jest za to odpowiedzialny.
Po trzecie – wpływ na prawa jednostki. Jeżeli system ma wpływ na decyzje o zatrudnieniu, przyznaniu kredytu, zawarciu lub wypowiedzeniu umowy, DPIA powinna zawierać opis mechanizmu „wyjścia awaryjnego”: w jaki sposób osoba może zakwestionować wynik, uzyskać interwencję człowieka, poprosić o wyjaśnienie logiki działania narzędzia w odniesieniu do swojej sprawy.
Wreszcie – rola dostawcy. Przy usługach chmurowych, gotowych modelach oraz narzędziach „AI as a Service” DPIA powinna obejmować nie tylko wewnętrzne procesy, ale także realne ryzyko po stronie podmiotu przetwarzającego: jakie ma zabezpieczenia, czy jest poza EOG, jak wygląda podwykonawstwo, czy wykorzystuje dane klienta do własnego rozwoju produktu.
Relacje z dostawcami i podwykonawcami – umowa powierzenia w wersji „AI”
Umowy powierzenia przetwarzania danych w projektach AI rzadko mieszczą się w prostym szablonie. Trzeba zachować czujność, bo standardowe paragrafy o „świadczeniu usług IT” nie odpowiadają na kluczowe pytania dotyczące uczenia modeli i wtórnego wykorzystania danych.
Dobrym podejściem jest zbudowanie sobie krótkiej „checklisty AI” do umów:
Czy dostawca może używać danych (lub metadanych) do samodzielnego treningu swoich modeli poza projektem klienta?
Czy klient ma prawo do wglądu w logi przetwarzania, konfigurację modeli i informacje o podwykonawcach?
Jak długo przechowywane są dane wejściowe, dane wyjściowe (np. rekomendacje, klasyfikacje) oraz ewentualne „ślady” treningowe?
Co dzieje się z modelem po zakończeniu umowy – czy trzeba go „oduczyć” danych klienta, czy wystarczy usunięcie surowych rekordów?
Jeżeli dostawca oferuje gotowy model, z którego korzystają dziesiątki klientów, kluczowa jest jasność: czy model jest wspólnym zasobem, dokarmianym danymi wszystkich użytkowników, czy też klient ma swoją wydzieloną instancję, trenowaną tylko na jego danych. Z biznesowego punktu widzenia ten pierwszy wariant jest często tańszy i bardziej efektywny, ale z perspektywy RODO bywa trudniejszy do obrony, zwłaszcza przy danych wrażliwych.
W umowach przydają się też zapisy o transparentności algorytmicznej w granicach rozsądku: prawo do informacji o głównych typach danych używanych do treningu, o stosowanych technikach (np. modele językowe, drzewa decyzyjne, systemy rekomendacyjne), o częstotliwości aktualizacji modelu. Nie chodzi o zdradzanie tajemnicy przedsiębiorstwa, tylko o stworzenie podstaw do realnej odpowiedzialności, gdy coś pójdzie nie tak.
Privacy by design i by default w systemach AI
Projektowanie minimalizacji danych na poziomie architektury
Zasada minimalizacji danych w świecie AI wymaga odwrócenia klasycznego myślenia „im więcej danych, tym lepszy model”. Można ją wdrażać na kilku warstwach architektury, tak aby deweloperzy nie musieli za każdym razem wymyślać koła na nowo.
Na poziomie projektowania systemu przydają się m.in.:
Warstwy dostępu do danych: zamiast dawać modelowi pełen wgląd w bazę, tworzy się ograniczone widoki lub zestawy cech (features), w których wrażliwe dane są już zanonimizowane lub zagregowane.
Konfiguratory zakresu danych: możliwość włączania/wyłączania konkretnych kategorii danych bez zmiany kodu źródłowego. Dzięki temu IOD lub właściciel procesu może dostosować zakres do realnych potrzeb, a nie do maksymalnych technicznych możliwości.
Domyślne skracanie retencji: modele uczą się na możliwie świeżych danych, a mechanizmy retencji automatycznie odcinają najstarsze warstwy, chyba że istnieje mocne uzasadnienie biznesowe i prawne.
W praktyce często wychodzi na jaw, że system AI mógłby działać na zestawie zredukowanych cech (np. kategoria produktu, ogólny przedział wiekowy, liczba zakupów w kwartale), a nie na pełnych danych transakcyjnych. Wymaga to jednak rozmowy między biznesem, IT i IOD na etapie projektu, a nie po roku produkcji, gdy model jest już „rozdęty” informacjami o każdym kliknięciu użytkownika.
Domyślna wysoka ochrona – jak wygląda „by default” w AI
Privacy by default w systemach sztucznej inteligencji nie sprowadza się do zaznaczenia kilku checkboxów w ustawieniach. Chodzi o to, aby domyślne konfiguracje modeli i aplikacji były ustawione konserwatywnie, a rozszerzenia zakresu danych czy funkcji wymagały świadomej decyzji.
Dobrą praktyką jest np.:
włączone z automatu maskowanie danych w interfejsie użytkownika (np. częściowa anonimizacja w logach, ukrywanie pełnych numerów dokumentów),
domyślne wyłączenie wykorzystania danych klienta do ogólnego treningu produktu, chyba że klient świadomie zdecyduje inaczej,
ograniczenie dostępu do paneli administracyjnych modeli (konfiguracja, podgląd danych treningowych) tylko do konkretnych ról, z silnym uwierzytelnianiem i logowaniem działań.
Wielu dostawców domyślnie ustawia opcje „maksymalnego” wykorzystania danych, licząc, że niewielu administratorów zajrzy głębiej w konfigurację. Po stronie firmy dobrze więc działać na zasadzie „zaufanie, ale sprawdzaj”: standaryzować wymagania co do ustawień startowych i weryfikować je przy każdym wdrożeniu, a nie dopiero przy incydencie lub kontroli. Im prostsze i bardziej opisowe są te ustawienia (zamiast enigmatycznych przełączników), tym łatwiej wytłumaczyć je biznesowi i IOD.
Privacy by default ma też wymiar bardzo przyziemny: jakie informacje widzi pracownik, który korzysta z narzędzia AI w codziennej pracy. Chatbot do obsługi klienta może podpowiadać konsultantowi odpowiedź na zgłoszenie, ale nie musi przy okazji wyświetlać całej historii zdrowotnej czy pełnej listy poprzednich reklamacji. Jeżeli w interfejsie pojawiają się „smaczki”, które są zbędne do realizacji konkretnego zadania, to znaczy, że domyślna ochrona nie zadziałała.
Przy projektach bardziej eksperymentalnych (pilotaże, prototypy) kusi, żeby na chwilę poluzować zasady i „wrzucić wszystko, co mamy, zobaczymy, co model z tego zrobi”. Lepiej jednak odwrócić logikę: na etapie eksperymentu w ogóle nie sięgać po realne dane osobowe, tylko korzystać z dobrze zanonimizowanych zbiorów lub syntetycznych danych, a dopiero przy wejściu w produkcję stopniowo włączać prawdziwe rekordy – już pod pełną kontrolą prawną i techniczną. Daje to nie tylko spokój pod kątem ryzyka, ale też uczy zespół, że pełne dane użytkowników to „towar luksusowy”, a nie standardowy materiał testowy.
Wreszcie, privacy by design i by default nie utrzyma się w jednym zespole, jeśli reszta organizacji żyje w innym tempie. AI bardzo szybko obnaża niespójności: gdy marketing zbiera zgody na wszystko, dział sprzedaży importuje hurtowo leady z zewnętrznych źródeł, a zespół data science próbuje zbudować uczciwy, przejrzysty model, efektem jest ciągłe gaszenie pożarów. Tam, gdzie udaje się połączyć prawo, technologię i biznes przy jednym stole, systemy AI nie tylko „przechodzą” przez RODO, ale stają się zwyczajnie lepsze – mniej podatne na błędy, łatwiejsze do wyjaśnienia i bardziej przewidywalne zarówno dla zarządu, jak i dla osób, których dane napędzają cały ten mechanizm.
Najczęściej zadawane pytania (FAQ)
Czy korzystanie z AI w firmie zawsze oznacza przetwarzanie danych osobowych?
Nie zawsze, ale w praktyce – bardzo często. Jeśli model AI „widzi” informacje o konkretnych klientach, kandydatach czy pracownikach (np. imię, e-mail, historię zgłoszeń, opis sytuacji), to mówimy o danych osobowych, nawet jeśli system technicznie zamienia je na liczby i wektory.
Dane osobowe pojawiają się też tam, gdzie łatwo o nich zapomnieć: w treści promptów wpisywanych do czatbota, w logach systemu, w identyfikatorach urządzeń czy użytkowników. W praktyce bezpieczniej jest założyć, że jeśli z działania modelu można odtworzyć informację o konkretnej osobie (np. fragment CV, opis problemu zdrowotnego), to wchodzimy w reżim RODO, nawet gdy dostawca narzędzia zapewnia, że „to tylko anonimowe dane techniczne”.
Jak RODO patrzy na AI typu chatbot albo asystent w chmurze?
RODO nie ma osobnego rozdziału „dla AI”, ale wszystkie ogólne zasady stosują się tak samo. Chatbot czy asystent AI są tylko kolejnym sposobem przetwarzania danych osobowych – tak samo trzeba mieć cel, podstawę prawną, określone role (administrator / podmiot przetwarzający) i zadbany przepływ danych.
W praktyce największe ryzyko przy narzędziach chmurowych polega na tym, że jednym kliknięciem włączasz funkcję, która:
rozszerza cel przetwarzania (np. z obsługi na marketing),
udostępnia dane dostawcy do „treningu modelu”,
powoduje transfer danych poza EOG.
Dlatego wdrożenie chatbota przypomina raczej mini-projekt RODO niż prostą instalację wtyczki.
Kto jest administratorem danych przy korzystaniu z narzędzi AI w modelu SaaS?
Zazwyczaj administratorem danych pozostaje Twoja firma – to ona decyduje, po co i jak dane są przetwarzane, a także wybiera narzędzie AI. Dostawca usługi SaaS, który technicznie „obrabia” dane w Twoim imieniu, jest wtedy podmiotem przetwarzającym (procesorem) i powinien mieć z Tobą podpisaną umowę powierzenia.
Sytuacja komplikuje się, gdy dostawca korzysta z danych także na własne potrzeby, np. do trenowania globalnego modelu albo tworzenia własnych statystyk. Wtedy dla tej części przetwarzania może występować już jako odrębny administrator. W praktyce trzeba więc czytać nie tylko folder sprzedażowy, ale i politykę prywatności oraz regulamin – właśnie tam ukryte są zapisy o „ulepszaniu usług na podstawie danych użytkowników”.
Na jakiej podstawie prawnej mogę używać AI do profilowania klientów lub pracowników?
RODO nie wprowadza „specjalnej” podstawy dla AI. Stosujesz te same przesłanki, które znasz: najczęściej uzasadniony interes administratora albo zgodę osoby, której dane dotyczą. Wybór zależy od tego, jak głęboko ingerujesz w prywatność i czego oczekuje rozsądnie poinformowany klient czy pracownik.
Przykład: system antyfraudowy, który analizuje zachowania logowania – zwykle da się oprzeć na uzasadnionym interesie (bezpieczeństwo systemów). Zaawansowana personalizacja marketingowa, która przewiduje prawdopodobieństwo rezygnacji i „podkręca” ofertę, może już wymagać zgody, szczególnie jeśli odbiorca się takiej analizy nie spodziewa. Kluczem jest rzetelny test równowagi i jasne poinformowanie, co dokładnie robi algorytm.
Jak w praktyce ograniczyć ryzyko przy wdrażaniu nowych funkcji AI w firmie?
Najprościej traktować każdą nową funkcję AI jak mały projekt: opisać cel, dane wejściowe, przepływ między systemami, dostawców, a na koniec przejść przez listę ryzyk (np. rozszerzenie celu, wyciek, transfer poza EOG). To brzmi biurokratycznie, ale często wystarcza jedna strona konkretnej notatki zamiast 20-stronicowej analizy.
W praktyce sprawdza się kilka nawyków:
zadać dostawcy wprost pytanie: „Czy używacie naszych danych do treningu swoich modeli?”;
ustawić domyślnie maksymalną prywatność (wyłączony training, ograniczona retencja, brak logów z pełną treścią);
przeszkolić zespół, by nie wrzucał do AI pełnych baz, numerów PESEL czy dokumentacji medycznej „dla wygody”.
Krótka checklista przy każdej nowej integracji robi tu większą różnicę niż najbardziej błyskotliwy regulamin.
Czy łączenie danych z wielu systemów (CRM, helpdesk, HR) w jeden „inteligentny ekosystem” jest zgodne z RODO?
Może być zgodne, ale nie „z automatu”. Kłopot pojawia się wtedy, gdy dane z różnych procesów – np. rekrutacji, obsługi klienta i marketingu – zaczynają się mieszać w jednym modelu AI, a Ty nie potrafisz już jasno wskazać celu i zakresu przetwarzania dla konkretnej osoby.
Żeby taki ekosystem był zgodny z RODO, musisz:
mieć jasno opisane cele dla poszczególnych przepływów danych (a nie jeden ogólny „AI do optymalizacji biznesu”),
sprawdzić, czy wybrane podstawy prawne nadal pasują po połączeniu danych,
ustawić realne ograniczenia dostępu i funkcji – nie każdy moduł AI musi widzieć „wszystko o wszystkich”.
Jeśli z perspektywy klienta czy pracownika to „jedna usługa”, pod spodem i tak powinna działać zdrowa segmentacja procesów i modeli.
Czy dane użyte do trenowania modelu AI można potem wykorzystywać do innych celów?
Sam fakt, że dane trafiły do treningu modelu, nie oznacza zgody na dowolne dalsze wykorzystanie. Nadal obowiązuje zasada ograniczenia celu: to, że używasz danych np. do poprawy jakości obsługi, nie uprawnia automatycznie do wykorzystania ich do agresywnego marketingu czy zewnętrznych analiz bez osobnej podstawy.
Problem dodatkowo komplikuje się, gdy model jest trenowany na danych wielu klientów dostawcy. Jeśli z modelu można „wyciągnąć” informacje o konkretnej osobie (np. odtworzyć fragment korespondencji), wciąż mówimy o przetwarzaniu danych osobowych. Rozsądne podejście to: minimalizować dane w treningu, separować modele tam, gdzie to możliwe, oraz jasno opisać w dokumentacji, które dane służą do bieżącego działania usługi, a które – do jej rozwoju i na jakiej podstawie.
Bibliografia i źródła
Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO). Dziennik Urzędowy Unii Europejskiej (2016) – Podstawowe definicje, zasady i role w ochronie danych osobowych
Wytyczne 05/2021 w sprawie przykładów dotyczących zgłaszania naruszeń ochrony danych osobowych. European Data Protection Board (2021) – Przykłady naruszeń, ocena ryzyka i obowiązki administratora
Artificial Intelligence Act – wspólne przepisy dotyczące sztucznej inteligencji. Parlament Europejski i Rada Unii Europejskiej (2024) – Ramowe regulacje UE dla systemów AI, poziomy ryzyka i obowiązki
