RODO a AI — dane osobowe w promptach, DPIA i umowy z dostawcami LLM (praktycznie)
POWRÓT_DO_BLOGA
AI & Bezpieczeństwo 15 min

RODO a AI — dane osobowe w promptach, DPIA i umowy z dostawcami LLM (praktycznie)

Paweł Wiszniewski
Paweł Wiszniewski
Specjalista SEO & GEO · AI Engineer

Konsultant wkleja do ChatGPT treść maila od klienta, żeby dostać szkic odpowiedzi. HR-owiec wrzuca CV kandydata do narzędzia AI, żeby streściło doświadczenie. Sprzedawca każe chatbotowi ocenić, czy lead jest „gorący", na podstawie notatek z rozmowy. W żadnym z tych przypadków nikt nie pomyślał „przetwarzam dane osobowe" — a każdy z nich właśnie to zrobił, w rozumieniu RODO, z całym bagażem obowiązków, jakie to za sobą niesie. Sześć tygodni przed publikacją tego wpisu, 6 sierpnia 2026, prezes UODO opublikował pierwsze oficjalne listy pytań wstępnych do sprawdzania zgodności narzędzi AI z RODO — sygnał, że polski regulator przestał teoretyzować i zaczął dawać firmom konkretne narzędzia do samooceny. To dobry moment, żeby zrobić to samo we własnej firmie, zanim zrobi to za Ciebie kontrola.

Wkleiłeś dane klienta do ChatGPT, żeby przyspieszyć odpowiedź na maila? To już przetwarzanie danych osobowych w rozumieniu RODO — z całym bagażem obowiązków, o których większość zespołów nie ma pojęcia. Sześć tygodni temu UODO opublikowało pierwsze oficjalne listy pytań do sprawdzania zgodności narzędzi AI z RODO — dowód, że regulator już na to patrzy, nie tylko teoretyzuje. Kiedy prompt wymaga DPIA, jak wypada test „znaczącego udziału człowieka” z art. 22 przy chatbocie oceniającym leada, i czym różnią się umowy DPA OpenAI, Anthropic i Google Cloud — praktyczny przewodnik bez prawniczego bełkotu.

Ten wpis otwiera trójkąt zgodności, który domykam w kolejnych tekstach: bezpieczeństwo techniczne danych odpowiada na pytanie „czy dane wyciekną", AI Act odpowiada na pytanie „czy system AI jest dozwolony i oznaczony", a RODO — temat tego wpisu — odpowiada na pytanie „czy w ogóle wolno Ci przetwarzać te dane w ten sposób". Trzy różne pytania, trzy różne odpowiedzialności, jeden i ten sam wdrożony chatbot.

Trójkąt zgodności — dlaczego RODO to osobna gra

/// TRÓJKĄT ZGODNOŚCI — TRZY RÓŻNE PYTANIA

Spełnienie jednego warunku nie zwalnia z pozostałych dwóch

01
BEZPIECZEŃSTWO TECHNICZNE
„Czy dane wyciekną?” — szyfrowanie, dostęp, czy dostawca trenuje na Twoich danych. To inżynieria, nie prawo
02
AI ACT
„Czy system AI jest dozwolony i oznaczony?” — klasyfikacja ryzyka, obowiązki dokumentacyjne, oznaczenie treści AI
03
RODO
„Czy w ogóle wolno Ci przetwarzać te dane w ten sposób?” — podstawa prawna, DPIA, umowa z dostawcą. Niezależne od tego, jak bezpieczny jest system

