RODO a sztuczna inteligencja w firmie – jak nie złamać przepisów

Po co łączyć RODO i sztuczną inteligencję – punkt wyjścia dla firmy

Dlaczego każdy projekt AI w firmie dotyka danych osobowych

Sztuczna inteligencja w firmie prawie zawsze „żywi się” danymi: klientami, leadami, użytkownikami, kandydatami, pracownikami. W praktyce wystarczy, że system AI operuje na imieniu, adresie e‑mail, identyfikatorze użytkownika, historii zakupów, nagraniach rozmów czy logach zachowań w aplikacji – i już wchodzisz w obszar przetwarzania danych osobowych w rozumieniu RODO.

Nawet jeśli wydaje się, że dane są „techniczne”, „wewnętrzne” czy „marketingowe”, bardzo często da się je powiązać z konkretną osobą (bezpośrednio albo pośrednio). Dla RODO nie ma znaczenia, czy patrzysz na dane jako na „surowiec do trenowania modelu”; istotne jest, czy dana osoba jest możliwa do zidentyfikowania.

Efekt jest prosty: większość komercyjnych zastosowań AI w firmach podlega RODO. Nie ma znaczenia, czy to zwykły scoring leadów, chatbot sprzedażowy, czy zaawansowany system rekomendacji. Jeżeli bazuje na danych osobowych – wchodzą w grę wszystkie zasady ochrony danych.

„Fajne narzędzie” kontra system przetwarzający dane klientów i pracowników

Z perspektywy zespołu AI czy marketingu narzędzie generatywne lub model predykcyjny to po prostu „fajna technologia”. Z perspektywy RODO – to system przetwarzania danych osobowych, który trzeba potraktować jak każdy inny system IT: CRM, ERP czy system kadrowo‑płacowy.

Kluczowa różnica: wiele narzędzi AI jest łatwo dostępnych (SaaS, przeglądarka, plugin), przez co pracownicy zaczynają ich używać „z marszu”, bez analizy prawnej i bezpieczeństwa. To klasyczny scenariusz shadow IT. Dla organu nadzorczego nie ma znaczenia, że „to był tylko test” albo „pracownik sam wpisał dane do ChatGPT”. Administrator danych odpowiada za to, jakie narzędzia realnie są używane.

Granica między „fajnym narzędziem” a krytycznym systemem danych przesuwa się bardzo szybko. Chatbot do wewnętrznych Q&A zaczyna nagle analizować konkretne sprawy klientów. Narzędzie do podsumowań rozmów sprzedażowych przechodzi w automatyczne scoringowanie klientów. Właśnie więc na starcie trzeba ustalić: czy i jakie dane osobowe trafią do AI oraz w jakich celach.

Ryzyka dla firmy: pieniądze, reputacja, zaufanie

Z perspektywy zarządu lub właściciela firmy trzy grupy ryzyk są najbardziej odczuwalne:

• Kary finansowe – za naruszenie zasad RODO przy wykorzystaniu AI UODO może nałożyć administracyjne kary pieniężne. Wysokość zależy od skali, ale sama procedura i jej nagłośnienie bywa dotkliwsze niż sama kwota.
• Szkody reputacyjne – wyciek danych, niewłaściwe profilowanie, dyskryminacja algorytmiczna, ujawnienie poufnych informacji przez model generatywny – to problemy, które bardzo szybko docierają do mediów i klientów.
• Utrata zaufania wewnętrznego – jeśli pracownicy widzą, że ich dane (np. raporty, rozmowy, oceny) trafiają do nieprzemyślanych systemów AI, spada poziom zaufania i otwartości, a rośnie ryzyko skarg i konfliktów.

RODO wymusza na firmie poukładanie sposobu korzystania z AI. To nie tylko „ochrona przed karą”, ale też element zarządzania ryzykiem biznesowym: gdy zdarzy się incydent, dobrze przygotowana firma jest w stanie go udokumentować, opanować i wytłumaczyć regulatorowi.

Przykład: użycie ChatGPT do obróbki treści z CRM

Wyobraźmy sobie handlowca, który kopiuje historię korespondencji z klientem z CRM i wkleja ją do publicznego narzędzia typu ChatGPT, prosząc o podsumowanie i propozycję odpowiedzi. Z jego perspektywy: oszczędność czasu. Z perspektywy RODO:

• dane klienta (adres e‑mail, imię, treść korespondencji) trafiają do zewnętrznego dostawcy AI, często poza EOG,
• firma nie ma z tym dostawcą umowy powierzenia przetwarzania danych,
• treści mogą być wykorzystane do trenowania modelu (w zależności od regulaminu),
• klient nie został poinformowany, że jego dane trafią do takiego systemu.

To klasyczny przykład przetwarzania danych osobowych niezgodnie z RODO. Aby działać legalnie, firma powinna: przeanalizować podstawę prawną, wybrać odpowiednią wersję narzędzia (np. biznesową z umową powierzenia), ustawić parametry (wyłączenie trenowania na danych klientów), przeszkolić pracowników, zaktualizować klauzule informacyjne.

Co w ogóle jest „danymi osobowymi” w kontekście AI

Zakres definicji danych osobowych a systemy AI

RODO definiuje dane osobowe szeroko: to wszelkie informacje o zidentyfikowanej lub możliwej do zidentyfikowania osobie fizycznej. W praktyce przy AI trzeba patrzeć nie tylko na „oczywiste” dane (imię, nazwisko), ale także na:

• dane wejściowe – teksty, pliki, obrazy, nagrania, które wprowadzasz do modelu,
• dane wyjściowe – odpowiedzi, rekomendacje, profile ryzyka wygenerowane przez system,
• metadane – znaczniki czasu, ID użytkownika, źródło danych,
• logi systemowe – historia zapytań, IP, dane urządzenia.

Jeśli z tego zestawu da się wyprowadzić informację o konkretnej osobie (samodzielnie albo w połączeniu z innymi danymi, które masz w firmie), to masz do czynienia z danymi osobowymi. AI często działa na dużej ilości pozornie „technicznych” danych, ale po ich powiązaniu powstaje pełny profil użytkownika – co wprost podlega RODO.

Anonimizacja a pseudonimizacja w projektach AI

W projektach AI dużo mówi się o „anonimizowaniu danych”, ale w praktyce większość firm stosuje pseudonimizację, a nie pełną anonimizację.

• Anonimizacja – dane są przetworzone tak, że nie da się zidentyfikować osoby w żaden rozsądny sposób, także przy użyciu innych informacji, które administrator lub ktoś inny może mieć. Takie dane nie podlegają RODO.
• Pseudonimizacja – z danych usuwa się bezpośrednie identyfikatory (np. imię, PESEL), ale istnieje klucz lub inne informacje, które pozwalają ponownie powiązać dane z osobą. Takie dane nadal są danymi osobowymi.

W AI typowe praktyki to zamiana imion na ID użytkownika, przycięcie adresu IP, usunięcie imion z transkryptów rozmów. Jeśli jednak wciąż istnieje możliwość powiązania rekordu z konkretnym klientem w CRM, mówimy o pseudonimizacji. Z punktu widzenia RODO nadal musisz mieć podstawę prawną, spełniać zasady minimalizacji, przechowywania, bezpieczeństwa.

Bezpiecznym podejściem jest przyjęcie założenia, że jeśli masz możliwość „odwrócenia” procesu i identyfikacji osoby, to nie jest to anonimizacja. Przy trenowaniu modeli na danych osobowych często jedynym realnym rozwiązaniem jest mocna pseudonimizacja i ograniczenie dostępu do kluczy, a nie pełna anonimizacja.

Przykłady danych w AI: tekst, obraz, audio, biometria, zachowania

Systemy AI przetwarzają dziś bardzo różne typy danych. Z punktu widzenia RODO typ danych może oznaczać różną wagę ryzyka:

• Dane tekstowe – e‑maile, czaty, notatki ze spotkań, opisy spraw. W tekście bardzo łatwo „przemycają się” dane wrażliwe (zdrowie, przekonania, dane karne). Wystarczy, że klient napisze „jestem po operacji, proszę o…” i już wprowadzasz do modelu szczególną kategorię danych.
• Nagrania audio – rozmowy call center, webinary, spotkania. Głos pozwala zidentyfikować osobę, a analiza treści rozmowy może ujawnić mnóstwo informacji o sytuacji życiowej, zdrowotnej, finansowej.
• Obraz i wideo – monitoring, rozpoznawanie twarzy, zdjęcia produktów z ludźmi w tle. To często dane biometryczne albo dane dotyczące wizerunku, które wymagają szczególnej ostrożności.
• Dane behawioralne – kliknięcia w aplikacji, czas spędzony na stronie, ścieżka zakupowa, reakcje na kampanie. Same z siebie mogą wyglądać „niewinnie”, ale w połączeniu z identyfikatorem konta tworzą profil w rozumieniu RODO.

W każdym z tych przypadków trzeba osobno przeanalizować, czy dane są osobowe, czy wrażliwe i jaki poziom ryzyka generuje ich przetwarzanie w ramach rozwiązań AI.

Dane treningowe vs dane operacyjne – różne perspektywy RODO

W projektach AI często rozróżnia się dwa główne zbiory danych:

• dane treningowe – używane do uczenia modelu (np. historyczne transakcje, transkrypty rozmów),
• dane operacyjne – bieżące dane, które „przepuszczasz” przez już wytrenowany model (np. nowe zapytania klientów).

Z perspektywy RODO oba typy to przetwarzanie danych osobowych, ale z inną dynamiką ryzyka:

• Przy danych treningowych najważniejsze są: podstawa prawna dla uczenia modelu, zakres danych, retencja (jak długo trzymasz dane treningowe), możliwość rozliczenia, komu i w jakim celu model służy.
• Przy danych operacyjnych kluczowe będą: informowanie osób, profilowanie, automatyczne podejmowanie decyzji, prawo do sprzeciwu, obsługa żądań dostępu i usunięcia danych.

Częsty błąd: zakładanie, że „jak raz wytrenuję model na danych, to później mogę dane źródłowe usunąć i jestem poza RODO”. Niestety, to nie jest takie proste. Dane osobowe były przetwarzane na etapie treningu, więc musisz udokumentować podstawę prawną, zakres, zabezpieczenia i retencję także dla tego etapu, nawet jeśli później model działa już na nowych, mniej wrażliwych danych.

Administrator, podmiot przetwarzający, dostawca AI – kto za co odpowiada

Jak ustalić rolę firmy w projekcie AI

RODO wyróżnia kilka ról. Dla AI kluczowe są trzy:

• Administrator – decyduje o celach i sposobach przetwarzania danych osobowych. To zazwyczaj Twoja firma, jeśli wdrażasz AI do własnych procesów (np. marketing, obsługa klienta, HR).
• Podmiot przetwarzający (procesor) – przetwarza dane w imieniu administratora i tylko na jego udokumentowane polecenie (np. dostawca narzędzia SaaS, operator chmury, software house).
• Współadministrator – dwie lub więcej organizacji wspólnie ustalają cele i sposoby przetwarzania (np. wspólny system scoringu klientów kilku spółek).

