Jak bezpiecznie korzystać z narzędzi AI w firmie: obowiązki administratora danych i praktyczne wskazówki RODO

Cel korzystania z narzędzi AI w firmie a perspektywa RODO

Firmy wdrażają narzędzia AI przede wszystkim po to, aby przyspieszyć pracę, obniżyć koszty i poprawić jakość obsługi klienta. Z perspektywy RODO kluczowe jest jednak coś innego: zrozumienie, jakie operacje na danych osobowych faktycznie wykonuje system AI oraz kto ponosi za nie odpowiedzialność. Administrator danych nie odpowiada za „sztuczną inteligencję w ogóle”, ale za konkretne czynności przetwarzania, które z udziałem AI wykonuje w ramach swojej działalności.

Intencją wielu administratorów danych jest „bezpieczne pobawienie się AI”, tymczasem nawet testowe wrzucenie danych klienta do darmowego czatu online może oznaczać naruszenie zasad poufności, brak odpowiedniej podstawy prawnej czy ryzykowny transfer poza EOG. Dlatego pierwszym krokiem powinno być zawsze zmapowanie, czy narzędzie AI ma obsługiwać dane osobowe, jakiego rodzaju oraz w jakim celu.

RODO nie zakazuje korzystania z narzędzi AI w firmie. Stawia jednak szereg warunków: od przejrzystości wobec osób, których dane dotyczą, po adekwatne środki bezpieczeństwa i umowy powierzenia z dostawcami technologii. Administrator, który rozumie swój „obszar odpowiedzialności”, jest w stanie wdrożyć AI w sposób, który realnie wspiera biznes, a jednocześnie nie generuje stałego ryzyka naruszenia przepisów.

Czym jest „narzędzie AI” z perspektywy RODO

System AI, model językowy, narzędzie SaaS – krótkie uporządkowanie pojęć

W dyskusjach o RODO i sztucznej inteligencji pojawia się wiele terminów technicznych. Z punktu widzenia administratora danych istotne jest, aby wiedzieć, z czym ma do czynienia, nawet jeśli nie wchodzi w głębokie szczegóły techniczne. System AI to zazwyczaj zestaw algorytmów i usług, które wykonują określone zadania, takie jak analiza tekstu, przewidywanie zachowań, generowanie treści czy klasyfikacja dokumentów. Może to być zarówno narzędzie dostępne przez przeglądarkę, jak i moduł wbudowany w istniejący system CRM czy ERP.

Model językowy (np. duży model językowy – LLM) to szczególny typ systemu AI, który przetwarza tekst: odpowiada na pytania, streszcza, tłumaczy, generuje treści czy podpowiada rozwiązania. Z kolei narzędzie SaaS z AI to gotowa aplikacja oferowana w chmurze, która wykorzystuje AI „pod spodem” – przykładowo platforma analityczna, chatbot obsługujący klientów czy system do analizy CV.

Z perspektywy RODO kluczowe jest nie tyle to, czy dostawca używa „AI”, „machine learning” czy „algorytmów predykcyjnych”, ale to, czy w ramach tego narzędzia przetwarza dane osobowe, w jakim zakresie i czy robi to jako podmiot przetwarzający, czy raczej jako niezależny administrator.

Kiedy korzystanie z AI oznacza przetwarzanie danych osobowych

Przetwarzanie danych osobowych w rozumieniu RODO pojawia się w momencie, gdy narzędzie AI otrzymuje, analizuje czy generuje dane, które pozwalają zidentyfikować konkretną osobę lub sprawiają, że osoba staje się identyfikowalna. Nie musi to być imię i nazwisko – wystarczy kombinacja informacji (np. stanowisko, firma, szczegółowy opis sytuacji zawodowej), która umożliwi rozpoznanie konkretnej osoby.

Przykładowe sytuacje, w których korzystanie z narzędzi AI jest jednocześnie przetwarzaniem danych osobowych:

• dział obsługi klienta wkleja do czatu AI treści maili z reklamacjami, zawierające dane kontaktowe klientów i szczegóły zamówień, żeby wygenerować propozycję odpowiedzi;
• zespół prawny przesyła do narzędzia AI projekty umów, które obejmują dane stron, przedstawicieli czy świadków, w celu ich redakcji lub skrócenia;
• HR wykorzystuje moduł AI w systemie rekrutacyjnym do wstępnej selekcji CV, które zawierają historię zatrudnienia, dane kontaktowe i informacje o kwalifikacjach;
• marketing używa narzędzia analitycznego z AI do segmentacji klientów na podstawie danych zakupowych i zachowań w aplikacji.

Jeżeli do systemu AI trafiają wyłącznie dane techniczne, całkowicie zanonimizowane lub sztucznie wygenerowane (np. fikcyjne rekordy do testów), wówczas mówimy o przetwarzaniu danych nieosobowych i RODO jako takie nie ma zastosowania. W praktyce jednak bardzo często granica nie jest oczywista i wymaga świadomej oceny przed wdrożeniem.

Dane osobowe vs dane nieosobowe – znaczenie dla narzędzi AI

W przypadku AI nawet pozornie „anonimowe” dane mogą po analizie i połączeniu z innymi źródłami stać się wystarczające do identyfikacji jednostki. Dlatego anonimizacja w kontekście AI powinna być rozumiana rygorystycznie: dane są anonimowe tylko wtedy, gdy z uzasadnionym nakładem sił nie da się ich przypisać do konkretnej osoby, nawet łącząc je z dodatkowymi bazami. Same inicjały, numer ID pracownika w wewnętrznym systemie czy dokładna data urodzenia zwykle nie wystarczają do uznania danych za prawdziwie anonimowe.

W praktyce dużo częściej mamy do czynienia z pseudonimizacją, czyli zastąpieniem bezpośrednich identyfikatorów (np. imienia i nazwiska) losowym ciągiem, który jednak da się powiązać z konkretną osobą przy użyciu dodatkowego klucza. Dla RODO to nadal przetwarzanie danych osobowych, choć z mniejszym ryzykiem.

Korzystanie z narzędzi AI wyłącznie na danych nieosobowych (np. analiza danych o cenach rynkowych, pogodowych, parametrach technicznych maszyn) jest z punktu widzenia RODO znacznie prostsze. Problem pojawia się, gdy pracownicy – wbrew zasadom – wprowadzają do takiego narzędzia treści z danymi osobowymi, bo „tak im łatwiej”. Dlatego kluczowe są nie tylko procedury, ale i praktyczne szkolenia.

Role RODO w kontekście AI: administrator, procesor, współadministrator

RODO wyróżnia kilka podstawowych ról. Administrator danych decyduje o celach i sposobach przetwarzania danych. Podmiot przetwarzający (procesor) przetwarza dane w imieniu administratora i na jego udokumentowane polecenie. Współadministratorzy wspólnie decydują o celach i sposobach przetwarzania.

Dostawca narzędzia AI może wejść w każdą z tych ról, w zależności od modelu usługi:

• typowy dostawca SaaS, który udostępnia firmie narzędzie AI do obsługi własnych klientów, zwykle działa jako podmiot przetwarzający – przetwarza dane w imieniu administratora;
• dostawca „ogólnego” czatu AI dla szerokiego rynku, który samodzielnie ustala cele (np. trenowanie modeli na danych użytkowników) i sposoby przetwarzania, może być odrębnym administratorem danych;
• w projektach wspólnych (np. platforma współtworzona przez kilka firm) dostawca może być współadministratorem – gdy razem z klientem ustalają cele i zakres wykorzystania danych.

Obowiązki administratora danych przy korzystaniu z narzędzi AI – mapa odpowiedzialności

Odpowiedzialny wybór narzędzia i dostawcy AI

Administrator danych, który decyduje się na wdrożenie narzędzia AI, ponosi odpowiedzialność za wybór takiego rozwiązania, które umożliwia zgodne z prawem przetwarzanie danych. Obejmuje to w szczególności due diligence dostawcy: sprawdzenie, gdzie fizycznie przetwarzane są dane, jak dostawca zapewnia bezpieczeństwo, jakie ma procedury reagowania na incydenty oraz w jaki sposób wykorzystuje dane klientów (np. czy używa ich do trenowania własnych modeli).

W praktyce warto, aby administrator – zwykle z pomocą działu prawnego i IT – przygotował krótką, ale konkretną listę kryteriów oceny dostawców AI. Mogą to być m.in.: zgodność z RODO (w tym regulacje dotyczące transferu danych), jasne zasady retencji danych, możliwości konfiguracji poziomu prywatności, certyfikaty bezpieczeństwa czy przejrzystość dokumentacji technicznej.