Firmy wdrażające AI najczęściej mylą te trzy warstwy albo zajmują się tylko jedną. Bezpieczeństwo techniczne pyta, czy dane są zaszyfrowane i czy dostawca ich nie wykorzysta do treningu — to inżynieria. AI Act pyta, czy system jest odpowiednio sklasyfikowany, oznaczony i udokumentowany — to zgodność z regulacją produktu. RODO pyta o coś bardziej fundamentalnego: czy w ogóle masz podstawę prawną, żeby te konkretne dane osobowe przetwarzać w ten konkretny sposób — niezależnie od tego, jak bezpieczny jest system i czy AI Act go dopuszcza. Można mieć system w pełni bezpieczny technicznie i zgodny z AI Act, a mimo to łamać RODO, bo nikt nie sprawdził podstawy prawnej albo nie przeprowadził wymaganej oceny skutków.

Kiedy prompt staje się przetwarzaniem danych osobowych

Odpowiedź jest prostsza, niż większość zespołów chce usłyszeć: jeśli w prompcie, załączniku albo kontekście rozmowy z modelem AI znajduje się jakakolwiek informacja pozwalająca zidentyfikować konkretną osobę — imię i nazwisko, adres e-mail, numer telefonu, treść wiadomości od klienta, dane w CV — to już jest przetwarzanie danych osobowych w rozumieniu RODO, dokładnie w momencie wysłania zapytania do modelu. Nie ma znaczenia, że nikt „nie zapisuje" tych danych świadomie — samo przesłanie ich do systemu (a tym bardziej ich przechowanie przez dostawcę do celów logowania czy poprawy usługi) jest operacją przetwarzania.

Z tego wynikają dwa pytania, które trzeba sobie zadać przed jakimkolwiek wdrożeniem: kto jest administratorem, a kto podmiotem przetwarzającym (zwykle Twoja firma jest administratorem, a dostawca modelu — OpenAI, Anthropic, Google — podmiotem przetwarzającym działającym na Twoje zlecenie, co wymaga umowy powierzenia), oraz jaka jest podstawa prawna tego konkretnego przetwarzania (zgoda, umowa z klientem, uzasadniony interes — każda ma inne wymogi i inne ryzyka). Firma, która nie potrafi odpowiedzieć na oba pytania dla każdego wdrożenia AI dotykającego danych osobowych, nie jest gotowa na kontrolę.

DPIA dla wdrożenia AI — kiedy jest obowiązkowa i jak ją zrobić

Ocena skutków dla ochrony danych (DPIA) jest wymagana, gdy przetwarzanie może powodować wysokie ryzyko dla praw i wolności osób — a wytyczne EDPB podają dziewięć kryteriów, z których spełnienie dwóch lub więcej automatycznie uruchamia obowiązek: ocenianie lub scoring, zautomatyzowane podejmowanie decyzji z istotnym skutkiem, systematyczne monitorowanie, dane wrażliwe, przetwarzanie na dużą skalę, łączenie zbiorów danych, dane osób w trudnej sytuacji (np. dzieci, pacjenci), innowacyjne wykorzystanie technologii oraz blokowanie dostępu do usługi. Systematyczne, szeroko zakrojone profilowanie z istotnym skutkiem prawnym wyzwala obowiązek DPIA samo w sobie, bez potrzeby spełniania drugiego kryterium. Większość wdrożeń chatbotów obsługi klienta albo scoringu leadów spełnia co najmniej dwa z tych kryteriów naraz — ocenianie plus przetwarzanie na skalę całej bazy klientów — więc DPIA jest regułą, nie wyjątkiem.

/// 9 KRYTERIÓW EDPB — DWA LUB WIĘCEJ = DPIA OBOWIĄZKOWA

Systematyczne, szerokie profilowanie z istotnym skutkiem wyzwala obowiązek samodzielnie

01Ocenianie lub scoring
02Zautomatyzowane decyzje z istotnym skutkiem
03Systematyczne monitorowanie
04Dane wrażliwe (szczególna kategoria)
05Przetwarzanie na dużą skalę
06Łączenie zbiorów danych
07Dane osób w trudnej sytuacji
08Innowacyjne wykorzystanie technologii
09Blokowanie dostępu do usługi

