
RODO a AI w praktyce - dane osobowe w promptach, DPIA i umowy z dostawcami modeli
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. Pięć tygodni przed publikacją tego wpisu, 5 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ął 10 marca 2026 pierwszy ujednolicony szablon DPIA (opublikowany w kwietniu, z konsultacjami do 9 czerwca 2026), a krajowe organy mają dostosować do niego swoje wzory - sygnał, jak regulatorzy oczekują, że ocena będzie ustrukturyzowana i udokumentowana. Szablon nie jest obowiązkowy, ale to najbezpieczniejszy punkt startu. 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. Od wyroku TSUE w sprawie SCHUFA (C-634/21, grudzień 2023) wiadomo też, że sam scoring może być „decyzją" w rozumieniu art. 22, jeśli w praktyce przesądza o wyniku - nawet gdy formalnie decyzję podejmuje ktoś inny, kto się na tym wyniku opiera.
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ą. Wytyczne Grupy Roboczej Art. 29 w sprawie zautomatyzowanego podejmowania decyzji i profilowania (WP251), przyjęte następnie przez EDPB, doprecyzowują, 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 | Natywne API nie ma regionu UE w żadnym planie (parametr inference_geo przyjmuje tylko global lub us); przetwarzanie w UE możliwe przez Claude na AWS Bedrock lub Google Vertex AI w regionie europejskim | Przy natywnym API transfer do USA wymaga własnej oceny (SCC) w rejestrze czynności - albo wybierz dostęp przez chmurę z regionem UE |
| 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 5 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 - plus wspólna wersja rozszerzona do pogłębionej analizy planowanego wdrożenia. Do 30 września 2026 UODO zbiera uwagi praktyków do tych list pod adresem pytania_inicjalne@uodo.gov.pl - 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.
Ta checklista naturalnie wpisuje się w szerszą politykę AI - jak ją spisać i kto powinien nią zarządzać w małej firmie, opisuję w polityce AI i ISO/IEC 42001.
---
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 (sierpień 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
- 07EDPB - Enhancing compliance and consistency: EDPB adopts DPIA template (2026)
- 08CJEU - Case C-634/21 SCHUFA Holding (Scoring), judgment of 7 December 2023
/// RELATED_RECORDS
Bezpieczeństwo agentów AI - uprawnienia, sandboxing i dziennik działań, zanim agent coś zepsuje
53% firm przyznaje, że ich agenci AI przekroczyli zakładane uprawnienia. Czego uczą incydenty z Replit, GitHub MCP i EchoLeak, czym jest zabójcze trio i zasada dwóch oraz pięć warstw ochrony: uprawnienia, sandbox, limity, akceptacja człowieka i dziennik działań.
Deepfake i oszustwa „na prezesa” - jak firmy tracą pieniądze przez AI i jak się bronić
Pracownik NASK sprawdził: 66% Polaków nie odróżni sklonowanego głosu prezesa od prawdziwego. W 2025 roku FBI po raz pierwszy w historii wydzieliło AI jako osobną kategorię oszustw - 22 364 zgłoszenia i 893 mln dolarów strat. Największy pojedynczy przypadek to 25,6 mln dolarów przelanych po jednej rozmowie wideo z deepfake'iem fałszywego CFO. To już nie science fiction z konferencji o cyberbezpieczeństwie - to realne ryzyko dla każdej firmy z działem finansów i telefonem. Pokazuję anatomię ataku, procedury, które go zatrzymują, i dlaczego samo „rozpoznawanie” fałszywki to strategia skazana na porażkę.
Obowiązkowe szkolenia z AI (art. 4 AI Act) - kogo, z czego i jak przeszkolić
Jeśli ktokolwiek w Twojej firmie używa ChatGPT do pisania maili, jesteś „podmiotem stosującym” w rozumieniu AI Act - i od 2 sierpnia 2026 krajowe organy nadzoru rynku mogą sprawdzić, czy zapewniłeś mu „wystarczający poziom kompetencji w zakresie AI”. Nie ma jednego wzorca szkolenia ani wymaganego certyfikatu - jest za to konkretna metodyka: kogo dotyczy obowiązek, jak zaprojektować program per rola (zarząd, operacje, IT), i jak udokumentować efekt, żeby przetrwał kontrolę.
Signal received?
Przerwij
Ciszę
Zainicjuj protokół. Nawiąż połączenie. Zbudujmy coś głośnego.
