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

Stan prawny i punkt wyjścia na 18 lipca 2026 r.

Generatywna AI tworzy nowe kanały przepływu informacji: prompty, załączniki, pamięć rozmów, logi, dane treningowe i wyniki modeli. Dla administratora danych najważniejsze jest przełożenie tych technicznych elementów na zwykłe pytania RODO: jakie dane przetwarzamy, po co, na jakiej podstawie, komu je powierzamy i jak długo pozostają dostępne.

• RODO pozostaje odrębnym reżimem od AI Act i ma zastosowanie, gdy w procesie AI dochodzi do przetwarzania danych osobowych.
• Organy ochrony danych i EDPB rozwijają podejście do modeli AI, anonimizacji, prawnie uzasadnionego interesu i web scrapingu; ocena wymaga analizy konkretnego modelu i procesu.

Ten poradnik ma charakter praktyczny i koncentruje się na sposobie organizacji zgodności. Nie zastępuje analizy konkretnego podmiotu, ponieważ zakres obowiązków zależy m.in. od roli prawnej, sektora, wielkości, rodzaju systemu, kategorii danych i modelu współpracy z dostawcami. W projektach technologicznych kilka reżimów często działa jednocześnie, dlatego kwalifikację trzeba wykonywać warstwowo.

Najlepszym punktem startu jest opis rzeczywistego procesu: kto korzysta z technologii, jakie dane są używane, co może się stać w razie błędu i od jakich dostawców zależy działanie usługi. Dopiero potem należy przypisać przepisy, obowiązki, właścicieli i dowody. Odwrócona kolejność — rozpoczęcie od generowania dokumentów — zwykle prowadzi do kosztownej dokumentacji, której nikt nie używa.

Najpierw przepływ danych: prompt to także wejście do systemu

Ocena RODO powinna zacząć się od diagramu przepływu danych. Trzeba uwzględnić treść promptu, pliki, historię rozmowy, logi, telemetrykę i dane generowane przez model.

Ocena RODO powinna zacząć się od diagramu przepływu danych. Trzeba uwzględnić treść promptu, pliki, historię rozmowy, logi, telemetrykę i dane generowane przez model. W praktyce oznacza to konieczność połączenia analizy prawnej z realnym procesem biznesowym. Dla obszaru „RODO i generatywna AI” kluczowe jest ustalenie odpowiedzialności, źródła danych i momentu, w którym decyzja wymaga eskalacji. Dopiero na tej podstawie można dobrać dokumenty, kontrolki techniczne i procedury, które rzeczywiście będą używane. Z punktu widzenia dowodowego warto zachować nie tylko finalną politykę, ale także historię decyzji, wyniki przeglądów i działania korygujące.

Pracownik może nieświadomie przekazać więcej danych niż wynika z celu zadania, zwłaszcza kopiując całe dokumenty. Samo zapisanie obowiązku w procedurze nie daje jeszcze zgodności. Organizacja powinna potrafić wykazać, kto wykonuje daną czynność, z jaką częstotliwością, na podstawie jakich danych i co dzieje się po wykryciu wyjątku. W małej firmie proces może być prosty i skupiony w kilku rolach; w dużej grupie wymaga zwykle rozdzielenia odpowiedzialności i wspólnego standardu. Proporcjonalność nie oznacza braku kontroli — oznacza kontrolę dopasowaną do skali i ryzyka.

• Dla każdego narzędzia opisz kategorie danych, źródła, odbiorców, lokalizacje, retencję, cele i możliwość wykorzystania danych przez dostawcę.
• Zapisz wynik oceny w jednym miejscu i wskaż osobę odpowiedzialną za jego aktualizację po zmianie systemu, dostawcy lub procesu.
• Ustal trigger ponownego przeglądu: incydent, istotna zmiana umowy, nowa kategoria danych, zmiana modelu biznesowego albo wymagania regulatora.

Przykład: Prośba o streszczenie reklamacji klienta może zawierać dane kontaktowe, historię zdrowotną albo dane płatnicze, choć do samego streszczenia nie były potrzebne.

