Agent AI i dane klientów: RODO, NIS2, DORA i europejskie endpointy

Weźmy firmę IT, która używa Claude Code do analizy problemów na infrastrukturze klienta. Agent ma dostęp do CloudWatch, konfiguracji aplikacji, logów i systemu zgłoszeniowego. Dostaje polecenie: przeanalizuj powtarzające się błędy i zaproponuj poprawki.

Żeby to zrobić, czyta fragmenty logów, konfiguracje i treść zgłoszeń, a część z nich trafia do kontekstu wysyłanego do modelu.

Sam sporo eksperymentuję z agentami AI przy swoich projektach infrastrukturalnych i automatyzacji i widzę, ile potrafią, kiedy dostaną odpowiednie narzędzia i kontekst. Chcę tu postawić inne pytanie: co dzieje się z danymi, do których agent dostaje dostęp? Najważniejsze staje się ono wtedy, gdy automatyzacja przestaje dotyczyć własnego projektu, a zaczyna korzystać z infrastruktury i informacji klienta.

Agent w AWS nie znaczy, że dane zostają w AWS

To, że agent działa na moim komputerze albo woła AWS CLI, mówi tylko, skąd pobiera dane. Nie mówi, gdzie model je przetwarza. Claude Code korzystający z bezpośredniej usługi Anthropic może przekazywać kontekst do Anthropic. Claude uruchamiany przez Amazon Bedrock korzysta z infrastruktury i warunków przetwarzania AWS.

Dla użytkownika efekt wygląda podobnie. Z punktu widzenia ochrony danych i zobowiązań umownych to dwa różne rozwiązania.

DPA, ZDR i europejski endpoint

Rozmowy o prywatności AI często sprowadzają się do pytania, czy dostawca trenuje modele na naszych danych. To za mało.

DPA (Data Processing Agreement) określa zasady powierzenia przetwarzania danych osobowych i ma znaczenie wtedy, gdy dostawca AI przetwarza je w imieniu organizacji. ZDR (Zero Data Retention) ogranicza przechowywanie danych przesłanych do modelu. Nie każda usługa go oferuje, a RODO nie wymaga go bezwzględnie. Data residency mówi, gdzie dane są przechowywane lub przetwarzane, a to nie zawsze to samo miejsce. Europejski adres API nie gwarantuje, że wszystkie komponenty usługi działają tylko w Europie. Wyłączenie trenowania modelu nie oznacza ZDR.

Są też dane, które nie są osobowe, a są poufne: dokumentacja techniczna, tajemnica przedsiębiorstwa, informacje objęte NDA, sekrety dostępowe. RODO ich nie obejmuje, ale umowa z klientem prawie na pewno tak.

Do relacji firmy IT z klientem i do tego, co z niej wynika, wracam w następnej sekcji.

RODO, NIS2 i DORA wobec agenta AI

To trzy osobne akty o różnym przedmiocie i różnych adresatach. Klient może podlegać jednemu z nich, kilku albo żadnemu, a od tego zależy, co firma IT musi mu zagwarantować w umowie. Streszczam przepisy tak, jak je czytam, z numerami artykułów. To nie jest porada prawna: granice zakresu w konkretnym przypadku ocenić powinien Twój prawnik.

RODO i DPA: dane osobowe w kontekście agenta

RODO obowiązuje niezależnie od branży i dotyczy danych osobowych, a nie informacji poufnych w ogóle. Logi z adresami e-mail, zgłoszenia z danymi kontaktowymi, rekordy z bazy klienta: jeśli agent je czyta i wysyła do modelu, to jest przetwarzanie danych osobowych.

Jeśli firma IT robi to na polecenie klienta, jest podmiotem przetwarzającym, a klient administratorem. Art. 28 RODO ustawia wtedy trzy reguły, które przy agentach łatwo przeoczyć.

Pierwsza dotyczy dalszego powierzenia. Podmiot przetwarzający nie może zaangażować kolejnego podmiotu przetwarzającego bez uprzedniej szczegółowej lub ogólnej pisemnej zgody administratora. Przy zgodzie ogólnej musi informować o zamiarze dodania albo zastąpienia takiego podmiotu i dać administratorowi możliwość sprzeciwu (art. 28 ust. 2). Dostawca modelu, do którego trafia kontekst z danymi osobowymi, jest w tym układzie takim kolejnym podmiotem. Dodanie go do procesu albo zmiana na innego dostawcę nie jest więc decyzją wyłącznie techniczną.

