Zero data retention (ZDR): co to jest i co sprawdzić u dostawcy AI

Zero data retention (ZDR) to ustawienie lub umowa, w której dostawca modelu AI nie zapisuje Twoich promptów ani odpowiedzi modelu po zwróceniu wyniku. Bez ZDR duzi dostawcy trzymają je zwykle do 30 dni (Google w płatnym Gemini API do 55 dni), żeby wykrywać nadużycia. ZDR trzeba jednak włączyć, często po akceptacji dostawcy, i obejmuje ono tylko część funkcji. Pliki, zadania wsadowe (batch), zapisane rozmowy i agenci w chmurze zwykle zostają poza nim.

W listopadzie 2026 temat wrócił z dwóch powodów. Notion poinformował, że po włamaniu do Fireworks AI wyciekły czaty z Notion AI, choć Fireworks miał umowne zobowiązanie do ZDR. Do tego Anthropic wymaga 30-dniowej retencji dla najmocniejszych modeli (Claude Fable i Mythos), więc firmy z włączonym ZDR widzą komunikat „Disable zero data retention to unlock Fable 5 access”. Ten tekst zbiera w jednym miejscu, co przechowują poszczególni dostawcy, gdzie są wyjątki i co sprawdzić przed wdrożeniem AI na danych firmy. Stan na 13.11.2026, źródła na końcu.

ZDR w skrócie

• Co to jest: zobowiązanie dostawcy, że treść zapytań i odpowiedzi nie zostaje zapisana na dyskach po obsłużeniu zapytania. Każdy dostawca definiuje to po swojemu.
• Czym nie jest: to nie to samo co „nie trenujemy na Twoich danych”. OpenAI, Anthropic i Google w płatnym API i tak domyślnie nie trenują na danych klientów. ZDR dotyczy przechowywania, nie trenowania.
• Jak się je dostaje: w OpenAI i Anthropic przez kontakt z działem sprzedaży i akceptację. W Amazon Bedrock jednym ustawieniem konta (data_retention_mode: none). W płatnym Gemini Developer API gwarantowanego ZDR nie ma, Google odsyła do Vertex AI.
• Czego nie obejmuje: funkcji, które z definicji coś przechowują: plików, batchy, zapisanych stanów rozmów, wykonywania kodu w kontenerach, części narzędzi.
• Co pokazał listopad 2026: umowa o ZDR z dostawcą nie chroni danych, które produkt sam zapisuje i potem wysyła dalej.

Co dostawcy AI przechowują domyślnie

Wniosek z tabeli: „mamy ZDR” to za mało jako odpowiedź. Trzeba wiedzieć, u którego dostawcy, na którym koncie lub projekcie i dla których endpointów.

Czego ZDR nie obejmuje

Dostawcy wyłączają z ZDR funkcje, które muszą coś zapisać, żeby działać. Anthropic pisze to wprost: funkcje oznaczone „No” w tabeli zgodności są zwykle stanowe, bo przechowują zadania, pliki albo stan kontenera. Co ważne, API ich nie blokuje. Użycie takiej funkcji oznacza wyjście poza ZDR dla tych danych.

Najczęstsze pułapki:

1. Zapisane rozmowy. Responses API w OpenAI i Fireworks domyślnie ma store: true. Interactions API w Gemini też domyślnie zapisuje stan. Jeśli w kodzie nikt nie ustawił store: false, dane leżą u dostawcy przez 30 dni.
2. Batch. Przetwarzanie wsadowe jest tańsze, ale wymaga zapisania danych wejściowych. W Anthropic to 29 dni, w Fireworks batch jest całkowicie poza ZDR.
3. Pliki i bazy wektorowe. Files API, vector stores i cache kontekstu leżą u dostawcy do czasu usunięcia albo do końca ustawionego TTL.
4. Agenci w chmurze dostawcy. Claude Managed Agents i obiekty Assistants w OpenAI przechowują sesje, aż je usuniesz.
5. Narzędzia. Wykonywanie kodu w Claude trzyma dane kontenera do 30 dni. Grounding z Google Search przechowuje prompty i odpowiedzi przez 30 dni.
6. Metadane. Liczba tokenów, czas, identyfikatory i dane rozliczeniowe są zbierane zawsze. U OpenAI dane systemowe (konto, metadane, statystyki) mogą być przetwarzane poza wybranym regionem nawet przy włączonej rezydencji danych.

