RODO a wdrożenie modelu językowego (LLM): co ustalić, zanim dane trafią do modelu

Autor: Opublikowano: Aktualizacja:

RODO nie zakazuje modeli językowych, ale nakłada obowiązki. Przed startem ustal, jak je spełnić. Siedem decyzji: od podstawy prawnej po prawa osób do danych.

Pytanie, które pada najczęściej, brzmi „czy RODO pozwala nam wdrożyć AI”. Jest źle postawione, bo sugeruje, że gdzieś istnieje przepis odnoszący się do modeli językowych. Nie istnieje. RODO dotyczy przetwarzania danych osobowych i obowiązuje tak samo w arkuszu kalkulacyjnym, w systemie CRM i w integracji z modelem. To, co zmienia model językowy, to nie zbiór przepisów, tylko liczba miejsc, w których dane mogą wypłynąć poza zakres zaplanowany przez kogokolwiek. Model językowy (LLM, ang. large language model) to silnik takich narzędzi jak ChatGPT, Claude czy Copilot: program, który czyta tekst i pisze odpowiedź.

Poniżej siedem rzeczy, które warto rozstrzygnąć przed budową, bo każda z nich jest po wdrożeniu kosztowna do zmiany. To opis strony technicznej i organizacyjnej, a nie porada prawna — ocena prawna należy do Twojego prawnika albo inspektora ochrony danych.

1. Ustal, czy w ogóle przetwarzasz dane osobowe

Brzmi trywialnie, a rozstrzyga o zakresie całego projektu — i bardzo często odpowiedź brzmi „nie”. Model klasyfikujący zgłoszenia serwisowe po treści usterki, model przewidujący awarie maszyn, asystent przeszukujący dokumentację techniczną: żaden z nich nie musi zobaczyć ani jednej danej osobowej, o ile zadbano o to na wejściu.

Warto sprawdzić to na konkretach, nie na deklaracji. Weź dziesięć rzeczywistych zapytań, które system miałby obsłużyć, i przeczytaj je linijka po linijce. Zwykle okazuje się jedno z dwojga: albo danych osobowych naprawdę nie ma i projekt jest znacznie prostszy, niż zakładano, albo są w miejscach, o których nikt nie pamiętał — w stopce maila, w nazwie pliku, w polu z uwagami.

2. Rozstrzygnij podstawę prawną, zanim cokolwiek wyślesz

Podstawę prawną ustala się przed przetwarzaniem, nie po nim, a ustalona po fakcie nie naprawia niczego wstecz. Jest to jeden z częstszych błędów przy pilotażach: dane trafiają do narzędzia na próbę, a pytanie o podstawę pojawia się dopiero wtedy, gdy pilotaż ma przejść do codziennej pracy.

Zgoda bywa odruchowym wyborem i zwykle nie jest najlepszym. Jest odwoływalna w każdej chwili, a w relacji pracodawca–pracownik trudno wykazać jej dobrowolność. W procesach biznesowych częściej właściwe okazują się wykonanie umowy albo prawnie uzasadniony interes. Przy pierwszej z tych podstaw warto pamiętać o warunku, który bywa pomijany: przetwarzanie musi być niezbędne do wykonania umowy zawartej z samą osobą, której dane dotyczą — a w procesach B2B osoba ta bywa kimś zupełnie innym niż Twój kontrahent. Druga wymaga udokumentowanego testu równowagi, który trzeba wykonać, a nie założyć.

Osobną sprawą są dane szczególnych kategorii — o zdrowiu, przekonaniach czy przynależności związkowej. Jeżeli mogą pojawić się w tym, co trafia do modelu, choćby przypadkiem w opisie zgłoszenia, sama podstawa z artykułu 6 nie wystarczy: potrzebna jest wtedy dodatkowo przesłanka z artykułu 9, a ich katalog jest wyraźnie węższy. Warto sprawdzić to na tych samych dziesięciu zapytaniach co w punkcie pierwszym.