Warstwa umowna i dowodowa powinna być analizowana równolegle. Jeżeli obowiązek jest wykonywany przez zewnętrznego dostawcę, organizacja nadal powinna wiedzieć, jakie informacje otrzyma, w jakim czasie i jak zweryfikuje ich jakość. W relacjach wewnętrznych potrzebny jest natomiast jasny podział pomiędzy właścicielem biznesowym, IT, bezpieczeństwem, ochroną danych i compliance. Nie każdy temat wymaga rozbudowanego komitetu, ale każdy istotny proces powinien mieć osobę zdolną podjąć decyzję.

Przy projektowaniu kontroli należy unikać dwóch skrajności. Pierwszą jest formalizm: tworzenie wielu dokumentów bez związku z codzienną pracą. Drugą jest nadmierna improwizacja, w której decyzje nie są odtwarzalne. Dobrze zaprojektowany model pozostawia ślad wystarczający do audytu, ale jednocześnie jest możliwy do wykonania przez zespół w normalnym rytmie pracy.

Podstawa prawna i zgodność celu

AI nie tworzy nowej podstawy prawnej przetwarzania. Organizacja nadal musi wskazać podstawę z RODO i ocenić, czy nowe użycie jest zgodne z pierwotnym celem.

AI nie tworzy nowej podstawy prawnej przetwarzania. Organizacja nadal musi wskazać podstawę z RODO i ocenić, czy nowe użycie jest zgodne z pierwotnym celem. Samo zapisanie obowiązku w procedurze nie daje jeszcze zgodności. Organizacja powinna potrafić wykazać, kto wykonuje daną czynność, z jaką częstotliwością, na podstawie jakich danych i co dzieje się po wykryciu wyjątku. W małej firmie proces może być prosty i skupiony w kilku rolach; w dużej grupie wymaga zwykle rozdzielenia odpowiedzialności i wspólnego standardu. Proporcjonalność nie oznacza braku kontroli — oznacza kontrolę dopasowaną do skali i ryzyka.

Ryzyko pojawia się, gdy dane zebrane do obsługi klienta są później używane do eksperymentów z modelem bez właściwej analizy. Na poziomie zarządczym warto przełożyć ten problem na mierzalny mechanizm: właściciela, termin, kryterium zakończenia i dowód wykonania. Takie podejście ogranicza sytuacje, w których compliance istnieje wyłącznie w dokumencie, a produkt lub infrastruktura działają według innych zasad. W sporze, audycie albo po incydencie właśnie ta spójność pomiędzy dokumentacją a praktyką ma zasadnicze znaczenie.

• Przed uruchomieniem przypadku użycia ustal cel, podstawę prawną, konieczność danych i zgodność z informacją przekazaną osobie.
• Zapisz wynik oceny w jednym miejscu i wskaż osobę odpowiedzialną za jego aktualizację po zmianie systemu, dostawcy lub procesu.
• Ustal trigger ponownego przeglądu: incydent, istotna zmiana umowy, nowa kategoria danych, zmiana modelu biznesowego albo wymagania regulatora.

Przykład: Dane klientów mogą być potrzebne do wykonania umowy, ale wykorzystanie ich do trenowania własnego modelu może wymagać odrębnej oceny.

Warstwa umowna i dowodowa powinna być analizowana równolegle. Jeżeli obowiązek jest wykonywany przez zewnętrznego dostawcę, organizacja nadal powinna wiedzieć, jakie informacje otrzyma, w jakim czasie i jak zweryfikuje ich jakość. W relacjach wewnętrznych potrzebny jest natomiast jasny podział pomiędzy właścicielem biznesowym, IT, bezpieczeństwem, ochroną danych i compliance. Nie każdy temat wymaga rozbudowanego komitetu, ale każdy istotny proces powinien mieć osobę zdolną podjąć decyzję.

Przy projektowaniu kontroli należy unikać dwóch skrajności. Pierwszą jest formalizm: tworzenie wielu dokumentów bez związku z codzienną pracą. Drugą jest nadmierna improwizacja, w której decyzje nie są odtwarzalne. Dobrze zaprojektowany model pozostawia ślad wystarczający do audytu, ale jednocześnie jest możliwy do wykonania przez zespół w normalnym rytmie pracy.

