OpenClaw a RODO - czy agent AI jest zgodny z prawem w UE?

Znasz tę sytuację. Ktoś z zarządu wraca z konferencji i mówi: "musimy wdrożyć agenta AI". Albo właściciel firmy przeczytał artykuł na LinkedIn i chce, żebyś "ogarnął tego OpenClaw". I teraz Ty, jako CTO, IT manager, albo ta jedna osoba w firmie, która "ogarnia technologię", musisz odpowiedzieć na pytanie: czy możemy to legalnie uruchomić?

Odpowiedź nie jest prosta. Nie jest "tak" ani "nie". Jest "to zależy od tego, jak to skonfigurujesz, jakie dane przetwarzasz i przez jakie API przechodzą". Ten artykuł rozpisuje każdy element tej odpowiedzi.

Jedno zastrzeżenie na starcie: to nie jest porada prawna. To analiza techniczna z kontekstem regulacyjnym, napisana przez inżynierów, którzy wdrażają agentów AI w polskich firmach i muszą odpowiadać na te pytania przed każdym klientem. Jeśli potrzebujesz formalnej opinii prawnej, idź do prawnika. Jeśli potrzebujesz zrozumieć, o czym ten prawnik będzie mówił - czytaj dalej.

Jak przepływają dane w OpenClaw

Żeby ocenić zgodność z RODO, musisz rozumieć architekturę. Nie na poziomie abstrakcji "AI przetwarza dane", ale na poziomie "które bajty lecą gdzie".

OpenClaw działa jako warstwa orkiestracji. Sam w sobie nie jest modelem AI. Jest programem, który siedzi na Twoim komputerze (albo serwerze) i koordynuje działania: odbiera polecenie od użytkownika, decyduje jakie narzędzia uruchomić, wysyła zapytanie do modelu językowego, odbiera odpowiedź, wykonuje akcję. Kluczowe jest to, co dzieje się w kroku "wysyła zapytanie do modelu językowego".

Przepływ danych wygląda tak:

Krok 1: Użytkownik (Twój pracownik albo klient) wpisuje tekst lub agent odczytuje dane z podłączonego narzędzia (mail, CRM, dokument). Te dane są na Twoim serwerze. Na razie wszystko w porządku.

Krok 2: OpenClaw buduje prompt. Łączy kontekst systemowy (instrukcje, kim jest agent, jak ma się zachowywać), dane z narzędzi (treść maila, fragment dokumentu, informację z CRM) i samo zapytanie użytkownika. Ten prompt zawiera dane osobowe, jeśli dane wejściowe je zawierały. Imię klienta w mailu? Jest w prompcie. Numer telefonu w CRM? Jest w prompcie. Adres z faktury? Jest w prompcie.

Krok 3: OpenClaw wysyła ten prompt przez API do zewnętrznego dostawcy modelu językowego. I tu zaczyna się problem.

Jeśli używasz OpenAI API, Twoje dane lecą na serwery w USA. Jeśli używasz Anthropic API, Twoje dane lecą na serwery w USA (z opcją AWS w Europie, ale nie domyślnie). Jeśli używasz Google Gemini, Twoje dane lecą na serwery w USA. Jeśli hostujesz model lokalnie (Llama, Mistral), dane nigdzie nie lecą - ale o tym za chwilę.

Krok 4: Dostawca API przetwarza prompt, generuje odpowiedź i odsyła ją do OpenClaw. W tym momencie Twoje dane osobowe zostały przesłane poza EOG (Europejski Obszar Gospodarczy), przetworzone przez podmiot trzeci i potencjalnie zalogowane.

To jest fundamentalny problem z punktu widzenia RODO.

Artykuł 44 RODO: transfer danych poza EOG

RODO nie zabrania przesyłania danych osobowych poza Europę. Ale ustanawia rygorystyczne warunki, pod którymi jest to legalne.

Decyzja o adekwatności. Komisja Europejska może uznać, że dany kraj zapewnia odpowiedni poziom ochrony danych. Dla USA obowiązuje EU-US Data Privacy Framework (DPF), przyjęty w lipcu 2023. OpenAI i Google są certyfikowane w ramach DPF. Anthropic również. Technicznie, transfer danych do tych dostawców jest legalny pod DPF.