Krótki cache w pamięci (prompt caching) dostawcy zwykle uznają za zgodny z ZDR, bo nic nie trafia na dysk.

Wyciek z Fireworks AI i Notion: co pokazał

Fireworks AI to platforma do uruchamiania otwartych modeli, z której korzysta ponad 10 tysięcy firm. Według BleepingComputer napastnik dostał się do środowiska deweloperskiego Fireworks przez zewnętrznego dostawcę chmury 23 października 2026. Notion opisał przebieg tak:

Dotyczyło to mniej niż 1% przestrzeni roboczych. W większości przypadków czaty nie były przypisane do konkretnej osoby ani firmy, ale ich treść mogła zawierać wszystko, co ktoś wkleił do Notion AI. Notion zaleca traktować te dane jako ujawnione i zmienić hasła oraz klucze API wklejone do czatu.

Najciekawsze jest to, dlaczego ZDR nie pomogło. Notion obiecuje klientom Enterprise ZDR dla zapytań do zewnętrznych modeli. Ta obietnica nie obejmuje jednak funkcji, które Notion sam musi przechowywać, jak historia czatów i Insights. Do analiz w Insights Notion wysyłał zapisane rozmowy do Fireworks, a Fireworks miał umowne zobowiązanie do ZDR. Śledztwo pokazało, że dane z używanych endpointów jednak były zatrzymywane. VentureBeat zwraca uwagę, że dokumentacja Fireworks od dawna wyłączała batch i zapisane odpowiedzi z ZDR, a komunikat Fireworks z 9 listopada mówi o braku wpływu na inferencję „z wyłączeniem inferencji wsadowej”.

Lekcje dla firmy, która kupuje narzędzie z AI albo zamawia wdrożenie:

• Pytaj nie tylko, czy dostawca ma ZDR, ale też które funkcje produktu same zapisują dane i komu je potem przekazują.
• Umowa nie zastąpi weryfikacji technicznej. Po incydencie Notion zapowiedział audyt kluczowych dostawców pod kątem ZDR.
• Sekrety nie powinny trafiać do promptów. Hasło wklejone do czatu staje się częścią danych, które ktoś może kiedyś przechowywać.

Claude Fable i „Covered Models”: kiedy ZDR jest niedostępne

Anthropic nazywa Claude Fable 5, 5.1, 5.2 i Mythos w tych samych wersjach „Covered Models”. Wymagają one 30-dniowej retencji danych do monitorowania bezpieczeństwa i nie są dostępne w ramach ZDR, chyba że Anthropic wyraźnie na to pozwoli. Organizacja z ZDR, która wyśle zapytanie do Fable 5, dostaje błąd 400 invalid_request_error. Przeglądać je może tylko mała grupa zatwierdzonych osób, każdy dostęp trafia do logu, którego nie da się zmienić, a po 30 dniach dane są usuwane automatycznie, poza rzadkimi przypadkami oznaczonymi przez systemy bezpieczeństwa albo wymaganymi przez prawo.

Ta sama zasada działa u pośredników. W Amazon Bedrock modele Fable wymagają trybu aws_review: dane zostają do 30 dni w granicach AWS i mogą przejść przegląd pracowników AWS, ale nie trafiają do Anthropic.

Obaj duzi dostawcy szukają wyjścia dla firm z branż regulowanych. Anthropic zapowiedział Enterprise Frontier Safeguards: dane do monitoringu leżą w chmurze klienta, a sygnały o możliwych nadużyciach trafiają do klienta, który sam je przegląda (The Register, 2.09.2026). OpenAI ma ZDR z Private Safety Processing, które wymaga przechowywania danych po stronie klienta i spełnienia dodatkowych wymagań. W obu przypadkach to oferty dla wybranych klientów, nie domyślne ustawienie.

W praktyce: jeśli proces wymaga ZDR, zaplanuj go na modelu, który ZDR obsługuje, i sprawdź to przed wyborem modelu, a nie po pierwszym błędzie na produkcji.

ZDR a RODO

RODO nie zna pojęcia zero data retention. Wymaga minimalizacji danych i ograniczenia przechowywania (art. 5), ochrony danych w fazie projektowania i domyślnej ochrony danych (art. 25) oraz umowy powierzenia z każdym podmiotem przetwarzającym (art. 28). Krótka albo zerowa retencja u dostawcy modelu pomaga te wymagania spełnić, ale ich nie zastępuje. To nie jest porada prawna. Przy danych osobowych, zdrowotnych lub finansowych decyzję warto podjąć razem z prawnikiem lub inspektorem ochrony danych.