Minimalizacja: nie wysyłaj całego dokumentu, jeśli potrzebujesz jednego pola

Zasada minimalizacji jest szczególnie praktyczna w AI. Im mniej danych trafia do systemu, tym mniejsze ryzyko wycieku, nieuprawnionego utrwalenia i błędnego użycia.

Zasada minimalizacji jest szczególnie praktyczna w AI. Im mniej danych trafia do systemu, tym mniejsze ryzyko wycieku, nieuprawnionego utrwalenia i błędnego użycia. Na poziomie zarządczym warto przełożyć ten problem na mierzalny mechanizm: właściciela, termin, kryterium zakończenia i dowód wykonania. Takie podejście ogranicza sytuacje, w których compliance istnieje wyłącznie w dokumencie, a produkt lub infrastruktura działają według innych zasad. W sporze, audycie albo po incydencie właśnie ta spójność pomiędzy dokumentacją a praktyką ma zasadnicze znaczenie.

Automatyzacje często są budowane na najłatwiejszym technicznie wejściu, czyli pełnym rekordzie lub dokumencie. W praktyce oznacza to konieczność połączenia analizy prawnej z realnym procesem biznesowym. Dla obszaru „RODO i generatywna AI” kluczowe jest ustalenie odpowiedzialności, źródła danych i momentu, w którym decyzja wymaga eskalacji. Dopiero na tej podstawie można dobrać dokumenty, kontrolki techniczne i procedury, które rzeczywiście będą używane. Z punktu widzenia dowodowego warto zachować nie tylko finalną politykę, ale także historię decyzji, wyniki przeglądów i działania korygujące.

• Stosuj maskowanie, pseudonimizację, selekcję pól, lokalne pre-processing i reguły DLP przed wysłaniem danych do zewnętrznego modelu.
• Zapisz wynik oceny w jednym miejscu i wskaż osobę odpowiedzialną za jego aktualizację po zmianie systemu, dostawcy lub procesu.
• Ustal trigger ponownego przeglądu: incydent, istotna zmiana umowy, nowa kategoria danych, zmiana modelu biznesowego albo wymagania regulatora.

Przykład: Bot przygotowujący kategorię sprawy nie musi otrzymywać imienia, PESEL i pełnego adresu, jeżeli klasyfikacja opiera się na opisie problemu.

Warstwa umowna i dowodowa powinna być analizowana równolegle. Jeżeli obowiązek jest wykonywany przez zewnętrznego dostawcę, organizacja nadal powinna wiedzieć, jakie informacje otrzyma, w jakim czasie i jak zweryfikuje ich jakość. W relacjach wewnętrznych potrzebny jest natomiast jasny podział pomiędzy właścicielem biznesowym, IT, bezpieczeństwem, ochroną danych i compliance. Nie każdy temat wymaga rozbudowanego komitetu, ale każdy istotny proces powinien mieć osobę zdolną podjąć decyzję.

Przy projektowaniu kontroli należy unikać dwóch skrajności. Pierwszą jest formalizm: tworzenie wielu dokumentów bez związku z codzienną pracą. Drugą jest nadmierna improwizacja, w której decyzje nie są odtwarzalne. Dobrze zaprojektowany model pozostawia ślad wystarczający do audytu, ale jednocześnie jest możliwy do wykonania przez zespół w normalnym rytmie pracy.

DPIA i wysoki poziom ryzyka

Ocena skutków dla ochrony danych może być potrzebna, gdy proces AI ze względu na skalę, charakter danych, profilowanie lub wpływ na osoby stwarza wysokie ryzyko.

Ocena skutków dla ochrony danych może być potrzebna, gdy proces AI ze względu na skalę, charakter danych, profilowanie lub wpływ na osoby stwarza wysokie ryzyko. W praktyce oznacza to konieczność połączenia analizy prawnej z realnym procesem biznesowym. Dla obszaru „RODO i generatywna AI” kluczowe jest ustalenie odpowiedzialności, źródła danych i momentu, w którym decyzja wymaga eskalacji. Dopiero na tej podstawie można dobrać dokumenty, kontrolki techniczne i procedury, które rzeczywiście będą używane. Z punktu widzenia dowodowego warto zachować nie tylko finalną politykę, ale także historię decyzji, wyniki przeglądów i działania korygujące.