EDPB przyjął w 2026 roku pierwszy ujednolicony szablon DPIA wraz z objaśnieniem — sygnał, jak regulatorzy oczekują, że ocena będzie ustrukturyzowana i udokumentowana. Praktyczny proces dla wdrożenia AI:

  1. 1.Opisz przetwarzanie — jakie dane, w jakim celu, kto ma dostęp, jak długo są przechowywane (włącznie z retencją u dostawcy modelu).
  2. 2.Oceń konieczność i proporcjonalność — czy da się osiągnąć cel mniejszą ilością danych albo mniej inwazyjnym narzędziem.
  3. 3.Zidentyfikuj ryzyka dla osób — błędna decyzja AI, wyciek, dyskryminujący błąd modelu, brak możliwości odwołania się.
  4. 4.Zaplanuj środki minimalizujące — anonimizacja przed promptem, ograniczenie retencji, próg ludzkiej weryfikacji, DPA z dostawcą.
  5. 5.Skonsultuj z IOD (inspektorem ochrony danych), jeśli masz obowiązek go powołać, zanim uruchomisz system produkcyjnie.

Jeśli system AI jest jednocześnie systemem wysokiego ryzyka w rozumieniu AI Act, DPIA nie zastępuje oceny skutków dla praw podstawowych (FRIA) — obydwa dokumenty muszą się ze sobą spinać, co rozwijam we wpisie o AI Act.

Art. 22 w praktyce — chatbot, scoring i test „znaczącego udziału człowieka"

Art. 22 RODO zakazuje decyzji opartych wyłącznie na zautomatyzowanym przetwarzaniu, które wywołują skutki prawne lub w podobny sposób istotnie wpływają na osobę — pożyczki, ubezpieczenia, rekrutacja, ocena zdolności kredytowej to klasyczne przykłady, ale dokładnie ten sam mechanizm dotyczy chatbota, który automatycznie odrzuca reklamację, albo systemu, który scoruje leada i automatycznie usuwa go z lejka sprzedażowego bez udziału człowieka.

Kluczowe słowo to „wyłącznie" — i tu leży pułapka, w którą wpada większość firm. Dodanie formalnego kroku „przegląd przez człowieka" nie wystarczy, jeśli ten przegląd jest fikcją. EDPB w opinii z 2024 roku o modelach AI doprecyzował, czego wymaga rzeczywisty udział człowieka:

/// ART. 22 — TEST „ZNACZĄCEGO UDZIAŁU CZŁOWIEKA”

Brak choćby jednego elementu = decyzja nadal liczy się jako w pełni zautomatyzowana

01
REALNA WŁADZA
Osoba przeglądająca decyzję może ją zmienić lub odrzucić — to nie jedno kliknięcie „zatwierdź”
02
DOSTĘP DO DANYCH
Widzi wszystkie dane, na podstawie których model podjął decyzję, nie tylko sam wynik
03
ZROZUMIENIE LOGIKI
Rozumie kryteria stojące za decyzją modelu na tyle, żeby ją realnie ocenić
04
DODATKOWE INFORMACJE
Może uwzględnić informacje, których model nie miał albo nie przetworzył
  • Osoba przeglądająca decyzję ma realną władzę, by ją zmienić lub odrzucić — nie jest to jednym kliknięciem „zatwierdź".
  • Ma dostęp do wszystkich danych, na podstawie których model podjął decyzję, nie tylko do samego wyniku.
  • Rozumie logikę i kryteria stojące za decyzją modelu na tyle, żeby ją realnie ocenić.
  • Może uwzględnić dodatkowe informacje, których model nie miał albo nie przetworzył.

Zwykłe „przybicie pieczątki" bez tych czterech elementów nie wyłącza przetwarzania spod art. 22 — a to oznacza, że osoba, której dotyczy decyzja, ma prawo do interwencji człowieka, wyrażenia swojego stanowiska i zakwestionowania decyzji. Projektując chatbota albo system scoringowy, zaplanuj ten mechanizm od razu, nie jako łatkę po skardze klienta.