Jeżeli narzędzie AI ma wspierać przetwarzanie danych wrażliwych (np. zdrowotnych, dotyczących wyroków skazujących czy związków zawodowych), poziom wymaganego due diligence powinien być wyraźnie wyższy. Niekiedy bardziej zasadne będzie wdrożenie rozwiązania on-premise lub w dedykowanej instancji chmurowej niż korzystanie z ogólnego serwisu publicznego.

Udokumentowanie decyzji o wdrożeniu AI i zasada rozliczalności

Zasada rozliczalności wymaga, aby administrator był w stanie wykazać, że spełnił wymogi RODO. W kontekście AI istotne są nie tylko same środki techniczne i organizacyjne, ale także dokumentacja procesu podejmowania decyzji. Jeżeli pojawi się pytanie ze strony organu nadzorczego, dobrze jest mieć nie tylko opis narzędzia AI, ale również notatki z analizy ryzyka, wyniki DPIA (o ile była przeprowadzana), uzasadnienie wyboru podstawy prawnej czy raport z testów pilotażowych.

W praktyce wystarczy często spójny zestaw dokumentów, takich jak:

• protokół z posiedzenia zespołu projektowego ds. AI oraz krótkie notatki z analizy opcji rynkowych,
• opis celu przetwarzania i kategorii danych w rejestrze czynności przetwarzania,
• wynik oceny ryzyka lub DPIA, wraz z listą przyjętych środków zaradczych,
• kopie podpisanych umów powierzenia z dostawcami AI,
• polityka korzystania z narzędzi AI przez pracowników.

Taka dokumentacja nie musi być rozbudowana, ale powinna być aktualna, spójna i możliwa do okazania. W razie incydentu lub skargi osoby, której dane dotyczą, administrator może wykazać, że nie działał w sposób lekkomyślny, tylko przeprowadził rozsądny proces decyzyjny.

W praktyce, dla komercyjnych narzędzi biznesowych AI, dostawca bywa przede wszystkim podmiotem przetwarzającym. Administrator powinien jednak krytycznie weryfikować dokumentację dostawcy – nie tylko to, jak nazywa on swoją rolę, ale jakie ma realne uprawnienia do używania danych. Tu przydaje się wiedza o Nowe zasady przetwarzania danych osobowych po wdrożeniu RODO, bo wiele mechanizmów z chmury i klasycznych usług IT ma swoje odpowiedniki w narzędziach AI.

Główne obszary obowiązków administratora przy AI

Obowiązki administratora danych w związku z wykorzystaniem AI można, co do zasady, podzielić na kilka głównych bloków. Każdy z nich wymaga świadomego podejścia i decyzji:

• Podstawa prawna i cel przetwarzania – określenie, po co dokładnie dane są przetwarzane przy użyciu AI i na jakiej podstawie (umowa, przepis prawa, uzasadniony interes, zgoda).
• Minimalizacja danych – ograniczenie zakresu danych wysyłanych do narzędzia AI do tych, które są niezbędne dla osiągnięcia celu.
• Bezpieczeństwo – dobór adekwatnych środków technicznych i organizacyjnych, w tym ocena ryzyk specyficznych dla AI (halucynacje, profilowanie, błędne decyzje systemu).
• Transparentność i informowanie – przekazanie osobom, których dane dotyczą, czytelnych informacji o tym, że ich dane trafiają do systemu AI i jakie mogą być tego konsekwencje.
• Realizacja praw jednostki – umożliwienie korzystania z praw przewidzianych w RODO, również w sytuacji, gdy część procesu przetwarzania realizowana jest przez narzędzie AI.

Do tego dochodzą obowiązki związane z ewentualnymi incydentami (np. wyciekiem danych z narzędzia AI) oraz zarządzaniem cyklem życia danych: od ich pozyskania, przez analizę, po usunięcie lub zanonimizowanie.

Podstawa prawna i cele przetwarzania przy użyciu AI

Precyzyjne opisanie celu przetwarzania z udziałem AI

W wielu firmach AI ma pełnić rolę narzędzia „wspomagającego” – np. usprawniającego obsługę klienta czy pracę działu prawnego. Z punktu widzenia RODO ma to jednak istotne konsekwencje: cel przetwarzania nie brzmi „korzystanie z narzędzia AI”, lecz odpowiada realnej operacji biznesowej. Przykładowo: „obsługa reklamacji klientów”, „przygotowywanie odpowiedzi na zapytania klientów”, „wewnętrzna analiza jakości usług na podstawie zgłoszeń” czy „wsparcie procesów rekrutacyjnych”.

AI jest w takim układzie tylko sposobem realizacji tego celu. W rejestrze czynności przetwarzania można dodać informację, że część operacji jest wykonywana przy pomocy narzędzia AI, ale nie ma potrzeby tworzenia osobnej czynności, jeśli cel pozostaje ten sam. Problem pojawia się dopiero wtedy, gdy firma chce wykorzystać dane np. klientów w nowym celu, jakim jest trenowanie własnego modelu AI lub udostępnianie ich dostawcy do treningu.

W takiej sytuacji należy odrębnie ocenić zgodność nowego celu z pierwotnym oraz dobrać właściwą podstawę prawną. Często okaże się, że wykorzystanie danych do uczenia modeli wymaga dodatkowej zgody lub przynajmniej szczegółowego zbadania zgodności celów.

Dobór podstawy prawnej: kiedy umowa, kiedy uzasadniony interes, kiedy zgoda

Przy przetwarzaniu danych z użyciem narzędzi AI najczęściej w praktyce pojawiają się trzy podstawy prawne: realizacja umowy, obowiązek prawny i uzasadniony interes administratora. Zgoda osoby, której dane dotyczą, bywa użyteczna, ale nie zawsze jest praktyczna czy konieczna.

Można przyjąć pewne schematy:

• Realizacja umowy – gdy AI wspiera bezpośrednio wykonanie umowy z klientem, np. automatyczna obsługa reklamacji, odpowiedzi na zapytania o status zamówienia, personalizacja treści w ramach płatnej usługi.
• Uzasadniony interes administratora – gdy AI służy poprawie jakości obsługi, bezpieczeństwu systemów, analizie wewnętrznej czy optymalizacji procesów, a wpływ na prywatność osób jest ograniczony i podlega ocenie równowagi interesów.
• Zgoda – gdy przetwarzanie z użyciem AI wykracza poza to, czego osoba racjonalnie oczekuje w danej relacji, wiąże się z istotnym ryzykiem profilowania lub ma charakter wyraźnie dodatkowy (np. wykorzystanie treści rozmów do trenowania modelu marketingowego).

W praktyce kluczowe jest rozróżnienie sytuacji, w których bez wykorzystania AI świadczenie usługi byłoby realnie niemożliwe lub znacząco utrudnione (co przemawia za umową lub obowiązkiem prawnym), od takich, w których AI jest jedynie usprawnieniem wewnętrznym. W tych drugich przypadkach częściej stosuje się uzasadniony interes, ale pod warunkiem przeprowadzenia testu równowagi i odpowiedniego poinformowania osób.

Jeżeli dostawca narzędzia AI chciałby wykorzystywać dane klientów administratora do własnych celów, w szczególności do trenowania modeli na potrzeby innych klientów, rośnie znaczenie zgody lub innej odrębnej podstawy po stronie administratora. Trzeba jasno określić, czy taka operacja w ogóle jest potrzebna i proporcjonalna, oraz czy osoba ma realną możliwość odmowy bez negatywnych konsekwencji dla świadczonej usługi.

Wtórne wykorzystanie danych: trening modeli, testy i doskonalenie usług

Dane, które „przechodzą” przez narzędzie AI, często są atrakcyjne z punktu widzenia dalszego treningu modeli, testów czy doskonalenia usług. Z perspektywy RODO jest to jednak co do zasady nowy cel przetwarzania, który trzeba opisać i uzasadnić. Niekiedy będzie możliwe oparcie się na uzasadnionym interesie administratora (np. testy bezpieczeństwa na zanonimizowanych danych), ale w innych przypadkach konieczne będzie uzyskanie zgody lub w ogóle rezygnacja z takiego wykorzystania.

Rozsądnym podejściem jest segmentacja danych używanych do treningu i testów modeli: maksymalnie korzystanie z danych zanonimizowanych lub silnie pseudonimizowanych oraz ograniczenie zakresu treści wrażliwych. Jeśli proces treningu musi obejmować dane osobowe, administrator powinien móc wykazać, że nie mógł osiągnąć tego samego efektu przy użyciu danych w mniejszym stopniu identyfikujących osoby.

W umowach z dostawcami narzędzi AI dobrze jest doprecyzować, czy i w jakim zakresie dane administratora są używane do wtórnych celów dostawcy, jak długo są przechowywane oraz czy istnieje możliwość całkowitego wyłączenia treningu na danych klienta. Zapis typu „dane mogą być wykorzystywane do ulepszania usług” jest zbyt ogólny – potrzebne są warunki brzegowe, np. wymóg anonimizacji, brak łączenia z danymi z innych źródeł czy brak wykorzystania do profilowania użytkowników końcowych.

