Dlaczego trenowanie modeli na danych klientów to temat ryzykowny
Na czym polega uczenie modeli na danych klientów
Model AI „uczy się” na danych, rozpoznając wzorce. Jeśli do treningu wykorzystujesz dane klientów, oznacza to, że wszystkie ich wiadomości, zgłoszenia, historyczne zakupy czy nagrania rozmów mogą zostać przetworzone, skategoryzowane, zanalizowane, a ich wzorce zapisane w strukturze modelu. Model nie „zapamiętuje” danych jak człowiek, ale pod wpływem treningu zmienia się jego wewnętrzna matematyczna struktura. Z punktu widzenia prawa istotne jest, że dane osobowe zostały wykorzystane do nowego celu.
W praktyce trenowanie modeli AI na danych klientów może wyglądać np. tak:
zestaw e-maili do biura obsługi klienta trafia do systemu, który ma się nauczyć automatycznie rozpoznawać temat zgłoszenia,
nagrania rozmów z call center służą do trenowania modelu rozpoznawania mowy lub analizy sentymentu,
historia zakupów klientów jest wykorzystywana do budowy systemu rekomendacji,
logi systemowe (np. kliknięcia w aplikacji) są używane do przewidywania rezygnacji z usługi.
W każdym z tych przykładów dane klientów są przetwarzane w sposób bardziej intensywny niż pierwotnie (np. do obsługi zamówienia czy reklamacji). Pojawia się pytanie: czy wolno na tych danych trenować model, czy tylko je przechowywać i realizować pierwotny cel (np. wystawienie faktury)?
Rodzaje ryzyka: prawne, reputacyjne i bezpieczeństwa
Trenowanie modeli na danych klientów niesie ze sobą kilka rodzajów ryzyka, które często się na siebie nakładają:
Ryzyko prawne – naruszenie RODO (np. przetwarzanie bez odpowiedniej podstawy prawnej), naruszenie umów z klientami (np. regulamin nie pozwala na takie wykorzystanie), złamanie wewnętrznych polityk bezpieczeństwa czy tajemnicy przedsiębiorstwa.
Ryzyko reputacyjne – nawet jeśli projekt mieści się w literze prawa, klienci mogą odebrać go jako nadużycie zaufania („nie wiedziałem, że moje zgłoszenia trafiają do AI”). Ujawnienie nielojalnego działania często uderza mocniej niż sama kara finansowa.
Ryzyko bezpieczeństwa informacji – dane treningowe są często kopiowane, przenoszone między zespołami, trafiają do chmury czy do dostawcy modelu. Każdy taki transfer zwiększa ryzyko wycieku, nieuprawnionego dostępu czy utraty kontroli nad tym, gdzie dane faktycznie są.
Jeśli do tego dojdzie możliwość „wydobycia” oryginalnych danych z wyszkolonego modelu (co jest technicznie trudne, ale w pewnych przypadkach realne), projekt staje się jeszcze bardziej wrażliwy z punktu widzenia ochrony danych osobowych.
Jakie dane klientów najczęściej trafiają do modeli
Źródła danych treningowych w firmach są dość powtarzalne. Najczęściej wykorzystywane są:
Dane z systemów CRM – imię, nazwisko, kontakt, historia kontaktów, notatki handlowców, statusy leadów. Modele uczą się np. przewidywać szansę wygrania sprzedaży.
Dane z obsługi klienta – treści zgłoszeń, kategorie spraw, czas odpowiedzi, wyniki ankiet satysfakcji. Na tej podstawie buduje się chatboty, systemy klasyfikujące zgłoszenia czy narzędzia do analizy nastroju klienta.
Logi systemów i aplikacji – kliknięcia w panelu, błędy, ścieżki użytkownika. Takie dane służą np. do trenowania modeli wykrywających ryzyko rezygnacji lub przewidujących obciążenie systemu.
Multimedia – nagrania z call center, obrazy (np. zdjęcia dokumentów, produktów), nagrania z wideokonsultacji. Na nich powstają modele rozpoznawania mowy, obrazu lub analizy emocji.
W każdym z tych zestawów mogą znajdować się zarówno dane osobowe (np. imię i nazwisko), jak i dane szczególnych kategorii (np. informacje o zdrowiu, przekonaniach, przynależności związkowej). Dla zgodności z prawem ogromne znaczenie ma to, jaki to rodzaj danych i po co ma być użyty.
Posiadanie danych a prawo do ich użycia do AI
Legalne pozyskanie danych klienta (np. do realizacji umowy) nie oznacza automatycznie, że można ich używać do dowolnego celu, w tym do trenowania modeli AI. Cel przetwarzania jest jednym z filarów RODO: dane mogą być przetwarzane tylko w ściśle określonych, jasno zakomunikowanych celach.
Przykładowo:
jeśli klient podał dane, aby założyć konto i kupować produkty, pierwotny cel to realizacja zamówień oraz związane z tym obowiązki księgowe,
wykorzystanie historii zakupów do zbudowania modelu rekomendacyjnego jest już innym, wtórnym celem,
uczenie modelu językowego na treści wiadomości prywatnych klientów do supportu to kolejne, jeszcze inne wykorzystanie tych samych danych.
Różnica między „legalnie mieć dane” a „legalnie użyć ich do trenowania AI” sprowadza się do tego, czy nowy cel jest zgodny z pierwotnym, czy potrafisz wykazać podstawę prawną, czy klient został o tym poinformowany i czy nowe wykorzystanie danych nie narusza jego praw i wolności.
Podstawy prawne: kiedy RODO dotyczy trenowania modeli
Kiedy dane są danymi osobowymi przy trenowaniu AI
RODO ma zastosowanie tylko do danych osobowych, czyli informacji o zidentyfikowanej lub możliwej do zidentyfikowania osobie fizycznej. Przy trenowaniu AI często pojawia się wątpliwość, czy dane po transformacji nadal są danymi osobowymi.
W kontekście AI danymi osobowymi mogą być m.in.:
treści maili i czatów, jeśli zawierają informacje o konkretnej osobie lub da się ją powiązać z kontem,
głos z nagrań audio, ponieważ może umożliwiać identyfikację osoby,
obrazy i nagrania wideo, na których widać twarz, sylwetkę, miejsce pracy, numer rejestracyjny samochodu,
identyfikatory techniczne (np. ID użytkownika, numer klienta), jeśli można je powiązać z konkretną osobą w Twoim systemie.
RODO nie ma zastosowania, jeśli dane zostały skutecznie zanonimizowane, tzn. nie da się już przypisać ich do konkretnej osoby w żaden rozsądny sposób. Samo usunięcie imienia czy zamiana ID klienta na inny numer nie zawsze wystarczy – wtedy mówimy raczej o pseudonimizacji, a nie anonimizacji, i RODO nadal obowiązuje.
Administrator a podmiot przetwarzający w projektach AI
Kluczowe jest rozróżnienie, kto w projekcie AI jest administratorem, a kto podmiotem przetwarzającym (procesorem):
Administrator danych – ten, kto decyduje o celach i sposobach przetwarzania. Zwykle będzie to firma, która zbiera dane klientów i postanawia wykorzystać je do trenowania modeli.
Podmiot przetwarzający – przetwarza dane w imieniu administratora i zgodnie z jego poleceniami. Typowy przykład: dostawca chmury czy usług AI, który udostępnia infrastrukturę lub narzędzia do treningu modelu.
Decydujące jest to, kto „ciągnie za sznurki”: jeśli dostawca technologii samodzielnie decyduje, do czego wykorzysta dane (np. może je używać także do trenowania swoich modeli dla innych klientów), może stać się współadministratorem lub osobnym administratorem. To trzeba jasno uregulować w umowie i dokumentacji, bo wpływa na zakres odpowiedzialności i obowiązków informacyjnych wobec klientów.
Najważniejsze zasady RODO istotne dla trenowania modeli
RODO opiera się na kilku zasadach ogólnych, z których w kontekście trenowania modeli AI najbardziej odczuwalne są:
Zasada zgodności z prawem, rzetelności i przejrzystości – dane muszą być przetwarzane na legalnej podstawie, w uczciwy sposób, a klient powinien wiedzieć, co się z jego danymi dzieje.
Zasada ograniczenia celu – dane osobowe mogą być zbierane w konkretnych, jasno określonych celach i nie mogą być dalej przetwarzane w sposób niezgodny z tymi celami.
Zasada minimalizacji danych – przetwarzaj tylko takie dane, które są niezbędne do osiągnięcia wskazanego celu. Trening modelu „na wszelki wypadek” na pełnej bazie jest trudny do obrony.
Zasada ograniczenia przechowywania – dane muszą być przechowywane w formie umożliwiającej identyfikację osoby nie dłużej, niż jest to konieczne do celów przetwarzania. Jeśli model już się nauczył, trzeba przemyśleć, czy nadal musisz trzymać pełny zbiór treningowy.
Zasada rozliczalności – musisz być w stanie wykazać, że spełniasz wymagania RODO. To oznacza dokumentację, rejestry czynności, oceny skutków (DPIA), decyzje architektoniczne.
Każdy etap projektu AI – od wyboru danych, przez przygotowanie datasetu, po wdrożenie modelu i jego utrzymanie – powinien być oceniany przez pryzmat tych zasad.
Profilowanie i zautomatyzowane decyzje – gdzie kończy się trening, a zaczyna ocena klienta
RODO wprowadza szczególne reguły dla profilowania i zautomatyzowanego podejmowania decyzji. Profilowanie to każdy rodzaj zautomatyzowanego przetwarzania danych osobowych, którego celem jest ocena czynników dotyczących osoby – np. jej preferencji, zachowania, wiarygodności.
Sam trening modelu na danych klientów nie zawsze będzie profilowaniem. Przykład: trenowanie modelu do rozpoznawania języka w wiadomościach (polski vs angielski) może nie wiązać się z oceną osoby. Ale jeśli na podstawie historii zakupów tworzysz model przewidujący skłonność do zakupu lub ryzyko rezygnacji, wchodzisz już w profilowanie.
Szczególnie wrażliwe są sytuacje, gdy decyzje są podejmowane w pełni automatycznie (bez realnej ingerencji człowieka) i wywołują wobec klienta skutki prawne lub podobnie istotne. Przykłady:
automatyczna odmowa przyznania kredytu na podstawie oceny modelu,
zablokowanie konta z powodu wyniku modelu antyfraudowego,
odmowa przyjęcia do programu lojalnościowego na podstawie oceny ryzyka.
W takich przypadkach trzeba spełnić dodatkowe wymogi (np. zapewnić prawo do zakwestionowania decyzji, wyjaśnień, interwencji człowieka), a podstawa prawna do przetwarzania danych musi być szczególnie dobrze dobrana i udokumentowana.
Legalne podstawy przetwarzania danych do trenowania AI
Przegląd podstaw z art. 6 RODO
Aby zgodnie z prawem trenować modele AI na danych klientów, trzeba oprzeć się na co najmniej jednej z podstaw z art. 6 RODO. W skrócie są to:
Zgoda – klient wyraźnie zgodził się na określone przetwarzanie danych.
Wykonanie umowy – przetwarzanie jest niezbędne do wykonania umowy, której stroną jest klient.
Obowiązek prawny – przetwarzanie wynika z przepisów prawa (np. obowiązki księgowe).
Ochrona żywotnych interesów – np. ratowanie życia, sytuacje nadzwyczajne (w praktyce rzadko stosowane w projektach komercyjnych AI).
Zadanie realizowane w interesie publicznym lub w ramach władzy publicznej – dotyczy głównie administracji publicznej.
Uzasadniony interes administratora lub strony trzeciej – jeśli przetwarzanie jest niezbędne do celów wynikających z prawnie uzasadnionych interesów, które nie są nadrzędne wobec interesów lub podstawowych praw i wolności osoby, której dane dotyczą.
W większości biznesowych projektów AI podstawami będą: wykonanie umowy, zgoda lub uzasadniony interes. Dobrze przeprowadzona analiza, na czym chcesz oprzeć przetwarzanie, to jeden z najważniejszych elementów zgodności.
Uzasadniony interes jako fundament wielu projektów AI
Uzasadniony interes jest kuszący, bo nie wymaga zbierania dodatkowych zgód. Aby się na niego powołać, trzeba jednak wykazać tzw. test równowagi – że interes firmy jest ważny, przetwarzanie jest konieczne do jego realizacji, a prawa klientów nie są naruszone w nadmierny sposób.
Przykładowo uzasadnionym interesem może być:
optymalizacja procesów obsługi klienta (np. uczenie modelu klasyfikacji zgłoszeń),
poprawa bezpieczeństwa systemów (np. modele wykrywające nietypowe logowania),
rozwój usług i funkcjonalności w sposób oczekiwany przez klientów (np. rekomendacje produktów, pod warunkiem właściwej transparentności).
Uzasadniony interes może być „za słaby” m.in. wtedy, gdy:
chcesz wykorzystać bardzo wrażliwe dane (np. zdrowotne, światopoglądowe),
skala monitorowania klienta jest duża i szczegółowa, np. śledzenie bardzo intymnych zachowań w aplikacji,
klient nie mógł się racjonalnie spodziewać takiego wykorzystania (np. treść prywatnej korespondencji jest używana do ogólnego modelu językowego),
nie zapewniasz prostego prawa sprzeciwu.
Zgoda – kiedy naprawdę jest dobrym pomysłem
Zgoda na trenowanie modeli AI brzmi bezpiecznie: klient „sam się zgodził”. W praktyce to wymagająca podstawa. Zgoda musi być:
konkretna – nie może być ukryta w ogólnej zgodzie „na przetwarzanie danych w celach marketingowych i rozwojowych”,
dobrowolna – klient nie może być „karany” za jej brak (np. wyższą ceną lub gorszą usługą, jeśli nie jest to obiektywnie uzasadnione),
świadoma – treść zgody musi jasno mówić, do czego dane są używane, w tym że służą do trenowania modeli,
odwoływalna tak łatwo, jak została udzielona – jeśli użytkownik kliknął jeden checkbox, odwołanie nie może wymagać pisania papierowego pisma.
Zgoda sprawdza się m.in. gdy:
prowadzisz pilotaż lub eksperyment, który wykracza poza typowe oczekiwania klienta,
chcesz wykorzystać treści, które klienci uznają za szczególnie prywatne (np. notatki w aplikacji zdrowotnej) do trenowania ogólnego modelu,
trenujesz model na danych, które same w sobie nie są niezbędne do wykonania umowy ani łatwo nie mieszczą się w „uzasadnionym interesie”.
Jeśli opierasz się na zgodzie, trzeba rozwiązać dwie kwestie techniczne: co robisz z danymi już wykorzystanymi do treningu po wycofaniu zgody oraz jak odnotowujesz, kto na co się zgodził. RODO nie wymaga cofania „nauki” modelu, ale musisz umieć wykazać, że od momentu wycofania zgody nie korzystasz dalej z danych tej osoby w nowych procesach treningowych.
Wykonanie umowy – kiedy trening jest „niezbędny”
Podstawa wykonania umowy kusi prostotą, lecz kluczowe jest słowo „niezbędne”. Jeśli bez trenowania modelu nie da się świadczyć usługi w obiecanej formie, ta podstawa może być właściwa. Przykład: aplikacja do rozpoznawania mowy, która w regulaminie wyraźnie przewiduje, że jakość rozpoznawania poprawia się dzięki uczeniu się na nagraniach użytkownika.
Ryzykowne są sytuacje, gdy:
trenowanie modeli ma charakter czysto „rozwojowy” lub marketingowy, bez bezpośredniego związku z usługą,
umowa nie wspomina o takim przetwarzaniu, a ty próbujesz „podpiąć” trening do tej podstawy po fakcie,
bez AI dałoby się świadczyć usługę w porównywalny sposób – wtedy trudno mówić o rzeczywistej niezbędności.
Jeśli powołujesz się na wykonanie umowy, zapisy regulaminów i polityk muszą jasno wskazywać, że częścią usługi jest rozwój i doskonalenie modeli w oparciu o dane klienta. Klient, czytając opis funkcjonalności, powinien bez zaskoczenia zrozumieć, że usługa działa w oparciu o uczenie maszynowe.
Szczególne kategorie danych – osobny poziom ostrożności
Dane o zdrowiu, poglądach politycznych czy pochodzeniu etnicznym podlegają zaostrzonemu reżimowi. Przy trenowaniu modeli pojawiają się często „przy okazji”, np. w wiadomościach do supportu klient potrafi opisać swój stan zdrowia, problemy rodzinne czy przekonania religijne.
Jeśli Twój dataset realnie obejmuje takie informacje, potrzebujesz nie tylko podstawy z art. 6, ale także jednego z wyjątków z art. 9 RODO (np. wyraźnej zgody na przetwarzanie danych zdrowotnych). Dodatkowo dochodzą wymogi dotyczące DPIA (oceny skutków dla ochrony danych) i zwykle podwyższony reżim bezpieczeństwa.
Często rozsądniej jest technicznie odfiltrować lub zanonimizować fragmenty, które zawierają szczególne kategorie danych, niż próbować legalizować ich wykorzystanie do ogólnego trenowania.
Źródło: Pexels | Autor: Pavel Danilyuk
Legalna zmiana celu: od obsługi klienta do trenowania modeli
Ograniczenie celu a „zgodność” nowego wykorzystania
Dane klientów najczęściej są zbierane w prostych celach: realizacja zamówienia, obsługa zgłoszeń, rozliczenia. W pewnym momencie zespół AI widzi w nich złoto do trenowania modeli. Z perspektywy RODO to zmiana celu przetwarzania.
Nie każda zmiana jest automatycznie zakazana. Kluczowa jest odpowiedź na pytanie, czy nowy cel jest zgodny z pierwotnym. RODO podaje kryteria oceny, m.in.:
związek między dawnym a nowym celem,
kontekst, w którym dane zostały zebrane (jakie były rozsądne oczekiwania klienta),
charakter danych (czy są wrażliwe),
potencjalny wpływ na osoby, których dane dotyczą,
zastosowane zabezpieczenia (np. pseudonimizacja, szyfrowanie).
Jeśli klient pisał do supportu w sprawie reklamacji, a ty chcesz na tej bazie uczyć model wewnętrznej klasyfikacji zgłoszeń, to zwykle można obronić zgodność celów. Jeśli jednak zamierzasz wykorzystywać całe treści korespondencji do stworzenia uniwersalnego modelu językowego, który będzie sprzedawany innym firmom, trudno powoływać się na „zgodność” bez dodatkowej podstawy.
Kiedy potrzebna jest nowa podstawa prawna
Jeśli analiza pokaże, że nowy cel jest zbyt odległy od pierwotnego, masz kilka opcji:
oparcie nowego celu na <strongosobnej zgodzie (np. opcjonalny checkbox „zgadzam się na wykorzystanie treści mojej korespondencji do doskonalenia modeli AI”),
udowodnienie, że nowy cel można objąć uzasadnionym interesem i że przeprowadzony test równowagi to wytrzymuje,
techniczne przekształcenie danych tak, by przestały być danymi osobowymi (np. skuteczna anonimizacja tekstów czatów).
W praktyce zmiana celu jest też momentem, w którym trzeba zaktualizować rejestry czynności przetwarzania, polityki prywatności i – często – wykonać lub odświeżyć DPIA. Organ nadzorczy nierzadko pyta właśnie o te dokumenty, badając legalność trenowania modeli.
Przykładowy scenariusz zmiany celu
Wyobraźmy sobie sklep internetowy, który od lat zbiera dane o zamówieniach i prowadzi korespondencję mailową z klientami. Pierwotne cele to: realizacja zamówień, obsługa reklamacji, marketing własny na podstawie zgody.
Zespół decyduje się na wdrożenie chatbota wspomagającego support. Do treningu chce użyć historii maili:
Jeśli chatbot ma odpowiadać wyłącznie w imieniu sklepu na podobne pytania jak dotąd pracownicy, a dane są pseudonimizowane, można rozważać zgodny cel oparty na uzasadnionym interesie (optymalizacja obsługi klienta).
Jeśli jednak na tych samych mailach ma powstać model, który trafi do oferty SaaS dla innych branż, trzeba mówić o nowym, odrębnym celu i szukać nowej podstawy (zgoda, pełna anonimizacja lub inna koncepcja prawna).
Informowanie klienta: transparentność i uczciwość w projektach AI
Jak mówić o AI w klauzulach informacyjnych
Obowiązek informacyjny z art. 13 i 14 RODO dotyczy także trenowania modeli. Nie wystarczy zdanie „Twoje dane są przetwarzane w celach analitycznych”. Trzeba w zrozumiały sposób opisać kluczowe elementy:
że dane mogą być wykorzystywane do trenowania lub doskonalenia modeli AI / uczenia maszynowego,
jakiego rodzaju modele rozwijasz (np. klasyfikacja zgłoszeń, rekomendacje produktów, analiza ryzyka),
czy model będzie używany tylko przez Twoją firmę, czy również udostępniany innym podmiotom,
jakie prawa przysługują klientowi – w tym prawo sprzeciwu wobec przetwarzania w uzasadnionym interesie.
Nie chodzi o techniczne szczegóły architektury sieci neuronowych, lecz o uczciwy opis sensu przetwarzania. „Uczymy nasze algorytmy, żeby lepiej rozumieć Twoje zgłoszenia i szybciej je obsługiwać” – to komunikat, który da się zrozumieć bez dyplomu z informatyki.
Prawo sprzeciwu i mechanizmy opt-out
Jeśli korzystasz z uzasadnionego interesu, klient ma prawo wniesienia sprzeciwu wobec takiego przetwarzania. W praktyce oznacza to konieczność zaprojektowania mechanizmu „opt-out” z treningu modeli:
w panelu klienta – np. checkbox „Nie chcę, aby moje dane były używane do trenowania modeli AI”,
w polityce prywatności – jasna instrukcja, jak zgłosić sprzeciw (adres mailowy, formularz),
w systemach – oznaczanie danych osób, które wniosły sprzeciw, i filtrowanie ich z datasetów treningowych.
Techniczna implementacja opt-outu, szczególnie w środowiskach big data, bywa bardziej wymagająca niż samo trenowanie modelu. Dlatego warto zaplanować ją na etapie architektury systemu, a nie „doklejać” po pierwszej skardze klienta.
Jasna komunikacja przy profilowaniu i automatycznych decyzjach
Gdy modele służą nie tylko do wewnętrznej analityki, ale też do profilowania lub automatycznego podejmowania decyzji, zakres informacji dla klienta się rozszerza. Trzeba w przystępny sposób wyjaśnić m.in.:
że jego dane są wykorzystywane do oceny określonych cech lub zachowań (np. ryzyka rezygnacji, skłonności do zakupu, wiarygodności płatniczej),
że decyzja może być podejmowana w sposób zautomatyzowany,
jakie mogą być konsekwencje takiej decyzji (np. odrzucenie wniosku, inny poziom limitu, brak dostępu do określonej funkcji),
jakie prawa mu przysługują: prawo do wyrażenia własnego stanowiska, do zakwestionowania decyzji, do interwencji człowieka.
Krótka, ludzka informacja typu „Decyzja o przyznaniu limitu kredytowego może zostać podjęta automatycznie na podstawie danych o Twoich płatnościach i historii zakupów. Masz prawo poprosić o weryfikację tej decyzji przez człowieka oraz zgłosić swoje uwagi.” spełni swoje zadanie lepiej niż paragrafy w stylu prawniczym.
Minimalizacja, anonimizacja i pseudonimizacja w treningu modeli
Praktyczna minimalizacja danych przy budowie datasetu
Minimalizacja zaczyna się nie w polityce prywatności, lecz przy projektowaniu datasetu. Zanim wrzucisz do modelu „wszystko, co jest w bazie”, odpowiedz na kilka prostych pytań:
czy model naprawdę potrzebuje imienia i nazwiska, czy wystarczy ID użytkownika?
czy daty urodzenia są niezbędne, czy może wystarczy przedział wiekowy?
czy historia wszystkich kliknięć w aplikacji jest konieczna, czy wystarczy zagregowana informacja (np. liczba wizyt w tygodniu)?
czy musisz przechowywać surowe teksty, czy możesz przekształcić je w wektory (reprezentacje numeryczne), które są trudniejsze do powiązania z osobą?
Dobrą praktyką jest ścisła współpraca zespołu AI z działem prawnym i bezpieczeństwa już na etapie feature engineering – projektowania cech wejściowych modelu. Często drobna zmiana (np. zaokrąglenie lokalizacji do poziomu miasta zamiast dokładnych współrzędnych GPS) radykalnie zmniejsza ryzyko prywatności bez istotnej utraty jakości modelu.
Anonimizacja – kiedy dane „wypadają” z RODO
Anonimizacja to przekształcenie danych w taki sposób, że nie da się już zidentyfikować osoby ani bezpośrednio, ani pośrednio przy użyciu rozsądnie dostępnych środków. Jeśli anonimizacja się uda, RODO przestaje mieć zastosowanie.
W praktyce anonimizacja to proces, a nie jednorazowe „zamazanie imienia”. Obejmuje techniki takie jak:
agregacja danych (np. zamiana dokładnych kwot na przedziały),
generalizacja (np. wiek → grupa wiekowa, kod pocztowy → region),
losowe modyfikacje wprowadzające „szum” (tak, by nie dało się odtworzyć konkretnych zachowań).
Trudność polega na tym, że w erze big data zaskakująco wiele informacji da się „odkręcić” przez łączenie różnych źródeł. Dlatego anonimizację trzeba planować z założeniem, że potencjalny atakujący ma dostęp do innych zbiorów danych i sporo cierpliwości.
Pseudonimizacja – nadal pod RODO, ale z niższym ryzykiem
Pseudonimizacja to sytuacja, gdy dane osobowe są zastąpione identyfikatorem (np. losowym numerem), a klucz pozwalający na powiązanie z konkretną osobą jest przechowywany osobno. Dane nadal są danymi osobowymi, lecz ryzyko dla osoby jest mniejsze.
W kontekście trenowania modeli pseudonimizacja jest jednym z podstawowych narzędzi technicznych. Przykładowe zasady:
modele i środowiska treningowe pracują wyłącznie na ID technicznych, bez imion, adresów czy numerów telefonów,
Separacja środowisk i dostęp „need-to-know”
Przy pseudonimizacji kluczowe jest nie tylko „jak”, ale także „gdzie” i „kto”. Dane wykorzystywane do trenowania modeli powinny być przetwarzane w środowisku odseparowanym od systemów produkcyjnych obsługujących klientów. Dzięki temu łatwiej kontrolować, kto ma dostęp do jakich informacji.
Praktyczne zasady, które często ratują sytuację przy audycie:
oddzielne bazy – baza z danymi operacyjnymi i baza z danymi treningowymi nie powinny być „tym samym” systemem widzianym tylko inną tabelą,
kontrola dostępu – inny zestaw uprawnień dla developerów modeli, inny dla administratorów systemów CRM,
brak klucza w środowisku AI – zespół ML nie potrzebuje dostępu do tabeli mapującej ID techniczne na konkretne osoby,
monitoring użycia danych – logi pokazujące, kto i kiedy pobierał dane do treningu.
Przy projektach zewnętrznych (np. model budowany przez software house) separacja środowisk ma dodatkowy plus: pozwala precyzyjniej określić w umowie, do jakich danych wykonawca faktycznie ma dostęp.
Specjalne kategorie danych a trening modeli
Dane dotyczące zdrowia, poglądów politycznych czy seksualności to zupełnie inna liga ryzyka. RODO nazywa je „szczególnymi kategoriami danych” i znacznie ogranicza możliwość ich przetwarzania.
Jeśli w korespondencji z klientem pojawiają się takie wątki (np. w branży medycznej, ubezpieczeniowej, NGO), dataset do trenowania modeli trzeba potraktować jak materiał szczególnie wrażliwy. Przykładowo:
systemy ETL mogą automatycznie wypychać całe wątki, w których rozpoznane zostaną frazy sugerujące dane o zdrowiu lub poglądach,
jeżeli takie dane są jednak niezbędne (np. asystent medyczny), trzeba oprzeć przetwarzanie na jednej z wyjątkowych podstaw z art. 9 RODO (np. wyraźna zgoda, szczególny przepis prawa),
każdy projekt z użyciem takich danych niemal automatycznie kwalifikuje się do DPIA – oceny skutków dla ochrony danych.
W praktyce zespoły często decydują się na dwa równoległe modele: „ogólny”, trenowany na zanonimizowanych danych bez elementów wrażliwych, oraz „wysokiego zaufania”, który działa na mniejszej, ściśle chronionej próbce danych, ale z mocniejszymi zabezpieczeniami i pod ścisłą kontrolą.
Ryzyko odtwarzania danych z modelu
Nawet jeśli wejściowe dane zostały zanonimizowane lub zredukowane, pojawia się pytanie: czy model da się „odpytać” tak, by ujawnił konkretne informacje o osobach? W literaturze mówi się o membership inference (próba ustalenia, czy dane kogoś były w zbiorze treningowym) albo model inversion (odtwarzanie przybliżonych danych wejściowych).
Dzisiejsze systemy komercyjne rzadko są w stanie wprost „wypluć” czyjeś dane, ale projektując architekturę, dobrze uwzględnić scenariusze ataku:
ograniczenie ekspozycji modelu – np. API z konkretnymi funkcjami zamiast „surowego” dostępu do generatywnego modelu na danych klientów,
regularne testy bezpieczeństwa modeli (tzw. red teaming) – próby wymuszenia na modelu ujawnienia poufnych informacji,
technikę regularyzacji i inne metody ograniczające „przeuczenie” (overfitting), które zmniejszają szansę zapamiętywania pojedynczych rekordów.
Organ nadzorczy, badając incydent związany z ujawnieniem danych przez model, będzie pytał nie tylko o to, jakie dane weszły do treningu, ale również: jakie testy i zabezpieczenia przewidziano, by model nie zamienił się w „kopiuj-wklej” z bazy klientów.
Umowy, podwykonawcy i dostawcy technologii AI
Administrator, podmiot przetwarzający i współadministracja w projektach AI
Przy projektach z wykorzystaniem zewnętrznych dostawców pojawia się klasyczne pytanie: kto jest administratorem danych, a kto podmiotem przetwarzającym (procesorem)? W świecie AI dochodzi jeszcze scenariusz współadministracji, gdy obie strony współdecydują o celach i sposobach przetwarzania.
Przykładowo:
jeśli przekazujesz dostawcy dane klientów wyłącznie po to, aby w Twoim imieniu zbudował model, z którego będziesz korzystać tylko Ty – zwykle będzie to podmiot przetwarzający,
jeśli dostawca używa danych od wielu klientów, by trenować swój „wspólny” model SaaS, z którego korzystają wszyscy – rośnie ryzyko, że organ uzna go za odrębnego administratora lub nawet współadministratora,
jeśli razem z partnerem projektujecie usługę i wspólnie określacie, jakie dane i w jakim celu trafią do modelu, scenariusz współadministracji jest bardzo prawdopodobny.
Z punktu widzenia ryzyka najgorsza jest sytuacja, w której umowa mówi „procesor”, ale praktyka wskazuje na samodzielne cele po stronie dostawcy. W razie kontroli może to być ocenione jako brak przejrzystości wobec klientów.
Kluczowe klauzule w umowie powierzenia przetwarzania
Jeżeli dostawca jest podmiotem przetwarzającym, z art. 28 RODO wynika konieczność zawarcia umowy powierzenia. W projektach AI taka umowa powinna doprecyzować kilka kwestii, które w „zwykłych” systemach bywają oczywiste, a tu generują spory.
W szczególności:
zakres celu – czy dostawca może używać danych tylko do budowy indywidualnego modelu dla Twojej firmy, czy dopuszczalne jest trenowanie modeli „wspólnych” lub doskonalenie własnych algorytmów,
rodzaj danych – czy w zbiorze mogą pojawić się dane wrażliwe, nagrania audio, obrazy twarzy, dane o lokalizacji,
lokalizacja przetwarzania – konkretne regiony chmurowe, informacja o ewentualnych transferach poza EOG,
podwykonawcy – czy i w jaki sposób dostawca może angażować dalszych procesorów (np. dostawców GPU, dodatkowych usług chmurowych),
czas retencji – jak długo dane treningowe i modele zawierające wzorce z tych danych będą przechowywane,
kasowanie i „zapominanie” – procedury usuwania danych z datasetów i modeli, szczególnie w kontekście żądań osób, których dane dotyczą.
Dobrze skonstruowana umowa powierzenia do AI jest zwykle dłuższa i bardziej szczegółowa niż klasyczna klauzula „do hostingu CRM w chmurze”, bo dotyka zupełnie innych typów ryzyka: nie tylko wycieku, lecz także nieautoryzowanego trenowania.
Gdy dostawca chce „uczyć swoje modele” na danych klientów
Coraz częściej dostawcy AI proponują atrakcyjniejsze ceny lub lepsze funkcje w zamian za możliwość trenowania „globalnych” modeli na danych wszystkich klientów. Z prawnego punktu widzenia oznacza to zwykle, że dostawca nie jest już wyłącznie procesorem.
Jeśli akceptujesz taki model współpracy, trzeba zadbać o kilka elementów:
jasny opis ról – w dokumentach trzeba wprost wskazać, że dostawca staje się odrębnym administratorem danych używanych do własnego treningu,
obowiązek informacyjny – klient końcowy powinien wiedzieć, że dane mogą trafić do zewnętrznego dostawcy, który użyje ich także dla innych klientów (z podaniem jego tożsamości),
odrębna podstawa prawna – np. zgoda klienta na udział w „wspólnym modelu” albo wykazanie, że taki trening mieści się w uzasadnionym interesie obu administratorów,
mechanizm rezygnacji – osoby, które sprzeciwią się takim operacjom, muszą mieć realną możliwość „wyjścia” z datasetu (co technicznie nie zawsze jest proste).
W praktyce pojawiają się tu też kwestie etyczne i reputacyjne. Nawet jeśli podstawa prawna się znajdzie, część klientów może źle zareagować na informację, że ich dane „pomagają” w budowaniu narzędzi także dla konkurencji.
Transfery danych poza EOG przy trenowaniu modeli
Jeżeli używasz chmury lub zespołów zlokalizowanych poza Europejskim Obszarem Gospodarczym, wchodzi do gry temat transferów danych. Trenowanie modeli na danych klientów w centrum danych w USA czy Indiach nie jest „technicznie inne” niż w Europie, ale z perspektywy prawa wymaga dodatkowych zabezpieczeń.
Typowe elementy takiego projektu to:
standardowe klauzule umowne (SCC) – wzorcowe umowy przyjęte przez Komisję Europejską, które wiążą odbiorcę danymi zobowiązaniami,
ocena poziomu ochrony w państwie trzecim – analiza, czy lokalne prawo (np. służby, masowa inwigilacja) nie podważa skuteczności SCC,
dodatkowe zabezpieczenia techniczne – szyfrowanie danych w spoczynku i w transmisji, a czasem pseudonimizacja przed transferem, tak by dostawca poza EOG nie widział danych bezpośrednio identyfikujących klienta.
Przy projektach AI rozsądnym kompromisem bywa architektura, w której szczegółowe dane osobowe pozostają w EOG, a poza ten obszar wysyłane są tylko reprezentacje numeryczne lub już przetworzone cechy – pod warunkiem, że faktycznie nie da się z nich odtworzyć tożsamości osoby.
Bezpieczeństwo przetwarzania a specyfika danych treningowych
RODO (art. 32) mówi o „odpowiednich środkach technicznych i organizacyjnych”. W projektach AI trzeba ten wymóg odnieść do specyfiki danych treningowych, które często są:
rozproszone po wielu systemach (CRM, helpdesk, nagrania call center, logi aplikacji),
konsolidowane w hurtowniach danych lub data lake’ach,
przetwarzane w iteracjach – kolejne wersje datasetów, kolejne snapshoty.
Z perspektywy praktyki oznacza to m.in.:
śledzenie „rodowodu” danych (data lineage) – możliwość sprawdzenia, z jakich źródeł i w jakim celu dane trafiły do konkretnego modelu,
etykietowanie danych – oznaczanie datasetów tagami typu „zawiera dane osobowe”, „zawiera dane wrażliwe”, „po anonimizacji”, aby łatwiej stosować właściwe zasady dostępu,
zarządzanie wersjami – nie tylko kodu modelu, ale i zbiorów treningowych, co ułatwia reagowanie, gdy trzeba usunąć czyjeś dane lub ograniczyć zakres przetwarzania.
W niejednej firmie dopiero projekt AI ujawnia, że przez lata brakowało systematycznego podejścia do bezpieczeństwa danych. Trenowanie modeli staje się impulsem do uporządkowania całej architektury informacyjnej – i to bywa jeden z nielicznych projektów IT, które docelowo poprawiają zarówno „inteligencję” organizacji, jak i poziom jej zgodności z prawem.
Najczęściej zadawane pytania (FAQ)
Czy mogę legalnie trenować modele AI na danych klientów bez ich dodatkowej zgody?
Możesz, ale tylko wtedy, gdy masz inną solidną podstawę prawną i nowy cel przetwarzania da się pogodzić z pierwotnym. Przykład: jeśli klient przekazał dane do realizacji umowy, a Ty budujesz prosty model do automatyzacji obsługi tej umowy, często da się to obronić jako zgodny cel. Jeżeli jednak sięgasz po dane do celów marketingowych, profilowania czy ogólnego „ulepszania AI”, zgoda lub inna odrębna podstawa może być już konieczna.
Za każdym razem trzeba sprawdzić: czy opisaliście taki cel w polityce prywatności, czy klient realnie mógł się go spodziewać, czy macie podstawę prawną (np. uzasadniony interes) oraz czy analiza ryzyka nie pokazuje nadmiernej ingerencji w prywatność. Brak zgody nie oznacza automatycznie zakazu, ale oznacza obowiązek porządnej analizy.
Czy anonimizacja danych klientów zwalnia z obowiązków RODO przy trenowaniu AI?
Tak, ale tylko przy faktycznej, nieodwracalnej anonimizacji. To oznacza, że z takiego zestawu danych nie da się już w rozsądny sposób dojść do konkretnej osoby – nawet przy użyciu dodatkowych informacji, które posiadasz w firmie. Proste usunięcie imienia, zamiana ID na inny numer czy zamaskowanie kilku pól najczęściej prowadzi do pseudonimizacji, a RODO wtedy nadal obowiązuje.
W projektach AI pełna anonimizacja jest trudna, zwłaszcza przy treści maili, nagraniach głosu czy obrazach. Jeżeli istnieje sensowne ryzyko „odklejenia” danych z powrotem do osoby (np. po połączeniu z systemem CRM), nie możesz traktować tych danych jako anonimowych i musisz stosować wszystkie wymogi RODO.
Jaką podstawę prawną wybrać do trenowania modeli AI na danych klientów?
Najczęściej rozważane są trzy podstawy: realizacja umowy, obowiązek prawny i uzasadniony interes administratora. Realizacja umowy ma sens, gdy model jest niezbędny do wykonania usługi, za którą klient płaci (np. filtrowanie zgłoszeń, bez którego nie ogarniesz obsługi). Obowiązek prawny pojawia się rzadko – dotyczy głównie sytuacji, gdy konkretne przepisy nakazują określone przetwarzanie.
W praktyce trenowanie modeli na danych klientów zwykle opiera się na „uzasadnionym interesie”, ale wtedy trzeba:
opisać ten interes (np. automatyzacja obsługi, poprawa jakości wsparcia),
zrobić test równowagi: czy interes firmy nie przeważa nad prawami klienta,
poinformować klientów o takim przetwarzaniu i umożliwić sprzeciw, jeśli to możliwe.
Jeśli model ma służyć szerokiemu profilowaniu, analizie wrażliwych danych czy celom marketingowym, często bez zgody się nie obejdzie.
Czy dostawca chmurowego rozwiązania AI może używać danych moich klientów do trenowania własnych modeli?
Nie z automatu. Jeżeli przekazujesz dane dostawcy chmury lub narzędzia AI jako podmiotowi przetwarzającemu, powinien on działać wyłącznie na Twoje polecenie i tylko w celu opisanym w umowie powierzenia. Używanie tych danych do trenowania własnych, „globalnych” modeli wymaga jasnej zgody administratora (czyli Ciebie), a często także spełnienia dodatkowych wymogów wobec samych klientów.
Jeśli w regulaminie dostawcy jest ogólny zapis, że może wykorzystywać dane do „ulepszania usług”, trzeba sprawdzić, czy nie staje się on w pewnym zakresie współadministratorem. W takiej sytuacji zmienia się podział odpowiedzialności, zakres informacji dla klientów i sposób realizacji ich praw. Wrażliwe projekty AI warto obsługiwać wyłącznie u dostawców, którzy wprost deklarują brak użycia danych do własnego treningu lub dają możliwość wyłączenia tego mechanizmu.
Czy model AI może „wyciec” dane osobowe klientów po treningu?
Takie ryzyko istnieje, choć technicznie nie jest trywialne. Model nie przechowuje danych jak baza SQL, ale w pewnych scenariuszach da się z niego „wyciągnąć” fragmenty danych treningowych – na przykład gdy:
model był trenowany na bardzo małej, specyficznej próbce (np. pojedyncze maile z danymi wrażliwymi),
ktoś celowo projektuje zapytania, by odtworzyć treści z treningu (tzw. ataki ekstrakcji danych),
model został nadmiernie dopasowany do danych (overfitting), co sprzyja zapamiętywaniu przykładów.
Dlatego przy danych wrażliwych stosuje się ograniczenia zakresu treningu, silniejszą anonimizację/pseudonimizację, a czasem rezygnuje z używania takich danych w ogóle.
Jak poinformować klientów, że ich dane są używane do trenowania AI zgodnie z RODO?
Podstawą jest przejrzysta informacja w polityce prywatności lub klauzulach informacyjnych. Powinny się tam znaleźć: cel (np. trenowanie modeli do automatyzacji obsługi klienta), podstawa prawna (np. uzasadniony interes), kategorie danych (np. treść zgłoszeń, historia kontaktu), okres przetwarzania oraz informacja o odbiorcach (np. dostawcy chmury). Jeżeli dane trafiają poza EOG, trzeba wskazać także mechanizmy transferu (np. standardowe klauzule umowne).
Przy bardziej wrażliwych projektach dobrą praktyką jest osobny, zrozumiały komunikat – np. na stronie formularza, w regulaminie usługi lub mailu powitalnym. Użytkownik powinien bez wysiłku zrozumieć: do czego używane są jego dane, jakie ma prawa (np. sprzeciw wobec przetwarzania do celów analitycznych/AI) i jak może z nich skorzystać.
Czy trenowanie modelu na danych z supportu lub call center to zawsze przetwarzanie szczególnych kategorii danych?
Nie zawsze, ale ryzyko jest wyraźnie wyższe niż przy „suchych” logach systemowych. W treści zgłoszeń, nagraniach rozmów czy czatach użytkownicy często spontanicznie ujawniają dane o zdrowiu, poglądach, wyznaniu czy życiu seksualnym – a to już szczególne kategorie danych w rozumieniu RODO. Włączenie takich materiałów do treningu bez dodatkowych zabezpieczeń może prowadzić do poważnych naruszeń.
Przy projektach opartych na treściach z supportu warto:
zastosować filtrację i redakcję treści przed treningiem (usuwanie fraz wrażliwych),
dokładnie zmapować, jakie typy danych mogą się pojawić,
rozważyć wyłączenie szczególnych kategorii danych z treningu albo oprzeć się na wyraźnej zgodzie, jeśli to uzasadnione i wykonalne.
Bez takiej analizy traktowanie wszystkich treści klientów „jak zwykłych danych” jest ryzykowne prawnie i wizerunkowo.
Co warto zapamiętać
Trenowanie modeli AI na danych klientów to nowe, odrębne przetwarzanie – nawet jeśli dane już „legalnie” posiadasz, nie oznacza to automatycznie prawa do wykorzystania ich do uczenia modeli.
Ryzyka są wielowarstwowe: oprócz kar za naruszenie RODO dochodzi ryzyko złamania umów z klientami, utraty reputacji (poczucie nadużycia zaufania) oraz podniesione ryzyko wycieku danych przez ich kopiowanie i transfery.
Typowe źródła danych treningowych (CRM, obsługa klienta, logi systemowe, multimedia) niemal zawsze zawierają dane osobowe, a często także wrażliwe informacje – dlatego wymagają szczególnie ostrożnej analizy celu i podstawy prawnej.
Legalne wykorzystanie danych do AI wymaga zgodności celu: trzeba wykazać, że nowy cel (np. rekomendacje, analiza sentymentu, predykcja churnu) ma solidną podstawę prawną, jest jasno zakomunikowany klientowi i nie narusza jego praw.
Dane w systemach AI pozostają danymi osobowymi, jeśli bez większego wysiłku da się je powiązać z konkretną osobą (np. przez treść wiadomości, głos, wizerunek, identyfikator użytkownika); dopiero skuteczna anonimizacja wyłącza je spod RODO.
Uczenie modeli na danych klientów niemal zawsze oznacza „bardziej intensywne” przetwarzanie niż pierwotny cel (obsługa zamówienia, reklamacja, wsparcie), więc wymaga odrębnego przemyślenia podstaw prawnych, zakresu danych i zabezpieczeń.
Im więcej kopii i miejsc przetwarzania danych (zespoły, chmury, dostawcy modeli), tym większa ekspozycja na incydenty bezpieczeństwa i trudniej realnie kontrolować, gdzie dane klientów się znajdują i kto ma do nich dostęp.
Opracowano na podstawie
Rozporządzenie (UE) 2016/679 (RODO). Dziennik Urzędowy Unii Europejskiej (2016) – Podstawy prawne przetwarzania danych, cele, anonimizacja, administrator
Ustawa z dnia 10 maja 2018 r. o ochronie danych osobowych. Dziennik Ustaw Rzeczypospolitej Polskiej (2018) – Krajowe przepisy uzupełniające RODO w Polsce
Wytyczne 07/2020 w sprawie pojęć administratora i podmiotu przetwarzającego. European Data Protection Board (2020) – Rozróżnienie administratora, procesora i współadministratora
Opinia 03/2013 w sprawie ograniczenia celu przetwarzania danych. Grupa Robocza Art. 29 (2013) – Interpretacja zasady ograniczenia celu w prawie ochrony danych
Artificial Intelligence Act (AI Act) – przyjęty tekst aktu o sztucznej inteligencji. Parlament Europejski (2024) – Wymogi dla systemów AI, zarządzanie danymi, ryzyka prawne
OECD Principles on Artificial Intelligence. Organisation for Economic Co-operation and Development (2019) – Zasady odpowiedzialnego rozwoju i użycia AI, w tym zarządzanie danymi
Guidelines on the protection of personal data in AI systems. Council of Europe (2021) – Wytyczne Rady Europy dot. ochrony danych w systemach AI
Data Protection and Privacy in the Age of Artificial Intelligence. European Union Agency for Fundamental Rights (2021) – Analiza ryzyk prawnych i etycznych AI wobec praw podstawowych
NIST AI Risk Management Framework. National Institute of Standards and Technology (2023) – Zarządzanie ryzykiem AI, w tym ryzykiem bezpieczeństwa danych
ISO/IEC 23894:2023 Information technology — Artificial intelligence — Risk management. International Organization for Standardization (2023) – Norma zarządzania ryzykiem w projektach AI
