Blog
RODO a agenci AI: jak zapewnić bezpieczeństwo danych i rezydencję w UE
RODO a agenci AI - co właściwie podlega przepisom
Agent AI, który odbiera zgłoszenia z maila, WhatsApp albo telefonu i przeszukuje dokumenty firmy, przetwarza dane osobowe dokładnie tak samo jak każdy inny system IT, czyli CRM, system ticketowy czy poczta firmowa. RODO nie robi tu wyjątku dla sztucznej inteligencji. Jeśli w treści zgłoszenia pojawia się imię i nazwisko, numer telefonu, PESEL, adres, a w branży medycznej informacja o stanie zdrowia, agent staje się elementem procesu przetwarzania danych. Podlega tym samym zasadom co każdy inny system, przez który te dane przechodzą. Automatyzacja niczego tu nie zmienia. Odpowiedzialność administratora nie znika, tylko przenosi się na wcześniejszy etap, czyli projektowanie systemu.
W praktyce firma, która wdraża agenta, zostaje administratorem danych, a dostawca modelu językowego, czyli Anthropic, OpenAI albo ktoś inny, staje się podmiotem przetwarzającym. Z takim dostawcą trzeba mieć podpisaną umowę powierzenia zgodną z art. 28 RODO, i to nie jest formalność do odhaczenia na końcu projektu. Zanim agent trafi do produkcji, dobrze mieć odpowiedzi na cztery pytania: gdzie fizycznie trafiają dane, jak długo są przechowywane, kto poza modelem ma do nich dostęp i czy da się je usunąć na żądanie osoby, której dotyczą. Brak odpowiedzi na którekolwiek z nich już na etapie prototypu prawie zawsze kończy się przebudową architektury później.
Gdzie faktycznie trafiają dane, gdy agent odbiera zgłoszenie
Kiedy agent AI przetwarza wiadomość, jej treść trafia do modelu językowego przez API dostawcy. Dane na chwilę opuszczają infrastrukturę firmy klienta i lądują na serwerach Anthropic, OpenAI albo innego dostawcy, zwykle poza Polską. Samo w sobie to nie jest problem, o ile są do tego odpowiednie podstawy prawne i umowa. Najważniejsze pytanie brzmi, co dzieje się z tą treścią dalej. Czy jest zapisywana na dłużej niż trwa samo zapytanie, czy służy do trenowania modelu, jak długo leży w logach dostawcy i kto w razie audytu może je przejrzeć.
Anthropic i OpenAI mają plany biznesowe, w których dane z API nie są używane do trenowania modeli, a retencja logów jest ograniczona do krótkiego okresu potrzebnego na diagnostykę błędów i wykrywanie nadużyć. To nie jest jednak ustawienie domyślne w każdym planie. W niektórych warstwach cenowych, zwłaszcza konsumenckich, dane mogą domyślnie służyć do rozwoju modelu, więc trzeba to świadomie wyłączyć i zapisać w umowie, zanim agent zacznie pracować na prawdziwych danych klientów. Dlatego wybór dostawcy modelu to dla mnie nie tylko kwestia jakości odpowiedzi. Ustalam go zawsze razem z warunkami przetwarzania danych, nie po fakcie.
Dane w UE - co rezydencja danych oznacza w praktyce
Dla firm z branży kadrowej, prawnej czy medycznej rezydencja danych w UE bywa warunkiem koniecznym, a nie tylko dobrą praktyką. Czasem wynika to wprost z umowy z klientem końcowym, czasem z wewnętrznej polityki bezpieczeństwa. W praktyce oznacza wybór regionu europejskiego dla każdego elementu architektury: bazy wektorowej, logów rozmów, kolejki zadań, backupów i wszystkich usług pomocniczych biorących udział w przetwarzaniu.
Rezydencja danych nie kończy się na modelu językowym. Sam model może odpowiadać z serwera w Irlandii albo we Frankfurcie, ale jeśli baza wektorowa albo system kolejkowy stoi w regionie USA, cała architektura traci sens z punktu widzenia RODO. Dane i tak trafiają poza UE, tylko przez inny komponent niż ten, na który wszyscy patrzą. Dlatego przy wdrożeniach GenAI w produkcie sprawdzam każdy komponent osobno, nie tylko punkt wejścia do modelu, czyli kolejkę zadań, pamięć podręczną, pliki tymczasowe, logi z monitoringu.
Klucze API, limity kosztów i kontrola nad modelem
Własne klucze API, czyli BYOK, dają firmie pełną kontrolę nad tym, co dzieje się z jej danymi. To klient jest wtedy stroną umowy z dostawcą modelu, a nie zewnętrzna platforma pośrednicząca, która agreguje ruch wielu klientów pod jednym kontem. Przy BYOK firma klienta bezpośrednio podpisuje umowę powierzenia z Anthropic czy OpenAI, więc dokładnie wie, na jakich warunkach dane są przetwarzane. To też jedyny sposób, żeby mieć realny wgląd w logi zapytań i limity zużycia.
Limity kosztów to nie tylko kwestia budżetu. Twardy limit na liczbę zapytań i wydatki miesięczne wymusza też dyscyplinę w tym, ile danych i jak często trafia do modelu. Agent bez limitu może zacząć wysyłać całe dokumenty tam, gdzie wystarczyłby jeden akapit, bo nikt tego nie pilnuje. Routing między więcej niż 35 modelami pozwala dodatkowo dobrać dostawcę i region hostingu do wrażliwości procesu, zamiast stosować jedno podejście do wszystkiego. Dane kadrowe mogą iść przez model z serwerami w UE, a prosty chatbot FAQ przez tańszy model bez takich wymagań.
Pseudonimizacja i logi w praktyce - case study Janina
Janina, asystentka kadrowa AI działająca w produkcji od 2026 roku, pracuje na hybrydowym RAG łączącym wyszukiwanie semantyczne i BM25 po 40 aktach prawnych i ponad 900 dokumentach, w tym orzecznictwie Sądu Najwyższego. Każda odpowiedź ma numer artykułu ustawy, na którym się opiera. To warunek, żeby dział kadr mógł ją zweryfikować, zamiast ślepo zaufać. Dane w systemie są pseudonimizowane na poziomie architektury, a nie jako dodatek dorzucony na końcu.
Pseudonimizacja w praktyce oznacza rozdzielenie danych identyfikujących osobę od treści trafiającej do modelu. Zamiast imienia i nazwiska pracownika w zapytaniu pojawia się identyfikator wewnętrzny, a mapowanie między nim a prawdziwą tożsamością siedzi osobno, w bazie z ograniczonym dostępem. Janina pilnuje terminów ZUS i PIT, generuje dokumenty kadrowe i integruje się z KSeF, działając na WhatsApp, a mimo to dane osobowe pracowników nie trafiają do modelu w formie umożliwiającej bezpośrednią identyfikację. Ten mechanizm trzeba zaprojektować, zanim powstanie pierwsza integracja, bo dołożenie pseudonimizacji do gotowego systemu oznacza przebudowę większości logiki agenta.
Chmura klienta, chmura UE czy on-premise - jak wybrać
Nie każdy proces wymaga tego samego poziomu izolacji danych. Dla wielu firm wystarczy chmura klienta albo chmura UE z jasno określonym dostawcą i regionem, taniej i szybciej we wdrożeniu, a przy tym w pełni zgodnie z RODO, jeśli dostawca ma odpowiednie certyfikaty i umowę powierzenia. Dla danych szczególnie wrażliwych, czyli kadrowych, medycznych czy finansowych, lepszym wyborem bywa on-premise, gdzie infrastruktura fizycznie stoi u klienta albo w kontrolowanym przez niego centrum danych.
W ClawLabs, studiu które prowadzę razem z zespołem, hosting agentów AI w produkcji działa na osobnym serwerze dla każdego agenta, w chmurze UE albo on-premise, z ponad 35 modelami LLM i automatycznym failoverem między nimi. Taki podział ogranicza wpływ awarii jednego agenta na resztę systemu i ułatwia audyt tego, gdzie dokładnie przetwarzane są dane danego procesu. Ten wybór rzadko jest zresztą jednorazowy. Widziałem projekty, które zaczynały w chmurze UE, a po kilku miesiącach, kiedy skala i wrażliwość danych rosły, przechodziły na on-premise.
Ile kosztuje bezpieczne wdrożenie i najczęstsze błędy
Orientacyjnie, na rynku polskim i unijnym w 2026 roku prosty agent AI obsługujący jeden kanał komunikacji to zwykle koszt rzędu kilkunastu do kilkudziesięciu tysięcy złotych. System wieloagentowy z orkiestracją, RAG i integracjami może kosztować od kilkudziesięciu do kilkuset tysięcy złotych, zależnie od liczby integracji i wymagań co do hostingu. To są widełki rynkowe, nie cennik konkretnego wdrożenia. Na koszt wpływa też to, czy bezpieczeństwo danych trzeba projektować od zera, czy klient ma już wewnętrzne standardy. Każdy projekt wyceniam po rozmowie i prototypie.
Najczęstsze błędy, jakie widzę: brak podpisanej umowy powierzenia z dostawcą modelu, wysyłanie danych osobowych bez pseudonimizacji tam, gdzie nie jest to konieczne, brak twardych limitów kosztów, które ograniczyłyby też skalę przetwarzanych danych, oraz brak logów wystarczających do wykazania zgodności podczas kontroli. Częsty jest też błąd organizacyjny, gdy nikt w firmie nie wie, kto odpowiada za dane po stronie agenta, bo temat przechodzi między działem IT a prawnym i nie ma jednego właściciela decyzji. Każdy z tych elementów da się rozwiązać już na etapie prototypu, zanim agent trafi do produkcji.
Najczęstsze pytania
Czy przesyłanie danych klientów do modelu językowego, np. Claude albo GPT, jest zgodne z RODO?
Tak, pod warunkiem podpisania umowy powierzenia z dostawcą modelu, wyłączenia trenowania na danych klienta i ustalenia, gdzie oraz jak długo dane są przechowywane. Konfiguruję to od pierwszego dnia wdrożenia, jeszcze przed etapem prototypu.
Czy agent AI może działać wyłącznie w infrastrukturze w Unii Europejskiej?
Tak. Model językowy, baza wektorowa i logi mogą działać w regionach UE, a jeśli to za mało ze względu na wrażliwość danych, całego agenta można postawić on-premise, na serwerach klienta albo w kontrolowanym przez niego centrum danych.
Ile trwa wdrożenie agenta AI zgodnego z RODO?
Proces zaczyna się od godzinnej rozmowy o tym, co zajmuje czas zespołu, potem przez dwa tygodnie budowany jest prototyp na prawdziwych danych klienta. Kontrola kosztów, logi i zgodność z RODO są częścią architektury od pierwszego dnia, nie dodatkiem na końcu.
Co się dzieje z danymi, jeśli osoba, której dotyczą, poprosi o ich usunięcie?
Taką prośbę realizuje się na dwóch poziomach: usuwa się dane z bazy wektorowej i logów po stronie infrastruktury klienta, i sprawdza się, czy dostawca modelu w ogóle przechowuje treść zapytania dłużej niż trzeba do wygenerowania odpowiedzi. Przy poprawnie skonfigurowanym API ten drugi krok sprowadza się właściwie do potwierdzenia, że danych już tam nie ma.
Zobacz też
Jeśli zastanawiasz się, czy dane w Twojej firmie będą bezpieczne przy wdrożeniu agentów AI, porozmawiajmy o architekturze, zanim powstanie pierwsza linijka kodu.
Kontakt
Masz proces, który zjada czas zespołu?
Napisz dwa zdania o tym, co boli. Odpiszę i powiem wprost, czy warto to automatyzować.
albo zadzwoń +48 735 170 951 · +48 516 461 444
Zwykle odpisuję tego samego dnia.