Przetwarzanie danych osobowych w narzędziach AI a RODO: praktyczny przewodnik dla biznesu

Scenka z życia firmy: gdy szybki eksperyment z AI kończy się problemem z RODO

Jak niewinny prompt stał się incydentem naruszenia danych

Specjalista ds. marketingu w średniej firmie B2B chciał sprawdzić, czy popularne narzędzie AI pomoże mu lepiej segmentować klientów. Skopiował więc fragment arkusza z CRM: imiona, nazwiska, stanowiska, adresy e-mail, informację o wielkości zamówień. Wkleił to do czatu AI z poleceniem „Przeanalizuj bazę i zaproponuj 5 segmentów klientów”. Wynik był świetny. Problem – właśnie nieświadomie przekazał dane osobowe niezidentyfikowanemu dostawcy AI, poza jakimkolwiek procesem i kontrolą.

Nie było żadnej wcześniejszej oceny ryzyka, brakowało polityki korzystania z narzędzi AI, nikt nie przeszkolił pracowników, jakich danych nie wolno wkleić do takich systemów. W logach narzędzia AI te dane pozostały, mogły posłużyć do dalszego trenowania modelu, a nawet zostać przetworzone w innym kontekście.

Co dokładnie poszło nie tak

W opisanym scenariuszu nałożyło się kilka błędów organizacyjnych i prawnych:

• Brak oceny ryzyka i DPIA – wdrożenie narzędzia AI do procesu, w którym przetwarza się dane klientów, wymaga przemyślenia, jakie ryzyka się pojawiają, gdzie dane są przesyłane, kto ma do nich dostęp.
• Brak formalnej podstawy przetwarzania w tym narzędziu – dane, które dotąd były w bezpiecznym CRM, nagle trafiły do dodatkowego systemu, bez wskazania podstawy prawnej, celu i zasad retencji.
• Brak umowy powierzenia danych z dostawcą AI – firma przekazała dane osobowe podmiotowi, który stał się podmiotem przetwarzającym, ale nie zawarto z nim wymaganej umowy powierzenia.
• Brak świadomości pracownika – z perspektywy użytkownika był to tylko „test” w darmowym narzędziu, a nie pełnoprawne przetwarzanie danych osobowych.

Do tego dochodzi jeszcze zwykle brak informacji w klauzuli informacyjnej dla klientów, że ich dane mogą być przetwarzane z wykorzystaniem narzędzi AI określonego dostawcy, a także brak kontroli nad ewentualnym transferem danych poza EOG.

Konsekwencje organizacyjne i prawne

Taka sytuacja może zostać uznana za naruszenie ochrony danych osobowych. W praktyce oznacza to konieczność:

• analizy, czy incydent rodzi ryzyko naruszenia praw lub wolności osób fizycznych,
• ewentualnego zgłoszenia naruszenia do Prezesa UODO w ciągu 72 godzin,
• ewentualnego poinformowania klientów o incydencie, jeśli ryzyko jest wysokie,
• weryfikacji, czy dostawca AI umożliwia usunięcie tych danych z logów i systemów,
• przeglądu procesów wewnętrznych oraz wdrożenia nowych zasad korzystania z narzędzi AI.

Nawet jeśli finalnie organ nie nałoży kary, sam proces wyjaśniania, przygotowania dokumentacji i komunikacji z klientami jest kosztowny i obciąża reputację firmy.

Wniosek z tej historii

Narzędzia AI nie są „piaskownicą do testów”, tylko kolejnym systemem przetwarzającym dane osobowe. Jeśli te dane wprowadzają pracownicy, biznes musi traktować takie narzędzia tak samo poważnie jak CRM, system kadrowy czy platformę mailingową – z analizą ryzyka, umową powierzenia, politykami, szkoleniami i kontrolą dostępu.

Podstawy – kiedy użycie narzędzi AI w firmie wchodzi w zakres RODO

Jak rozpoznać dane osobowe w kontekście narzędzi AI

RODO definiuje dane osobowe szeroko: to każda informacja o zidentyfikowanej lub możliwej do zidentyfikowania osobie fizycznej. W praktyce oznacza to, że nie tylko imię i nazwisko są danymi osobowymi, ale także:

• adres e-mail (zwłaszcza imię.nazwisko@…),
• numer telefonu,
• identyfikatory użytkowników (ID klienta powiązane z bazą),
• informacje o stanowisku, miejscu pracy połączone z innymi danymi,
• treść korespondencji, w której da się zidentyfikować konkretne osoby.

W kontekście AI szczególnie zgubne są sytuacje, gdy ktoś zakłada, że „po usunięciu nazwisk dane są anonimowe”. Często tak nie jest. Jeśli z kontekstu można odtworzyć, o kogo chodzi (np. opis rzadkiego stanowiska w małej firmie plus szczegółowe okoliczności), nadal mamy do czynienia z danymi osobowymi w rozumieniu RODO.

Gdzie w firmie AI najczęściej styka się z danymi osobowymi

W wielu organizacjach narzędzia AI są już używane w kluczowych obszarach, czasem nieformalnie. Najczęstsze przykłady:

• HR i rekrutacja – analiza CV, tworzenie opisów stanowisk na podstawie profili pracowników, generowanie odpowiedzi dla kandydatów, podsumowania rozmów rekrutacyjnych.
• Obsługa klienta – chatboty, automatyczne odpowiedzi na maile, analiza zgłoszeń serwisowych, podsumowania rozmów telefonicznych po transkrypcji.
• Marketing i sprzedaż – segmentacja klientów, personalizacja treści ofert, tworzenie scenariuszy kampanii opartych na zachowaniach konkretnych klientów.
• Analityka biznesowa – modele predykcyjne przewidujące zachowania klientów, ryzyko odejścia, wartość życiową klienta.
• Produkcja i logistyka – niekiedy analizowane są dane operatorów, kierowców, osób odpowiedzialnych za konkretne etapy procesu.

W każdym z tych obszarów AI może przetwarzać dane, które bezpośrednio lub pośrednio identyfikują konkretne osoby. To wystarczy, aby w pełni uruchomiły się obowiązki wynikające z RODO.

Przetwarzanie danych osobowych vs praca wyłącznie na danych technicznych