Transparentność wobec osób, których dane dotyczą

Skoro narzędzie AI jest tylko jednym z elementów procesu przetwarzania, informacje kierowane do osób powinny obejmować ten element, ale nie mogą się do niego ograniczać. W praktyce oznacza to aktualizację klauzul informacyjnych tak, aby wynikało z nich, że część analizy danych lub komunikacji może być realizowana z użyciem systemów AI, często przy zaangażowaniu zewnętrznego dostawcy.

Informacja powinna obejmować przede wszystkim: cele wykorzystania AI, kategorię danych przetwarzanych w tym trybie, ewentualne transfery poza EOG, okres przechowywania oraz – jeśli ma to miejsce – istnienie zautomatyzowanego podejmowania decyzji, w tym profilowania. W przypadku zastosowań o większym ciężarze gatunkowym (np. rekrutacja z wykorzystaniem algorytmów oceniających kandydatów) nie wystarczy ogólny zapis w polityce prywatności; potrzebne jest wyraźne zakomunikowanie tego faktu w punkcie styku z osobą.

Dobrym rozwiązaniem są także krótkie komunikaty kontekstowe, pojawiające się bezpośrednio w interfejsie: np. informacja, że czat obsługiwany jest częściowo przez system AI, a odpowiedzi mogą być weryfikowane przez pracownika. Takie drobne elementy zwiększają zaufanie i zmniejszają ryzyko zarzutu, że osoba nie była świadoma charakteru interakcji.

W niektórych projektach przydają się również bardziej rozbudowane warstwy informacji, np. FAQ dla kandydatów opisujące sposób działania narzędzia rekrutacyjnego czy osobna podstrona wyjaśniająca logikę scoringu kredytowego wspieranego przez algorytmy. Tego typu materiały nie zastępują klauzul informacyjnych, ale dobrze uzupełniają obowiązek przejrzystości i ułatwiają obsługę zapytań osób korzystających z prawa dostępu.

Transparentność nie powinna kończyć się na etapie pierwszej informacji. Jeżeli zakres wykorzystania AI w organizacji istotnie się zmienia – np. system, który dotąd służył wyłącznie do analizy zgłoszeń serwisowych, zaczyna być wykorzystywany również do oceny wiarygodności klientów – potrzebna jest aktualizacja komunikatów i, w razie potrzeby, ponowne spełnienie obowiązku informacyjnego. W przeciwnym razie administrator ryzykuje zarzut, że osoby nie miały realnej możliwości zrozumienia nowych operacji na ich danych.

Wrażliwe zastosowania AI (rekrutacja, ocena pracowników, przyznawanie świadczeń, analiza zachowań klientów pod kątem nadużyć) wymagają dodatkowo wyjaśnienia, jaką rolę odgrywa człowiek w podejmowaniu decyzji. Trzeba jasno wskazać, czy decyzja jest podejmowana automatycznie, czy jedynie wspierana przez system, oraz jak można zakwestionować jej wynik. To istotne nie tylko z perspektywy art. 22 RODO, lecz także z punktu widzenia zaufania pracowników i klientów.

Dobre praktyki w obszarze AI zwykle łączą trzy elementy: rozsądny dobór podstawy prawnej i celu przetwarzania, kontrolę nad dostawcami narzędzi oraz przejrzystą komunikację z osobami, których dane dotyczą. Jeżeli administrator z wyprzedzeniem porządkuje te obszary, wdrożenie nowych rozwiązań AI staje się zarówno prostsze, jak i bezpieczniejsze – a dyskusja o innowacji nie musi stać w sprzeczności z wymaganiami RODO.

Zasady przetwarzania danych a specyfika AI: minimalizacja, ograniczenie celu, retencja

Klasyczne zasady z art. 5 RODO – w szczególności minimalizacja danych, ograniczenie celu i ograniczenie przechowywania – przy projektach AI wymagają bardziej świadomego podejścia. W narzędziach opartych na dużych modelach językowych czy systemach uczenia maszynowego naturalną pokusą jest „wrzucić jak najwięcej”, bo im więcej danych, tym teoretycznie lepszy efekt. Z perspektywy administratora taka logika jest jednak ryzykowna i wprost sprzeczna z zasadą minimalizacji.

Minimalizacja danych: co naprawdę musi trafić do narzędzia AI

Minimalizacja w kontekście AI to nie tylko „mniej rekordów”, ale też mniej pól w każdym rekordzie oraz kontrola, jakie informacje trafiają do dostawcy zewnętrznego. Dobrze zaprojektowany proces zwykle zakłada kilka warstw redukcji danych.

Najpierw warto ustalić, jaką dokładnie odpowiedź lub efekt ma zapewnić narzędzie AI. Dopiero na tej podstawie dobiera się zestaw danych wejściowych. W praktyce przydaje się podział na:

• dane niezbędne – bez nich system nie zadziała albo wynik będzie bez znaczenia;
• dane użyteczne – poprawiają jakość wyniku, ale nie są kluczowe;
• dane zbędne – nie wpływają na efekt, a jedynie zwiększają ryzyko.

Najpierw do narzędzia powinny trafiać dane z pierwszej kategorii, a rozszerzanie zakresu przetwarzania wymaga konkretnych argumentów biznesowych i oceny ryzyka. Nierzadko okazuje się, że system analizujący treść reklamacji w ogóle nie potrzebuje imienia i nazwiska, a do generowania odpowiedzi wystarczy streszczenie problemu i informacja o typie usługi.

Administrator może zastosować kilka praktycznych technik ograniczania danych:

• pseudonimizację – zastąpienie identyfikatorów (np. numeru klienta) losowym identyfikatorem technicznym;
• maskowanie niektórych pól (np. tylko część numeru telefonu czy PESEL-u, jeśli w ogóle jest potrzebny);
• pre‑processing po stronie własnych systemów – automatyczne wycinanie fragmentów wiadomości zawierających oczywiste dane wrażliwe, zanim trafią do narzędzia AI;
• „okna kontekstu” – przekazywanie do modelu tylko niezbędnego wycinka historii rozmowy, a nie całości całorocznej korespondencji.

W organizacjach, w których pracownicy mają swobodny dostęp do narzędzi generatywnych, konieczne jest dookreślenie zasad w regulaminach i politykach bezpieczeństwa: czego nie wolno wprowadzać do narzędzi AI (np. haseł, danych wrażliwych, dokumentacji medycznej, poufnych umów). Same szkolenia „miękkie” zwykle nie wystarczą; potrzebne są także ograniczenia techniczne, choćby blokada wklejania danych z konkretnego systemu do aplikacji webowej dostawcy.

Ograniczenie celu: unikanie „przetwarzania przy okazji”

Systemy AI szczególnie sprzyjają tzw. „przetwarzaniu przy okazji”. Dane raz wprowadzone do narzędzia łatwo potem wykorzystywać do innych analiz, które administrator uznaje za „interesujące” – np. dodatkowej segmentacji klientów czy oceny efektywności pracowników. Z perspektywy RODO jest to jednak odrębny cel, który należy opisać i ocenić.

Pomocne bywa rozróżnienie między:

• celem podstawowym – np. udzielenie odpowiedzi klientowi, analiza zgłoszenia serwisowego, weryfikacja tożsamości;
• celami wtórnymi powiązanymi – np. statystyczna analiza typów zgłoszeń, monitoring jakości obsługi, konfiguracja modeli pod kątem często występujących problemów;
• celami dalszymi – np. profilowanie klientów na potrzeby marketingu, scoring ryzyka, ocenianie efektywności poszczególnych konsultantów.

Między celem podstawowym a powiązanymi zwykle można uzasadnić „zgodność celów” w rozumieniu RODO, ale cele dalsze często wymagają dodatkowej podstawy prawnej lub przynajmniej szczegółowej analizy testu zgodności (art. 6 ust. 4 RODO). Z poziomu praktyki dobrze sprawdza się zasada, że każdy nowy pomysł na użycie danych przetworzonych przez AI przechodzi krótką ocenę prawną, zanim zostanie wdrożony przez dział IT czy biznes.

Mechanizmy ograniczenia celu mogą mieć także wymiar techniczny. W systemach, które agregują dane z wielu źródeł (CRM, system helpdesk, monitoring aktywności), administrator powinien zadbać, aby poszczególne moduły miały jasno wyznaczone granice wykorzystania danych. Przykład: treść rozmowy z czatu używana jest do ulepszania bota obsługującego pytania produktowe, ale nie jest przekazywana do modułu oceniającego ryzyko wypowiedzenia umowy, o ile nie ma ku temu odrębnej podstawy prawnej i informacji w klauzuli.