Druga dotyczy treści umów. Umowa z administratorem musi m.in. przewidywać przetwarzanie wyłącznie na udokumentowane polecenie administratora, także w sprawie przekazywania danych do państwa trzeciego, usunięcie albo zwrot danych po zakończeniu usług oraz udostępnianie informacji i umożliwienie audytów (art. 28 ust. 3 lit. a, g i h). Tę samą ochronę trzeba umownie nałożyć na kolejny podmiot przetwarzający, a podmiot pierwotny odpowiada wobec administratora za wykonanie jego obowiązków (art. 28 ust. 4). DPA z dostawcą modelu zamyka więc tylko jedną połowę łańcucha. Druga to zgoda i warunki z umowy z klientem, których DPA z dostawcą nie zastępuje.

Trzecia dotyczy lokalizacji. Jeśli dostawca przetwarza dane poza Europejskim Obszarem Gospodarczym, wchodzi rozdział V RODO o przekazywaniu danych do państw trzecich. Dlatego pytanie o endpoint i region ma skutek prawny: od niego zależy, czy przekazanie w ogóle następuje.

ZDR nie jest wymogiem RODO, ale moim zdaniem pomaga w tej samej sprawie. Im krócej dostawca trzyma dane, tym łatwiej spełnić obowiązek usunięcia albo zwrotu po zakończeniu usług. Najtańszym środkiem zostaje jednak nie wysyłać danych osobowych w ogóle: maskowanie albo anonimizacja logów, zanim trafią do kontekstu, to zasada minimalizacji danych w praktyce (art. 5 ust. 1 lit. c).

NIS2: dwa różne powody, dla których może dotyczyć

NIS2 nie reguluje danych, tylko bezpieczeństwo sieci i systemów informatycznych. Wchodzi do tej historii na dwa sposoby.

Po pierwsze, firma IT sama może być w zakresie. Dostawcy usług zarządzanych (managed service providers) i dostawcy zarządzanych usług bezpieczeństwa (MSSP) są w załączniku I, w sektorze zarządzania usługami ICT w modelu B2B. Podmiot duży jest wtedy kluczowy, średni ważny, a małe i mikroprzedsiębiorstwa co do zasady zostają poza zakresem. Kto świadczy klientom takie usługi, powinien sprawdzić własny status, zanim zacznie rozmawiać o statusie klienta.

Po drugie, klient może być podmiotem kluczowym albo ważnym. Art. 21 ust. 2 lit. d wymaga wtedy od niego środków dotyczących bezpieczeństwa łańcucha dostaw, w tym relacji z bezpośrednimi dostawcami i usługodawcami. Ust. 3 każe uwzględniać podatności specyficzne dla każdego z nich oraz ogólną jakość ich produktów i praktyk cyberbezpieczeństwa. Firma IT jest takim bezpośrednim dostawcą. Dostawca modelu stoi dla klienta o jeden szczebel dalej, a dyrektywa mówi o dostawcach bezpośrednich. Moim zdaniem nie zwalnia to z odpowiedzi na pytanie, dokąd trafia kontekst, bo klient, który ocenia ryzyko dostawcy, ocenia też to, na czym ten dostawca polega.

Dochodzą incydenty. Art. 23 wymaga od podmiotów kluczowych i ważnych wczesnego ostrzeżenia w ciągu 24 godzin od stwierdzenia istotnego incydentu i zgłoszenia incydentu w ciągu 72 godzin. Czytam to tak, że wyciek kontekstu u dostawcy modelu może być istotnym incydentem po stronie klienta, jeśli spełnia kryteria z art. 23 ust. 3, a wtedy godziny biegną od chwili, w której klient się o nim dowiaduje. Umowa z firmą IT powinna więc mówić, w jakim czasie firma informuje klienta o incydencie u swoich dostawców.

