OpenClaw a RODO: jak oceniamy ryzyko danych w agencie AI
RODO zależy od przepływu danych, modeli, logów, retencji i dostępu, nie od samego runtimeu.
OpenClaw nie jest automatycznie zgodny ani niezgodny z RODO. Ryzyko zależy od architektury: jakie dane widzi agent, jakie modele wywołuje, gdzie trafiają logi, kto ma dostęp i jak długo dane są przechowywane.
To jest temat dla mapy danych i decyzji architektonicznej, nie dla hasła marketingowego.
Od czego zaczynamy
Najpierw opisujemy agenta: Praca, Kontekst, Narzędzia, Granice, Eskalacja, Pomiar, Ślad. Dopiero potem sprawdzamy, czy OpenClaw jest właściwym narzędziem.
Przy RODO najważniejsze są zwykle cztery pytania: jakie dane osobowe trafiają do systemu, kto jest administratorem i procesorem, czy dane wychodzą poza EOG oraz jak obsługiwane są logi, retencja i prawa osób.
To oznacza, że rozmowa o zgodności zaczyna się od mapy przepływu danych, a nie od nazwy runtime'u. Trzeba opisać źródła danych, modele, integracje, środowiska, osoby z dostępem administracyjnym i miejsca, w których dane mogą zostać zapisane pośrednio: logi, cache, backupy, narzędzia monitoringu.
Co trzeba ustalić w projekcie
| Obszar | Pytanie kontrolne |
|---|---|
| Dane wejściowe | Czy agent widzi dane osobowe, dane szczególnej kategorii albo dane klientów? |
| Modele | Czy wywołujemy model lokalny, API komercyjne, czy oba warianty? |
| Logi | Czy log zawiera treść dokumentu, identyfikatory, prompt, wynik albo decyzję? |
| Retencja | Jak długo trzymamy dane robocze i kto może je usunąć? |
| Dostęp | Kto administruje środowiskiem, sekretami i wynikami pracy agenta? |
| Eskalacja | Kiedy człowiek przejmuje sprawę i co dostaje do przeglądu? |
Lokalny runtime nie wystarcza
Lokalne uruchomienie może ograniczyć część ryzyka, ale nie kończy analizy. Jeśli agent używa zewnętrznego modelu, wysyła dane do API, zapisuje logi w chmurze albo wymaga zdalnego wsparcia, dane nadal mogą opuszczać kontrolowany zakres.
Dlatego nie piszemy, że dane "nigdy" nie wychodzą. Piszemy, jaki jest faktyczny przepływ.
Ta precyzja jest ważna sprzedażowo i prawnie. Hasło "lokalnie" może oznaczać lokalny runtime, ale zewnętrzny model. Może oznaczać lokalne pliki, ale chmurowe logi. Może oznaczać brak transferu treści, ale transfer metadanych. Każdy wariant wymaga innej oceny.
Ślad i nadzór
RODO i AI Act nie są tym samym, ale oba wzmacniają potrzebę kontroli. W naszym języku: Ślad wspiera logowanie, Granice i Eskalacja wspierają nadzór człowieka, Pomiar wspiera monitorowanie działania. To nie jest porada prawna ani certyfikacja. To operator-side dokumentacja, którą można pokazać prawnikom i właścicielom procesu.
W praktyce ślad powinien odpowiadać na proste pytania: co agent zobaczył, jakie narzędzie wywołał, jaki wynik przygotował, dlaczego się zatrzymał albo dlaczego kontynuował. Nie każdy projekt powinien logować pełną treść dokumentów. Czasem lepszy jest log metadanych, hash, identyfikator sprawy i link do źródła w systemie właściciela danych.
Jak naprawić ryzykowny projekt
Ryzykowny projekt zwykle nie wymaga większego modelu. Wymaga ograniczenia danych, krótszej retencji, oddzielenia środowisk, usunięcia niepotrzebnych narzędzi, zatwierdzenia człowieka przed skutkiem produkcyjnym i jasnej odpowiedzialności za wyjątki.
Syntalith nie zastępuje klientowi prawnika ani inspektora ochrony danych. Możemy jednak przygotować architekturę, mapę danych, opis granic, logikę eskalacji i artefakty techniczne, które ułatwiają ocenę ryzyka. To jest uczciwa rola wykonawcy technologicznego: zbudować system tak, żeby compliance miało co ocenić.