DPIA wykonana po wdrożeniu traci funkcję projektową i może ujawnić problemy, które trudno już usunąć z produktu. Samo zapisanie obowiązku w procedurze nie daje jeszcze zgodności. Organizacja powinna potrafić wykazać, kto wykonuje daną czynność, z jaką częstotliwością, na podstawie jakich danych i co dzieje się po wykryciu wyjątku. W małej firmie proces może być prosty i skupiony w kilku rolach; w dużej grupie wymaga zwykle rozdzielenia odpowiedzialności i wspólnego standardu. Proporcjonalność nie oznacza braku kontroli — oznacza kontrolę dopasowaną do skali i ryzyka.

• Włącz privacy review do procesu zakupowego i produktowego, używając progów eskalacji opartych na danych wrażliwych, skali, automatycznych decyzjach i monitorowaniu.
• Zapisz wynik oceny w jednym miejscu i wskaż osobę odpowiedzialną za jego aktualizację po zmianie systemu, dostawcy lub procesu.
• Ustal trigger ponownego przeglądu: incydent, istotna zmiana umowy, nowa kategoria danych, zmiana modelu biznesowego albo wymagania regulatora.

Przykład: System analizujący wydajność pracowników na podstawie wielu źródeł danych wymaga innej oceny niż asystent poprawiający stylistykę publicznego komunikatu.

Warstwa umowna i dowodowa powinna być analizowana równolegle. Jeżeli obowiązek jest wykonywany przez zewnętrznego dostawcę, organizacja nadal powinna wiedzieć, jakie informacje otrzyma, w jakim czasie i jak zweryfikuje ich jakość. W relacjach wewnętrznych potrzebny jest natomiast jasny podział pomiędzy właścicielem biznesowym, IT, bezpieczeństwem, ochroną danych i compliance. Nie każdy temat wymaga rozbudowanego komitetu, ale każdy istotny proces powinien mieć osobę zdolną podjąć decyzję.

Przy projektowaniu kontroli należy unikać dwóch skrajności. Pierwszą jest formalizm: tworzenie wielu dokumentów bez związku z codzienną pracą. Drugą jest nadmierna improwizacja, w której decyzje nie są odtwarzalne. Dobrze zaprojektowany model pozostawia ślad wystarczający do audytu, ale jednocześnie jest możliwy do wykonania przez zespół w normalnym rytmie pracy.

Dostawca AI jako procesor lub odrębny administrator

Rola dostawcy zależy od tego, kto ustala cele i sposoby przetwarzania. Nie wolno zakładać automatycznie, że każda usługa chmurowa jest procesorem.

Rola dostawcy zależy od tego, kto ustala cele i sposoby przetwarzania. Nie wolno zakładać automatycznie, że każda usługa chmurowa jest procesorem. Samo zapisanie obowiązku w procedurze nie daje jeszcze zgodności. Organizacja powinna potrafić wykazać, kto wykonuje daną czynność, z jaką częstotliwością, na podstawie jakich danych i co dzieje się po wykryciu wyjątku. W małej firmie proces może być prosty i skupiony w kilku rolach; w dużej grupie wymaga zwykle rozdzielenia odpowiedzialności i wspólnego standardu. Proporcjonalność nie oznacza braku kontroli — oznacza kontrolę dopasowaną do skali i ryzyka.

Warunki usługi mogą przewidywać własne cele dostawcy, np. bezpieczeństwo, rozwój produktu lub trening, co trzeba przeanalizować. Na poziomie zarządczym warto przełożyć ten problem na mierzalny mechanizm: właściciela, termin, kryterium zakończenia i dowód wykonania. Takie podejście ogranicza sytuacje, w których compliance istnieje wyłącznie w dokumencie, a produkt lub infrastruktura działają według innych zasad. W sporze, audycie albo po incydencie właśnie ta spójność pomiędzy dokumentacją a praktyką ma zasadnicze znaczenie.