Tworząc lub kupując rozwiązanie AI, musisz jasno ustalić, w jakiej roli występujesz. W 90% przypadków firma, która korzysta z narzędzia AI w swoim biznesie, jest administratorem, a dostawca narzędzia – podmiotem przetwarzającym. Są jednak wyjątki, gdy dostawca korzysta z danych klientów do własnych celów (np. trenowania uniwersalnego modelu) – wtedy może stać się odrębnym administratorem lub współadministratorem.

Typowe modele wdrożenia AI a odpowiedzialność

W praktyce spotykasz najczęściej trzy scenariusze techniczne, które niosą różną odpowiedzialność prawną.

SaaS AI od zewnętrznego dostawcy

Przykład: korzystasz z platformy AI w modelu subskrypcyjnym (np. narzędzie do analizy sentymentu, generowania treści, scoringu leadów), gdzie interfejs jest dostępny przez przeglądarkę lub API.

• Twoja firma jest administratorem danych – decydujesz, jakich danych użyjesz i w jakim celu.
• Dostawca jest zazwyczaj podmiotem przetwarzającym – przetwarza dane w Twoim imieniu.
• Potrzebujesz umowy powierzenia przetwarzania danych, która jasno określa: zakres, środki bezpieczeństwa, podwykonawców (subprocesorów), transfery poza EOG, okres przechowywania.

Własny model na infrastrukturze chmurowej

Przykład: budujesz własny model (np. klasyfikator zgłoszeń serwisowych) i hostujesz go na AWS, Azure, GCP lub innej chmurze.

• Twoja firma pozostaje administratorem danych.
• Dostawca chmury jest podmiotem przetwarzającym (np. przechowuje dane w bazach, logach, backupach).
• Jeżeli korzystasz także z gotowych usług AI (np. API do rozpoznawania mowy), zakres roli dostawcy może być szerszy – trzeba sprawdzić regulaminy i dokumentację.

Wdrożenie on‑premise (lokalnie)

Przykład: instalujesz model AI na własnych serwerach, całe przetwarzanie odbywa się wewnątrz sieci firmowej, bez usług zewnętrznych.

Rola dostawcy technologii przy wdrożeniu lokalnym

Nawet gdy cały system działa na Twoich serwerach, dostawca technologii AI często ma pewien dostęp do danych:

• pomaga przy instalacji i konfiguracji,
• zapewnia wsparcie techniczne (zdalny dostęp, zrzuty ekranu, logi błędów),
• dostarcza aktualizacje i łatki bezpieczeństwa.

Trzeba wtedy doprecyzować, czy dostawca w ogóle widzi dane osobowe. Jeśli tak, zwykle jest podmiotem przetwarzającym i wymaga umowy powierzenia, nawet jeśli nie ma stałego dostępu, tylko incydentalny (np. przy awarii).

Bezpieczne podejście to:

• ograniczenie dostępu dostawcy do środowisk z danymi produkcyjnymi,
• stosowanie masek danych i środowisk testowych z pseudonimizacją,
• jasne procedury: kto, kiedy i na jakiej podstawie może wchodzić na serwer z AI.

Dostawca AI jako odrębny administrator

Część dostawców staje się odrębnym administratorem, gdy używa danych klientów do własnych celów, niezależnych od Twoich. Typowe przykłady:

• trenowanie uniwersalnego modelu na danych wielu klientów,
• budowa benchmarków i statystyk jakości niezwiązanych z Twoją usługą,
• retencja danych dłużej, niż wynika to z Twojej relacji z klientem.

W takiej konfiguracji masz dwóch administratorów: Ciebie i dostawcę. Każdy odpowiada za swoją część przetwarzania: cele, zakres, podstawy prawne, informowanie osób. W praktyce trzeba:

• przeanalizować regulaminy i polityki prywatności dostawcy,
• ustalić, czy występuje współadministracja (np. wspólne ustalanie parametrów modelu, wspólne cele marketingowe),
• uzgodnić, kto i w jakim zakresie przekazuje informacje osobom oraz obsługuje ich prawa.

Jeśli dostawca zastrzega sobie „prawo do wykorzystania Twoich danych do dowolnego uczenia modeli”, to z perspektywy RODO jest to czerwone światło. Taka klauzula wymaga dokładnego przejrzenia pod kątem legalnej podstawy, przejrzystości i zgodności z zasadą minimalizacji.

Jak ustawić umowy z dostawcą AI

Umowa z dostawcą AI powinna odzwierciedlać realny sposób działania systemu, a nie być tylko generyczną „umową powierzenia do wszystkiego”. Dobrze, jeśli zawiera przynajmniej:

• Opis przetwarzania – jakie dane, w jakim celu, w jakich procesach biznesowych są używane.
• Zakaz samodzielnego użycia danych – chyba że strony jasno i legalnie umówią się inaczej.
• Reguły dalszego powierzenia – lista subprocesorów (np. infrastruktura chmurowa, usługi logowania), procedura dodawania nowych.
• Okres przechowywania – zarówno danych operacyjnych, jak i logów, backupów, danych treningowych.
• Wsparcie w realizacji praw osób – jak dostawca pomoże w realizacji żądań dostępu, sprostowania, usunięcia.
• Bezpieczeństwo – szyfrowanie, kontrola dostępu, testy bezpieczeństwa, incydenty.
• Transfery poza EOG – lokalizacja serwerów, mechanizmy transferu (SCC, TIA), sposób informowania o zmianach.