Istotne jest też to, że dodanie modelu do procesu, w którym dane już przetwarzasz, nie jest automatycznie objęte dotychczasową podstawą. Jeżeli zmienia się cel albo zakres przetwarzania, zmiana wymaga osobnej oceny.

3. Wyślij mniej

To najskuteczniejsze zabezpieczenie w całym projekcie i jednocześnie najtańsze: dane, których nie wysłano, nie wymagają po stronie dostawcy żadnych gwarancji umownych, żadnego regionu przetwarzania ani żadnej procedury usuwania.

W praktyce oznacza to program pośredniczący między Twoim systemem a modelem, który decyduje, co opuszcza Twój system: które pola są naprawdę potrzebne, co da się pominąć, a co zastąpić identyfikatorem. Model rozstrzygający, czy reklamacja jest zasadna, nie potrzebuje nazwiska klienta — potrzebuje treści reklamacji i historii zamówienia.

Uwaga na pojęcia: zastąpienie nazwiska identyfikatorem to pseudonimizacja, a dane spseudonimizowane nadal są danymi osobowymi. Jest to bardzo dobra praktyka, ale nie wyprowadza projektu spod RODO — robi to dopiero rzeczywista anonimizacja, czyli taka, po której powiązania z osobą nie da się odtworzyć rozsądnym nakładem środków.

4. Uporządkuj role: kto jest administratorem, a kto przetwarza

W typowym wdrożeniu występują trzy podmioty i trzy różne role. Administratorem jesteś Ty, bo to Twoje dane i Twoje cele przetwarzania. Wykonawca budujący system działa jako podmiot przetwarzający, czyli przetwarza dane na Twoje udokumentowane polecenie, a nie do własnych celów.

Rola dostawcy modelu nie jest natomiast przesądzona z góry i nie rozstrzyga jej sama umowa. W RODO rolę wyznacza to, kto dla danej operacji decyduje o celach i sposobach przetwarzania — umowa powinna to odzwierciedlać, a nie ustanawiać. W praktyce wygląda to tak. W zakresie zapytań wykonywanych na Twoje polecenie dostawca działa jako podmiot przetwarzający. Jeżeli angażuje go wykonawca, jest dalszym podmiotem przetwarzającym i potrzebna jest Twoja zgoda na podpowierzenie. Jeżeli umowę zawierasz z nim sam, jest bezpośrednio Twoim podmiotem przetwarzającym. W zakresie, w jakim wykorzystuje te same dane do własnych celów — co bywa regułą w wariantach konsumenckich — jest w tej części odrębnym administratorem.

Te dwie role potrafią występować jednocześnie: ta sama usługa bywa podmiotem przetwarzającym dla jednej operacji i administratorem dla drugiej. Dlatego rolę ustala się osobno dla każdej operacji, a nie raz dla całego dostawcy.

Konsekwencje są praktyczne, nie formalne. To administrator odpowiada za podstawę prawną, za obowiązek informacyjny wobec osób i za rejestr czynności przetwarzania — również wtedy, gdy zawiedzie podmiot, któremu powierzył dane. Dlatego wybór dostawcy modelu nigdy nie jest wyłącznie decyzją techniczną.

Praktyczny wniosek dla harmonogramu, z jednym zastrzeżeniem. Umowa powierzenia jest wymagana wtedy, gdy ktoś przetwarza dane osobowe w Twoim imieniu — jeżeli pilotaż obchodzi się bez danych osobowych, jak w punkcie pierwszym, nie jest w tym miejscu potrzebna wcale. Jeżeli jednak dane osobowe w grę wchodzą, umowa jest warunkiem startu, a nie dokumentem domykanym przy odbiorze: podpisana po uruchomieniu pilotażu znaczy tyle, że pilotaż działał bez niej.

