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</