Nie każde użycie AI w firmie oznacza przetwarzanie danych osobowych. Są scenariusze, gdzie narzędzie pracuje wyłącznie na:

• danych technicznych (parametry urządzeń, logi maszyn bez powiązania z osobami),
• danych w pełni zanonimizowanych (brak możliwości identyfikacji osób przy użyciu rozsądnie dostępnych środków),
• danych wyłącznie biznesowych (np. opisy produktów, treści regulaminów, dokumentacja techniczna).

Kluczowe pytanie brzmi: czy osoba fizyczna jest zidentyfikowana lub możliwa do zidentyfikowania w tym konkretnym kontekście użycia AI. Jeśli nie – RODO nie ma zastosowania. Jeżeli jednak przynajmniej w jednym z systemów, do których organizacja ma dostęp, można z powiązania danych odtworzyć tożsamość osoby, RODO zaczyna obowiązywać.

Dane „testowe” i „przykładowe” też mogą być danymi osobowymi

Częstym błędem jest przekonanie, że jeśli dane są używane tylko „do testów” lub „na próbę”, to nie obowiązują pełne wymogi RODO. Tymczasem RODO nie rozróżnia poważnych i niepoważnych procesów – jeżeli dane dotyczą osób fizycznych, przepisy stosuje się tak samo.

Przykłady problematycznych praktyk:

• używanie prawdziwych CV kandydatów jako „danych testowych” do sprawdzania nowego systemu AI HR,
• wgrywanie realnych zgłoszeń klientów do narzędzia do analizy sentymentu bez anonimizacji,
• testowanie integracji z zewnętrznym API AI na kopii bazy produkcyjnej.

Jeżeli dane testowe da się powiązać z prawdziwymi ludźmi, mamy pełnoprawne przetwarzanie danych osobowych, wymagające podstawy prawnej, zabezpieczeń, informacji i umowy z dostawcą narzędzia.

Dlaczego nazwanie kategorii danych na starcie jest krytyczne

Zanim zespół IT lub biznes wdroży narzędzie AI do jakiegokolwiek procesu, powinien jasno wskazać:

• jakie kategorie danych będą przetwarzane (np. dane podstawowe, dane finansowe, dane o zdrowiu),
• czy w grę wchodzą szczególne kategorie danych (np. dane o zdrowiu, poglądach, przynależności związkowej),
• jakie grupy osób są objęte przetwarzaniem (klienci, pracownicy, kandydaci, użytkownicy aplikacji),
• czy dane są pseudonimizowane lub anonimizowane przed przekazaniem do AI.

Takie uporządkowanie pozwala realnie ocenić ryzyko, dobrać podstawę prawną, zdecydować o potrzebie DPIA i przygotować właściwe zapisy w umowach z dostawcami narzędzi AI.

RODO w praktyce – jakie obowiązki uruchamiają się przy korzystaniu z narzędzi AI

Administrator danych, podmiot przetwarzający i współadministrator – kto jest kim

W relacji biznes – dostawca narzędzia AI najczęściej występują dwie role:

• Administrator danych – firma, która decyduje o celach i sposobach przetwarzania danych (np. sklep internetowy, który używa AI do segmentacji klientów).
• Podmiot przetwarzający – dostawca narzędzia AI, który przetwarza dane w imieniu administratora i na jego udokumentowane polecenie.

Bywa jednak, że dostawca AI ma własne cele przetwarzania (np. wykorzystuje dane klientów do trenowania swojego modelu w celach ogólnych). Wtedy relacja może trafić w obszar współadministracji albo nawet dwóch niezależnych administratorów. To ma poważne skutki: zakres odpowiedzialności, sposób wypełniania obowiązków informacyjnych, udzielanie dostępu osobom, których dane dotyczą.

Dlatego przed wyborem narzędzia warto sprawdzić w regulaminach i politykach prywatności dostawcy, jak definiuje on swoją rolę, i skonfrontować to z rzeczywistym sposobem przetwarzania danych.

Podstawy prawne przetwarzania danych w narzędziach AI

Użycie AI nie tworzy specjalnej, nowej podstawy prawnej. Wciąż trzeba zmieścić przetwarzanie w jednej z podstaw z art. 6 RODO, a dla danych szczególnych – w art. 9. W praktyce w biznesie pojawiają się głównie:

• Wykonanie umowy – np. użycie AI w procesie obsługi klienta, jeśli bez tego nie dałoby się zrealizować świadczenia w ustalonym standardzie.
• Prawnie uzasadniony interes administratora – np. analiza zachowań klientów dla poprawy jakości usług, bezpieczeństwa systemów, przeciwdziałania nadużyciom.
• Zgoda – raczej w sytuacjach fakultatywnych, gdy przetwarzanie nie jest niezbędne do świadczenia usługi (np. zaawansowana personalizacja oferty przy użyciu AI).
• Obowiązek prawny – rzadziej, np. gdy AI pomaga spełniać obowiązki sprawozdawcze lub nadzorcze wynikające z przepisów.

Podstawę prawną trzeba zdefiniować dla konkretnego celu. Jeśli AI nagle zaczyna być wykorzystywana do nowego celu (np. dane z obsługi klienta trafiają do modelu marketingowego), może to oznaczać nowy proces przetwarzania z inną podstawą prawną i innym okresem przechowywania.

Obowiązek informacyjny wobec osób, których dane przetwarza AI

Osoby, których dane są przetwarzane, muszą wiedzieć nie tylko, że ich dane są w ogóle przetwarzane, ale również:

• kto jest administratorem danych,
• jakie są cele i podstawy prawne przetwarzania,
• jakie kategorie danych są przetwarzane,
• kto jest odbiorcą danych (np. konkretny dostawca narzędzia AI lub kategorie odbiorców),
• czy dane są przekazywane poza EOG,
• jakie prawa przysługują osobom (dostęp, sprostowanie, sprzeciw, usunięcie, ograniczenie),
• jak długo dane będą przetwarzane lub według jakich kryteriów określa się ten okres.

Jeśli narzędzie AI ma istotny wpływ na osobę (np. użycie w procesie rekrutacji, profilowanie marketingowe, scoring kredytowy), zakres informacji powinien dodatkowo obejmować zasady podejmowania decyzji, znaczenie i przewidywane konsekwencje takiego przetwarzania.

Privacy by design i privacy by default przy wdrażaniu AI