Co zwykle sprawdza się w tym miejscu:

• Umowa powierzenia (DPA) z dostawcą modelu i z każdym narzędziem, które przekazuje dane dalej.
• Lista podprocesorów. Przypadek Notion pokazuje, że dane mogą trafić do dostawcy, o którym użytkownik nie słyszał.
• Lokalizacja danych. OpenAI pozwala ustawić region przechowywania i przetwarzania dla projektu. Za modele wydane od 5 marca 2026 objęte rezydencją danych dolicza 10%. W Microsoft Foundry przegląd przez człowieka dla wdrożeń w EOG robią pracownicy z EOG.

Jak sprawdzić ZDR we własnej aplikacji AI

Nawet idealne ustawienia u dostawcy nic nie dadzą, jeśli aplikacja zapisuje prompty u siebie. Lista kontrolna dla zespołu, który buduje integrację AI albo agenta:

1. Spisz przepływ danych. Dla każdej funkcji: jakie dane idą do modelu, przez którego dostawcę, na którym koncie i z jaką retencją.
2. Sprawdź status ZDR w konsoli dostawcy, osobno dla każdej organizacji, projektu i regionu. W Anthropic ZDR nie przechodzi automatycznie na nowe organizacje. W Bedrock ustawienie działa per region.
3. Wyłącz zapisywanie stanu. store: false w Responses API i Gemini Interactions API. Bez batchy i Files API dla danych wrażliwych, chyba że świadomie akceptujesz ich retencję.
4. Przejrzyj własne logi. Narzędzia do obserwowalności, logi serwera, trace agentów i raporty błędów często zapisują pełne prompty. Ustal, gdzie leżą i jak długo.
5. Usuń sekrety z kontekstu. Klucze, hasła i tokeny nie powinny trafiać do promptów ani do plików, które agent czyta.
6. Sprawdź, czy wybrany model obsługuje ZDR. Covered Models u Anthropic go nie obsługują. Test jest prosty: w organizacji z ZDR zapytanie do takiego modelu kończy się błędem 400.
7. Wołaj API z backendu. Organizacje Anthropic z ZDR nie mogą wywoływać API bezpośrednio z przeglądarki, bo API odrzuca takie zapytania (CORS). To i tak dobra praktyka, bo klucz API nie trafia do frontendu.
8. Opisz wyjątki w dokumentacji projektu. Jeśli jakaś funkcja musi przechowywać dane (np. historia czatu dla użytkownika), zapisz gdzie, jak długo i kto ma dostęp.

Pytania do dostawcy albo wykonawcy

• Których dostawców modeli używacie i czy macie z nimi ZDR albo inną umowę o retencji?
• Które funkcje Waszego produktu zapisują prompty lub odpowiedzi i do kogo je potem wysyłacie?
• Czy używacie batchy, plików albo zapisanych rozmów w API? Na jak długo?
• Kto jest podprocesorem i gdzie fizycznie są dane?
• Czy logi aplikacji i narzędzia do monitoringu zawierają treść promptów?
• Jakich modeli używacie i czy któryś wymaga retencji (jak Claude Fable)?
• Jak szybko poinformujecie nas o incydencie u swojego dostawcy?
• Czy mogę dostać to wszystko na piśmie, w umowie albo w dokumentacji projektu?

Więcej pytań do wykonawcy, nie tylko o dane, jest w tekście jak wybrać wykonawcę wdrożenia AI. O ryzykach po stronie narzędzi programistycznych pisałem w tekście o bezpieczeństwie agentów kodujących.

Kiedy ZDR nie jest potrzebne

ZDR ma koszt: trzeba o nie zabiegać, odpada część funkcji (batch bywa o połowę tańszy, pliki i zapisane rozmowy upraszczają kod), a niektóre modele są wtedy niedostępne. Jeśli przez AI przechodzą tylko publiczne dane, treści marketingowe albo zanonimizowane rekordy, standardowa 30-dniowa retencja u dużego dostawcy bywa rozsądnym kompromisem. Gorzej, gdy firma rezygnuje z ZDR bez decyzji, bo nikt nie sprawdził ustawień. Wybór warto podjąć świadomie, proces po procesie.