• Sprawdź DPA, podprocesorów, retencję, użycie do trenowania, transfery, mechanizmy usuwania i wsparcie praw osób.
• Zapisz wynik oceny w jednym miejscu i wskaż osobę odpowiedzialną za jego aktualizację po zmianie systemu, dostawcy lub procesu.
• Ustal trigger ponownego przeglądu: incydent, istotna zmiana umowy, nowa kategoria danych, zmiana modelu biznesowego albo wymagania regulatora.

Przykład: Dwie wersje tego samego produktu — konsumencka i enterprise — mogą mieć zupełnie inne warunki wykorzystania danych.

Warstwa umowna i dowodowa powinna być analizowana równolegle. Jeżeli obowiązek jest wykonywany przez zewnętrznego dostawcę, organizacja nadal powinna wiedzieć, jakie informacje otrzyma, w jakim czasie i jak zweryfikuje ich jakość. W relacjach wewnętrznych potrzebny jest natomiast jasny podział pomiędzy właścicielem biznesowym, IT, bezpieczeństwem, ochroną danych i compliance. Nie każdy temat wymaga rozbudowanego komitetu, ale każdy istotny proces powinien mieć osobę zdolną podjąć decyzję.

Przy projektowaniu kontroli należy unikać dwóch skrajności. Pierwszą jest formalizm: tworzenie wielu dokumentów bez związku z codzienną pracą. Drugą jest nadmierna improwizacja, w której decyzje nie są odtwarzalne. Dobrze zaprojektowany model pozostawia ślad wystarczający do audytu, ale jednocześnie jest możliwy do wykonania przez zespół w normalnym rytmie pracy.

Transfery poza EOG i dostęp z państw trzecich

Lokalizacja serwera to tylko część oceny transferu. Znaczenie może mieć również zdalny dostęp personelu lub podwykonawców z państw trzecich.

Lokalizacja serwera to tylko część oceny transferu. Znaczenie może mieć również zdalny dostęp personelu lub podwykonawców z państw trzecich. Na poziomie zarządczym warto przełożyć ten problem na mierzalny mechanizm: właściciela, termin, kryterium zakończenia i dowód wykonania. Takie podejście ogranicza sytuacje, w których compliance istnieje wyłącznie w dokumencie, a produkt lub infrastruktura działają według innych zasad. W sporze, audycie albo po incydencie właśnie ta spójność pomiędzy dokumentacją a praktyką ma zasadnicze znaczenie.

Brak mapy podprocesorów utrudnia ocenę mechanizmu transferowego i środków dodatkowych. W praktyce oznacza to konieczność połączenia analizy prawnej z realnym procesem biznesowym. Dla obszaru „RODO i generatywna AI” kluczowe jest ustalenie odpowiedzialności, źródła danych i momentu, w którym decyzja wymaga eskalacji. Dopiero na tej podstawie można dobrać dokumenty, kontrolki techniczne i procedury, które rzeczywiście będą używane. Z punktu widzenia dowodowego warto zachować nie tylko finalną politykę, ale także historię decyzji, wyniki przeglądów i działania korygujące.

• Ustal pełny łańcuch dostaw, podstawy transferu, lokalizacje wsparcia i procedurę aktualizacji po zmianie podprocesora.
• Zapisz wynik oceny w jednym miejscu i wskaż osobę odpowiedzialną za jego aktualizację po zmianie systemu, dostawcy lub procesu.
• Ustal trigger ponownego przeglądu: incydent, istotna zmiana umowy, nowa kategoria danych, zmiana modelu biznesowego albo wymagania regulatora.

Przykład: Deklaracja „dane przechowywane w UE” nie zawsze wyklucza administracyjny dostęp spoza EOG.