Ale jest haczyk. DPF jest kwestionowany przez organizacje zajmujące się ochroną prywatności (NOYB, EDPB) i może zostać unieważniony przez TSUE, tak jak wcześniej Privacy Shield (unieważniony w 2020 - wyrok Schrems II) i Safe Harbor (unieważniony w 2015 - wyrok Schrems I). Jeśli DPF padnie, firmy, które opierały swoją strategię compliance wyłącznie na nim, z dnia na dzień stracą podstawę prawną do transferu danych.

To nie jest spekulacja. To jest scenariusz, który wydarzył się już dwukrotnie.

Standardowe klauzule umowne (SCC). Alternatywa dla decyzji o adekwatności. Podpisujesz z dostawcą API umowę zawierającą standardowe klauzule zatwierdzone przez KE. OpenAI i Anthropic oferują SCC w swoich umowach. Ale SCC same w sobie nie wystarczą, jeśli prawo kraju docelowego (w tym przypadku USA, z jej FISA 702 i Executive Order 12333) pozwala służbom na dostęp do danych bez wiedzy podmiotu danych.

Podejście pragmatyczne. Czy UODO (polski organ nadzorczy) przyjdzie do Twojej firmy z 20 pracownikami i nałoży karę za to, że agent AI wysyła maile klientów przez API OpenAI? Prawdopodobnie nie. Czy może? Tak. Czy ryzyko rośnie, jeśli przetwarzasz dane wrażliwe (dane medyczne, dane finansowe, dane pracownicze)? Zdecydowanie tak.

Problem z DPA: czego OpenClaw nie oferuje

DPA (Data Processing Agreement, po polsku: umowa powierzenia przetwarzania danych osobowych) to dokument wymagany przez Art. 28 RODO, gdy powierzasz przetwarzanie danych osobowych innemu podmiotowi.

OpenClaw jest oprogramowaniem open-source. Nie jest podmiotem, z którym podpisujesz DPA. Nikt nie jest "dostawcą OpenClaw" w sensie prawnym. Nie ma firmy, która bierze odpowiedzialność za to, jak narzędzie przetwarza dane. Nie ma SLA. Nie ma gwarancji bezpieczeństwa. Nie ma polityki retencji danych. Nie ma procedury Data Breach Notification.

To nie jest wada. To jest natura oprogramowania open-source. Ale ma konsekwencje prawne.

DPA musisz podpisać z dostawcą API (OpenAI, Anthropic, Google), z dostawcą hostingu (Hetzner, OVH, AWS) i z każdym innym podmiotem, któremu przekazujesz dane osobowe w ramach pipeline'u. I musisz zapewnić, że cały łańcuch przetwarzania jest udokumentowany w Twoim Rejestrze Czynności Przetwarzania (Art. 30 RODO).

OpenAI oferuje DPA. Anthropic oferuje DPA. Google oferuje DPA. Ale czy je przeczytałeś? Czy wiesz, jakie prawa retencji sobie zastrzegają? Czy wiesz, czy Twoje dane mogą być używane do trenowania modeli? (Spoiler: w większości przypadków dane z API nie są używane do treningu, ale diabeł tkwi w szczegółach i wersjach umów.)

Artykuł 35 RODO: DPIA - kiedy jest wymagane

Ocena Skutków dla Ochrony Danych (Data Protection Impact Assessment, DPIA) jest wymagana, gdy przetwarzanie "może powodować wysokie ryzyko naruszenia praw lub wolności osób fizycznych" (Art. 35 ust. 1).

Kiedy agent AI przetwarza dane osobowe klientów na dużą skalę - a 100+ interakcji dziennie to duża skala w kontekście DPIA - DPIA jest prawdopodobnie wymagane. Szczególnie jeśli przetwarzasz dane szczególnych kategorii (Art. 9): dane zdrowotne (klinika, apteka), dane dotyczące wyroków skazujących (kancelaria prawna), dane biometryczne, dane dotyczące orientacji seksualnej, przekonań religijnych, poglądów politycznych.

DPIA to nie formalność. To dokument, który wymaga: opisu operacji przetwarzania i celów, oceny konieczności i proporcjonalności, oceny ryzyka dla praw i wolności osób, których dane dotyczą, oraz środków zaradczych minimalizujących to ryzyko.

