
RODO a AI — dane osobowe w promptach, DPIA i umowy z dostawcami LLM (praktycznie)
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
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
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.Opisz przetwarzanie — jakie dane, w jakim celu, kto ma dostęp, jak długo są przechowywane (włącznie z retencją u dostawcy modelu).
- 2.Oceń konieczność i proporcjonalność — czy da się osiągnąć cel mniejszą ilością danych albo mniej inwazyjnym narzędziem.
- 3.Zidentyfikuj ryzyka dla osób — błędna decyzja AI, wyciek, dyskryminujący błąd modelu, brak możliwości odwołania się.
- 4.Zaplanuj środki minimalizujące — anonimizacja przed promptem, ograniczenie retencji, próg ludzkiej weryfikacji, DPA z dostawcą.
- 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
- 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:
| Dostawca | DPA | Rezydencja danych w UE | Uwaga praktyczna |
|---|---|---|---|
| OpenAI | Do podpisania przez panel konta, nie jest domyślna | Dostępna na wyższych planach, wymaga jawnej konfiguracji | Zero Data Retention dla wybranych endpointów API łagodzi ryzyko retencji |
| Anthropic | Wbudowane w Commercial Terms of Service — akceptujesz je razem z warunkami | Brak natywnego regionu UE dla większości warstw — przetwarzanie API odbywa się w USA | Transfer danych do USA wymaga własnej oceny (SCC) w Twoim rejestrze czynności |
| Google (Vertex AI / Gemini Enterprise) | Cloud Data Processing Addendum jako standardowa umowa | Konfigurowalna rezydencja danych w wybranym regionie UE | Pł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
- 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.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.Ustal administratora i podstawę prawną dla każdego wdrożenia dotykającego danych osobowych — zanim, nie po uruchomieniu.
- 3.Przejdź listę pytań UODO właściwą dla Twojej kategorii jako pierwszy przegląd.
- 4.Zrób DPIA, jeśli spełniasz dwa lub więcej kryteriów EDPB — użyj nowego szablonu jako punktu wyjścia.
- 5.Podpisz DPA z dostawcą modelu i sprawdź opcję rezydencji danych w UE, jeśli dostępna.
- 6.Wdróż pseudonimizację przed promptem wszędzie, gdzie cel biznesowy na to pozwala.
- 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.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:
/// RELATED_SERVICES
Potrzebujesz wdrożenia tych koncepcji? Zobacz usługi powiązane z tym tematem.
/// ŹRÓDŁA
- 01GDPR-info.eu – Art. 22 GDPR: Automated individual decision-making, including profiling
- 02EDPB – Guidelines on Data Protection Impact Assessment (DPIA) and high-risk processing
- 03UODO – Zanim wdrożysz narzędzie AI, sprawdź czy jest ono zgodne z zasadami RODO (06.08.2026)
- 04OpenAI – Introducing data residency in Europe
- 05Anthropic Privacy Center – How do I view and sign your Data Processing Addendum (DPA)?
- 06Google Cloud – Cloud Data Processing Addendum
/// RELATED_RECORDS
Shadow AI — pracownicy używają AI bez Twojej wiedzy i to jest Twój problem
68% pracowników używa niezatwierdzonych narzędzi AI bez wiedzy działu IT. Wklejają umowy, dane klientów, kod źródłowy i strategie do publicznych chatbotów — a firma o tym nie wie. Shadow AI to nie problem technologiczny, to problem zarządzania. Wyjaśniam jak wykryć co używa Twój zespół, jak napisać politykę AI, która faktycznie działa, i dlaczego zakaz jest najgorszym możliwym rozwiązaniem.
AI Act w praktyce — co Twoja firma musi zrobić w 2026 (bez paniki i prawniczego bełkotu)
AI Act brzmi groźnie, ale 90% automatyzacji w MŚP to „minimalne ryzyko” bez dodatkowych obowiązków. Wyjaśniam cztery poziomy ryzyka, różnicę między dostawcą a podmiotem stosującym, co obowiązuje JUŻ teraz (AI literacy, transparentność chatbotów), kiedy wpadasz w „wysokie ryzyko” i jak wygląda realna checklista zgodności. Z aktualnym kalendarzem po pakiecie Digital Omnibus z maja 2026.
Bezpieczeństwo danych przy wdrożeniu AI — jak nie oddać tajemnic firmy?
Darmowy ChatGPT w przeglądarce to nie sejf — to ryzyko. Dowiedz się, czym różni się Web UI od API Enterprise i on-premise, jak działa masking PII i dlaczego profesjonalna architektura AI jest zgodna z RODO bez żadnych kompromisów.
Signal received?
Przerwij
Ciszę
Zainicjuj protokół. Nawiąż połączenie. Zbudujmy coś głośnego.