W Polsce NIS2 wdraża nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa (Dz.U. 2026 poz. 252), w mocy od 3 kwietnia 2026 r. Wniosek o wpis do wykazu podmiotów kluczowych i ważnych trzeba było złożyć do 3 października 2026 r. Obowiązki, w tym system zarządzania bezpieczeństwem informacji (SZBI) i zgłaszanie incydentów, trzeba wdrożyć do 3 kwietnia 2027 r., a pierwszy audyt podmiotów kluczowych przeprowadzić do 3 kwietnia 2028 r. Administracyjne kary pieniężne za większość obowiązków można nakładać dopiero po 3 kwietnia 2028 r. Źródło: Ministerstwo Cyfryzacji, gov.pl.

DORA: gdy klient jest z sektora finansowego

DORA jest rozporządzeniem, więc działa bezpośrednio, bez wdrażania do prawa krajowego, i stosuje się od 17 stycznia 2025 r. Dotyczy podmiotów finansowych: banków, ubezpieczycieli, firm inwestycyjnych, instytucji płatniczych i innych, łącznie ponad 20 rodzajów. Dla takiego klienta firma IT jest dostawcą usług ICT (ICT third-party service provider), a klient musi mieć z nią umowę z elementami z art. 30.

Przy agencie znaczenie mają zwłaszcza te z ust. 2:

opis wszystkich funkcji i usług ICT oraz informacja, czy podwykonawstwo usługi wspierającej funkcję krytyczną lub ważną jest dozwolone i na jakich warunkach (lit. a);
lokalizacje, czyli regiony lub kraje, w których usługi są świadczone i dane przetwarzane, razem z miejscem przechowywania, oraz obowiązek wcześniejszego powiadomienia klienta o ich zmianie (lit. b);
postanowienia o dostępności, autentyczności, integralności i poufności danych, także osobowych (lit. c);
dostęp do danych, ich odzyskanie i zwrot w łatwo dostępnym formacie także przy upadłości dostawcy albo zakończeniu umowy (lit. d);
pomoc dostawcy przy incydencie związanym z usługą (lit. f).

Dla usług wspierających funkcje krytyczne lub ważne dochodzą m.in. nieograniczone prawa dostępu, inspekcji i audytu oraz strategie wyjścia z okresem przejściowym (ust. 3 lit. e i f). Ocena, czy dana funkcja jest krytyczna lub ważna, należy do klienta.

Podwykonawstwo ma osobny akt: rozporządzenie delegowane Komisji (UE) 2025/532 o elementach, które podmiot finansowy ocenia, gdy usługi ICT wspierające funkcje krytyczne lub ważne są podwykonywane. Wśród elementów umowy są m.in. te same prawa dostępu, inspekcji i audytu dla klienta i organów nadzoru wobec podwykonawcy, obowiązek powiadamiania o istotnych zmianach w podwykonawstwie i prawo klienta do wypowiedzenia umowy. Do tego klient prowadzi rejestr informacji o umowach na usługi ICT i musi umieć zidentyfikować łańcuch podwykonawców (art. 28 ust. 3).

Moim zdaniem dostawca modelu, do którego agent wysyła kontekst klienta, jest w tym łańcuchu podwykonawcą usługi ICT, o ile agent wspiera usługę świadczoną klientowi. Wtedy globalny endpoint bez gwarancji lokalizacji trudno pogodzić z klauzulą o lokalizacji przetwarzania, a dostawcę, który nie zgodzi się na audyt, z wymaganiami dla funkcji krytycznych. Regionalny endpoint, ZDR i warunki umowy z dostawcą modelu przestają być wtedy preferencją, a stają się elementem umowy z klientem.

Co z tego wynika dla umowy z klientem

Z tych trzech źródeł wychodzi podobna lista rzeczy do ustalenia, zanim agent dostanie dostęp do czegokolwiek:

czy klient podlega NIS2, DORA, obu albo żadnemu z nich, i co jego wymagania wobec dostawców mówią o AI;
czy umowa dopuszcza podwykonawców i jak klient wyraża na nich zgodę (art. 28 ust. 2 RODO, art. 30 ust. 2 lit. a DORA);
gdzie dostawca modelu przetwarza i przechowuje dane oraz jak klient dowie się o zmianie lokalizacji;
jak długo dostawca trzyma dane i czy da się to skrócić (ZDR);
jak wygląda audyt i dostęp dla klienta oraz organu nadzoru;
w jakim czasie firma IT informuje klienta o incydencie u dostawcy;
co dzieje się z danymi po zakończeniu współpracy: usunięcie albo zwrot.