Warstwa umowna i dowodowa powinna być analizowana równolegle. Jeżeli obowiązek jest wykonywany przez zewnętrznego dostawcę, organizacja nadal powinna wiedzieć, jakie informacje otrzyma, w jakim czasie i jak zweryfikuje ich jakość. W relacjach wewnętrznych potrzebny jest natomiast jasny podział pomiędzy właścicielem biznesowym, IT, bezpieczeństwem, ochroną danych i compliance. Nie każdy temat wymaga rozbudowanego komitetu, ale każdy istotny proces powinien mieć osobę zdolną podjąć decyzję.

Przy projektowaniu kontroli należy unikać dwóch skrajności. Pierwszą jest formalizm: tworzenie wielu dokumentów bez związku z codzienną pracą. Drugą jest nadmierna improwizacja, w której decyzje nie są odtwarzalne. Dobrze zaprojektowany model pozostawia ślad wystarczający do audytu, ale jednocześnie jest możliwy do wykonania przez zespół w normalnym rytmie pracy.

Prawa osób i możliwość odnalezienia danych

Administrator musi być w stanie obsługiwać prawa osób także wtedy, gdy dane są przetwarzane w rozwiązaniu AI. Problemem bywa ustalenie, gdzie dane występują i czy da się je usunąć.

Administrator musi być w stanie obsługiwać prawa osób także wtedy, gdy dane są przetwarzane w rozwiązaniu AI. Problemem bywa ustalenie, gdzie dane występują i czy da się je usunąć. W praktyce oznacza to konieczność połączenia analizy prawnej z realnym procesem biznesowym. Dla obszaru „RODO i generatywna AI” kluczowe jest ustalenie odpowiedzialności, źródła danych i momentu, w którym decyzja wymaga eskalacji. Dopiero na tej podstawie można dobrać dokumenty, kontrolki techniczne i procedury, które rzeczywiście będą używane. Z punktu widzenia dowodowego warto zachować nie tylko finalną politykę, ale także historię decyzji, wyniki przeglądów i działania korygujące.

Niektóre architektury rozdzielają logi, pamięć użytkownika, dane analityczne i dane treningowe, co komplikuje odpowiedź na żądanie. Samo zapisanie obowiązku w procedurze nie daje jeszcze zgodności. Organizacja powinna potrafić wykazać, kto wykonuje daną czynność, z jaką częstotliwością, na podstawie jakich danych i co dzieje się po wykryciu wyjątku. W małej firmie proces może być prosty i skupiony w kilku rolach; w dużej grupie wymaga zwykle rozdzielenia odpowiedzialności i wspólnego standardu. Proporcjonalność nie oznacza braku kontroli — oznacza kontrolę dopasowaną do skali i ryzyka.

• Przed wdrożeniem sprawdź techniczną wykonalność dostępu, sprostowania, usunięcia, ograniczenia i sprzeciwu w zakresie właściwym dla procesu.
• Zapisz wynik oceny w jednym miejscu i wskaż osobę odpowiedzialną za jego aktualizację po zmianie systemu, dostawcy lub procesu.
• Ustal trigger ponownego przeglądu: incydent, istotna zmiana umowy, nowa kategoria danych, zmiana modelu biznesowego albo wymagania regulatora.

Przykład: Jeżeli firma nie potrafi wskazać, czy prompt jest przechowywany 30 dni czy bezterminowo, trudno rzetelnie odpowiedzieć osobie na pytanie o retencję.

Warstwa umowna i dowodowa powinna być analizowana równolegle. Jeżeli obowiązek jest wykonywany przez zewnętrznego dostawcę, organizacja nadal powinna wiedzieć, jakie informacje otrzyma, w jakim czasie i jak zweryfikuje ich jakość. W relacjach wewnętrznych potrzebny jest natomiast jasny podział pomiędzy właścicielem biznesowym, IT, bezpieczeństwem, ochroną danych i compliance. Nie każdy temat wymaga rozbudowanego komitetu, ale każdy istotny proces powinien mieć osobę zdolną podjąć decyzję.

Przy projektowaniu kontroli należy unikać dwóch skrajności. Pierwszą jest formalizm: tworzenie wielu dokumentów bez związku z codzienną pracą. Drugą jest nadmierna improwizacja, w której decyzje nie są odtwarzalne. Dobrze zaprojektowany model pozostawia ślad wystarczający do audytu, ale jednocześnie jest możliwy do wykonania przez zespół w normalnym rytmie pracy.