Retencja danych i „śladów” w systemach AI

W przypadku narzędzi AI retencja obejmuje co najmniej trzy poziomy:

• dane źródłowe – np. treści e‑maili, zgłoszeń, nagrania rozmów;
• dane pośrednie – wyniki analizy, etykiety, kategorie, tagi nadawane przez system;
• artefakty modelu – wagi modelu, dane treningowe, logi techniczne.

Zasada ograniczenia przechowywania dotyczy każdego z tych poziomów, choć w różnym stopniu. Dane źródłowe zwykle podlegają standardowym okresom retencji określonym w polityce archiwizacji. Dane pośrednie – np. przyporządkowane etykiety „klient wysokiego ryzyka rezygnacji” – często „przeżywają” dane pierwotne, a to rodzi pytanie, czy administrator ma dla nich samodzielną podstawę prawną i odrębny okres przechowywania.

Przy artefaktach modelu pojawia się dodatkowy problem: trudność w „odczepieniu” danych konkretnej osoby od wytrenowanego modelu. Jeżeli administrator zakłada możliwą konieczność usuwania danych z procesów treningowych (np. w razie wycofania zgody), musi z góry zdecydować, czy:

• zachowuje dane treningowe w formie odtwarzalnej (np. zbiory uczące, wersjonowanie modeli) i w razie potrzeby trenuje model ponownie bez danego rekordu,
• czy też proces treningu jest projektowany wyłącznie na danych zanonimizowanych, tak aby obowiązek usunięcia danych dotyczył jedynie źródłowych baz, a nie samego modelu.

Warto doprecyzować w dokumentacji wewnętrznej, jak długo przechowywane są logi interakcji z narzędziem AI, kto ma do nich dostęp i w jakim celu są wykorzystywane. Dostawcy narzędzi SaaS często domyślnie zachowują logi przez okres „technicznie potrzebny do utrzymania usługi”, co jest określeniem bardzo pojemnym. Administrator powinien dążyć do wpisania konkretnych okresów w umowie (np. 30, 90, 180 dni) oraz rozróżnienia logów zawierających dane osobowe od logów czysto technicznych.

W tym miejscu przyda się jeszcze jeden praktyczny punkt odniesienia: Incydent w chmurze: jakie pytania zadać dostawcy i co zapisać w raporcie.

Ocena ryzyka i DPIA dla narzędzi AI – kiedy i jak ją przeprowadzić

Narzędzia AI rzadko są „neutralnym” dodatkiem do istniejących procesów. Zwykle zmieniają skalę, sposób oraz konsekwencje przetwarzania danych. Dlatego plany wdrożenia takich rozwiązań powinny być automatycznie wiązane z analizą ryzyka, a w wielu przypadkach także z oceną skutków dla ochrony danych (DPIA).

Kiedy DPIA dla AI jest konieczna, a kiedy wystarczy ogólna analiza ryzyka

RODO i wytyczne organów nadzorczych nie odnoszą się wprost do „AI” jako takiej, ale do charakteru i kontekstu przetwarzania. W praktyce DPIA będzie niemal zawsze potrzebna, gdy narzędzie AI:

• prowadzi do zautomatyzowanego podejmowania decyzji wywołujących skutki prawne lub w podobny sposób istotnie wpływających na osobę (np. odmowa kredytu, decyzja o zatrudnieniu);
• służy do systematycznej oceny lub profilowania na dużą skalę (np. scoring zachowań klientów, predykcja ryzyka nadużyć);
• przetwarza na dużą skalę szczególne kategorie danych (np. dane zdrowotne, poglądy polityczne, dane biometryczne);
• jest wykorzystywane w obszarach szczególnie wrażliwych (HR, ubezpieczenia, sektor finansowy, opieka zdrowotna, edukacja).

Jeżeli narzędzie AI ma charakter wyłącznie wspierający, nie decyduje samodzielnie i nie obejmuje danych szczególnych ani szerokiego profilowania, często wystarczy ogólna analiza ryzyka i udokumentowanie, dlaczego administrator uznał, że formalne DPIA nie jest wymagane. Uzasadnienie takiej decyzji dobrze jest zachować w aktach projektu – to ułatwia obronę stanowiska przed organem nadzorczym.

Elementy DPIA „szyte” pod AI

Standardowy schemat DPIA zwykle obejmuje opis operacji, ocenę niezbędności i proporcjonalności, analizę ryzyk oraz środki zaradcze. Projekty z AI wymagają jednak kilku dodatkowych akcentów. W opisie operacji warto wyodrębnić:

• rodzaj modelu (model własny, model dostawcy, model open‑source utrzymywany lokalnie);
• źródła danych (systemy wewnętrzne, dane pozyskiwane od osób, dane kupowane, dane publiczne);
• rodzaj interakcji (batch processing, analiza offline, chatbot, asystent dla pracowników).

W części dotyczącej niezbędności i proporcjonalności trzeba wyjaśnić, dlaczego wybrano właśnie AI, a nie prostszy, bardziej przewidywalny mechanizm (np. reguły biznesowe). Nie chodzi o techniczną szczegółowość, lecz o pokazanie, że korzystanie z AI jest przemyślane i wynika z konkretnych potrzeb, a nie wyłącznie z mody na nowe technologie.

Analiza ryzyk w kontekście AI powinna obejmować m.in.:

• ryzyko błędnych lub stronniczych decyzji wynikających z jakości danych uczących lub konstrukcji modelu;
• ryzyko nadmiernego ujawnienia danych do dostawcy zewnętrznego lub do innych użytkowników (np. w scenariuszu multi‑tenant);
• ryzyko braku możliwości wyjaśnienia działania systemu osobom, których dane dotyczą;
• ryzyko „dryfu” modelu – pogorszenia jakości wyników w czasie, które może niezauważenie wpływać na osoby;
• ryzyko wtórnego wykorzystania danych w ramach organizacji (tzw. function creep).

Środki zaradcze, które zwykle pojawiają się w DPIA dla AI, to m.in.:

• wdrożenie zasady human‑in‑the‑loop przy decyzjach o istotnych skutkach, wraz z opisem kompetencji osób weryfikujących wynik;
• testy jakości i biasu przed wdrożeniem i cyklicznie po wdrożeniu, na reprezentatywnych próbach danych;
• ograniczenie zakresu i jakości danych wejściowych (np. kategoryczne wyłączenie pól wrażliwych z treningu i inferencji, jeśli nie są absolutnie konieczne);
• monitoring dzienników i mechanizmy wykrywania nietypowych wzorców (np. nagły wzrost liczby odrzuconych wniosków w określonej grupie);
• jasno opisane procedury obsługi żądań osób (dostęp, sprzeciw, ograniczenie, usunięcie) w kontekście AI.

Użyteczne jest włączenie do zespołu DPIA nie tylko prawnika i inspektora ochrony danych, lecz także przedstawicieli IT, bezpieczeństwa, biznesu i – jeśli to możliwe – osoby odpowiedzialne za etykę w AI lub compliance. Tylko wtedy opis ryzyk nie będzie czysto formalny, a zaproponowane środki faktycznie wpiszą się w procesy organizacji.

Aktualizacja DPIA po zmianach w systemie AI

Systemy AI rzadko pozostają niezmienne. Zmieniają się wersje modeli, parametry, zakres danych, integracje z innymi systemami. Administrator powinien przyjąć konkretne kryteria, kiedy zmiana uznawana jest za „istotną” i uruchamia przegląd DPIA. Mogą to być na przykład:

• rozszerzenie zakresu danych (np. dołączenie danych geolokalizacyjnych lub finansowych);
• zmiana dostawcy modelu lub istotna zmiana architektury (przejście z modelu lokalnego na usługę chmurową);
• włączenie nowych grup osób (np. rozszerzenie systemu z pracowników na kandydatów, z klientów indywidualnych na przedsiębiorców jednoosobowych);
• dodanie nowej funkcji decyzyjnej, która może wywoływać skutki prawne lub podobnie istotne.

Przegląd DPIA nie musi oznaczać pisania dokumentu od zera. Często wystarcza aneks, który opisze zmiany, ponownie oceni ryzyka i sprawdzi, czy wdrożone wcześniej środki zaradcze nadal są adekwatne. Kluczowe jest, aby ta praktyka była systematyczna, a nie uzależniona od indywidualnej wrażliwości kierownika projektu.

Wybór dostawcy AI i umowy powierzenia przetwarzania

Przy większości biznesowych zastosowań AI administrator korzysta z rozwiązań dostarczanych przez podmioty zewnętrzne – od dużych platform chmurowych po wyspecjalizowane startupy. Z perspektywy RODO kluczowe jest ustalenie, czy dostawca działa jako podmiot przetwarzający (processor), współadministrator, czy raczej jako <strongsamodzielny administrator, który udostępnia określoną usługę. To rozróżnienie przesądza o treści umów, podziale obowiązków wobec osób, których dane dotyczą, oraz o tym, jakie ryzyka pozostają po stronie firmy korzystającej z narzędzia.

