RODO i generatywna AI w firmie – jak legalnie korzystać z modeli językowych, chatbotów i automatyzacji

Najpierw mapa danych: wejście, model, wynik i logi

W procesie generatywnej AI dane osobowe mogą pojawić się w promptach, załącznikach, historii rozmowy, logach aplikacyjnych, bazie wiedzy RAG i w odpowiedzi modelu. Dlatego analiza ograniczona do samego okna czatu może pominąć znaczną część przetwarzania.

Mapa powinna wskazywać źródło danych, cel, użytkownika, dostawcę, miejsce przetwarzania, retencję oraz dalsze wykorzystanie wyników. Pozwala to ustalić, czy określone dane są w ogóle potrzebne i czy można zastosować pseudonimizację albo środowisko o większej kontroli.

Podstawa prawna musi odpowiadać konkretnemu celowi przetwarzania

RODO nie tworzy osobnej podstawy prawnej dla „używania AI”. Administrator musi wskazać podstawę z art. 6, a w przypadku szczególnych kategorii danych także spełnić dodatkowe warunki. Ta sama organizacja może wykorzystywać model w kilku celach, z których każdy wymaga oddzielnej oceny.

Europejska Rada Ochrony Danych w opinii 28/2024 analizuje między innymi możliwość powołania się na prawnie uzasadniony interes przy rozwoju i stosowaniu modeli AI. Nie oznacza to automatycznej legalności każdego procesu. Konieczna jest ocena celu, niezbędności i równowagi praw oraz rozsądnych oczekiwań osób.

Minimalizacja i poufność – czego nie należy wysyłać do modelu?

Najprostsze zabezpieczenie polega na ograniczeniu danych wejściowych do informacji potrzebnych do zadania. W wielu zastosowaniach nazwisko, PESEL, pełny dokument klienta albo tajemnica przedsiębiorstwa nie są konieczne, aby model przygotował strukturę tekstu lub pomógł w analizie problemu.

Organizacja powinna rozróżnić narzędzia konsumenckie od zatwierdzonych środowisk biznesowych i technicznych. Zasady muszą uwzględniać ustawienia wykorzystywania danych do uczenia, dostęp administratorów, historię rozmów i możliwość usunięcia danych. Sam zapis „nie wklejaj danych wrażliwych” jest zbyt nieprecyzyjny.

Administrator, podmiot przetwarzający i dostawca modelu

Relacja prawna zależy od tego, kto ustala cele i sposoby przetwarzania. Dostawca usługi może działać jako podmiot przetwarzający w określonym zakresie, ale jego własne cele przetwarzania mogą wymagać osobnej analizy. Trzeba czytać nie tylko DPA, lecz również warunki usługi i dokumentację ustawień prywatności.

Umowa powierzenia powinna odpowiadać art. 28 RODO, a podwykonawcy i transfery muszą być transparentne dla klienta. Przy usługach globalnych ważne jest ustalenie lokalizacji danych oraz mechanizmu transferowego, a nie tylko siedziby sprzedawcy wystawiającego fakturę.

Kiedy potrzebna jest DPIA dla rozwiązania AI?

Ocena skutków dla ochrony danych jest wymagana, gdy rodzaj przetwarzania może powodować wysokie ryzyko dla praw i wolności osób. AI może zwiększać ryzyko przez skalę, łączenie źródeł, profilowanie, automatyzację lub nieprzejrzystość działania, ale nie każda funkcja AI automatycznie oznacza obowiązek DPIA.

Dobra DPIA opisuje realny proces i zabezpieczenia, a nie ogólną technologię. Powinna badać między innymi rodzaj danych, osoby, konsekwencje błędu, możliwość ingerencji człowieka, retencję, dostęp, transfery i ryzyko ujawnienia informacji w wyniku modelu.

Web scraping i dane wykorzystane do rozwoju modeli

Publiczna dostępność informacji w internecie nie oznacza, że przestają one być danymi osobowymi ani że można je dowolnie wykorzystywać. Przy pozyskiwaniu danych do trenowania lub wzbogacania modeli trzeba ocenić podstawę prawną, obowiązki informacyjne, źródło danych, minimalizację i prawa osób.

8 lipca 2026 r. EROD poinformowała o przyjęciu Guidelines 03/2026 dotyczących web scrapingu w kontekście generatywnej AI do konsultacji publicznych. To dodatkowo pokazuje, że projekt wykorzystujący masowe dane z sieci wymaga odrębnej analizy, a nie prostego założenia „dane są publiczne, więc RODO nie działa”.

AI wspierająca decyzje o osobach – profilowanie i art. 22 RODO