Zasada privacy by design wymaga, aby ochronę danych uwzględniać już na etapie projektowania procesu z użyciem AI. W praktyce oznacza to m.in.:

• wybór narzędzia z funkcjami prywatności (wyłączenie trenowania na danych, szyfrowanie, logi ograniczone do niezbędnego minimum),
• projektowanie integracji tak, by przekazywać do AI tylko te dane, które są niezbędne do osiągnięcia celu,
• zastosowanie pseudonimizacji lub anonimizacji tam, gdzie to możliwe,
• wprowadzenie kontroli dostępu i mechanizmów monitorowania użycia AI.

Privacy by default oznacza natomiast, że domyślne ustawienia systemu i procesu są „privacy-friendly”. Przykładowo: konta pracowników domyślnie nie zapisują historii czatów dłużej niż to konieczne, trenowanie modelu na danych organizacji jest domyślnie wyłączone, a dostęp do zaawansowanych funkcji analitycznych wymaga dodatkowego uprawnienia.

Dlaczego AI komplikuje i poszerza obowiązki RODO

Nowe pola ryzyka: skala, nieprzewidywalność i „drugie życie” danych

W pewnej spółce technologicznej, po pół roku korzystania z chatu AI do obsługi klienta, dział prawny odkrył, że transkrypcje rozmów były przesyłane do chmury poza EOG i używane do trenowania globalnego modelu. Z punktu widzenia zespołów biznesowych wszystko „działało świetnie”. Z perspektywy RODO okazało się, że część procesów nigdy nie została w ogóle zarejestrowana i przeanalizowana.

AI komplikuje praktyczne stosowanie RODO z kilku powodów. Po pierwsze, procesy są rozproszone – dane wędrują przez integracje, logi, mechanizmy monitoringu jakości modelu. Po drugie, modele mają tendencję do „uczenia się” na podstawie tego, co dostają, a granica między zwykłym przetwarzaniem a dalszym użyciem do trenowania bywa niejasna. Po trzecie, łatwo o sytuację, w której jeden prompt lub jeden endpoint API powoduje, że dane wyciekają poza kontrolowany ekosystem.

W konsekwencji organizacja często nie ma pełnej odpowiedzi na proste pytania typu: „Gdzie dokładnie są moje dane?”, „Kto tak naprawdę ma do nich dostęp?” czy „Jak je usunąć z modelu?”. To właśnie te luki zamieniają się później w realne naruszenia ochrony danych albo w niewykonalne żądania osób, których dane dotyczą.

Rejestr czynności przetwarzania z modułem „AI”

W wielu firmach wdrożenie AI zaczyna się od szybkiego proof of concept, a dopiero później ktoś pyta, czy proces jest ujęty w rejestrze czynności przetwarzania. Tymczasem każde poważniejsze wykorzystanie AI, które dotyka danych osobowych, powinno zostać opisane tak samo jak inne procesy.

W rejestrze dobrze jest wydzielić dodatkowe pola dla procesów opartych na AI, np.:

• Rodzaj narzędzia AI – model generatywny, klasyfikator, system rekomendacyjny, model predykcyjny.
• Źródła danych wejściowych – system CRM, skrzynka mailowa, nagrania call center, formularze www.
• Status trenowania na danych – czy dane są wykorzystywane do trenowania lub doskonalenia modelu dostawcy, czy tylko do inferencji.
• Mechanizmy ograniczania danych – pseudonimizacja, maskowanie, filtrowanie pól przed wysłaniem do AI.
• Skutki dla osób – wpływ na decyzje, profilowanie, automatyczne rekomendacje.

Taka „warstwa AI” w rejestrze pozwala szybciej wychwycić, gdzie kumuluje się ryzyko i które procesy wymagają np. DPIA lub dodatkowych zapisów w umowach z dostawcami.

DPIA dla projektów z AI – kiedy jest obowiązkowa i jak ją ugryźć

W średniej firmie pożyczkowej nowy algorytm scoringowy oparty o AI miał skrócić czas decyzji kredytowej do kilku minut. Po pierwszych testach okazało się jednak, że niektóre grupy klientów są systematycznie oceniane gorzej. Dopiero wtedy zarząd zapytał o DPIA – analizę skutków przetwarzania dla ochrony danych. Powinno to nastąpić dużo wcześniej, zanim model dostał prawdziwe dane.

DPIA staje się obowiązkowa, gdy przetwarzanie z użyciem AI prawdopodobnie wiąże się z wysokim ryzykiem dla praw i wolności osób. W realiach biznesowych najczęściej chodzi o sytuacje, gdy:

• występuje zautomatyzowane podejmowanie decyzji wywołujące skutki prawne lub w podobny sposób istotnie wpływające na osobę (np. odrzucenie wniosku kredytowego, negatywny wynik w rekrutacji),
• dochodzi do systematycznego monitorowania pracowników lub klientów (np. analiza zachowań w aplikacji, monitoring jakości pracy z wykorzystaniem AI),
• przetwarzane są szczególne kategorie danych na dużą skalę (np. dane zdrowotne w aplikacjach medycznych, dane biometryczne),
• łączone są duże zbiory danych z różnych źródeł, tworząc rozbudowane profile osób.

DPIA dla rozwiązania AI powinna uwzględniać kilka dodatkowych wątków w porównaniu z klasycznym IT:

• Opis logiki działania modelu – na ile jest zrozumiały, jakie ma ograniczenia, jakie dane są najbardziej wpływowe.
• Ryzyko błędów i halucynacji – jak często mogą się pojawiać, jak są wychwytywane, jakie są procedury korekty.
• Ryzyko dyskryminacji – czy model może faworyzować lub dyskryminować określone grupy (płeć, wiek, lokalizacja, status ekonomiczny).
• Możliwość wyjaśnienia decyzji – czy da się w praktyce zrealizować obowiązek informowania o zasadach podejmowania decyzji (art. 22 i motywy RODO).

Jeśli DPIA wykaże wysokie ryzyko, którego nie da się zredukować do akceptowalnego poziomu, wdrożenie AI powinno być albo istotnie zmodyfikowane, albo w skrajnych przypadkach – zaniechane. To trudne decyzje, ale odwlekanie ich zwykle kończy się drożej: skargami, kontrolą i kosztownymi przeróbkami systemu.