Jeżeli narzędzie AI przetwarza dane wyłącznie na instrukcje klienta, w ramach jego celów i bez samodzielnego decydowania o dalszym wykorzystaniu (np. trenowanie własnych modeli na danych klienta), dostawca zwykle będzie podmiotem przetwarzającym. Uzasadnione jest wtedy zawarcie umowy powierzenia przetwarzania spełniającej wymogi art. 28 RODO. Gdy jednak dostawca używa danych klientów do rozwoju własnej platformy, łączy dane wielu odbiorców lub samodzielnie określa istotne elementy celu i sposobu przetwarzania, może dojść do współadministracji. W takiej sytuacji sama umowa powierzenia nie wystarczy – potrzebne jest ustalenie, kto i w jakim zakresie odpowiada za realizację obowiązków informacyjnych, obsługę żądań oraz zapewnienie odpowiednich środków technicznych i organizacyjnych.

Przed podpisaniem kontraktu dobrze jest przeprowadzić prostą, ale uporządkowaną ocenę dostawcy. Obejmuje ona nie tylko deklaracje marketingowe, lecz także realne mechanizmy bezpieczeństwa, zgodności i kontroli po stronie partnera. W praktyce przydatne są m.in.:

• informacje o lokalizacji przetwarzania (UE, EOG, państwa trzecie) wraz z podstawą transferu danych,
• opis środków bezpieczeństwa (szyfrowanie, pseudonimizacja, zarządzanie dostępem, dzienniki zdarzeń),
• polityka wykorzystania danych klienta do treningu modeli oraz możliwość wyłączenia się z takiego treningu,
• zakres podpowierzenia (lista podwykonawców, zasady ich dodawania, mechanizm sprzeciwu),
• mechanizmy wsparcia przy incydentach, audytach oraz przy realizacji praw osób, których dane dotyczą.

W dużych organizacjach ocena dostawcy bywa elementem szerszego procesu due diligence (compliance, bezpieczeństwo, finanse). Dobrze, jeżeli kryteria „AI/RODO” są tam dopisane wprost – np. jako osobna sekcja w kwestionariuszu dla dostawców technologicznych. Pozwala to uniknąć sytuacji, w której o ryzyku transferu danych poza EOG lub o trenowaniu modeli na danych pracowników dowiadujemy się dopiero po wdrożeniu.

Umowa z dostawcą AI powinna w możliwie precyzyjny sposób odwzorowywać ustalony model odpowiedzialności. W klasycznej umowie powierzenia, poza elementami wymaganymi przez art. 28 RODO, warto doprecyzować m.in.:

• czy dostawca może wykorzystywać dane klienta do trenowania lub doskonalenia modeli, a jeśli tak – na jakich zasadach i z jakimi ograniczeniami (np. wyłącznie na danych zanonimizowanych, wyłącznie w środowisku odseparowanym od innych klientów),
• szczegółowe zasady retencji danych i logów – w tym okresy przechowywania, kategorie danych, tryb ich usuwania lub zwrotu po zakończeniu współpracy,
• tryb zgłaszania incydentów bezpieczeństwa (czas reakcji, zakres przekazywanych informacji, dalsze wsparcie),
• możliwość przeprowadzenia audyty lub inspekcji – bez iluzorycznych zapisów, których i tak nie da się wykonać w modelu chmurowym, lecz z realnym mechanizmem uzyskania dowodów zgodności (raporty z audytów, certyfikaty, wyniki testów bezpieczeństwa),
• zakres i formę współpracy przy realizacji obowiązków RODO – w szczególności sposób obsługi żądań osób, których dane dotyczą, wsparcie przy ocenie skutków dla ochrony danych oraz przy konsultacjach z organem nadzorczym.

W modelu współadministracji sama etykieta „joint controller” w nagłówku umowy nie wystarcza. Potrzebne jest praktyczne rozpisanie, kto odpowiada za które elementy przetwarzania: treść klauzul informacyjnych, podstawy prawne, obsługę wniosków, bezpieczeństwo techniczne, a także komunikację w razie naruszeń. Taki podział obowiązków powinien być możliwy do wyjaśnienia osobie, której dane dotyczą – jeżeli nawet prawnik ma trudność z jego odczytaniem, użytkownik końcowy nie będzie miał szans zrozumieć, do kogo może się zwrócić z żądaniem.

Przy usługach AI dostarczanych spoza EOG kluczowy jest również aspekt transferu danych do państw trzecich. Oprócz standardowych klauzul umownych należy zbadać faktyczny model działania dostawcy: gdzie znajdują się serwery, jakie podmioty mają dostęp administracyjny, czy dane są szyfrowane w spoczynku i w tranzycie oraz kto kontroluje klucze. W niektórych przypadkach konieczna będzie ocena TIA (transfer impact assessment) oraz zastosowanie dodatkowych środków – np. mocnej pseudonimizacji po stronie klienta lub architektury, w której dane osobowe w ogóle nie opuszczają środowiska administratora.

Kiedy narzędzie AI jest mocno zintegrowane z kluczowymi procesami (rekrutacja, scoring klientów, obsługa reklamacji), kontrakt z dostawcą przestaje być „zwykłą” umową IT. Warto wtedy wprowadzić mechanizmy umożliwiające kontrolowane wyjście z usługi: obowiązek wsparcia przy migracji danych, zapewnienie ich czytelnego formatu, a także gwarancje usunięcia kopii, backupów i modeli wytrenowanych wyłącznie na danych klienta, jeśli takie treningi były dopuszczone. Brak takich postanowień może w praktyce zablokować zmianę dostawcy, nawet jeśli analiza ryzyka lub wyniki audytu na to wskazują.

Bezpieczne i zgodne z RODO korzystanie z narzędzi AI wymaga połączenia kilku perspektyw: technicznej, prawnej, biznesowej i organizacyjnej. Administrator, który jasno określi cele, podstawy prawne, role podmiotów, a następnie przełoży je na konkretne procedury i umowy, zyskuje nie tylko większe bezpieczeństwo regulacyjne, lecz także lepszą kontrolę nad tym, jak AI realnie wpływa na pracowników, klientów i całą organizację.

Szkolenia, procedury wewnętrzne i kultura korzystania z AI

Nawet najlepiej skonstruowane umowy i DPIA stracą znaczenie, jeżeli użytkownicy w firmie będą wprowadzać do narzędzi AI dane „po swojemu”. Potrzebny jest jasny zestaw reguł organizacyjnych, które przekładają wymagania RODO na codzienne decyzje pracowników.

Polityka korzystania z narzędzi AI

Podstawowym dokumentem jest wewnętrzna polityka (lub instrukcja) korzystania z narzędzi AI. Nie musi mieć kilkudziesięciu stron – ważniejsze, aby odpowiadała na praktyczne pytania pracowników:

• jakie narzędzia AI są dopuszczone w organizacji, a jakie są zakazane (np. publiczne chatboty bez umowy, bez kontroli lokalizacji danych);
• jakiego rodzaju danych nie wolno wprowadzać do narzędzi (np. pełne dane klientów, numery dokumentów, wrażliwe informacje o zdrowiu, szczegóły sporów sądowych);
• w jakich przypadkach wymagane jest uprzednie zatwierdzenie przez administratora bezpieczeństwa informacji, inspektora ochrony danych lub prawnika (np. wdrożenia AI w procesach HR, scoringu czy monitoringu pracowników);
• kto odpowiada za konfigurację narzędzi (uprawnienia, logowanie, integracje) i aktualizację ustawień w razie zmian u dostawcy;
• jak zgłaszać incydenty lub nieprawidłowości związane z narzędziami AI (np. pojawienie się danych innej osoby w odpowiedzi modelu).

Polityka powinna być spójna z innymi dokumentami – regulaminem pracy, polityką bezpieczeństwa informacji, zasadami korzystania z chmury. Częsty błąd to tworzenie „wyspy AI”, której zasady stoją w sprzeczności z istniejącą praktyką IT i ochrony danych.

Praktyczne szkolenia dla użytkowników AI

Szkolenia z ochrony danych zwykle koncentrują się na klasycznych systemach: CRM, ERP, poczcie. W przypadku AI przydaje się osobny moduł, nastawiony na konkretne scenariusze użycia. Dobrym punktem wyjścia są krótkie bloki tematyczne:

• Co jest „daną osobową” w kontekście AI – z przykładami, jak łatwo zidentyfikować osobę po pozornie anonimowych opisach;
• Jak bezpiecznie promptować – czyli jak zadawać pytania, by nie przekazywać nadmiarowych informacji o klientach czy współpracownikach;
• Granice automatyzacji decyzji – kiedy AI może służyć jako podpowiedź, a kiedy człowiek musi przejąć odpowiedzialność (szczególnie w HR, sprzedaży, obsłudze sporów);
• Rozpoznawanie incydentów – przykładowo: pojawienie się w odpowiedzi danych, które wyglądają na cudze; nieoczekiwany e‑mail od dostawcy z prośbą o „testowe” dane; nagła zmiana jakości odpowiedzi po aktualizacji usługi.

Dobrze, jeśli szkolenie zawiera choć kilka przykładów z własnej organizacji – np. jak marketing używa generatora treści, jak zespół prawny wspiera się analizą dokumentów, jakie zabezpieczenia wprowadzono w dziale HR. Pracownicy szybciej zapamiętują zasady, gdy widzą, że nie jest to abstrakcyjna teoria, tylko opis ich codziennych zadań.

Role i odpowiedzialności w organizacji

Dla porządku i przewidywalności osób nadzorujących AI przydatne jest określenie konkretnych ról w strukturze firmy. Nie zawsze wymaga to nowych stanowisk – zwykle wystarczy przypisanie funkcji do istniejących ról:

• właściciel biznesowy procesu (np. dyrektor HR, szef sprzedaży) – odpowiada za to, by użycie AI było zgodne z celem biznesowym oraz politykami firmy;
• IT / bezpieczeństwo – odpowiada za integracje, uprawnienia, monitoring bezpieczeństwa, reagowanie na incydenty techniczne;
• DPO lub osoba odpowiedzialna za ochronę danych – doradza przy DPIA, przy ocenie nowych narzędzi, przygotowuje klauzule informacyjne i rekomendacje dot. podstaw prawnych;
• komórka compliance / prawna – ocenia umowy z dostawcami, model odpowiedzialności, kwestie transferu do państw trzecich;
• koordynator AI (często rola rozproszona) – zbiera informacje o projektach AI, dba o aktualizację rejestru narzędzi i wewnętrznych wytycznych.

W małych firmach te role często łączą się w jednej lub dwóch osobach. Nawet wtedy użyteczne jest spisanie, kto pełni którą funkcję, tak aby pracownicy wiedzieli, do kogo zwrócić się z pytaniem o nowe narzędzie czy o ryzyko konkretnego wdrożenia.

Rejestr narzędzi AI i integracja z rejestrem czynności

Ogólne rejestry systemów IT nie zawsze odzwierciedlają specyfikę narzędzi AI. Pomaga utworzenie rejestru narzędzi AI, który co do zasady będzie uzupełnieniem rejestru czynności przetwarzania. Taki rejestr może zawierać m.in.:

• nazwę narzędzia oraz jego dostawcę;
• opis zastosowania biznesowego (np. „wspomaganie redakcji ofert, bez wprowadzania danych klientów”);
• informację, czy wprowadzane są dane osobowe, a jeśli tak – jakich kategorii;
• powiązanie z konkretnymi czynnościami przetwarzania z rejestru RODO (np. „rekrutacja”, „obsługa reklamacji”, „marketing”);
• status DPIA (wymagana / przeprowadzona / nie jest konieczna wraz z krótkim uzasadnieniem);
• model odpowiedzialności (powierzenie, współadministracja, odrębny administrator);
• informację o lokalizacji danych (EOG / państwo trzecie + mechanizm transferu).

Taki rejestr pozwala w miarę szybko odpowiedzieć na pytania zarządu, działu prawnego czy regulatora: gdzie używane są narzędzia AI, na jakich zasadach i z jakim poziomem ryzyka. Ułatwia też planowanie kolejnych wdrożeń w sposób bardziej świadomy, z unikaniem dublowania rozwiązań.

Zarządzanie incydentami i błędami systemów AI

Systemy AI mogą generować nie tylko klasyczne incydenty bezpieczeństwa (wycieki, nieuprawnione dostępy), ale też błędy merytoryczne, które przekładają się na decyzje wobec osób fizycznych. Dobrze zorganizowany administrator danych traktuje oba te obszary jako element jednego procesu zarządzania ryzykiem.

Specyfika incydentów związanych z AI

W przypadku narzędzi AI incydentem może być nie tylko utrata poufności danych, ale także sytuacja, w której:

• model generuje odpowiedzi zawierające dane innych osób, których użytkownik nie powinien widzieć (np. fragmenty cudzych zgłoszeń czy dokumentów);
• na skutek zmiany konfiguracji lub aktualizacji usług dostawcy dochodzi do poszerzenia dostępu do danych wśród użytkowników wewnętrznych;
• narzędzie niewłaściwie łączy dane kilku systemów (np. przypisuje historię klienta do osoby o podobnym imieniu i nazwisku);
• dochodzi do nieautoryzowanego treningu na danych klienta, wbrew zapisom umownym lub wewnętrznym wytycznym.

Część z tych zdarzeń będzie kwalifikowała się jako naruszenie ochrony danych osobowych w rozumieniu RODO, część jako incydent bezpieczeństwa informacji bez konsekwencji RODO, a jeszcze inne jako błąd działania systemu, który wpływa głównie na jakość decyzji biznesowych. W praktyce kluczowe jest, aby procedura zgłaszania incydentów była na tyle szeroka, by pracownicy nie musieli samodzielnie decydować, do której kategorii coś należy.

Procedura reagowania na naruszenia w kontekście AI

Istniejące procedury reagowania na naruszenia można zwykle rozszerzyć o specyficzne elementy dla AI. Przydatne jest wprowadzenie kroków, które wymuszają zebranie informacji istotnych z perspektywy odpowiedzialności administratora:

• jaki rodzaj narzędzia AI brał udział w zdarzeniu (chatbot, system rekomendacyjny, model analizujący dokumenty);
• czy i jakie dane osobowe były przetwarzane – oraz czy były to dane szczególnych kategorii (np. o zdrowiu);
• czy zdarzenie ma związek z dostawcą zewnętrznym (np. błąd po stronie chmury) i jakie obowiązki ma dostawca w zakresie notyfikacji;
• czy odpowiedzi/wnioski wygenerowane przez AI mogły zostać zastosowane wobec osób (podjęto decyzje, wysłano komunikaty, odrzucono wnioski);
• czy konieczna jest zmiana konfiguracji, zawieszenie integracji lub czasowe wyłączenie funkcji AI do czasu wyjaśnienia sprawy.

Na tej podstawie administrator jest w stanie ocenić, czy naruszenie wymaga zgłoszenia organowi nadzorczemu lub poinformowania osób, których dane dotyczą, a także jakie działania naprawcze są potrzebne (np. ponowna ocena wniosków, wysłanie korekt pism do klientów).

Błędy decyzyjne AI a odpowiedzialność administratora

Osobny problem to sytuacje, gdy system AI nie narusza poufności danych, lecz podejmuje lub sugeruje błędne decyzje, które dotykają osób fizycznych: niesłuszne odrzucenie reklamacji, wstrzymanie wypłaty, negatywna ocena kandydata. Z perspektywy RODO takie zdarzenia dotykają kwestii rzetelności, prawidłowości danych i – często – zautomatyzowanego podejmowania decyzji.

Aby ograniczyć te ryzyka, warto wprowadzić m.in.:

• zasadę, że w decyzjach wysokiego ryzyka AI ma charakter wyłącznie wspierający, a ostateczną decyzję podejmuje człowiek;
• mechanizm „drugiej pary oczu” dla sytuacji granicznych – np. gdy system rekomenduje odrzucenie wniosku, ale wskaźniki są blisko progu;
• procedurę weryfikacji decyzji po zgłoszeniu reklamacji przez osobę, której sprawa dotyczy – z wyraźnym zaznaczeniem, że decyzja zostanie ponownie przeanalizowana przez człowieka;
• cykliczny przegląd statystycznych efektów działania systemu (np. odsetek odwołań uwzględnionych po interwencji człowieka), aby wyłapać potencjalne schematy błędów lub dyskryminacji.

W praktyce problem ujawnia się często dopiero wtedy, gdy kilka osób zgłosi podobne zastrzeżenia. System raportowania uwag od użytkowników wewnętrznych (pracowników) i zewnętrznych (klientów, kandydatów) powinien więc pozwalać na szybkie łączenie takich sygnałów w spójny obraz.

Prawa osób, których dane dotyczą, w środowisku AI

Osoby, których dane dotyczą, zazwyczaj nie rozróżniają klasycznych baz danych od systemów AI – oczekują po prostu, że ich prawa będą respektowane. Administrator powinien z wyprzedzeniem zaplanować, jak w środowisku wspieranym przez AI realizować obowiązki wynikające z RODO.

Obowiązek informacyjny przy użyciu narzędzi AI