Legalne podstawy przetwarzania danych przez systemy AI

Dopasowanie podstawy prawnej do zastosowania AI

Ta sama technologia AI może mieć różne podstawy prawne, zależnie od procesu. Najpierw trzeba nazwać konkretny cel biznesowy, a dopiero potem szukać podstawy z art. 6 RODO. Przykłady:

• automatyczne kategoryzowanie zgłoszeń serwisowych – zwykle niezbędność do wykonania umowy,
• personalizacja oferty na stronie – zazwyczaj prawnie uzasadniony interes lub zgoda,
• rekrutacja z wykorzystaniem analizy CV przez AI – często uzasadniony interes + obowiązki z prawa pracy,
• scoring ryzyka nadużyć finansowych – obowiązek prawny (AML) + ew. uzasadniony interes.

Zgoda na przetwarzanie danych przez AI – kiedy ma sens

Zgoda w kontekście AI jest wymagająca organizacyjnie. Sprawdza się, gdy:

• AI służy do celów dodatkowych, nie niezbędnych do wykonania umowy (np. zaawansowana personalizacja komunikacji marketingowej),
• przetwarzane są szczególne kategorie danych (np. dane zdrowotne w aplikacji wellbeingowej),
• AI w sposób istotny wpływa na osobę, a brak innej jasnej podstawy.

Zgoda musi być:

• konkretna – na określony cel, nie „na AI ogólnie”,
• dobrowolna – brak zgody nie może blokować podstawowej usługi, jeśli AI nie jest do niej konieczne,
• świadoma – osoba wie, że używasz AI, w jakim celu i z jakimi skutkami.

Jeśli nie jesteś w stanie realnie zapewnić prawa do łatwego wycofania zgody i późniejszego „wyjęcia” danych z procesów AI, lepiej szukać innej podstawy prawnej albo zmienić projekt tak, by takie wycofanie było możliwe.

Prawnie uzasadniony interes przy AI

W wielu przypadkach to właśnie uzasadniony interes administratora jest główną podstawą prawną. Dotyczy to m.in.:

• optymalizacji procesów (np. automatyczne przypisywanie spraw do konsultantów),
• wykrywania nadużyć lub anomalii,
• podstawowej personalizacji komunikacji z klientem.

Przed sięgnięciem po tę podstawę trzeba wykonać test równowagi (LIA). Dobrze, jeśli test uwzględnia specyfikę AI:

• jak bardzo wpływa na osobę (czy skutkuje odmową, gorszą ofertą, odrzuceniem w rekrutacji),
• czy istnieje profilowanie na dużą skalę,
• czy system podejmuje decyzje w pełni automatycznie.

Jeżeli interes biznesowy da się zrealizować innym, mniej „inwazyjnym” sposobem niż masowe profilowanie przez AI, trzeba to wziąć pod uwagę w ocenie. Uzasadniony interes nie przykryje wszystkiego.

Obowiązek prawny i wykonanie umowy

AI może być tylko sposobem realizacji już istniejącego obowiązku prawnego albo wykonania umowy. Przykłady:

• w bankowości – automatyczne monitorowanie transakcji pod kątem prania pieniędzy (obowiązek AML),
• w e‑commerce – AI dopasowujące czas dostawy i sposób komunikacji w ramach realizacji zamówienia,
• w HR – systemy AI wspierające rozliczanie czasu pracy czy naliczanie świadczeń.

W takich scenariuszach model AI jest tylko „narzędziem”, a nie odrębnym celem przetwarzania. Trzeba jednak wciąż przestrzegać zasad RODO, zwłaszcza minimalizacji i ograniczenia celu: to, że masz obowiązek monitorowania transakcji, nie oznacza nieograniczonego trenowania modeli na pełnej historii życia finansowego klienta.

Szczególne kategorie danych a AI

Jeśli AI choćby czasem „wchodzi” na dane zdrowotne, poglądy polityczne, dane biometryczne, przynależność związkową czy dane dotyczące życia seksualnego, wchodzisz w reżim szczególnych kategorii danych. W praktyce może do tego dojść „przy okazji”:

• analiza treści e‑maili i czatów,
• rozpoznawanie twarzy (biometria),
• analiza nastroju z głosu w aplikacjach wellbeingowych.

Potrzebujesz wtedy zarówno podstawy z art. 6, jak i wyjątku z art. 9 RODO (np. zgoda, prawo pracy, ochrona żywotnych interesów, roszczenia prawne). Dodatkowo rośnie wymóg co do DPIA, bezpieczeństwa i transparentności.

Zasady RODO „przekładane” na projekty AI krok po kroku

Minimalizacja danych w praktyce AI

Minimalizacja w AI to przede wszystkim decyzje architektoniczne. Dobre pytania na start:

• Czy model naprawdę potrzebuje surowych tekstów/nagrań, czy wystarczą zanonimizowane cechy (np. wektory, statystyki)?
• Czy wszystkie pola z bazy muszą trafić do modelu, czy część można odrzucić już na etapie ekstrakcji?
• Czy okres przechowywania danych treningowych jest spójny z polityką retencji biznesowej?

W praktyce często wystarcza:

• usunięcie danych identyfikujących (np. imię, PESEL, szczegółowe adresy) przed wejściem do pipeline’u,
• agregacja danych (np. zamiast pełnej historii kliknięć – liczba sesji, segment aktywności),
• oddzielenie kluczy identyfikacyjnych od zbioru treningowego i mocne ograniczenie dostępu do nich.