Jeżeli wynik modelu wpływa na ocenę kandydata, pracownika, klienta lub osoby ubezpieczonej, trzeba ustalić, jaką rolę odgrywa człowiek i czy decyzja ma skutki prawne lub podobnie istotne. Formalne kliknięcie „zatwierdź” przez pracownika nie zawsze oznacza rzeczywistą kontrolę, jeżeli system w praktyce determinuje wynik.

W procesach wysokiego wpływu potrzebne są zasady weryfikacji wyniku, możliwość zakwestionowania błędu oraz dokumentacja źródeł informacji. Równolegle należy ocenić AI Act, jeżeli zastosowanie mieści się w obszarze wysokiego ryzyka.

Retencja, prawa osób i możliwość usunięcia danych

Przed wdrożeniem trzeba ustalić, jak długo przechowywane są prompty, pliki, logi i dane w bazach wiedzy. Jeżeli dostawca oferuje opcję zerowej retencji albo środowisko bez używania danych do ulepszania modelu, decyzja o konfiguracji powinna wynikać z celu i ryzyka organizacji.

Trzeba również przewidzieć obsługę żądań osób. W systemach opartych na wielu źródłach samo usunięcie rekordu w aplikacji frontowej może nie usuwać danych z logów, kopii lub indeksu wektorowego. Architektura powinna wspierać wykonanie przyjętej polityki retencji.

Jak wdrożyć generatywną AI bez paraliżowania pracowników?

Skuteczny model łączy listę dopuszczonych narzędzi, reguły danych, szkolenie, ścieżkę zgłaszania nowych zastosowań i prostą ocenę ryzyka. Pracownik powinien wiedzieć, kiedy może użyć AI samodzielnie, kiedy musi zanonimizować materiał, a kiedy potrzebna jest zgoda właściciela procesu lub IOD.

Audyt można połączyć z AI Act i umowami dostawców. Więcej o takim podejściu: Prawo nowych technologii. Celem nie jest zakaz technologii, lecz taki model użycia, w którym firma kontroluje dane i potrafi wyjaśnić swoje decyzje.

Obowiązek informacyjny i przejrzystość użycia AI

Osoba, której dane są przetwarzane, powinna otrzymać informacje wymagane przez RODO w sposób zrozumiały. Jeżeli AI jest tylko narzędziem wewnętrznym, nie zawsze trzeba eksponować nazwę modelu w każdym komunikacie, ale opis celu, podstawy, odbiorców i praw musi odpowiadać rzeczywistemu procesowi.

W procesach, w których AI ma istotny wpływ na osobę, przejrzystość nabiera większego znaczenia. Dokumentacja powinna wyjaśniać rolę automatyzacji i nadzoru człowieka oraz umożliwiać obsługę pytań lub sprzeciwu tam, gdzie przysługuje.

Bezpieczeństwo integracji AI: klucze API, logi i baza wiedzy

Ryzyko danych nie kończy się na modelu. Integracja może zapisywać prompty w logach aplikacyjnych, systemie monitoringu, narzędziu helpdesk albo w hurtowni danych. Klucze API i konta serwisowe również wymagają kontroli dostępu i rotacji.

Przy RAG szczególne znaczenie ma kontrola uprawnień do źródłowych dokumentów. Model nie powinien ujawniać użytkownikowi fragmentu dokumentu, do którego użytkownik nie miałby dostępu bez pośrednictwa AI. Testy uprawnień trzeba wykonywać na warstwie aplikacji i indeksu.

Zasady dla pracowników – proste reguły zamiast zakazu wszystkiego

Polityka powinna podawać przykłady: jakie dane można wprowadzać do zatwierdzonego narzędzia, kiedy trzeba je zanonimizować, jak oznaczać wynik wymagający weryfikacji i kiedy zgłosić nowe zastosowanie. Pracownik nie powinien samodzielnie interpretować skomplikowanego DPA dostawcy.

Warto wprowadzić kanał do zgłaszania pomysłów na automatyzację. Pozwala to wychwycić shadow AI i przenieść użyteczne pomysły do kontrolowanego środowiska, zamiast tworzyć kulturę, w której narzędzia są używane po cichu.

Gdy AI ujawni dane lub wyśle je do niewłaściwego miejsca

Błędny prompt, wadliwa integracja lub konfiguracja dostawcy może prowadzić do naruszenia ochrony danych. Organizacja potrzebuje sposobu szybkiego ustalenia, jakie dane trafiły do systemu, czy można je usunąć i czy dostawca wykorzystał je w dalszym procesie.

Incydent należy ocenić według zwykłych zasad RODO, a nie według osobnej kategorii „incydentu AI”. Jednocześnie warto sprawdzić obowiązki z AI Act, umowy z dostawcą i – w organizacjach regulowanych – KSC/NIS2 lub DORA.

Najczęstsze pytania