Jeśli nigdy nie robiłeś DPIA, to nie jest coś, co napiszesz w sobotę po obiedzie. To jest projekt, który wymaga zaangażowania IOD (Inspektora Ochrony Danych), jeśli go masz, albo zewnętrznego konsultanta, jeśli nie masz.

Praktyczne scenariusze: co jest OK, a co nie

Przejdźmy od teorii do praktyki. Oto konkretne scenariusze, z oceną ryzyka.

Scenariusz 1: Agent AI segreguje maile wewnętrzne. Maile od pracowników do pracowników. Dane osobowe: imiona, nazwiska, może numery telefonów. Ryzyko: niskie. Przetwarzanie wewnętrzne, dane pracownicze objęte inną podstawą prawną (Art. 6 ust. 1 lit. b - wykonanie umowy o pracę). Transfer do API: nadal problematyczny, ale ryzyko realne jest minimalne, bo to dane wewnętrzne, a nie dane klientów.

Scenariusz 2: Agent AI odpowiada klientom na WhatsApp. Dane osobowe klientów: imię, numer telefonu, treść rozmowy, potencjalnie dane wrażliwe (np. "mam ból zęba, czy przyjmujecie na NFZ?"). Ryzyko: średnie do wysokiego. Potrzebujesz: podstawy prawnej (zgoda lub prawnie uzasadniony interes), DPA z dostawcą API, informacji dla klientów o przetwarzaniu (Art. 13/14), i możliwości realizacji praw podmiotów danych (dostęp, usunięcie, sprostowanie).

Scenariusz 3: Agent AI przeszukuje bazę dokumentów firmy. Dokumenty zawierają dane osobowe klientów: umowy, faktury, korespondencja. Agent indeksuje te dokumenty i wysyła fragmenty do API w celu odpowiedzi na pytanie użytkownika. Ryzyko: wysokie. Każde zapytanie potencjalnie wysyła dane osobowe klientów (bez ich wiedzy) do serwera w USA. DPIA prawdopodobnie wymagane.

Scenariusz 4: Agent AI analizuje dane medyczne pacjentów. Ryzyko: bardzo wysokie. Dane szczególnych kategorii (Art. 9). Wymaga wyraźnej zgody lub innej podstawy z Art. 9 ust. 2. DPIA obowiązkowe. Transfer do API w USA przy danych medycznych to proszenie się o kłopoty regulacyjne. Nie rób tego bez opinii prawnej.

Jak zminimalizować ryzyko: checklist techniczny

Jeśli zdecydujesz się na OpenClaw mimo ryzyk, oto konkretne kroki, które zmniejszają ekspozycję prawną.

1. Data minimization (Art. 5 ust. 1 lit. c RODO). Nie wysyłaj do API więcej danych, niż jest konieczne. Jeśli agent odpowiada na pytanie o godziny otwarcia, nie potrzebuje w kontekście pełnej historii klienta z CRM. Konfiguruj prompty tak, żeby zawierały minimum danych osobowych. Anonimizuj lub pseudonimizuj dane przed wysłaniem do API (zamień "Jan Kowalski" na "Klient_7834" w promptcie, a mapowanie trzymaj lokalnie).

2. Hosting w UE. Postaw OpenClaw na serwerze w UE (Hetzner w Niemczech, OVH w Polsce, AWS eu-central-1 we Frankfurcie). Logi, cache, dane tymczasowe - wszystko zostaje w UE. To nie rozwiązuje problemu z API (dane i tak lecą do USA), ale eliminuje jeden wektor ryzyka.

3. Modele lokalne zamiast API. To jest jedyne rozwiązanie, które w pełni eliminuje transfer danych poza Twoją infrastrukturę. Hostujesz model językowy (Llama 3, Mistral, Qwen) na własnym serwerze w UE. Dane nigdy nie opuszczają Twojego środowiska. Problem: modele lokalne są znacząco słabsze niż GPT-4o czy Claude. Dla prostych zadań (klasyfikacja, ekstrakcja, odpowiedzi na FAQ) wystarczają. Dla skomplikowanych (analiza dokumentów prawnych, generowanie raportów) mogą nie spełniać oczekiwań jakościowych.

4. Szyfrowanie. TLS w transporcie (to jest standard, każdy dostawca API to robi). Szyfrowanie at-rest na serwerze (zaszyfrowany dysk VPS). Szyfrowanie logów i cache agenta.