Umowa powierzenia z dostawcą AI – jakie zapisy mają realne znaczenie

Gdy mała firma usługowa podpisała „standardową” umowę powierzenia z dostawcą AI do transkrypcji rozmów telefonicznych, nikt nie zwrócił uwagi na kilka z pozoru niewinnych zdań o „usprawnianiu usług i rozwoju produktów”. Po roku dostawca poinformował, że z modeli trenowanych na nagraniach klientów nie da się usunąć pojedynczego pliku. Pojawiło się pytanie, czy w ogóle była to klasyczna relacja powierzenia.

Umowa z dostawcą narzędzia AI nie może być tylko formalnością. Przy ustalaniu jej treści kluczowe są zwłaszcza:

• Cel i zakres przetwarzania – precyzyjne opisanie, w jakich celach dostawca może przetwarzać dane (wykluczenie „własnych” celów, jeśli chcemy pozostać przy powierzeniu).
• Zasady trenowania na danych – jednoznaczne stwierdzenie, czy dane mogą być używane do trenowania modeli, a jeśli tak, to w jakim zakresie i na jakich warunkach.
• Podprzetwarzający – lista podwykonawców, zasady ich zmiany, kraje przetwarzania i transfery poza EOG.
• Środki bezpieczeństwa – szyfrowanie w tranzycie i spoczynku, segmentacja środowisk, logowanie dostępu, testy bezpieczeństwa, certyfikacje.
• Wsparcie przy realizacji praw osób – w jaki sposób i w jakim czasie dostawca pomaga w dostępie do danych, ich usunięciu czy sprostowaniu.
• Okres przechowywania i usunięcie danych – jak długo dane są przechowywane po zakończeniu umowy, jak są kasowane z backupów, czy da się je „wytrenować” z modelu lub przynajmniej ograniczyć ich użycie.

Przy narzędziach generatywnych dochodzi jeszcze aspekt treści wygenerowanych: kto jest za nie odpowiedzialny, czy mogą zawierać dane osobowe oraz jak są przechowywane po stronie dostawcy. Tu również warto zadbać o precyzyjne klauzule, a nie tylko polegać na ogólnych regulaminach SaaS.

Kluczowe zasady RODO a codzienne korzystanie z AI w firmie

Zasada minimalizacji danych i ograniczenia celu w praktyce promptów

Podczas warsztatów w dziale HR jeden z menedżerów wrzucił do chatu AI całe CV kandydata z numerem telefonu, adresem i szczegółową historią zatrudnienia, prosząc o „analizę dopasowania do kultury organizacyjnej”. System odpowiedział błyskawicznie, ale z perspektywy RODO padło kilka pytań: czy te wszystkie dane były potrzebne? Czy cel był jasno zdefiniowany?

Zasada minimalizacji danych oznacza, że do narzędzia AI należy przekazywać tylko te dane, które są niezbędne dla konkretnego, z góry ustalonego celu. W praktyce:

• zamiast pełnych dokumentów (np. CV, umów) często wystarczy zanonimizowany fragment istotny dla analizy,
• w danych klientów można zastąpić imię, nazwisko i e-mail losowym identyfikatorem, jeśli do realizacji zadania nie jest potrzebna wiedza, kim dana osoba jest,
• przekazywanie dokumentów „hurtowo”, bo „tak szybciej”, jest sprzeczne z zasadą ograniczenia celu – każdy transfer powinien mieć uzasadnienie biznesowe i prawne.

Ograniczenie celu z kolei wymaga, aby dane użyte w jednym procesie (np. obsługa reklamacji) nie trafiały automatycznie do innych modeli (np. marketingowych), jeśli pierwotny cel i podstawa prawna na to nie pozwalają. W świecie AI, gdzie jedna integracja może „podłączyć” dane do wielu procesów, ta zasada wymaga szczególnie dokładnego mapowania przepływów.

Prawidłowość danych i zarządzanie błędami AI

W pewnym dziale windykacji chat AI został użyty do podsumowywania rozmów z dłużnikami. Po kilku tygodniach okazało się, że w części notatek system błędnie interpretował ustalenia, przypisując klientom zobowiązania, których nie podjęli. Te notatki trafiały później do innych systemów i wpływały na kolejne decyzje.

Zasada prawidłowości danych wymaga, aby wszelkie informacje o osobach były poprawne i aktualne. W środowisku AI trzeba więc wdrożyć mechanizmy, które:

• nie traktują wyniku AI jako „prawdy objawionej” – końcowa decyzja powinna należeć do człowieka, zwłaszcza przy wysokim ryzyku,
• umożliwiają szybkie skorygowanie błędnych danych i odtworzenie ścieżki, skąd dana informacja się wzięła (logi, wersjonowanie),
• zapobiegają propagowaniu błędów – np. zanim wygenerowane podsumowanie trafi do systemu produkcyjnego, przechodzi prostą walidację.

Jeżeli AI generuje treści, które trafiają do dokumentów wysyłanych klientom (maile, decyzje, oferty), kontrola jakości treści staje się de facto elementem systemu ochrony danych. Błąd w piśmie do klienta może być naruszeniem RODO, jeśli opiera się na nieprawdziwych danych osobowych.

Przejrzystość i wyjaśnialność – jak mówić klientom o AI

W dużym e-sklepie wdrożono system rekomendacji oparty na AI. Gdy jeden z klientów zażądał wyjaśnienia, dlaczego widzi określoną ofertę i czy jest profilowany, konsultant miał do dyspozycji tylko ogólny opis działania modelu przygotowany przez dostawcę. To było za mało, by spełnić oczekiwania klienta i wymogi RODO.

Przejrzystość w kontekście AI oznacza nie tylko publikację ogólnej informacji „używamy narzędzi AI”. Potrzebne są także:

• jasne wyjaśnienie, w jakich procesach AI jest używana (np. obsługa czatu, rekomendacje produktów, analiza opinii),
• informacja, czy dochodzi do profilowania lub zautomatyzowanego podejmowania decyzji, oraz jaki ma to wpływ na osobę,
• możliwość uzyskania zrozumiałego opisu logiki działania modelu na poziomie, który daje się przełożyć na język biznesowy, a nie tylko techniczny.