DPA i data residency — czym różnią się OpenAI, Anthropic i Google

Podpisanie umowy powierzenia przetwarzania danych (DPA) z dostawcą modelu jest warunkiem koniecznym legalnego korzystania z AI przy danych osobowych — bez niej dostawca przetwarza dane bez podstawy prawnej po Twojej stronie, niezależnie od tego, jak dobre ma zabezpieczenia. Trzy główni dostawcy różnią się jednak defaultami, a różnice mają znaczenie praktyczne:

DostawcaDPARezydencja danych w UEUwaga praktyczna
OpenAIDo podpisania przez panel konta, nie jest domyślnaDostępna na wyższych planach, wymaga jawnej konfiguracjiZero Data Retention dla wybranych endpointów API łagodzi ryzyko retencji
AnthropicWbudowane w Commercial Terms of Service — akceptujesz je razem z warunkamiBrak natywnego regionu UE dla większości warstw — przetwarzanie API odbywa się w USATransfer danych do USA wymaga własnej oceny (SCC) w Twoim rejestrze czynności
Google (Vertex AI / Gemini Enterprise)Cloud Data Processing Addendum jako standardowa umowaKonfigurowalna rezydencja danych w wybranym regionie UEPłatne API nie trenuje na Twoich danych domyślnie — sprawdź to jawnie w warunkach dla konkretnego produktu

Żadna z tych umów nie zwalnia Cię z odpowiedzialności administratora — DPA reguluje relację z podmiotem przetwarzającym, ale to Ty odpowiadasz przed regulatorem za to, czy w ogóle miałeś podstawę prawną, żeby te dane tam wysłać. Sprawdź DPA dostawcy przed podpisaniem umowy wdrożeniowej z klientem, nie po.

Anonimizacja i pseudonimizacja przed promptem — najtańsze zabezpieczenie, jakie masz

Najskuteczniejszy sposób ograniczenia ryzyka RODO w AI nie wymaga żadnej umowy ani zgody — polega na tym, żeby dane osobowe w ogóle nie trafiały do modelu w rozpoznawalnej formie. Warstwa pre-processingu przed wysłaniem promptu:

/// POZIOMY ANONIMIZACJI — OD RYZYKOWNEGO DO BEZPIECZNEGO

Najtańsze zabezpieczenie: dane, które nigdy nie trafiają do modelu w rozpoznawalnej formie

01
NIGDY WPROST
PESEL, numer dowodu, dane karty, dane szczególnej kategorii — bez odrębnej, udokumentowanej podstawy prawnej
02
PSEUDONIMIZUJ PRZED PROMPTEM
„Jan Kowalski, jan.kowalski@firma.pl” → token „Klient_A482”; prawdziwe dane podstawiasz dopiero po odpowiedzi modelu
03
AGREGUJ, GDZIE MOŻNA
Pytanie o trend w skargach nie wymaga nazwisk — wymaga treści skarg bez identyfikatorów
04
MODEL SELF-HOSTED
Gdy anonimizacja niemożliwa, a AI musi znać tożsamość klienta — jedyne w pełni bezpieczne wyjście
  • Nigdy nie wysyłaj wprost: PESEL, numer dowodu, dane karty płatniczej, dane szczególnej kategorii (zdrowie, wyznanie, orientacja) bez odrębnej, udokumentowanej podstawy prawnej.
  • Pseudonimizuj przed promptem, gdy to możliwe: zamień „Jan Kowalski, jan.kowalski@firma.pl" na token „Klient_A482" przed wysłaniem do modelu, a podstawiaj prawdziwe dane dopiero po stronie Twojej aplikacji, na podstawie odpowiedzi. Wymaga to prostej warstwy kodu (regex albo lekki model NER wykrywający dane osobowe), ale radykalnie zmniejsza ekspozycję.
  • Agreguj tam, gdzie cel na to pozwala: jeśli pytasz model o trend w skargach klientów, nie potrzebujesz pojedynczych nazwisk — potrzebujesz treści skarg pozbawionych identyfikatorów.
  • Dla danych najbardziej wrażliwych — model self-hosted. Jeśli anonimizacja nie jest możliwa (np. AI musi znać tożsamość klienta, żeby wykonać zadanie), jedynym w pełni bezpiecznym wyjściem jest model uruchomiony w Twojej infrastrukturze, bez wysyłania czegokolwiek na zewnątrz — opisałem architekturę takich wdrożeń w bezpieczeństwie danych przy AI.