5. Retencja danych. Skonfiguruj automatyczne usuwanie logów rozmów. OpenClaw domyślnie może logować wszystkie interakcje - upewnij się, że logi zawierające dane osobowe są usuwane po określonym czasie (np. 30 dni). Poinformuj o tym w polityce prywatności.

6. Prawa podmiotów danych. Twoi klienci mają prawo do: dostępu do swoich danych (Art. 15), sprostowania (Art. 16), usunięcia (Art. 17, "prawo do bycia zapomnianym"), ograniczenia przetwarzania (Art. 18), przenoszenia danych (Art. 20), sprzeciwu (Art. 21). Musisz być w stanie zrealizować każde z tych żądań. Jeśli klient powie "usuń wszystkie moje dane", musisz wiedzieć, gdzie te dane są: w logach OpenClaw, w cache, w API dostawcy, w backupach serwera. Czy potrafisz to zrobić w ciągu 30 dni (termin RODO)?

Kary: ile to kosztuje, jak się nie dostosujesz

RODO przewiduje kary do 20 milionów EUR lub 4% rocznego obrotu globalnego (zależnie od tego, co jest wyższe). W praktyce polskie kary od UODO są niższe, ale rosną. W 2024-2025 UODO nałożył kilka kar powyżej 100 000 PLN na polskie firmy za naruszenia związane z niewystarczającymi zabezpieczeniami technicznymi i brakiem DPA.

Dla firmy z obrotem 5 milionów PLN rocznie, maksymalna kara to 200 000 PLN (4% obrotu). Ale karą nie jest tylko pieniądze. To również: nakaz zaprzestania przetwarzania (co oznacza wyłączenie agenta AI z dnia na dzień), obowiązek poinformowania klientów o naruszeniu (reputacja), i koszty prawne obsługi postępowania.

Czy to prawdopodobne? Przy małej firmie, która przetwarza dane ograniczonej liczby klientów - ryzyko niskie. Przy firmie, która przetwarza dane tysięcy klientów przez agenta AI bez DPA i DPIA - ryzyko rośnie z każdym miesiącem.

Jak Syntalith rozwiązuje te problemy

Nie piszę tego artykułu, żeby Cię przestraszyć do rezygnacji z agenta AI. Piszę go, żeby pokazać, że compliance jest możliwy, ale wymaga świadomych decyzji architektonicznych.

Kiedy wdrażamy agentów AI dla klientów w Syntalith, robimy to tak:

Hosting w UE. Cała infrastruktura na serwerach w Unii Europejskiej (AWS Frankfurt, Hetzner Falkenstein). Dane osobowe nigdy nie opuszczają EOG na poziomie hostingu.

Routing modeli z uwzględnieniem danych. Zapytania zawierające dane osobowe kierujemy przez modele hostowane w UE (Azure OpenAI w regionie EU, Anthropic przez AWS Bedrock eu-west, albo modele lokalne). Zapytania bez danych osobowych mogą iść przez standardowe API. To wymaga dodatkowej logiki, ale eliminuje problem transferu.

DPA na każdym poziomie. Podpisujemy DPA z klientem. Mamy DPA z dostawcami API. Mamy DPA z dostawcami hostingu. Cały łańcuch jest udokumentowany i audytowalny.

Audit trail. Logujemy każdą operację przetwarzania danych osobowych: kto, co, kiedy, dlaczego, jak długo. Logi są zaszyfrowane i przechowywane zgodnie z polityką retencji. To pozwala odpowiedzieć na pytanie audytora: "pokażcie mi, jakie dane osobowe przetworzyliście w ostatnim kwartale i na jakiej podstawie prawnej".

Data minimization by design. Prompty systemowe nie zawierają danych osobowych klientów. Dane są pseudonimizowane przed wysłaniem do modelu i depseudonomizowane dopiero w odpowiedzi. To dodaje złożoność, ale zmniejsza ryzyko.

Realizacja praw podmiotów danych. Mamy zbudowane procedury na realizację żądań z Art. 15-21 RODO. Klient chce usunięcia danych? Wiemy dokładnie, gdzie te dane są i jak je usunąć w ciągu 72 godzin.

To jest różnica między "postawiłem OpenClaw i podłączyłem API" a "mam produkcyjnego agenta AI, który przejdzie audyt RODO". Więcej o naszych wdrożeniach znajdziesz na stronie konfiguracji agentów AI.