W praktyce dobrze sprawdza się przygotowanie krótkich, „ludzkich” opisów dla kluczowych zastosowań AI, które można wykorzystać zarówno na stronie internetowej, jak i w rozmowach z klientami czy pracownikami. To ułatwia realizację obowiązku informacyjnego i zmniejsza ryzyko nieporozumień.

Integralność, poufność i kontrola dostępu w środowisku AI

W jednej z firm marketingowych konto „eksperymentalne” w zewnętrznym narzędziu AI miało szerokie uprawnienia i brak ograniczeń co do rodzaju przetwarzanych danych. Po kilku miesięcach okazało się, że dostęp do niego mają praktycznie wszyscy stażyści, a w historii czatu znajdują się dane klientów VIP.

AI wprowadza dodatkowe punkty dostępu do danych osobowych – interfejsy webowe, API, integracje no-code. Aby zachować zasadę integralności i poufności, trzeba zadbać o:

• Role i uprawnienia – różne poziomy dostępu do narzędzia (np. konta „sandbox” bez realnych danych, konta produkcyjne tylko dla wybranych osób),
• Segmentację środowisk – oddzielenie środowisk testowych od produkcyjnych i zakaz używania realnych danych w testach, chyba że jest to absolutnie konieczne i odpowiednio zabezpieczone,
• Logowanie i monitoring – zapisywanie, kto, kiedy i jakie dane wysłał do AI, oraz okresowy przegląd logów pod kątem naruszeń polityk,
• Szyfrowanie i konfigurację bezpieczeństwa – zwłaszcza przy korzystaniu z API w aplikacjach własnych (klucze, tokeny, ograniczenia IP, rotacja kluczy).

Bez tych elementów narzędzia AI szybko stają się „czarną skrzynką”, do której każdy może wrzucić wszystko – a to prosta droga do wycieków danych i poważnych naruszeń RODO.

Jak dobrać i „oswoić” narzędzie AI: kryteria zgodności z RODO

Checklista wyboru dostawcy AI z perspektywy ochrony danych

Przy wyborze narzędzia AI decyzję często przesądza cena lub jakość wyników. W jednej z firm sprzedażowych zwyciężył dostawca z najlepszym „demo”. Dopiero później wyszło na jaw, że wszystkie dane klientów trafiają do modelu trenowanego globalnie, a serwery znajdują się poza EOG. Dostosowanie się do RODO po fakcie okazało się bardzo kosztowne.

Przy analizie dostawcy AI dobrze jest zadać kilka konkretnych pytań:

Kluczowe pytania do dostawcy – co musi paść przed wdrożeniem

Podczas spotkania z dostawcą AI zarząd skupił się na prezentacji funkcji i oszczędności czasu. Dopiero gdy inspektor ochrony danych poprosił o wyjaśnienie, gdzie fizycznie trzymane są logi i czy dane z czatu trafiają do trenowania modelu, po drugiej stronie zapadła niezręczna cisza. Sprzedaż już naciskała na „szybkie podpisanie umowy”.

Żeby uniknąć takich sytuacji, rozmowa z dostawcą powinna objąć kilka konkretnych bloków tematycznych, a odpowiedzi najlepiej zebrać w formie notatki lub krótkiej tabeli porównawczej. Przykładowe pytania:

• Model i trenowanie – czy dane z Twojej organizacji są używane do trenowania modeli ogólnych? Czy możesz to wyłączyć per klient / per środowisko? Jak wygląda proces „wycofania” danych z trenowania w razie żądania usunięcia?
• Architektura i lokalizacja danych – w jakich krajach znajdują się serwery produkcyjne, backupy i środowiska testowe? Czy dane są replikowane poza EOG, a jeśli tak, na jakiej podstawie prawnej (SCC, decyzja stwierdzająca odpowiedni poziom ochrony, inne mechanizmy)?
• Logi i metadane – jakie informacje są zapisywane w logach (identyfikatory użytkowników, fragmenty promptów, IP, dane z nagłówków)? Jak długo się je przechowuje i kto ma do nich dostęp po stronie dostawcy?
• Bezpieczeństwo techniczne – jakie standardy i certyfikacje posiada dostawca (np. ISO 27001, SOC 2)? Czy przeprowadza regularne testy penetracyjne, audyty zewnętrzne, bug bounty?
• Wsparcie dla praw osób – czy dostawca jest w stanie wyszukać dane na podstawie identyfikatora klienta i wesprzeć przy realizacji żądania dostępu, sprostowania lub usunięcia? W jakim czasie i w jakim formacie?
• Konfiguracja prywatności – jakie ustawienia możesz kontrolować jako administrator (retencja historii, wyłączenie zapisywania czatów, granularne uprawnienia dla użytkowników, poziom anonimizacji logów)?

Im bardziej szczegółowe odpowiedzi otrzymasz na starcie, tym łatwiej będzie później obronić wdrożenie przed klientami, audytorami czy organem nadzorczym. „Nie wiemy, jak dokładnie działa dostawca” brzmi słabo zarówno w polityce prywatności, jak i w toku kontroli.

Ocena dostawcy w kontekście transferów danych poza EOG

W jednej firmie technologicznej dział IT wybrał usługę AI hostowaną na serwerach w USA, argumentując, że „przecież wszyscy tak robią”. Gdy klient z Niemiec zapytał o podstawę prawną transferu danych, padło ogólne odwołanie do „bezpiecznych rozwiązań chmurowych”. To nie wystarczyło.

Przy narzędziach AI trzeba rozdzielić dwa poziomy: marketingowe hasła o „europejskiej chmurze” oraz faktyczny przepływ danych. Kilka elementów do sprawdzenia:

• Rzeczywista lokalizacja przetwarzania – nie tylko region główny, lecz także miejsce przechowywania backupów, logów technicznych oraz środowisk awaryjnych (DR – disaster recovery).
• Mechanizm transferu – jeśli dane trafiają poza EOG, dostawca powinien wskazać konkretny instrument prawny (np. standardowe klauzule umowne) oraz opisać dodatkowe środki techniczne i organizacyjne.
• Zakres danych objętych transferem – czy poza granice UE/EOG wychodzi cała treść promptów, czy tylko zanonimizowane metadane? Czy transfer dotyczy także danych wrażliwych, jeśli takie mogą pojawić się w systemie?
• Możliwość wyboru regionu – w wielu rozwiązaniach biznesowych można skonfigurować region przechowywania danych. Jeśli dostawca nie daje takiej opcji, trzeba świadomie ocenić ryzyko.