Przepisy w oryginale: RODO, NIS2, DORA i rozporządzenie delegowane 2025/532.

Dostawcy i tryby wdrożenia

Żeby rozsądniej podchodzić do danych, nie trzeba rezygnować z agentów. Poniżej opcje z dokumentacji dostawców.

Mistral AI - europejski endpoint i możliwość ZDR

Oprócz globalnego API Mistral ma regionalny endpoint api.eu.mistral.ai, który wykonuje inferencję w centrach danych w UE i państwach EFTA. Dla zwykłego api.mistral.ai Mistral nie gwarantuje konkretnej lokalizacji inferencji.

Regionalna inferencja kosztuje obecnie o 10% więcej, a nie wszystkie modele i funkcje są na niej dostępne. Function calling działa, ale brakuje części narzędzi i usług stanowych, na przykład zarządzanego Agents API i Files API.

Mistral udostępnia DPA oraz ZDR dla wspieranych bezstanowych wywołań API w płatnych planach. ZDR wymaga zgłoszenia i zatwierdzenia, nie obejmuje wszystkich produktów, a ustawienia trenowania są osobne. Regionalna inferencja nie oznacza też, że metadane operacyjne i systemy zarządzania kontami są w UE. Mistral sam o tym pisze.

Moim zdaniem to dobry wariant dla firm, które chcą uruchamiać własną logikę agentową na europejskim endpoincie modelu, zamiast oddawać całą orkiestrację zewnętrznej platformie.

Dokumentacja: Mistral Regional Inference oraz Zero Data Retention.

OpenAI - europejska rezydencja danych w API

OpenAI ma regionalny endpoint eu.api.openai.com. Dla kwalifikujących się projektów API można ustawić europejską lokalizację przetwarzania i przechowywania danych razem z kontrolą retencji, taką jak ZDR albo Modified Abuse Monitoring.

Nie każda subskrypcja ChatGPT i nie każde użycie API ma automatycznie europejską rezydencję danych. Zależy to od projektu, modelu, endpointu i używanych funkcji. To dobra opcja, jeśli potrzebny jest model OpenAI i większa kontrola nad przetwarzaniem.

Dokumentacja: OpenAI Data Controls.

Anthropic - subskrypcja a komercyjne API

Prywatna subskrypcja Claude Pro lub Max nie daje takich samych warunków ochrony danych jak komercyjne API albo wdrożenie Enterprise. Cena abonamentu Max tego nie zmienia.

Anthropic udostępnia DPA w warunkach komercyjnych, a w standardowej ofercie komercyjnej domyślnie nie trenuje modeli na danych wejściowych i wyjściowych. ZDR jest dostępne dla kwalifikujących się zastosowań API i Claude Code Enterprise, ale wymaga osobnych ustaleń lub aktywacji. Do oceny trzeba dołożyć domyślny model lokalizacji i retencji danych Anthropic.

Dokumentacja: Anthropic API and Data Retention.

Amazon Bedrock - dla organizacji, które już są w AWS

Bedrock daje dostęp do wielu rodzin modeli przez infrastrukturę AWS. Można wybrać obsługiwane regiony europejskie albo profile inferencji ograniczone do geografii UE, zamiast globalnego routingu. Do tego dochodzą mechanizmy AWS: IAM, kontrola dostępu i zarządzanie przetwarzaniem. Według dokumentacji AWS zewnętrzni dostawcy modeli nie dostają dostępu do promptów i odpowiedzi przetwarzanych przez Bedrock.

To nie jest gwarancja zerowej retencji we wszystkich przypadkach. Niektóre modele i funkcje mają własne wymagania dotyczące przechowywania danych, na przykład na potrzeby kontroli nadużyć. Trzeba więc sprawdzić konkretny model, region, profil inferencji i ustawienia retencji.

Dokumentacja: AWS Bedrock Geographic Inference.

Microsoft Azure i Google Cloud

Microsoft Foundry oferuje m.in. wdrożenia Global, Data Zone i regionalne. Zasób utworzony w europejskim regionie Azure nie musi oznaczać, że inferencja odbywa się tylko w Europie, bo zależy to od typu deploymentu. Wdrożenia EU Data Zone ograniczają przetwarzanie do europejskiej strefy danych zdefiniowanej przez Microsoft, a dla wybranych modeli są też wdrożenia o węższej geografii.