5. Zdecyduj o regionie i o trenowaniu — świadomie, nie domyślnie

Dwie rzeczy trzeba sprawdzić w warunkach konkretnej usługi, bo w obu domyślne ustawienie bywa nie tym, którego się spodziewasz.

Pierwsza to region przetwarzania. Główni dostawcy modeli oferują dziś przetwarzanie w regionach europejskich, ale nie w każdym z nich jest to wartość domyślna, a zmiana regionu po wdrożeniu bywa równoznaczna z migracją. Jeżeli dopuszczasz transfer poza EOG, potrzebujesz podstawy tego transferu — i jest to ustalenie na start, nie na później. Sam europejski region nie zamyka jednak tematu: jeżeli do danych może sięgnąć wsparcie techniczne albo podwykonawca spoza EOG, transfer i tak występuje, mimo że dane fizycznie leżą w Europie. Pytaj więc nie tylko o to, gdzie dane są przechowywane, ale też o to, skąd są dostępne.

Druga to wykorzystanie treści do trenowania modelu. Biznesowe warianty usług dużych dostawców standardowo je wyłączają, konsumenckie bywają odwrotne — i to jest realna różnica między korzystaniem z tego samego modelu przez konto firmowe a przez prywatne konto pracownika. Który wariant obowiązuje w Twoim projekcie, powinno wynikać z warunków umownych, a nie z założenia.

6. Rozdziel RODO od AI Act, zamiast je mieszać

Oba zbiory przepisów trzeba stosować równolegle i żaden nie zastępuje drugiego, a bywają ze sobą mylone w obie strony.

Z RODO wynika ograniczenie decyzji podejmowanych wyłącznie automatycznie, o ile wywołują wobec osoby skutki prawne albo w podobny sposób istotnie na nią wpływają. Słowo „wyłącznie” jest tu decydujące: sam udział człowieka nie wystarczy, jeżeli sprowadza się do zatwierdzania podpowiedzi bez realnej możliwości jej zmiany.

Z AI Act wynika co innego. Jego obowiązki zależą od klasyfikacji systemu, a nie od wagi pojedynczej decyzji — i część z nich obowiązuje niezależnie od tego, czy w rozmowie w ogóle padają dane osobowe. Tak jest z obowiązkiem poinformowania człowieka, że rozmawia z systemem AI: dotyczy systemów przeznaczonych do bezpośredniej interakcji z osobą i nie stosuje się tam, gdzie jest to oczywiste z kontekstu, ale o danych osobowych nie mówi w ogóle. Co z tego wynika po stronie technicznej, opisaliśmy przy technicznym sprincie zgodności z AI Act.

Najkrócej: RODO pyta, czyje dane przetwarzasz i na jakiej podstawie. AI Act pyta, czym jest zbudowany przez Ciebie system i w jakim kontekście działa. Można spełnić jedno i naruszyć drugie.

7. Zaplanuj obsługę praw osób do ich danych (np. wgląd, poprawienie, usunięcie), zanim ktoś z nich skorzysta

Ten punkt najczęściej odkłada się na koniec, a jest jedynym, którego po wdrożeniu nie da się dopisać tanio. Osoba, której dane dotyczą, może zażądać dostępu, sprostowania albo usunięcia — a odpowiedź zależy od tego, gdzie jej dane osiadły.

Jeżeli model jedynie przetworzył zapytanie i niczego nie zapamiętał, usunięcie sprowadza się do Twoich systemów oraz do rejestrów działań (logów): Twoich, programu pośredniczącego i dostawcy. Jest to wykonalne, o ile z góry wiadomo, co jest w nich zapisywane i jak długo.