Ograniczenie celu i „rozlewanie się” AI

Projekty AI mają tendencję do „pączkowania” – model stworzony do jednego celu zaczyna służyć kolejnym. Z punktu widzenia RODO każdy nowy cel to nowe przetwarzanie. Przykład:

• model do klasyfikacji zgłoszeń technicznych zaczyna być używany do oceny wydajności pracowników,
• model scoringowy dla ryzyka nadużyć zaczyna wpływać na oferty marketingowe.

Takie zmiany wymagają ponownej analizy:

• czy nowy cel jest zgodny z pierwotnym (test kompatybilności),
• czy nie trzeba zmienić informacji przekazywanych osobom,
• czy podstawa prawna nadal „trzyma”, czy potrzebna jest nowa (np. zgoda).

Prawidłowość, rzetelność i aktualność danych

AI opiera się na danych historycznych, które bywają:

• niekompletne,
• zabrudzone,
• zawierające dawne błędy (np. źle oznaczone kategorie).

Jeśli model podejmuje decyzje wpływające na ludzi, musisz mieć procedury zapewnienia jakości danych:

• walidacja zbiorów treningowych (np. próbkowanie, ręczny przegląd, statystyki braków),
• aktualizacja modeli przy istotnych zmianach otoczenia (koniec „życia” starego modelu),
• monitorowanie błędów predykcji i ich wpływu na osoby.

Jeśli osoba skarży się, że decyzja AI „oparta jest na nieaktualnych danych”, system musi umożliwiać korektę i – przynajmniej docelowo – uwzględnienie tej korekty także w logice modelu lub przyszłych decyzjach.

Rozliczalność: dokumentacja projektu AI pod RODO

Rozliczalność to umiejętność pokazania jak wdrożyłeś RODO, a nie tylko stwierdzenia, że „działasz zgodnie z przepisami”. Dla AI przydaje się prosta, ale konsekwentna dokumentacja:

• opis modelu i jego celu,
• rodzaje danych wejściowych (+ czy są osobowe/wrażliwe),
• źródła danych (systemy, z których zasilasz model),
• role: kto jest administratorem, kto procesorem,
• podstawa prawna dla treningu i dla operacyjnego użycia modelu,
• retencja danych i modelu (jak długo, gdzie i w jakiej formie),
• wyniki DPIA / testu równowagi dla uzasadnionego interesu.

Taka „karta projektu AI” bardzo pomaga przy audycie, zapytaniu organu nadzorczego czy zmianach w zespole.

DPIA (ocena skutków dla ochrony danych) dla systemów AI

Przy wielu projektach AI DPIA nie jest opcją, tylko obowiązkiem. Dotyczy to zwłaszcza scenariuszy, gdzie:

• dochodzi do profilowania na dużą skalę,
• decyzje mogą wywoływać skutki prawne lub podobnie istotne (np. odrzucenie w rekrutacji, odmowa kredytu),
• przetwarzane są dane wrażliwe, w tym biometryczne,
• stosujesz nowatorskie technologie w obszarach podwyższonego ryzyka (np. zdrowie, finanse, dzieci).

Dobra DPIA dla AI powinna wyjść poza ogólniki i dotknąć konkretnych elementów:

• jakie są możliwe skutki błędu modelu dla osoby,
• jakie są ryzyka dyskryminacji (np. wobec określonych grup),
• jakie są wewnętrzne procedury odwołania się od decyzji AI,
• czy ktoś z ludzi regularnie przegląda działanie systemu.

Informowanie osób i transparentność działania AI

Jak opisać użycie AI w klauzulach informacyjnych

Standardowa klauzula informacyjna często nie wystarczy, jeśli w procesie działa AI. Trzeba doprecyzować przynajmniej:

• że w danym procesie używany jest system AI lub profilowanie,

Jakie informacje o AI muszą dostać osoby

Treść komunikatu zależy od wagi skutków dla osoby. Inaczej wygląda opis prostego rekomendatora treści, inaczej – systemu, który może odmówić kredytu. W praktyce przydają się trzy poziomy szczegółowości:

• krótki komunikat „przy wejściu” – np. w formularzu lub aplikacji, że używasz AI/profilowania w danym procesie,
• szczegółowa klauzula – powiązana z konkretnym celem i podstawą prawną, dostępna jednym kliknięciem,
• dodatkowe wyjaśnienia – np. na podstronie „Jak działa nasza AI”, jeśli system mocno wpływa na prawa lub sytuację osób.

W samej klauzuli informacyjnej (art. 13/14 RODO) trzeba doprecyzować m.in.:

• czy dochodzi do zautomatyzowanego podejmowania decyzji, w tym profilowania,
• jakie konsekwencje może mieć takie przetwarzanie dla osoby,
• na jakiej podstawie prawnej opiera się użycie AI,
• jakie prawa przysługują osobie (w tym prawo do sprzeciwu, jeżeli podstawą jest uzasadniony interes),
• czy dane są przekazywane dalej, np. dostawcom modeli lub chmurom poza EOG.

Dobrą praktyką jest krótki, ludzki opis logiki systemu, unikający żargonu:

• zamiast: „system wykorzystuje sieci neuronowe do modelowania ryzyka kredytowego”,
• raczej: „analizujemy dane o Twojej historii płatności i podstawowe informacje z wniosku, aby oszacować ryzyko niespłacenia kredytu”.

Kanały komunikacji o AI – nie tylko polityka prywatności