Podobne możliwości ma Google Cloud w Vertex AI, rozwijanym obecnie w ramach Gemini Enterprise Agent Platform. Tu również trzeba sprawdzić dostępność konkretnego modelu i funkcji regionalnych. Nie wszystkie usługi pomocnicze, na przykład grounding, mają takie same gwarancje dotyczące danych.

Dla organizacji, które już działają w tych ekosystemach, istniejące umowy, IAM i kontrole bezpieczeństwa mogą być praktyczniejsze niż kolejny dostawca bezpośredniego API.

Dokumentacja: Microsoft Foundry Deployment Types oraz Google Cloud Data Residency.

Modele lokalne i prywatna infrastruktura

Wybrane modele open-weight, na przykład z rodziny Mistral lub Devstral, można uruchomić na własnej infrastrukturze albo u dostawcy hostingu, który spełnia uzgodnione wymagania. Daje to większą kontrolę nad tym, gdzie odbywa się inferencja i kto ma dostęp do jej danych. Prompty nie trafiają do zewnętrznego API modelu, o ile cały przepływ rzeczywiście zostaje lokalny.

To nie rozwiązuje automatycznie bezpieczeństwa i RODO: nadal odpowiadamy za infrastrukturę, logi, uprawnienia, zabezpieczenia i retencję. Dochodzą koszt utrzymania, sprzęt i potencjalnie niższa jakość w złożonych zadaniach agentowych. Trzeba też sprawdzić licencję wybranego modelu.

Nie traktowałbym self-hostingu jako obowiązku dla każdej firmy. To realna opcja tam, gdzie potrzebna jest szczególna kontrola.

Ograniczenia agenta to więcej niż wybór dostawcy

Moim zdaniem ważniejsze od wyboru modelu jest to, jak zaprojektowana jest cała automatyzacja. Agent nie powinien dostawać dostępu do wszystkich systemów tylko dlatego, że technicznie da się go z nimi połączyć. Najbardziej ostrożnie podchodziłbym do zbierania poczty, zgłoszeń, dokumentacji klientów i logów w jednym kontekście.

Zanim agent dostanie takie uprawnienia, odpowiedziałbym na kilka pytań:

Czy naprawdę potrzebuje tych danych, czy wystarczy ich ograniczony lub zanonimizowany fragment?
Czy umowy z klientami pozwalają na użycie zewnętrznego dostawcy AI?
Czy znamy trasę przesyłania danych, podwykonawców, lokalizację przetwarzania i zasady retencji?
Czy możemy technicznie ograniczyć dostęp agenta i wymagać zatwierdzenia istotnych zmian?
Czy nasze logi i narzędzia monitorujące same nie zaczynają przechowywać danych, których nie chcieliśmy ujawniać?

W projektach agentowych oddzielam model, który podejmuje decyzje, od systemu, który egzekwuje uprawnienia. Agent może być bardzo zaawansowany i mieć jednocześnie zablokowany dostęp do sekretów, produkcji i dokumentacji klientów. Zatwierdzanie niebezpiecznych operacji powinno być wymuszane technicznie, niezależnie od instrukcji, którą dostał model.

Automatyzować można, ale ze świadomością, co się wysyła

Nie uważam, że firmy powinny bać się agentów AI. Widzę w nich duży potencjał w administracji, analizie incydentów, obsłudze klientów i codziennej pracy operacyjnej. Rozwiązanie, które świetnie działa na prywatnym homelabie, nie zawsze przeniesie się bez zmian do środowiska klienta, bo klient ma własne obowiązki: wobec RODO, a zależnie od sektora także wobec NIS2 albo DORA.

Nie potrzebujemy ZDR do każdego zastosowania AI i nie zawsze potrzebujemy własnego modelu. Potrzebujemy wiedzieć, jakie dane przetwarzamy, na jakiej podstawie i komu je powierzamy.

Stan porównania warunków i dokumentacji dostawców oraz przepisów: 10 października 2026 r. Dostępność funkcji, modele rozliczeń, warunki przetwarzania i terminy wdrożeniowe mogą się zmieniać.