Jeżeli AI jest wykorzystywana w procesie, który dotyczy osób fizycznych, informacje przekazywane na podstawie art. 13–14 RODO powinny w przejrzysty sposób wskazywać:

• że w danym procesie stosowane są narzędzia lub systemy AI, w jakim celu i w jakim zakresie;
• czy wykorzystanie AI ma wpływ na podejmowanie decyzji wobec osoby (np. wstępna selekcja CV, priorytety obsługi zgłoszeń, scoring klientów);
• czy przetwarzanie obejmuje profilowanie i jakie mogą być tego konsekwencje dla osoby;
• czy dane są przekazywane do państw trzecich, a jeśli tak – z użyciem jakich zabezpieczeń.

Opis nie musi zawierać szczegółów technicznych działania modeli, ale powinien umożliwić osobie zorientowanie się, że jej dane są przetwarzane przy użyciu technologii AI i jakie ma to praktyczne skutki. W projektach o podwyższonym ryzyku (np. rekrutacja, usługi finansowe) rozsądne jest przygotowanie rozszerzonej informacji, dostępnej np. na stronie internetowej, która szerzej opisuje stosowane rozwiązania i mechanizmy ochrony praw jednostki.

Dostęp do danych i „wyjaśnialność” wyników AI

Prawo dostępu z art. 15 RODO zachowuje pełne znaczenie także w środowisku AI. Osoba może więc oczekiwać informacji o:

• kategoriach danych wejściowych, które zostały użyte w jej sprawie (np. dane z formularza, historia transakcji, odpowiedzi z ankiety);
• celach, w jakich wykorzystano AI (np. ocena ryzyka, kategoryzacja zgłoszenia, personalizacja oferty);
• logice podejmowania decyzji, w tym znaczeniu i przewidywanych konsekwencjach takiego przetwarzania.

W praktyce wyzwanie dotyczy przede wszystkim wyjaśnienia działania modelu. Nie chodzi o ujawnienie kodu źródłowego czy parametrów technicznych, lecz o takie opisanie procesu, aby osoba mogła zrozumieć, które rodzaje danych miały znaczenie oraz jakiego typu reguły zostały zastosowane (np. „Analizujemy historię terminowości płatności i zbliżające się terminy spłaty, aby ocenić ryzyko opóźnienia w przyszłości”).

Warto przewidzieć standardowe szablony odpowiedzi dla typowych procesów: rekrutacja, ocena wniosku, personalizacja oferty. Dzięki temu pracownicy odpowiedzialni za obsługę żądań nie będą za każdym razem tworzyć wyjaśnień od zera, co zmniejsza ryzyko niespójnej komunikacji.

Przy bardziej złożonych systemach pomocne bywa wsparcie działu IT lub dostawcy rozwiązania, tak aby przygotowane wyjaśnienia były jednocześnie zrozumiałe dla osób niebędących specjalistami technicznymi i zgodne z rzeczywistym sposobem działania narzędzia. Wrażliwe fragmenty know-how można ująć w formie opisowej, bez ujawniania tajemnicy przedsiębiorstwa, pod warunkiem że osoba otrzyma realną możliwość zorientowania się, na jakiej podstawie została oceniona.

Praktycznym rozwiązaniem jest opracowanie wewnętrznych „kart systemów AI”, w których opisuje się źródła danych, główne funkcje modeli, typy decyzji oraz przykładowe kryteria oceny. Takie karty mogą służyć zarówno jako pomoc dla zespołu obsługującego wnioski osób, jak i jako materiał bazowy do przygotowania komunikatów na zewnątrz. Dzięki temu organizacja unika sytuacji, w której każda odpowiedź jest pisana ad hoc, a pracownicy przedstawiają różne, wzajemnie niespójne wersje działania tego samego procesu.

W przypadku systemów o szczególnie doniosłych skutkach dla osób (np. decyzje kredytowe, weryfikacja tożsamości, przyznawanie świadczeń) uzasadnione jest wprowadzenie rozszerzonej ścieżki obsługi żądań dostępu – z udziałem osoby technicznej i prawnika. Pozwala to zweryfikować, czy opis logiki działania jest wystarczająco precyzyjny, a jednocześnie nie prowadzi do nadmiernego ujawnienia algorytmów czy zabezpieczeń.

Sprostowanie, ograniczenie i sprzeciw wobec przetwarzania z użyciem AI

AI często korzysta z wielu źródeł danych jednocześnie, dlatego realizacja prawa do sprostowania lub ograniczenia przetwarzania wymaga dobrej orientacji w architekturze systemów. Administrator powinien wiedzieć, z których systemów dane są pobierane do modelu, czy i kiedy następuje ich replikacja oraz czy wynik działania AI jest później zapisywany w innych rejestrach (np. w systemie CRM lub w dokumentacji kadrowej).

Jeżeli osoba zgłasza żądanie sprostowania danych (art. 16 RODO), trzeba zwykle rozróżnić trzy poziomy: poprawienie danych źródłowych (np. adresu, statusu zatrudnienia), korektę ewentualnych etykiet nadanych przez AI (np. kategoria klienta, segment ryzyka) oraz wpływ tej zmiany na dalsze decyzje. W praktyce dobrze jest określić, czy i kiedy nastąpi ponowne przeliczenie wyniku przez system AI oraz jak poinformować osobę o skutkach tej operacji.

Prawo do ograniczenia przetwarzania (art. 18 RODO) w środowisku AI bywa trudniejsze technicznie, ale ma szczególne znaczenie, gdy osoba kwestionuje poprawność danych wejściowych lub samego wyniku modelu. Przy projektowaniu systemu warto przewidzieć mechanizmy oznaczania rekordów jako „zablokowane do dalszego trenowania” albo wyłączania ich z określonych procesów decyzyjnych. W przeciwnym razie realizacja żądania może wymagać ręcznych obejść, które są podatne na błąd i trudne do utrzymania w dłuższym okresie.

Sprzeciw wobec przetwarzania (art. 21 RODO), zwłaszcza w przypadku profilowania na potrzeby marketingu lub oceny ryzyka, powinien skutkować nie tylko zablokowaniem dalszego wykorzystania danych w bieżących kampaniach, lecz także uwzględnieniem tej decyzji w konfiguracji modeli. Czasem oznacza to konieczność dodania w systemie flagi, która wyklucza dane osoby z określonych segmentów lub scenariuszy. Jeżeli z obiektywnych powodów nie jest możliwe „wycofanie” danych z już wytrenowanego modelu, administrator powinien umieć wyjaśnić, jakie praktyczne ograniczenia zostały zastosowane (np. brak dalszego profilowania oraz brak wykorzystania danych przy kolejnych iteracjach treningu).

Prawo do niepodlegania decyzji opierającej się wyłącznie na zautomatyzowanym przetwarzaniu

W wielu projektach AI kluczowe jest prawidłowe rozróżnienie sytuacji, w których decyzja ma charakter w pełni zautomatyzowany, od tych, w których człowiek rzeczywiście zachowuje swobodę oceny. Jeżeli narzędzie AI jedynie proponuje rozstrzygnięcie, a pracownik może je zmienić po weryfikacji materiału dowodowego, zwykle nie dochodzi do zastosowania art. 22 RODO. Inaczej jest, gdy algorytm praktycznie „przesądza” o wyniku, a rola człowieka ogranicza się do formalnego zatwierdzenia bez realnej możliwości sprzeciwu.

Jeżeli dochodzi do zautomatyzowanego podejmowania decyzji w rozumieniu art. 22 RODO, osoba powinna mieć zapewnioną co najmniej możliwość:

• uzyskania interwencji człowieka, który realnie przeanalizuje jej sprawę, a nie tylko mechanicznie potwierdzi wynik systemu;
• przedstawienia swojego stanowiska oraz dodatkowych informacji, które mogą mieć znaczenie dla wyniku;
• zakwestionowania decyzji i uzyskania ponownej oceny w rozsądnym czasie.

Te uprawnienia wymagają odpowiedniego zaprojektowania procesu obsługi – nie wystarczy ogólne odesłanie do „procedury odwoławczej”. W praktyce dobrze sprawdza się przypisanie określonych ról (np. osoby pierwszej i drugiej instancji), z jasno opisanymi kryteriami, kiedy i w jaki sposób wynik AI może zostać zmieniony. W projektach wysokiego ryzyka wskazane jest także okresowe badanie, jak często decyzje są korygowane przez ludzi; jeżeli korekt jest dużo, może to oznaczać problem z samym modelem lub jego parametryzacją.