Anonimizacja, syntetyczne dane i web scraping

Anonimizacja może ograniczyć zakres RODO tylko wtedy, gdy jest rzeczywista i trwała w danym kontekście. Samo usunięcie imienia często nie wystarcza.

Anonimizacja może ograniczyć zakres RODO tylko wtedy, gdy jest rzeczywista i trwała w danym kontekście. Samo usunięcie imienia często nie wystarcza. Samo zapisanie obowiązku w procedurze nie daje jeszcze zgodności. Organizacja powinna potrafić wykazać, kto wykonuje daną czynność, z jaką częstotliwością, na podstawie jakich danych i co dzieje się po wykryciu wyjątku. W małej firmie proces może być prosty i skupiony w kilku rolach; w dużej grupie wymaga zwykle rozdzielenia odpowiedzialności i wspólnego standardu. Proporcjonalność nie oznacza braku kontroli — oznacza kontrolę dopasowaną do skali i ryzyka.

Duże zbiory i możliwość łączenia informacji zwiększają ryzyko ponownej identyfikacji. Web scraping nie jest automatycznie dozwolony tylko dlatego, że dane są publiczne. Na poziomie zarządczym warto przełożyć ten problem na mierzalny mechanizm: właściciela, termin, kryterium zakończenia i dowód wykonania. Takie podejście ogranicza sytuacje, w których compliance istnieje wyłącznie w dokumencie, a produkt lub infrastruktura działają według innych zasad. W sporze, audycie albo po incydencie właśnie ta spójność pomiędzy dokumentacją a praktyką ma zasadnicze znaczenie.

• Dokumentuj metodę anonimizacji, ryzyko reidentyfikacji, źródła danych, oczekiwania osób i podstawę prawną; w razie potrzeby przeprowadź testy.
• Zapisz wynik oceny w jednym miejscu i wskaż osobę odpowiedzialną za jego aktualizację po zmianie systemu, dostawcy lub procesu.
• Ustal trigger ponownego przeglądu: incydent, istotna zmiana umowy, nowa kategoria danych, zmiana modelu biznesowego albo wymagania regulatora.

Przykład: Publiczny profil zawodowy może zawierać dane osobowe, a masowe zebranie i wykorzystanie do trenowania modelu tworzy inny kontekst niż zwykłe wyświetlenie strony.

Warstwa umowna i dowodowa powinna być analizowana równolegle. Jeżeli obowiązek jest wykonywany przez zewnętrznego dostawcę, organizacja nadal powinna wiedzieć, jakie informacje otrzyma, w jakim czasie i jak zweryfikuje ich jakość. W relacjach wewnętrznych potrzebny jest natomiast jasny podział pomiędzy właścicielem biznesowym, IT, bezpieczeństwem, ochroną danych i compliance. Nie każdy temat wymaga rozbudowanego komitetu, ale każdy istotny proces powinien mieć osobę zdolną podjąć decyzję.

Przy projektowaniu kontroli należy unikać dwóch skrajności. Pierwszą jest formalizm: tworzenie wielu dokumentów bez związku z codzienną pracą. Drugą jest nadmierna improwizacja, w której decyzje nie są odtwarzalne. Dobrze zaprojektowany model pozostawia ślad wystarczający do audytu, ale jednocześnie jest możliwy do wykonania przez zespół w normalnym rytmie pracy.

Polityka firmowa: jak połączyć prywatność z użytecznością

Całkowity zakaz AI często prowadzi do użycia poza kontrolą. Lepszy jest model zatwierdzonych narzędzi i jasnych kategorii danych.

Całkowity zakaz AI często prowadzi do użycia poza kontrolą. Lepszy jest model zatwierdzonych narzędzi i jasnych kategorii danych. Na poziomie zarządczym warto przełożyć ten problem na mierzalny mechanizm: właściciela, termin, kryterium zakończenia i dowód wykonania. Takie podejście ogranicza sytuacje, w których compliance istnieje wyłącznie w dokumencie, a produkt lub infrastruktura działają według innych zasad. W sporze, audycie albo po incydencie właśnie ta spójność pomiędzy dokumentacją a praktyką ma zasadnicze znaczenie.