UODO już patrzy — co zawierają nowe listy pytań

Listy opublikowane przez UODO 6 sierpnia 2026 nie zastępują pełnej analizy ryzyka ani DPIA, ale są punktem wyjścia, którego warto użyć jako pierwszego sita: osobny zestaw pytań dla MŚP korzystających z gotowych narzędzi AI (bez własnego treningu modelu), osobny dla sektora publicznego (z uwzględnieniem zasady legalizmu i procedury administracyjnej) i osobny dla organizacji budujących lub douczających własne modele. Do 30 września 2026 UODO zbiera uwagi praktyków do tych list na dedykowany adres — sygnał, że dokument będzie aktualizowany, więc warto traktować go jako żywy standard, nie jednorazową publikację. Dla firmy wdrażającej gotowy chatbot (np. system obsługi klienta albo chatbota biznesowego) właściwy jest pierwszy zestaw — i to dobry punkt startu przed własnym DPIA, nie substytut.

Checklist wdrożeniowy dla MŚP

  1. 1.Zmapuj, gdzie dane osobowe już trafiają do AI — świadomie i nieświadomie (patrz: Shadow AI, gdzie opisuję skalę problemu narzędzi używanych bez wiedzy firmy).
  2. 2.Ustal administratora i podstawę prawną dla każdego wdrożenia dotykającego danych osobowych — zanim, nie po uruchomieniu.
  3. 3.Przejdź listę pytań UODO właściwą dla Twojej kategorii jako pierwszy przegląd.
  4. 4.Zrób DPIA, jeśli spełniasz dwa lub więcej kryteriów EDPB — użyj nowego szablonu jako punktu wyjścia.
  5. 5.Podpisz DPA z dostawcą modelu i sprawdź opcję rezydencji danych w UE, jeśli dostępna.
  6. 6.Wdróż pseudonimizację przed promptem wszędzie, gdzie cel biznesowy na to pozwala.
  7. 7.Zaprojektuj rzeczywisty ludzki nadzór dla każdej decyzji AI ze skutkiem dla klienta — z realną władzą zmiany, nie kosmetycznym przeglądem.
  8. 8.Udokumentuj wszystko — rejestr czynności przetwarzania, DPIA, DPA, procedurę weryfikacji ludzkiej. Kontrola pyta o dokumenty, nie o intencje.

---

Prowadzę wdrożenia AI zgodne z RODO od pierwszego dnia: mapowanie przepływu danych, DPIA, dobór DPA i rezydencji danych u dostawcy, architektura pseudonimizacji i self-hostingu dla danych wrażliwych. Robię to w ramach konsultingu AI. Napisz do mnie — zacznę od audytu, gdzie dane osobowe realnie trafiają dziś do narzędzi AI w Twojej firmie i jakie jest Twoje rzeczywiste ryzyko.

Warto przeczytać dalej:

/// AUTHOR
Paweł Wiszniewski – AI & Web Engineer

Paweł Wiszniewski

SEO & GEO Specialist & AI Engineer

Specjalista SEO/GEO (10 lat) i AI engineer (3 lata). Buduję widoczność w wyszukiwarkach, systemy AI i automatyzacje, które redukują koszty i zwiększają efektywność operacyjną firm.

Signal received?

Przerwij
Ciszę

Zainicjuj protokół. Nawiąż połączenie. Zbudujmy coś głośnego.

> OCZEKIWANIE_NA_SYGNAŁ...