Formalne klauzule to podstawa, ale osoby i tak najczęściej patrzą na to, co widzą „po drodze”. Warto rozłożyć komunikację o AI w kilku punktach styku:

• formularze i aplikacje – krótkie adnotacje przy polach lub przyciskach, jeśli decyzja dalej będzie wspierana przez AI,
• regulaminy usług i produkty – jasne wskazanie, w których elementach usługi występuje profilowanie lub scoring,
• komunikaty e‑mail/SMS – jeśli wdrażasz nowy system AI, dobrze uprzedzić istniejących klientów o zmianie sposobu przetwarzania danych,
• intranet / komunikacja wewnętrzna – przy systemach HR AI informacja dla pracowników, co jest automatyzowane i jak mogą zgłaszać wątpliwości.

Przy decyzjach o dużym ciężarze (rekrutacja, kredyty, ubezpieczenia) osoba powinna od razu wiedzieć, że w procesie pracuje algorytm. Informacja schowana w ogólnym regulaminie nie spełni standardu przejrzystości.

Wyjaśnialność decyzji – jak „przetłumaczyć” AI na język użytkownika

Przy systemach, które wpływają na sytuację prawną lub ekonomiczną osoby, trzeba przygotować się na pytanie: „dlaczego tak zdecydowaliście?”. Odpowiedź nie może brzmieć „tak wyszło z algorytmu”.

Pomaga prosty model działania:

• lista głównych czynników – np. terminowość płatności, wiek zobowiązania, liczba wcześniejszych wniosków,
• opis mechanizmu – czy system porównuje do innych klientów, czy analizuje ryzyko na podstawie historii,
• wskazanie, gdzie jest człowiek – czy decyzja jest w pełni automatyczna, czy ktoś ją zatwierdza,
• co osoba może zrobić – kanał odwołania, możliwość uzupełnienia danych, powtórnej weryfikacji.

Jeżeli korzystasz z modeli typu „czarna skrzynka”, zaplanuj mechanizmy generowania prostych, zrozumiałych uzasadnień (np. narzędzia explainable AI, reguły biznesowe nakładane na wynik modelu). Bez tego trudno będzie spełnić obowiązek przejrzystości i obsłużyć skargi.

Transparentność wobec pracowników a systemy HR AI

Przy projektach wewnętrznych (monitoring wydajności, analityka zachowań pracowników, narzędzia rekrutacyjne) zakres informacji bywa jeszcze szerszy. Dobrze, by pracownicy znali:

• jakie dane trafiają do narzędzia AI (np. logi systemowe, czas reakcji na zgłoszenia, zapisy rozmów),
• czy system służy tylko do analityki zbiorczej, czy ma wpływ na oceny indywidualne i awanse,
• jak wygląda proces kontroli – kto ma dostęp do raportów, czy jest drugi poziom weryfikacji,
• czy pracownik może sprzeciwić się profilowaniu lub zgłosić wątpliwości co do oceny.

W praktyce dobrze sprawdza się osobna notyfikacja w intranecie lub polityka „AI w HR”, uzupełniająca ogólną informację o przetwarzaniu danych pracowników.

Prawa osób, których dane dotyczą, a algorytmy i modele

Dostęp do danych i informacji o działaniu AI

Prawo dostępu (art. 15 RODO) w kontekście AI to nie tylko wydruk danych z systemu. Osoba może oczekiwać trzech grup informacji:

• dane wejściowe – jakie konkretne dane o niej weszły do systemu (np. transakcje, odpowiedzi w formularzu),
• dane wyjściowe – scoring, kategorie, etykiety przypisane przez model,
• informacje o logice – ogólny opis zasad działania modelu i czynników mających główny wpływ na wynik.

Warto z góry ustalić techniczny sposób realizacji:

• czy potrafisz wyciągnąć indywidualny zapis predykcji z logów,
• czy możesz wygenerować „raport z profilu” dla konkretnej osoby,
• kto w zespole (IT, analitycy, IOD) pomaga przygotować odpowiedź.

Trzeba przy tym uważać, by nie ujawnić tajemnicy przedsiębiorstwa ani nie naruszyć bezpieczeństwa systemu. Odpowiedź powinna być wystarczająca z punktu widzenia osoby, ale nie musi ujawniać całego kodu modelu.

Sprostowanie i uzupełnienie danych w systemach AI

Sprostowanie danych dotyczy nie tylko „surowej” bazy, lecz także tego, jak dane wykorzystuje model. Przykład: kandydat zauważa, że system rekrutacyjny ocenił go słabo, bo życiorys zawierał nieaktualne informacje, które już poprawił w profilu.

Przy planowaniu architektury zadbaj o kilka mechanizmów:

• możliwość szybkiej zmiany danych źródłowych (np. CRM, HR),
• aktualizacja feature’ów lub profili wykorzystywanych przez model po sprostowaniu,
• jasne zasady, czy i kiedy zaktualizowane dane wpływają na bieżące decyzje (np. ponowna ocena wniosku),
• procedura oznaczania „starych” wyników modelu jako nieaktualnych.

Nie zawsze da się „przetrenować” model po każdej korekcie jednostkowej. Trzeba jednak móc przynajmniej zaktualizować decyzję operacyjną dotyczącą tej osoby lub przestać używać starych danych w kolejnych decyzjach.

Prawo do usunięcia danych i „bycia zapomnianym” a modele AI

Usunięcie danych w świecie AI oznacza więcej niż wykasowanie rekordu z jednej bazy. Trzeba rozważyć kilka poziomów:

• systemy źródłowe – CRM, system transakcyjny, HR,
• zbiory treningowe i walidacyjne – pliki, hurtownie danych, feature store,
• sam model – czy wiedza o osobie jest w nim utrwalona w sposób możliwy do powiązania.

W praktyce przydaje się podział na trzy scenariusze:

1. dane operacyjne – można i trzeba usuwać zgodnie z wnioskiem, chyba że istnieje obowiązek prawny przechowywania,
2. dane w zbiorach treningowych – jeżeli to możliwe, usuń w kolejnych iteracjach zestawów danych i przy okazji retrainingu modelu,
3. model jako taki – zazwyczaj nie trzeba „rozbrajać” starego modelu wstecznie dla pojedynczych osób, jeśli dane są zanonimizowane i nie da się ich odtworzyć, ale tę ocenę trzeba dobrze udokumentować.

Przy projektach, gdzie przewidujesz liczne wnioski o usunięcie (np. produkty konsumenckie na dużą skalę), warto rozważyć techniki projektowe ułatwiające „zapominanie”, np. częstsze trenowanie od zera na aktualnych danych, utrzymywanie rozdzielnych zbiorów po okresach retencji, ograniczanie granularności danych historycznych.

Prawo do ograniczenia przetwarzania – „pauza” w AI

Gdy osoba kwestionuje poprawność danych albo sprzeciwia się przetwarzaniu, w grę wchodzi ograniczenie przetwarzania. W środowisku AI oznacza to często konieczność wprowadzenia „pauzy”: system nadal przechowuje dane, ale nie wykorzystuje ich w modelu ani w decyzjach.

Technicznie można to rozwiązać na kilka sposobów:

• flagi przy rekordach w systemie źródłowym, które blokują ich pobieranie do pipeline’u,
• filtry w procesach ETL i przy generowaniu feature’ów,
• mechanizm wyłączania konkretnej osoby z scoringu (np. przez listę wykluczeń).

Dobrze, gdy te mechanizmy są uwzględnione już na etapie projektowania. Późniejsze „doklejanie” ograniczeń bywa kosztowne i zawodne.

Prawo do przenoszenia danych a systemy AI

Prawo do przenoszenia danych (art. 20 RODO) działa szczególnie przy usługach cyfrowych. Osoba może oczekiwać nie tylko surowych danych, ale również ich użytecznej formy do dalszego wykorzystania.

Przy AI sprowadza się to do kilku zasad:

• udostępnij dane, które osoba sama dostarczyła lub które generujesz na jej rzecz w ramach usługi (np. historia aktywności w aplikacji, podstawowe profile zachowań),
• zadbaj o standardowy format (CSV, JSON, inny prosty do odczytu),
• nie musisz przekazywać modelu ani szczegółowych parametrów algorytmu.

Jeżeli używasz AI do tworzenia dodatkowych wskaźników (np. segmenty klientów oparte na klastrach), warto ustalić, czy i w jakim zakresie te informacje też podlegają przenoszeniu – zwłaszcza tam, gdzie segment jest kluczowy dla usługi (np. taryfa cenowa).

Prawo sprzeciwu wobec profilowania i AI

Jeżeli podstawą prawną użycia AI jest uzasadniony interes, osoba ma prawo wnieść sprzeciw. Wtedy trzeba ocenić, czy istnieją „ważne, prawnie uzasadnione podstawy” nadrzędne wobec interesów lub praw osoby.

W praktyce dobrze z góry podzielić procesy na kategorie:

• sprzeciw zawsze honorowany – np. profilowanie marketingowe, personalizacja treści,
• sprzeciw z dużym prawdopodobieństwem honorowany – analityka wygody korzystania z aplikacji, podstawowy scoring ryzyka w sprzedaży niekrytycznych usług,
• sprzeciw możliwy, ale często odrzucany – obszary wymagane przez prawo lub kluczowe dla bezpieczeństwa (np. przeciwdziałanie nadużyciom), pod warunkiem rzetelnej analizy.

Na poziomie technicznym ponownie przydzi się flagowanie rekordów i możliwość wyłączenia osoby z określonych pipeline’ów lub wybranych modeli (np. modeli marketingowych, ale nie antyfraudowych).

Zautomatyzowane podejmowanie decyzji – dodatkowe gwarancje

Jeśli decyzja wobec osoby jest:

• oparta wyłącznie na automatycznym przetwarzaniu (w tym profilowaniu), oraz
• wywołuje skutki prawne lub w podobny sposób istotnie na nią wpływa,

uruchamia się art. 22 RODO i związane z nim uprawnienia. Niezależnie od podstawy prawnej trzeba zapewnić co najmniej:

• prawo do uzyskania interwencji człowieka po stronie administratora,
• prawo do wyrażenia własnego stanowiska,
• prawo do zakwestionowania decyzji.

Wymaga to realnych, a nie „papierowych” procedur. Kilka praktycznych elementów:

• kanał kontaktu (np. mail, formularz) wyraźnie wskazany przy decyzji AI,
• zespół lub rola odpowiedzialna za ręczną weryfikację sporów,
• możliwość podejmowania decyzji odmiennych od wyniku modelu, wraz z logowaniem takich przypadków,
• cykliczny przegląd odwołań pod kątem jakości modelu i ewentualnej dyskryminacji.

Jeżeli nie jesteś w stanie zaoferować sensownych gwarancji dla osób, rozważ zmianę architektury: np. uczynić model narzędziem wspomagającym decyzję człowieka, a nie jedynym decydentem.

Najczęściej zadawane pytania (FAQ)