Polityka zbyt ogólna nie pomaga pracownikowi zdecydować, czy może wkleić konkretny dokument. W praktyce oznacza to konieczność połączenia analizy prawnej z realnym procesem biznesowym. Dla obszaru „RODO i generatywna AI” kluczowe jest ustalenie odpowiedzialności, źródła danych i momentu, w którym decyzja wymaga eskalacji. Dopiero na tej podstawie można dobrać dokumenty, kontrolki techniczne i procedury, które rzeczywiście będą używane. Z punktu widzenia dowodowego warto zachować nie tylko finalną politykę, ale także historię decyzji, wyniki przeglądów i działania korygujące.

• Stwórz prostą macierz: dane publiczne, wewnętrzne, poufne, dane osobowe zwykłe, szczególne kategorie i tajemnice; przypisz do nich dozwolone narzędzia i działania.
• Zapisz wynik oceny w jednym miejscu i wskaż osobę odpowiedzialną za jego aktualizację po zmianie systemu, dostawcy lub procesu.
• Ustal trigger ponownego przeglądu: incydent, istotna zmiana umowy, nowa kategoria danych, zmiana modelu biznesowego albo wymagania regulatora.

Przykład: Pracownik powinien w kilka sekund wiedzieć, czy zadanie może wykonać w narzędziu publicznym, firmowym enterprise, lokalnym modelu albo bez AI.

Warstwa umowna i dowodowa powinna być analizowana równolegle. Jeżeli obowiązek jest wykonywany przez zewnętrznego dostawcę, organizacja nadal powinna wiedzieć, jakie informacje otrzyma, w jakim czasie i jak zweryfikuje ich jakość. W relacjach wewnętrznych potrzebny jest natomiast jasny podział pomiędzy właścicielem biznesowym, IT, bezpieczeństwem, ochroną danych i compliance. Nie każdy temat wymaga rozbudowanego komitetu, ale każdy istotny proces powinien mieć osobę zdolną podjąć decyzję.

Przy projektowaniu kontroli należy unikać dwóch skrajności. Pierwszą jest formalizm: tworzenie wielu dokumentów bez związku z codzienną pracą. Drugą jest nadmierna improwizacja, w której decyzje nie są odtwarzalne. Dobrze zaprojektowany model pozostawia ślad wystarczający do audytu, ale jednocześnie jest możliwy do wykonania przez zespół w normalnym rytmie pracy.

Checklista dla zarządu i właściciela procesu

1. Potwierdź kwalifikację prawną i zapisz jej uzasadnienie.
2. Zidentyfikuj systemy, dane, dostawców i procesy krytyczne.
3. Przypisz właścicieli obowiązków i punkty eskalacji.
4. Sprawdź umowy, incydenty, dostęp do logów i współpracę z dostawcami.
5. Zbuduj dowody działania: rejestry, testy, protokoły decyzji i działania korygujące.
6. Ustal cykliczny przegląd i triggery ponownej oceny.

Podstawowe źródła prawne i urzędowe

• Rozporządzenie (UE) 2016/679 (RODO)
• EDPB/UODO — materiały dotyczące modeli AI, anonimizacji i web scrapingu

Przed podjęciem decyzji wdrożeniowej należy sprawdzić aktualne brzmienie przepisów, akty wykonawcze i stanowiska właściwych organów, zwłaszcza gdy harmonogram regulacji jest w toku zmian.

Powiązane obszary

• AI Act 2026 w firmie — praktyczne rozwinięcie powiązanego ryzyka.
• Cyberincydent i ransomware — praktyczne rozwinięcie powiązanego ryzyka.
• Umowy IT, SaaS i cloud — praktyczne rozwinięcie powiązanego ryzyka.

Powiązane materiały w klastrze

• Zero Trust, NIS2 i DORA — fundament cyberbezpieczeństwa

Najczęstsze pytania