W regulaminach, formularzach zgód oraz klauzulach informacyjnych przydatne jest precyzyjne rozróżnienie, kiedy decyzja ma charakter wspomagany (AI jako narzędzie analityczne), a kiedy wyłącznie zautomatyzowany. Jasny opis procesu ogranicza ryzyko zarzutu, że organizacja ukrywa użycie systemu decyzyjnego. Jeżeli dany proces dopuszcza zarówno ścieżkę automatyczną, jak i z udziałem człowieka, można rozważyć umożliwienie osobie wyboru trybu (np. „szybsza decyzja automatyczna” albo „pełna analiza manualna”), oczywiście przy zachowaniu pozostałych wymogów RODO.

Administrator powinien także zadbać o to, aby pracownicy dokonujący „ludzkiej” weryfikacji wyników AI mieli odpowiednie narzędzia i czas na rzeczywistą ocenę sprawy. Jeżeli osoba rozpatrująca odwołanie widzi jedynie końcowy scoring bez informacji o głównych czynnikach wpływających na wynik, jej rola staje się czysto formalna. Z punktu widzenia RODO oraz zaufania klientów istotne jest, aby taki pracownik miał dostęp do kluczowych danych wejściowych oraz zrozumiałych wskazówek, dlaczego system ocenił sytuację w określony sposób.

W firmach, które wdrażają kilka równoległych narzędzi AI, pomocne jest stworzenie jednej, spójnej „polityki decyzji zautomatyzowanych”. Taki dokument porządkuje, kiedy wolno korzystać z pełnej automatyzacji, jak dokumentować przebieg procesu, jakie są standardy wyjaśniania decyzji oraz jakie mechanizmy kontroli okresowej obowiązują. Ułatwia to także kontakt z organem nadzorczym – zamiast tłumaczyć każdy system osobno, można odwołać się do przyjętych ram postępowania, a następnie opisać specyfikę danego narzędzia.

Do kompletu polecam jeszcze: Monitoring urządzeń służbowych: polityka MDM, logi i prywatność pracownika — znajdziesz tam dodatkowe wskazówki.

Dobrze ułożone korzystanie z narzędzi AI – z jasną mapą odpowiedzialności, zrozumiałymi podstawami prawnymi, przemyślaną oceną ryzyka i realnymi gwarancjami dla osób, których dane dotyczą – staje się elementem przewagi konkurencyjnej. Organizacje, które traktują RODO jako integralną część projektów AI, zwykle szybciej reagują na zmiany regulacyjne i spokojniej przechodzą przez audyty, a przy tym budują większe zaufanie użytkowników i partnerów biznesowych.

Najczęściej zadawane pytania (FAQ)

Czy RODO pozwala firmom korzystać z narzędzi AI, takich jak ChatGPT?

RODO nie zakazuje korzystania z narzędzi AI. Nakłada natomiast warunki, które muszą zostać spełnione: zgodna z prawem podstawa przetwarzania danych (np. umowa, uzasadniony interes), przejrzystość wobec osób, których dane dotyczą, odpowiednie środki bezpieczeństwa oraz właściwe uregulowanie relacji z dostawcą (np. umowa powierzenia).

Problemem nie jest samo „AI”, tylko to, jakie dane są do niego wprowadzane i na jakich zasadach są przetwarzane. Jeżeli narzędzie służy do analizy danych klientów czy pracowników, trzeba założyć, że mamy do czynienia z przetwarzaniem danych osobowych i odpowiednio to uregulować.

Czy mogę wkleić dane klienta do darmowego czatu AI, żeby szybciej przygotować odpowiedź?

Zwykle będzie to ryzykowne z perspektywy RODO. Wklejenie maila klienta z danymi kontaktowymi, numerem zamówienia czy opisem sytuacji oznacza przekazanie danych osobowych zewnętrznemu dostawcy, często poza EOG, bez jasnej podstawy prawnej i bez kontroli nad dalszym wykorzystaniem tych danych (np. do trenowania modeli).

Bezpieczniejszym podejściem jest: usuwanie lub modyfikowanie elementów pozwalających na identyfikację osoby, korzystanie z wersji narzędzia objętej umową powierzenia oraz wyraźne zasady wewnętrzne, czego nie wolno wprowadzać do ogólnodostępnych czatów AI.

Kiedy korzystanie z AI w firmie oznacza przetwarzanie danych osobowych w rozumieniu RODO?

Przetwarzanie danych osobowych pojawia się wtedy, gdy narzędzie AI otrzymuje, analizuje lub generuje informacje, które pozwalają zidentyfikować konkretną osobę albo czynią ją identyfikowalną w połączeniu z innymi danymi. To może być imię i nazwisko, ale także kombinacja szczegółów dotyczących stanowiska, firmy i sytuacji zawodowej.

Typowe przykłady to: analiza treści maili klientów, redakcja umów zawierających dane stron, selekcja CV kandydatów czy segmentacja klientów na podstawie historii zakupów. Jeśli system pracuje wyłącznie na danych technicznych lub prawidłowo zanonimizowanych, wówczas RODO zasadniczo nie ma zastosowania.

Jak odróżnić dane anonimowe od pseudonimizowanych przy korzystaniu z AI?

Dane anonimowe to takie, których nie da się przypisać do konkretnej osoby przy użyciu rozsądnie dostępnych środków, także po połączeniu z innymi bazami. W praktyce to wysoki próg – samo usunięcie imienia i nazwiska czy zastąpienie ich numerem ID zwykle nie wystarcza, zwłaszcza gdy opis sytuacji jest bardzo szczegółowy.

Pseudonimizacja polega na zastąpieniu bezpośrednich identyfikatorów (np. imienia i nazwiska) innymi oznaczeniami, ale z zachowaniem możliwości powiązania tych danych z osobą za pomocą dodatkowego „klucza”. Dla RODO to nadal dane osobowe, choć z mniejszym ryzykiem, które trzeba traktować jak informacje podlegające pełnej ochronie.

Kim jest administrator, a kim podmiot przetwarzający w kontekście narzędzi AI?

Administrator danych to podmiot, który decyduje o celach i sposobach przetwarzania danych – w przypadku firmy będzie to zazwyczaj sama organizacja korzystająca z AI w swojej działalności (np. do obsługi klientów lub rekrutacji). To ona odpowiada za zgodność przetwarzania z RODO.

Dostawca narzędzia AI bywa najczęściej podmiotem przetwarzającym (procesorem), gdy działa na udokumentowane polecenie administratora, np. dostawca SaaS obsługujący bazę klientów. Może jednak być też odrębnym administratorem, jeśli samodzielnie określa cele wykorzystania danych (np. otwarty czat AI zbierający dane do trenowania modeli) lub współadministratorem w projektach, gdzie cele i zakres przetwarzania ustalane są wspólnie.

Jakie obowiązki ma administrator danych przy wyborze dostawcy narzędzia AI?

Administrator powinien przeprowadzić choćby podstawowe due diligence dostawcy. Obejmuje to m.in.: ustalenie, gdzie są przetwarzane dane (w tym czy poza EOG), jakie środki bezpieczeństwa technicznego i organizacyjnego są stosowane, czy dostawca wykorzystuje dane klientów do własnych celów (np. trenowania modeli) oraz jakie są zasady retencji i usuwania danych.

W praktyce przydaje się krótka lista kryteriów, przygotowana wspólnie przez dział prawny i IT, obejmująca: zgodność z RODO, mechanizmy transferu danych poza EOG, możliwość konfiguracji poziomu prywatności, dostępne certyfikaty bezpieczeństwa oraz przejrzystą dokumentację. W przypadku danych wrażliwych ta ocena powinna być znacznie bardziej szczegółowa.

Jak ograniczyć ryzyko naruszenia RODO, gdy pracownicy korzystają z AI w codziennej pracy?

Kluczowe są jasne zasady i praktyczne szkolenia. Sam zakaz „nie wklejać danych osobowych do AI” zwykle nie wystarcza. Lepiej sprawdza się konkretna polityka: wskazanie, z jakich narzędzi wolno korzystać, jakie typy danych można tam wprowadzać, a które są zabronione (np. dane zdrowotne, szczegółowe dane finansowe klientów).

Warto też wprowadzić rozwiązania techniczne: korzystanie z wersji biznesowych narzędzi z umową powierzenia, domyślne wyłączenie używania danych do trenowania modeli, maksymalnie ograniczone logowanie danych w systemie oraz procedurę reagowania na incydenty, gdyby dane trafiły do niewłaściwego narzędzia.

Źródła informacji

• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO). Dziennik Urzędowy Unii Europejskiej (2016) – Podstawowe definicje, role RODO, zasady przetwarzania danych osobowych
• Wytyczne 05/2021 dotyczące przykładów zgłaszania naruszeń ochrony danych osobowych. Europejska Rada Ochrony Danych (2021) – Przykłady naruszeń poufności i obowiązki administratora
• Artificial Intelligence Act – przyjęty tekst aktu o sztucznej inteligencji. Parlament Europejski (2024) – Ramy prawne dla systemów AI w UE, relacja do ochrony danych