Jeżeli dane trafiły do indeksu wyszukiwania — jak w rozwiązaniach RAG, w których AI najpierw wyszukuje pasujące fragmenty Twoich dokumentów, a potem odpowiada na ich podstawie — usunięcie jest jak najbardziej wykonalne, ale trzeba je zaprojektować: skasowanie fragmentów i przebudowa indeksu to osobna funkcja, a nie skutek uboczny usunięcia rekordu w systemie źródłowym. Inaczej jest ze zbiorem treningowym: danych, które weszły w wagi modelu (jego wewnętrzne wartości), w praktyce nie da się z niego wyjąć — i to jest ten przypadek, do którego lepiej w ogóle nie dopuścić.

Stąd zasada projektowa, która rozwiązuje ten problem u źródła: dane osobowe zostają w Twoich systemach, a do modelu trafia możliwie wąski wycinek. Wtedy prawa osób realizuje się tam, gdzie realizowało się je zawsze, a integracja z modelem komplikuje to znacznie mniej — pod warunkiem że procedurą objęte są również logi, odpowiedzi modelu i indeksy zbudowane na ich podstawie.

Warto przy okazji rozstrzygnąć, jak długo przechowywać logi zapytań. Bywają traktowane jako dane techniczne, a potrafią zawierać kompletne treści dokumentów — łącznie z tym, co program pośredniczący właśnie starannie odfiltrował z zapytania do modelu.

Lista kontrolna przed startem

Zanim uruchomisz choćby pilotaż, przejdź przez sześć punktów. Zajmą jedno spotkanie, a oszczędzają rozmowy, które inaczej odbywają się później i w gorszych okolicznościach:

  1. Czy do modelu trafiają dane osobowe? Sprawdzone na dziesięciu rzeczywistych zapytaniach, nie założone.
  2. Jaka jest podstawa prawna i czy obejmuje również nowy cel, jeżeli cel się zmienia.
  3. Jaki dokładnie zakres pól opuszcza Twój system i co da się z niego jeszcze usunąć.
  4. Czy umowa powierzenia jest w ogóle potrzebna — a jeżeli tak, czy obejmuje układ z dostawcą modelu: zgodę na podpowierzenie, gdy angażuje go wykonawca, albo osobną umowę, gdy zawierasz ją sam.
  5. W jakim regionie działa usługa i czy warunki wykluczają trenowanie na Twoich treściach.
  6. Co trafia do rejestrów działań (logów), jak długo i w jaki sposób zrealizujesz żądanie usunięcia danych.

Jeżeli na którykolwiek z tych punktów nie ma dziś odpowiedzi na piśmie, to jest właśnie zakres pierwszego etapu — a nie powód, żeby projektu nie robić.

Gdzie to wchodzi w harmonogram projektu

W praktyce te ustalenia zapadają w fazie audytu, razem z wyborem procesu i sprawdzeniem stanu danych, ponieważ wszystkie wpływają na to samo: na zakres. Jak taki projekt wygląda etap po etapie i co powstaje na każdym z nich, opisaliśmy na stronie wdrożenie AI w firmie.

Jeżeli natomiast interesuje Cię, jak te same pytania wyglądają od strony wykonawcy — którędy dokładnie przepływają dane i o co warto zapytać każdego dostawcę, nie tylko nas — zebraliśmy to w bezpieczeństwie danych i RODO.

Podstawa prawna i źródła — stan na 9 października 2026 roku

Najczęstsze pytania

Czy RODO zakazuje korzystania z ChatGPT i innych modeli w firmie?

Nie. RODO nie zakazuje żadnej konkretnej technologii — reguluje przetwarzanie danych osobowych niezależnie od użytego narzędzia. Jeżeli do modelu nie trafiają dane osobowe, RODO nie jest w tym miejscu właściwym zbiorem przepisów. Jeżeli trafiają, obowiązują te same wymogi co przy każdym innym systemie: podstawa prawna, minimalizacja zakresu, umowa powierzenia z dostawcą działającym jako podmiot przetwarzający, obowiązek informacyjny i możliwość realizacji praw osób. Różnica polega na tym, że w wariantach konsumenckich tych narzędzi część z tych warunków bywa niespełniona domyślnie.