Jeżeli transfery są nieuniknione, konieczna staje się ocena adekwatności zabezpieczeń (tzw. TIA – transfer impact assessment). W branży AI ta analiza powinna objąć nie tylko główną aplikację, lecz także narzędzia wspierające – systemy logowania, monitoringu, analityki.

„Oswajanie” narzędzia – konfiguracja prywatności i polityki użycia

Po wdrożeniu nowego chatu AI w firmie konsultanci zaczęli z niego korzystać jak z prywatnego asystenta: od analizy skarg klientów po pisanie zaproszeń na imprezę integracyjną. Administrator szybko stracił kontrolę nad tym, jakie dane faktycznie przepływają przez system.

Samo wybranie „bezpiecznego” dostawcy nie wystarczy. Narzędzie trzeba skonfigurować i osadzić w konkretnych zasadach organizacyjnych. Pomaga w tym kilka kroków:

• Profile i uprawnienia – stworzenie odrębnych ról użytkowników (np. wersja „lite” bez możliwości przesyłania plików, konto eksperckie z dostępem do integracji, uprawnienia administracyjne wyłącznie dla kilku osób).
• Ograniczenia funkcjonalne – wyłączenie historii czatów, jeśli nie jest niezbędna; ograniczenie długości promptów; blokada wklejania plików wrażliwych, jeśli dostawca na to pozwala technicznie.
• Polityki wewnętrzne – jasny dokument „jak używamy AI”, który określa rodzaje dozwolonych i zakazanych danych, minimalne zasady anonimizacji, wymogi weryfikacji wyników.
• Szablony promptów – przygotowanie gotowych, przetestowanych schematów zapytań dla powtarzalnych procesów (np. analiza reklamacji, przygotowanie odpowiedzi na zapytanie przetargowe), tak aby użytkownicy nie „wymyślali” ich od zera i nie dokładali zbędnych danych osobowych.

Ucywilizowanie narzędzia na etapie konfiguracji i polityk często bardziej obniża ryzyko niż kolejne zapisy w umowie. Ludzie rzadziej eksperymentują z danymi w niekontrolowany sposób, jeśli mają jasne wytyczne i przyjazne im, gotowe schematy pracy.

Dane w środku promptu – jak projektować zapytania do AI, by nie łamać RODO

Scenariusze ryzyka w promptach – gdzie najczęściej „wypadają” dane osobowe

Podczas szkolenia w dziale obsługi klienta wyszło na jaw, że konsultanci wrzucają do AI całe wątki mailowe z klientami „żeby szybciej napisać odpowiedź”. W treści wiadomości były numery zamówień, adresy, a czasem także informacje o stanie zdrowia, bo dotyczyły reklamacji produktów medycznych. W teorii wszyscy znali RODO, w praktyce liczyła się wygoda.

Prompt to kolejny kanał przetwarzania danych osobowych, często bardziej „luźny” niż klasyczne formularze. Najczęstsze błędy to:

• wklejanie pełnych konwersacji z systemów ticketowych lub e-maili, gdy do analizy wystarczyłby wybrany fragment,
• pozostawianie pełnych identyfikatorów (PESEL, NIP, numery dokumentów, numery polis), choć model ich w ogóle nie potrzebuje,
• łączenie w jednym promptcie danych z wielu źródeł (CRM, HR, support), co tworzy nowy, szeroki kontekst o osobie, którego nie było w żadnym pojedynczym systemie,
• przekazywanie danych szczególnych kategorii (zdrowie, przekonania, związki zawodowe) bez wyraźnej podstawy prawnej i oceny ryzyka.

Jeśli zmapujesz te scenariusze i pokażesz je zespołowi na prostych przykładach, świadomość ryzyka w promptach rośnie bardzo szybko. Ludzie rzadko działają w złej wierze – zwykle po prostu nie łączą faktów, że „to tylko czat” też podlega RODO.

Techniki anonimizacji i pseudonimizacji w praktyce promptów

W zespole ds. jakości obsługi klienta manager chciał analizować styl komunikacji konsultantów i prosił AI o propozycje usprawnień. Na początku wklejał wiadomości „jak leci”. Po krótkich warsztatach z IOD zaczął korzystać z prostych masek i identyfikatorów, a wyniki analizy wcale na tym nie ucierpiały.

Anonimizacja w kontekście promptów rzadko oznacza skomplikowane procesy. Często wystarczą proste, konsekwentne techniki:

• Zastępowanie danych identyfikujących – imię i nazwisko, e-mail, numer telefonu można zamienić na neutralne etykiety typu „[KLIENT_123]”, „[PRACOWNIK_A]”. Istotne jest, by klucze mapujące pozostawały wyłącznie w systemach wewnętrznych, a nie w treści promptu.
• Usuwanie szczegółowych adresów – zamiast pełnego adresu („ul. X 10/5, 00-000 Warszawa”) często wystarczy informacja o mieście lub województwie, o ile kontekst zadania na to pozwala.
• Maskowanie numerów – numery zamówień, polis, kont można skrócić (np. zostawić ostatnie 4 znaki) lub zastąpić losowymi ciągami, jeśli nie są potrzebne do analizy merytorycznej.
• Usuwanie wzmianek o zdrowiu i poglądach – przy analizie jakości obsługi czy języka wiadomości fragmenty zawierające dane szczególnych kategorii można logicznie „wyciąć”, zachowując sens rozmowy.

Dobrym nawykiem jest też krótkie pytanie zadawane samemu sobie przed wysłaniem promptu: „Czy do tego zadania naprawdę potrzebuję wiedzieć, kto dokładnie jest bohaterem tej historii?”. Jeśli odpowiedź brzmi „nie”, pełne dane osobowe są zbędne.

Szablony promptów jako element zgodności z RODO

W firmie B2B opiekunowie klienta korzystali z AI do pisania ofert i odpowiedzi na zapytania. Każdy miał swoje „patenty” na prompt, więc raz do systemu trafiały wyłącznie parametry techniczne, a innym razem pełne dane kontaktowe osoby decyzyjnej. Chaos utrudniał kontrolę nad przepływem danych.

