Zero data retention w AI: jak sprawdzić ten zapis w umowie i dlaczego własny serwer go nie potrzebuje?

Zero data retention to deklaracja dostawcy AI, że po przetworzeniu zapytania nie zachowuje Twoich danych. W praktyce jednak sam napis na stronie dostawcy nic nie gwarantuje: musisz wiedzieć, gdzie w umowie szukać konkretnych zapisów, co one faktycznie obejmują i jakie pytania zadać przed podpisaniem. Jeśli Twój model AI działa na serwerze wewnątrz firmy, cały ten temat przestaje mieć znaczenie, bo dane nigdy nie opuszczają Twojej sieci.

Co tak naprawdę oznacza "zero data retention" i dlaczego to nie jest jedno pojęcie?

Kiedy dostawca pisze „zero data retention", może mieć na myśli jedną z kilku rzeczy. Albo kilka naraz. I tu zaczyna się problem, bo te znaczenia nakładają się na siebie w dokumentach prawnych niemal nigdy nie wprost.

Są trzy warstwy, które trzeba sprawdzić osobno:

• Brak trenowania modelu na Twoich danych. Twoje zapytania i odpowiedzi nie trafiają do zestawu danych, na którym dostawca ulepsza model. To najczęściej omawiana gwarancja i przy API jest standardem u większości dużych dostawców.
• Brak przechowywania zapytań po przetworzeniu. Dane wchodzą, model odpowiada, dane znikają z serwera dostawcy. Żaden log nie zostaje. To już znacznie rzadziej dostępna opcja i często wymaga wniosku do dostawcy.
• Brak retencji w celach bezpieczeństwa i tzw. abuse monitoringu. Tu jest najczęściej schowane zaskoczenie: wielu dostawców zastrzega sobie prawo do przechowywania treści zapytań przez określony czas na potrzeby wykrywania naruszeń polityki lub wymogów prawnych w ich własnej jurysdykcji.

U jednego z klientów z branży doradczej wyszło podczas przeglądu, że ich plan SaaS zawierał opcję „no training", ale logi zapytań były przechowywane przez 30 dni na serwerach w USA. Firma przetwarzała przez to narzędzie dane osobowe swoich klientów końcowych. RODO ma dużo do powiedzenia na temat takiego scenariusza: transfer do USA, brak podpisanego DPA, brak podstawy prawnej. Trzy problemy zamiast jednego.

Samo hasło „zero data retention" w materiałach marketingowych nie mówi Ci, o której z tych trzech warstw mowa. Musisz sięgnąć do dokumentów.

Gdzie szukać tych zapisów w umowie z OpenAI, Microsoft Copilot i innymi dostawcami?

Każdy z tych dostawców ma inną strukturę dokumentów. Żeby znaleźć właściwe zapisy, trzeba wiedzieć, gdzie patrzeć, bo Terms of Service to nie to samo co Data Processing Agreement.

OpenAI API: szukaj w dokumencie „API Data Usage Policies" oraz w „Data Processing Agreement" (DPA), który musisz aktywować osobno w panelu swojej organizacji. Sekcja do sprawdzenia to „Zero Data Retention" w ustawieniach projektu. Domyślnie OpenAI przechowuje dane przez 30 dni do celów bezpieczeństwa. Opcja ZDR jest dostępna wyłącznie dla określonych endpointów i nie dla wszystkich planów: wymaga osobnego wniosku i akceptacji przez OpenAI.

Microsoft Azure OpenAI / Copilot dla firm: tutaj bazowym dokumentem jest „Data Processing Addendum" oraz „Microsoft Commercial Data Protection Pledge". Sekcje do sprawdzenia to „Data residency" i „Abuse monitoring". Microsoft pozwala wyłączyć abuse monitoring dla Azure OpenAI, ale wymaga to odrębnego wniosku i wiąże się z ograniczeniami funkcjonalnymi. W przypadku Microsoft 365 Copilot sprawdź dodatkowo „Microsoft 365 Data Protection Addendum".

Anthropic API (Claude): patrz na „Privacy Policy" oraz DPA dostępny po kontakcie z działem sprzedaży. Domyślna retencja logów istnieje, choć warunki różnią się od OpenAI i zmieniają się przy przejściu na plan komercyjny.

We wszystkich przypadkach obowiązuje jedna zasada: plan „dla firm" w modelu SaaS i plan Enterprise to często dwa zupełnie różne zestawy dokumentów prawnych. Sprawdź, na którym planie faktycznie jesteś, zanim zaczniesz czytać załączniki.

Gotowa lista pytań do dostawcy AI przed podpisaniem umowy

Poniższe pytania możesz wysłać mailem do działu sprzedaży lub prawnego dostawcy. Pisemne odpowiedzi mają wartość podczas audytu RODO, bo pokazują, że firma dochowała należytej staranności.