Czy potrzebuję zgody pracowników albo klientów, żeby użyć AI?

Zgoda jest tylko jedną z kilku podstaw prawnych i w relacjach biznesowych rzadko bywa najlepszą, ponieważ jest odwoływalna w każdej chwili, a w stosunku pracy trudno wykazać jej dobrowolność. Częściej właściwą podstawą okazuje się wykonanie umowy — pod warunkiem że przetwarzanie jest niezbędne do wykonania umowy zawartej z samą osobą, której dane dotyczą — albo prawnie uzasadniony interes administratora, który z kolei wymaga udokumentowanego testu równowagi. Wybór podstawy należy do Ciebie jako administratora oraz do Twojego prawnika lub inspektora ochrony danych — my odpowiadamy za to, żeby system dało się zbudować zgodnie z tym wyborem, a nie odwrotnie.

Czy dane zanonimizowane albo spseudonimizowane podlegają RODO?

To dwie różne rzeczy i mylenie ich jest najczęstszym błędem w tym obszarze. Dane naprawdę zanonimizowane, czyli takie, których nie da się już powiązać z osobą rozsądnym nakładem środków, nie podlegają RODO. Dane spseudonimizowane — w których nazwisko zastąpiono identyfikatorem, ale gdzieś istnieje tabela pozwalająca to odwrócić — pozostają danymi osobowymi i podlegają RODO w całości. Zamiana imion na identyfikatory przed wysłaniem do modelu jest bardzo dobrą praktyką minimalizacji, ale nie wyprowadza projektu spod RODO.

Czy przy wdrożeniu LLM trzeba wykonać ocenę skutków dla ochrony danych?

Zależy od tego, co system robi, a nie od tego, że korzysta z modelu językowego. Ocena skutków jest wymagana wtedy, gdy przetwarzanie z dużym prawdopodobieństwem może powodować wysokie ryzyko naruszenia praw i wolności osób, a Prezes UODO opublikował wykaz rodzajów operacji, przy których jej przeprowadzenie jest konieczne. Systematyczna ocena osób, zautomatyzowane decyzje o istotnych skutkach oraz przetwarzanie szczególnych kategorii danych na dużą skalę to typowe przesłanki, które potrafią wystąpić także wtedy, gdy nikt w projekcie nie myślał o nich jako o profilowaniu. Rozstrzygnięcie należy do administratora; nasza rola polega na dostarczeniu opisu przepływu danych, na którym taka ocena może się oprzeć.

Jak zrealizować prawo do usunięcia danych, które przeszły przez model?

Odpowiedź zależy od tego, gdzie te dane faktycznie osiadły, i właśnie dlatego warto zaprojektować to z góry. Jeżeli model jedynie przetworzył zapytanie i niczego z niego nie zapamiętał, usunięcie sprowadza się do Twoich systemów oraz do rejestrów działań (logów) programu pośredniczącego (między Twoim systemem a modelem) i dostawcy — a to jest wykonalne i sprawdzalne. Jeżeli dane trafiły do indeksu wyszukiwania, czyli zbioru przygotowanego do przeszukiwania — jak w rozwiązaniach RAG, w których AI najpierw wyszukuje pasujące fragmenty Twoich dokumentów, a potem odpowiada na ich podstawie — usunięcie jest wykonalne, ale wymaga zaprojektowania: skasowanie fragmentów i przebudowa indeksu to osobna funkcja, a nie skutek uboczny usunięcia rekordu w systemie źródłowym. Zbiór treningowy to natomiast przypadek odmienny — danych, które podczas trenowania weszły w wewnętrzne wartości modelu (tak zwane wagi), w praktyce nie da się z niego wyjąć. To jeden z mocniejszych argumentów za tym, żeby dane osobowe pozostawały w Twoich systemach, a do modelu trafiał możliwie wąski wycinek.