Szablony promptów porządkują ten obszar i zmniejszają ryzyko. Można je przygotować dla typowych zadań:

• „Przeanalizuj poniższy opis sprawy i zaproponuj 3 warianty odpowiedzi. Dane osobowe klientów zostały usunięte, skup się wyłącznie na meritum sprawy.”
• „Na podstawie zanonimizowanego opisu reklamacji wskaż luki w procesie obsługi. Nie zakładaj żadnych dodatkowych danych o kliencie poza tym, co widzisz w treści.”

Ustandaryzowanie promptów:

• ogranicza „nadmiarowe” dzielenie się informacjami,
• ułatwia szkolenie nowych pracowników,
• pozwala IOD i działowi prawnemu łatwiej ocenić ryzyko, bo wiedzą, jaki jest typowy wzorzec przetwarzania.

Szablon może być prostą notatką w firmowym intranecie lub gotową funkcją w narzędziu (np. przycisk „stwórz odpowiedź na reklamację” z wstępnie wypełnionym promptem). Kluczowa jest konsekwencja w korzystaniu z nich.

Metadane i kontekst – „niewidoczne” dane osobowe wokół promptów

Podczas przeglądu logów okazało się, że chociaż same treści promptów były zanonimizowane, system w tle zapisywał identyfikator użytkownika, datę, adres IP i tag projektu. Po połączeniu tych elementów osoby z działu IT mogły z dużym prawdopodobieństwem odtworzyć, o jakich klientach była mowa w analizach.

RODO obejmuje nie tylko widoczną treść promptu, ale też wszystkie metadane, które pozwalają kogoś zidentyfikować. W praktyce oznacza to potrzebę kontroli:

• zakresu logowania – czy naprawdę trzeba zapisywać pełne identyfikatory użytkowników, czy wystarczy pseudonim? Jak długo trzeba przechowywać te dane do celów audytu?
• integracji z innymi systemami – gdy prompt jest wysyłany z CRM lub helpdesku, do żądania często „doklejają się” identyfikatory klienta lub linki do rekordów – to też dane osobowe, które wędrują do usługodawcy AI,
• kontekstu projektowego – tagi typu „VIP”, „windykacja”, „HR – redukcje etatów” mogą same w sobie stanowić wrażliwą informację, jeśli da się je połączyć z konkretną osobą.

Przy wdrożeniach opartych o API dobrze jest przeprowadzić wspólny przegląd z IT: zobaczyć „surowe” requesty i response’y, a nie tylko ładny interfejs użytkownika. Tam często wychodzą na jaw dodatkowe pola, które przypadkowo niosą dane osobowe.

Wysokie ryzyko? Kiedy AI wymaga oceny skutków (DPIA) i dodatkowych zabezpieczeń

Przykłady zastosowań AI, które zwykle wchodzą w strefę „wysokiego ryzyka”

Podczas narady dotyczącej wdrożenia modelu oceniającego kandydatów HR usłyszał, że „to tylko ranking CV, resztę i tak sprawdzą rekruterzy”. Po krótkiej analizie okazało się jednak, że od tego rankingu zależy, kto w ogóle zostanie zaproszony na rozmowę – a więc realny wpływ na prawa i wolności osób był bardzo duży.

Nie każde wykorzystanie AI oznacza wysokie ryzyko w rozumieniu RODO. Są jednak scenariusze, w których ocena skutków dla ochrony danych (DPIA) staje się praktycznie koniecznością. Typowe przykłady to:

• systemy wspierające decyzje kadrowe – preselekcja CV, sugestie dotyczące awansów, plany redukcji etatów, ocena wydajności na podstawie danych z wielu systemów,

Najczęściej zadawane pytania (FAQ)

Czy mogę wkleić dane klientów do ChatGPT lub innego czatu AI, żeby „tylko coś przetestować”?

Scenariusz jest powtarzalny: ktoś z zespołu ma świetny pomysł na analizę bazy, kopiuje dane z CRM i wrzuca do darmowego narzędzia AI „na próbę”. Z pozoru niewinny test w kilka sekund zamienia się w pełnoprawne przekazanie danych osobowych zewnętrznemu dostawcy – często poza UE i bez żadnej kontroli.

Z perspektywy RODO nie ma znaczenia, że to był „tylko test”. Jeśli dane pozwalają zidentyfikować osoby (np. imię, nazwisko, e‑mail, stanowisko, kontekst, który zwęża grupę), mamy przetwarzanie danych osobowych w dodatkowym systemie. To wymaga podstawy prawnej, oceny ryzyka, umowy powierzenia danych z dostawcą AI i uwzględnienia tego procesu w dokumentacji. Wklejanie surowych danych z CRM do publicznych czatów AI bez tych elementów jest ryzykowne i może zostać uznane za naruszenie ochrony danych.

Jak rozpoznać, czy dane używane w narzędziu AI podlegają RODO?

Częsty obrazek: ktoś usuwa z pliku kolumnę „imię i nazwisko” i ogłasza, że dane są „zanonimizowane”. Tymczasem wciąż zostaje stanowisko, nazwa firmy, opis sytuacji i unikalne połączenia okoliczności, po których bez trudu da się dojść, o kogo chodzi – zwłaszcza w małych organizacjach.

RODO stosuje się wtedy, gdy osoba fizyczna jest zidentyfikowana lub możliwa do zidentyfikowania przy użyciu rozsądnie dostępnych środków. To oznacza, że danymi osobowymi mogą być m.in. biznesowy e‑mail (imię.nazwisko@…), ID klienta powiązane z bazą, treść korespondencji czy opis stanowiska z kontekstem. Jeśli w Twojej organizacji da się po tych danych odtworzyć, o kim mowa, narzędzie AI pracuje na danych osobowych i uruchamia obowiązki z RODO.

Czy dane „testowe” w AI też podlegają RODO?

W wielu firmach start wygląda tak: „Na razie wgrajmy prawdziwe zgłoszenia klientów / CV / bazę zamówień, tylko do testów nowego rozwiązania AI”. Z biznesowego punktu widzenia to przyspiesza projekt, ale z perspektywy ochrony danych niczego nie upraszcza.