• Które dokumenty regulują retencję danych zapytań: Terms of Service, DPA czy oddzielna polityka dla API?
• Jak długo przechowywane są logi zapytań (prompts) i odpowiedzi modelu, w tym w celach bezpieczeństwa i abuse monitoringu?
• Czy opcja zero data retention eliminuje retencję całkowicie, łącznie z logami bezpieczeństwa, czy tylko wyłącza trenowanie modelu?
• W jakim kraju i u jakiego podprocesora fizycznie przetwarzane są dane w trakcie obsługi zapytania?
• Czy umowa zawiera standardowe klauzule umowne (SCC) wymagane przy transferze danych osobowych poza Europejski Obszar Gospodarczy?
• Kto pełni rolę procesora danych w rozumieniu RODO: bezpośrednio dostawca modelu, operator chmury czy inny podmiot?
• Jak wygląda procedura zgłoszenia naruszenia ochrony danych (data breach notification) i w jakim czasie zostaniemy poinformowani?
• Czy istnieje możliwość wglądu do raportów zgodności: SOC 2 Type II, ISO 27001 lub innego aktualnego certyfikatu?

Jeżeli dostawca odpowiada ogólnikowo na którekolwiek z tych pytań, to sygnał do negocjacji albo do dokładniejszej analizy przez prawnika z doświadczeniem w RODO. „Dbamy o bezpieczeństwo danych" jako odpowiedź na pytanie o czas retencji logów to nie odpowiedź.

Dlaczego własny serwer eliminuje ten problem strukturalnie?

Kiedy model działa on-premises lub na prywatnej infrastrukturze w Twojej sieci, pytanie o retencję u zewnętrznego dostawcy staje się po prostu nieaktualne. Dane nigdy nie opuszczają sieci firmowej. Nie ma zewnętrznego procesora. Nie ma DPA do podpisywania z dostawcą modelu. Nie ma transferu danych do USA ani żadnej innej jurysdykcji.

To zmiana strukturalna, nie tylko formalna. Zamiast pytać „czy dostawca naprawdę wymaże te dane po 30 dniach", pytasz „kto ma dostęp do naszego serwera?" i to już jest pytanie, na które Twój dział IT potrafi odpowiedzieć.

Typowo wygląda to tak: firma wdraża otwarty model językowy na serwerze w serwerowni firmy albo na dedykowanym VPS w polskim data center. Interfejs użytkownika łączy się z modelem przez sieć wewnętrzną. Żadne dane z zapytań nie wychodzą na zewnątrz. Polityka retencji jest Twoja: Ty decydujesz, ile historii rozmów przechowujesz i jak długo.

Z perspektywy RODO Twoja firma jest jedynym administratorem tych danych. Nie ma zewnętrznego procesora, więc nie prowadzisz rejestru czynności przetwarzania dla tego narzędzia jako zewnętrznej usługi. Jeden punkt ryzyka mniej w każdym audycie.

Co to oznacza dla Twojej odpowiedzialności wobec klientów i audytorów?

Jeśli przetwarzasz dane klientów lub pracowników przez zewnętrzne AI, masz obowiązek wskazać tego dostawcę jako procesora w umowie powierzenia danych oraz uwzględnić go w rejestrze czynności przetwarzania. To nie jest formalność, którą można odłożyć. Audytorzy UODO i audytorzy ISO 27001 pytają o listę procesorów z dostępem do danych osobowych.

Klientom B2B, którzy sami podlegają RODO, może być od Ciebie potrzebna lista podprocesorów. Firma prawnicza, kancelaria podatkowa albo agencja HR korzystająca z zewnętrznego AI musi wiedzieć, gdzie trafiają dane, które wpisuje do tego narzędzia. Jeśli korzystasz z zewnętrznego AI jako procesora, ten dostawca trafia na tę listę i musisz potrafić go uzasadnić.

Przy modelu działającym na własnym serwerze tej kwestii po prostu nie ma w kontekście narzędzia AI. Jeden problem mniej do wyjaśnienia klientowi albo na audycie.

Od czego zacząć, jeśli chcesz sprawdzić swoją sytuację?

Pierwsza rzecz: zbierz listę narzędzi AI, z których korzystają pracownicy. Nie tylko oficjalnie wdrożonych. Zapytaj też, co ludzie używają na własną rękę, bo właśnie tam najczęściej brakuje umów i kontroli.

Potem sprawdź, czy dla każdego narzędzia przetwarzającego dane osobowe jest podpisana umowa powierzenia przetwarzania danych. Jeśli jakiegoś narzędzia nie ma na tej liście albo nie ma umowy: to jest ryzyko RODO, niezależnie od tego, co dostawca pisze na stronie o bezpieczeństwie.

Krok drugi: dla narzędzi, gdzie przetwarza się dane klientów lub pracowników, wróć do dokumentów wymienionych wyżej i sprawdź konkretne zapisy dotyczące retencji logów oraz lokalizacji serwerów. Nie Terms of Service na głównej stronie. DPA.

Krok trzeci: jeśli wyniki tego przeglądu budzą wątpliwości, to dobry moment, żeby porozmawiać o wdrożeniu modelu on-premises. Koszt utrzymania takiego serwera jest znacznie łatwiej uzasadnić, kiedy ma się przed oczami konkretną listę ryzyk z zewnętrznych dostawców.

Taki przegląd robimy razem z klientami w ramach bezpłatnego audytu: sprawdzamy, które narzędzia AI są w firmie, jakie dane przetwarzają i czy istniejące umowy pokrywają to, co naprawdę się dzieje. Jak wygląda to w praktyce, pokazujemy w realnych wdrożeniach z polskich firm.