AI Act - nowy wymiar regulacji od 2025

RODO to nie jedyna regulacja, o której musisz myśleć. EU AI Act (Rozporządzenie w sprawie sztucznej inteligencji) wchodzi w życie etapami od 2024 roku. Obowiązki zależą od kategorii ryzyka systemu AI.

Agent AI obsługujący klientów (chatbot, voicebot) to w większości przypadków "ograniczone ryzyko" (Limited Risk). Główny obowiązek: transparentność. Musisz poinformować klienta, że rozmawia z AI, a nie z człowiekiem. To jest proste do wdrożenia technicznie (komunikat na początku rozmowy), ale wiele firm o tym zapomina.

Jeśli Twój agent AI podejmuje decyzje mające wpływ na osoby fizyczne (np. ocena zdolności kredytowej, scoring kandydatów w rekrutacji, priorytetyzacja pacjentów), to jest "wysokie ryzyko" (High Risk). Obowiązki: rejestracja w unijnej bazie, system zarządzania ryzykiem, dokumentacja techniczna, logowanie, nadzór ludzki, cyberbezpieczeństwo. To jest poważna operacja compliance, nie coś, co ogarniesz w weekend.

Dla większości polskich MŚP, które używają agenta AI do obsługi komunikacji, wymagania AI Act są wykonalne. Ale trzeba o nich wiedzieć i trzeba je wdrożyć, zanim zacznie się egzekwowanie.

Rekomendacja: pragmatyczna ścieżka do compliance

Oto co bym zrobił na Twoim miejscu, gdybym był IT managerem w polskiej firmie MŚP, który dostał zadanie "wdróż agenta AI".

Krok 1: Zidentyfikuj dane. Jakie dane osobowe będzie przetwarzał agent? Czyje? Ile rekordów? Czy są dane wrażliwe? To jest 2 godziny pracy z arkuszem kalkulacyjnym.

Krok 2: Oceń ryzyko. Jeśli przetwarzasz wyłącznie dane kontaktowe (imię, mail, telefon) w kontekście obsługi klienta, ryzyko jest umiarkowane. Jeśli przetwarzasz dane medyczne albo finansowe, ryzyko jest wysokie. Spisz to.

Krok 3: Wybierz architekturę. Niskie ryzyko? OpenClaw z API w USA + DPA z dostawcą + informacja dla klientów. Średnie ryzyko? OpenClaw z API w UE (Azure OpenAI EU, Bedrock EU) + pseudonimizacja + DPIA. Wysokie ryzyko? Dedykowane wdrożenie z modelem lokalnym + audit trail + pełna dokumentacja RODO. Skontaktuj się z nami - to jest dokładnie to, co robimy.

Krok 4: Udokumentuj. Uzupełnij Rejestr Czynności Przetwarzania o nową operację. Zaktualizuj politykę prywatności. Przygotuj klauzulę informacyjną dla klientów obsługiwanych przez AI.

Krok 5: Zrób DPIA, jeśli jest wymagane. Jeśli nie jesteś pewien czy jest wymagane, zrób je i tak. Lepiej mieć niepotrzebne DPIA niż nie mieć wymaganego.

To nie jest rakietowa nauka. To jest systematyczna praca, która wymaga czasu i uwagi, ale nie jest niemożliwa. Problem polega na tym, że większość firm pomija te kroki, bo "nikt tego nie sprawdza". Do momentu, aż ktoś sprawdzi.

Podsumowanie

OpenClaw nie jest z definicji niezgodny z RODO. Ale nie jest też z definicji zgodny. Zgodność zależy od tego, jak go skonfigurujesz, jakie dane przetwarzasz i jakie zabezpieczenia wdrożysz.

Minimum, które musisz zrobić: DPA z dostawcą API, hosting w UE, informacja dla klientów o AI, aktualizacja polityki prywatności. Przy danych wrażliwych: dodaj DPIA, pseudonimizację i rozważ modele lokalne.

Potrzebujesz pomocy ze zgodnością RODO przy wdrożeniu agenta AI? To jest dokładnie to, co budujemy w Syntalith. Dedykowani agenci AI z wbudowaną zgodnością RODO, hostingiem w UE, audit trailem i podpisaną DPA. Porozmawiajmy.