Najczęstsze pytania

Co to jest zero data retention?

To zobowiązanie dostawcy modelu AI, że prompty i odpowiedzi nie są zapisywane na dyskach po zwróceniu wyniku. Nie ma jednej definicji: każdy dostawca sam opisuje zakres i wyjątki w dokumentacji albo w umowie.

Czy OpenAI ma zero data retention?

Tak, ale po akceptacji OpenAI. Domyślnie logi do wykrywania nadużyć są trzymane do 30 dni. Zatwierdzeni klienci wybierają ZDR albo Modified Abuse Monitoring dla organizacji lub projektu. Część endpointów, np. Assistants, pliki i batch, dalej przechowuje dane.

Czy Claude (Anthropic) ma zero data retention?

Tak, dla Claude API na podstawie umowy z działem sprzedaży, osobno dla każdej organizacji. Bez ZDR Anthropic usuwa wejścia i wyjścia w ciągu 30 dni. Modele Claude Fable i Mythos wymagają 30-dniowej retencji i w ramach ZDR są niedostępne, chyba że Anthropic wyraźnie na to pozwoli.

Czy ZDR oznacza, że dostawca nie trenuje modeli na moich danych?

Nie, to dwie osobne sprawy. OpenAI, Anthropic i Google w płatnym API domyślnie nie trenują modeli na danych klientów, także bez ZDR. ZDR określa, czy dane są w ogóle przechowywane.

Czy RODO wymaga zero data retention?

Nie wprost. RODO wymaga minimalizacji danych, ograniczenia przechowywania i umowy powierzenia z dostawcą. Krótka lub zerowa retencja pomaga to spełnić. Przy danych wrażliwych decyzję warto skonsultować z prawnikiem.

Czy ZDR chroni przed wyciekiem danych?

Ogranicza to, co może wyciec od dostawcy modelu. Nie chroni danych, które aplikacja albo narzędzie zapisuje u siebie i przekazuje dalej. Tak było w przypadku Notion i Fireworks AI w listopadzie 2026.

Wdrażasz AI na danych firmy?

Buduję integracje AI, agentów AI, MVP oraz aplikacje mobilne i webowe jako freelancer. Pracuję bliżej roli forward deployed engineera: najpierw warsztat i spisany zakres, potem dwutygodniowe sprinty z działającą wersją po każdym. Jeśli chcesz, żeby wybór modeli i ustawienia retencji były opisane w zakresie od pierwszego dnia, napisz, co chcesz zbudować. Projekty od 10 000 zł netto, bez górnej granicy, bo każdy zakres jest inny. Rozliczam się godzinowo na fakturę B2B i odpowiadam w ciągu 24 godzin. Więcej: wdrożenie AI, agenci AI dla firm.

Źródła

Odczyt 13.11.2026, chyba że zaznaczono inaczej.

1. OpenAI, Data controls in the OpenAI platform: logi do 30 dni, ZDR i Modified Abuse Monitoring, tabela endpointów, rezydencja danych (+10% dla modeli od 5.03.2026)
2. Anthropic, API and data retention: zakres ZDR, tabela funkcji, Covered Models, CORS
3. Anthropic Privacy Center, How long do you store my organization's data? (1.07.2026) i Data retention practices for Covered Models
4. Google, Zero data retention in the Gemini Developer API i Abuse monitoring (55 dni)
5. AWS, Amazon Bedrock: Data retention: tryby none, default, aws_review
6. Microsoft Learn, Foundry Models sold by Azure: abuse monitoring
7. Fireworks AI, Zero Data Retention policy i Data handling
8. Notion, Fireworks AI incident (aktualizacja 12.11.2026) i Help Center: Notice about the Fireworks AI incident
9. BleepingComputer, Notion says Fireworks breach exposed customer AI chat transcripts
10. VentureBeat, Attackers breached the Fireworks AI storage where Notion AI chats sat outside zero data retention
11. The Register, Anthropic promises zero data retention, but customers must check it worked (2.09.2026)
12. Nodion, Zero data retention w API LLM: co znaczy i co sprawdzić (22.10.2026): przegląd dostawców
13. Cooper daily briefing (11.11.2026): Fireworks AI incident impacting Notion AI data; Google Suggest PL i US dla „zero data retention” (13.11.2026)