RODO nie rozróżnia danych „na poważnie” i „na próbę”. Jeśli w danych testowych występują prawdziwe osoby, ich dane są tak samo chronione jak w systemie produkcyjnym. Oznacza to konieczność posiadania podstawy prawnej, umowy powierzenia z dostawcą AI, odpowiednich zabezpieczeń oraz uwzględnienia takiego testu w rejestrze czynności przetwarzania. Chcąc uniknąć problemów, warto przygotować osobne, zanonimizowane lub syntetyczne zbiory danych testowych.

Czy usunięcie imion i nazwisk z pliku przed wgraniem do AI wystarczy, żeby dane były anonimowe?

Popularna praktyka wygląda tak: zespół kasuje kolumnę „imię i nazwisko” i spokojnie wysyła plik do analizy w narzędziu AI. Kłopot w tym, że w wielu przypadkach pozostałe informacje nadal pozwalają dojść do konkretnej osoby – szczególnie w połączeniu z wiedzą wewnętrzną firmy.

Prawdziwa anonimizacja oznacza, że nie da się zidentyfikować osób nawet przy użyciu rozsądnie dostępnych środków, również po połączeniu z innymi danymi, do których realnie masz dostęp. Jeśli z opisu „jedyny CTO w firmie X, który przeszedł z działu sprzedaży i pracuje z klientem Y” każdy w organizacji wie, o kogo chodzi, to nadal są dane osobowe. Samo usunięcie imion i nazwisk to najczęściej tylko pseudonimizacja, a więc RODO nadal obowiązuje.

Jakie obowiązki RODO uruchamia użycie narzędzi AI w firmie?

Często wygląda to tak: biznes zamawia dostęp do „sprytnego AI w chmurze”, integracja rusza, a dopiero po czasie ktoś pyta dział prawny, czy „trzeba coś z RODO”. Tymczasem większość obowiązków powinna być załatwiona jeszcze przed wprowadzeniem narzędzia do codziennej pracy z danymi osób.

Przy korzystaniu z AI, które przetwarza dane osobowe, zwykle trzeba: przeanalizować ryzyka (często w formie DPIA), ustalić podstawę prawną i cele przetwarzania, zawrzeć umowę powierzenia danych z dostawcą, sprawdzić transfery poza EOG, zaktualizować klauzule informacyjne dla klientów/pracowników oraz wprowadzić wewnętrzne polityki i szkolenia z bezpiecznego użycia AI. Dodatkowo trzeba mieć procedurę postępowania na wypadek incydentów – na przykład gdy ktoś wklei do czatu AI więcej danych, niż powinien.

Co zrobić, jeśli pracownik już wkleił dane osobowe do zewnętrznego narzędzia AI?

Typowy scenariusz: ktoś przyznaje się po fakcie, że „wrzucił parę rekordów z CRM do czatu, żeby zobaczyć, jak to zadziała”. W takiej sytuacji nie ma sensu udawać, że nic się nie stało – trzeba potraktować to jak potencjalne naruszenie ochrony danych.

Praktyczne kroki obejmują zazwyczaj: szybką analizę, jakie dane i w jakiej skali wyciekły do narzędzia AI, ocenę ryzyka dla osób, których dane dotyczą, sprawdzenie, czy incydent trzeba zgłosić do Prezesa UODO (w ciągu 72 godzin) i czy trzeba powiadomić osoby, których dane dotyczą. Równolegle należy zweryfikować, czy dostawca AI oferuje usunięcie danych z logów i systemów oraz wdrożyć środki zapobiegawcze: doprecyzować polityki, przeszkolić zespół, ograniczyć dostęp do narzędzi AI lub wprowadzić wersje „enterprise” z umową powierzenia danych.

Jak bezpiecznie wdrożyć AI w obszarach takich jak HR, marketing czy obsługa klienta?

W praktyce to często wygląda tak: poszczególne działy zaczynają używać AI „oddolnie” – HR do analiz CV, marketing do segmentacji, support do odpowiedzi na maile – a dopiero po kilku miesiącach ktoś próbuje to ułożyć w spójną całość. Lepiej odwrócić kolejność i zacząć od uporządkowania zasad.

Bezpieczne podejście to m.in.: zidentyfikowanie obszarów, w których AI ma styczność z danymi osób (klienci, pracownicy, kandydaci), nazwanie kategorii danych (w tym danych wrażliwych), wybór dostawców AI z odpowiednimi gwarancjami (umowa powierzenia, lokalizacja serwerów, możliwość usuwania danych), przygotowanie polityki korzystania z AI oraz cykliczne szkolenia. Dobrą praktyką jest też ograniczanie danych przekazywanych do AI do minimum niezbędnego do osiągnięcia celu – im mniej identyfikujących szczegółów, tym niższe ryzyko naruszenia RODO.

Kluczowe Wnioski

• Nawet „szybki test” w darmowym czacie AI może być pełnoprawnym incydentem naruszenia danych osobowych, jeśli pracownik wkleja tam realne dane klientów lub pracowników.
• Narzędzia AI trzeba traktować jak każdy inny system przetwarzający dane (CRM, system kadrowy): z oceną ryzyka/DPIA, określonym celem, podstawą prawną i zasadami retencji danych.
• Przekazanie danych osobowych dostawcy AI bez umowy powierzenia, jasnego zakresu przetwarzania i informacji o ewentualnych transferach poza EOG jest złamaniem wymogów RODO.
• Brak polityki korzystania z AI i szkoleń powoduje, że pracownicy nieświadomie wklejają do modeli językowych imiona, maile, stanowiska czy historię współpracy – co może skończyć się obowiązkiem zgłoszenia naruszenia do UODO i informowania klientów.
• Dane osobowe w kontekście AI to nie tylko nazwiska – także adresy e-mail, identyfikatory, opisy stanowisk połączone z kontekstem czy treść korespondencji, z której łatwo wywnioskować, o kogo chodzi.
• Obszary szczególnie narażone na „przecieki” do narzędzi AI to HR, obsługa klienta, marketing i sprzedaż oraz analityka – tam modele często pracują na danych, które pozwalają zidentyfikować konkretne osoby.
• RODO nie ma zastosowania tylko wtedy, gdy AI działa na danych technicznych, w pełni zanonimizowanych lub stricte biznesowych; jeśli da się z rozsądnym wysiłkiem przypisać informacje do osoby fizycznej, uruchamiają się wszystkie obowiązki ochrony danych.