Czy korzystanie z ChatGPT lub innych modeli generatywnych w firmie podlega RODO?

Tak. Jeżeli wklejasz do narzędzia AI dane klientów, pracowników czy kandydatów (np. e‑maile, historię korespondencji, CV, notatki ze spotkań), przetwarzasz dane osobowe i wchodzisz w reżim RODO. Nie ma znaczenia, że „to tylko test” albo że pracownik zrobił to z własnej inicjatywy.

Firma jako administrator odpowiada za to, jakie narzędzia są faktycznie używane i jakie dane tam trafiają. Dlatego narzędzia generatywne trzeba traktować jak normalny system IT: mieć podstawę prawną, umowę powierzenia z dostawcą, ustawione zasady przetwarzania danych oraz przeszkolonych pracowników.

Jak legalnie używać AI w firmie, żeby nie złamać RODO?

W praktyce przydaje się prosta checklista:

• określ cel użycia AI (np. scoring leadów, podsumowanie rozmów, rekomendacje produktów),
• sprawdź, czy wchodzą w grę dane osobowe i jakiego typu,
• dobierz podstawę prawną (np. prawnie uzasadniony interes, umowa, zgoda),
• zawrzyj umowę powierzenia z dostawcą AI i sprawdź transfery poza EOG,
• skonfiguruj narzędzie (wyłączenie trenowania na danych klientów, logi, retencja),
• zaktualizuj klauzule informacyjne i polityki,
• przeszkol pracowników, co wolno wklejać do AI, a czego nie.

Dopiero po takim minimum wdrażaj AI na szeroką skalę. „Kliknięcie konta trial” bez żadnych ustaleń to proszenie się o kłopot.

Jakie dane w kontekście AI są traktowane jako dane osobowe zgodnie z RODO?

To nie tylko imię, nazwisko czy e‑mail. Przy AI danymi osobowymi mogą być:

• dane wejściowe – teksty, pliki, obrazy, nagrania wrzucane do modelu,
• dane wyjściowe – profile ryzyka, rekomendacje, etykiety przypisane do konkretnego użytkownika,
• metadane – identyfikatory użytkownika, znaczniki czasu, źródła danych,
• logi – historia zapytań, IP, dane urządzenia wykorzystywane do profilowania.

Jeżeli na podstawie tych informacji da się zidentyfikować osobę (bezpośrednio lub po połączeniu z innymi danymi, które masz w firmie), to w pełni obowiązuje RODO.

Czym różni się anonimizacja od pseudonimizacji danych w projektach AI?

Anonimizacja oznacza, że po przetworzeniu danych nie ma już realnej możliwości zidentyfikowania osoby – nawet przy użyciu innych informacji, które ma administrator lub ktoś trzeci. Takie dane wypadają z zakresu RODO, ale osiągnięcie prawdziwej anonimizacji w projektach AI jest trudne.

Pseudonimizacja to usunięcie bezpośrednich identyfikatorów (np. imienia, PESEL), przy zachowaniu klucza lub powiązania, które pozwala „odwrócić” proces i przypisać dane do konkretnej osoby. W AI najczęściej mamy właśnie pseudonimizację (np. zamiana imion na ID klienta w CRM), co nadal oznacza pełne stosowanie RODO.

Czy mogę wkleić historię korespondencji z CRM do ChatGPT, żeby przygotował podsumowanie dla handlowca?

Wklejenie surowej korespondencji z CRM do publicznej wersji narzędzia typu ChatGPT jest co do zasady niezgodne z RODO. Dane klienta trafiają do zewnętrznego dostawcy, często poza EOG, bez umowy powierzenia i bez poinformowania klienta o takim przetwarzaniu. Dodatkowo treści mogą być użyte do trenowania modelu, jeśli tak stanowi regulamin.

Aby zrobić to legalnie, trzeba: wybrać biznesową wersję narzędzia z umową powierzenia, ustawić brak trenowania na danych klientów, ograniczyć zakres danych (np. pseudonimizacja), uregulować transfery poza EOG oraz zaktualizować klauzule informacyjne dla klientów.

Jakie są główne ryzyka RODO przy wdrażaniu AI w firmie?

W praktyce firmy najczęściej mierzą się z trzema grupami ryzyk:

• pieniężne – administracyjne kary pieniężne, koszty obsługi incydentów, audytów, prawników,
• reputacyjne – nagłośniony wyciek danych, zarzuty dyskryminacji algorytmicznej, niewłaściwe profilowanie,
• wewnętrzne – utrata zaufania pracowników, skargi do UODO, konflikty z działem HR lub związkami.

Dobrze poukładane procesy RODO wokół AI (rejestr czynności, DPIA przy ryzykownych projektach, jasne zasady korzystania z narzędzi SaaS) realnie zmniejszają te problemy, a nie są tylko „papierologią”.

Czy dane zbierane przez systemy analityczne i behawioralne też podlegają RODO w kontekście AI?

Tak, jeżeli można je powiązać z konkretną osobą lub kontem użytkownika. Kliknięcia w aplikacji, czas spędzony na stronie, ścieżka zakupowa czy reakcje na kampanie, po połączeniu z ID użytkownika tworzą profil, który AI wykorzystuje do rekomendacji lub scoringu.

Taki profil jest przetwarzaniem danych osobowych w rozumieniu RODO. Trzeba więc zadbać o podstawę prawną (np. zgoda na profilowanie marketingowe, prawnie uzasadniony interes), przejrzyste informowanie użytkownika oraz możliwość sprzeciwu lub rezygnacji z profilowania.