OpenAI rozszerza Zero Data Retention i zapowiada Private Safety Processing

OpenAI ogłosiło 19 sierpnia 2026 roku rozszerzenie Zero Data Retention dla kwalifikujących się klientów API korzystających z modeli frontier. Firma zapowiedziała także Private Safety Processing, mechanizm mający wykrywać wzorce powiązanych nadużyć bez udostępniania treści pracownikom OpenAI. Wczesne wdrożenia trwają, a szersze informacje techniczne i white paper mają pojawić się we wrześniu.

To ważna zmiana dla organizacji, które dotąd nie mogły przesyłać danych do najbardziej zdolnych modeli z powodu retencji i dostępu operatora. Nie jest to jednak uniwersalna obietnica „OpenAI niczego nie widzi”. ZDR wymaga kwalifikacji klienta i ustalenia zakresu, Private Safety Processing pozostaje zapowiedzią lub wczesnym programem, a komunikat zawiera prawny wyjątek dotyczący materiałów przedstawiających seksualne wykorzystywanie dzieci.

Co OpenAI obiecuje w Zero Data Retention

W opisanym modelu prompt i odpowiedź kwalifikującego się żądania API nie są przechowywane po zakończeniu obsługi i nie są dostępne dla personelu OpenAI. Firma przypomina również, że danych klientów biznesowych nie wykorzystuje do treningu modeli, chyba że klient wyraźnie wyrazi na to zgodę.

Retencja i trening to dwie odrębne osie. Dane mogą nie być używane do trenowania, a nadal przez pewien czas znajdować się w logach bezpieczeństwa. Mogą też zostać usunięte po żądaniu, lecz powstałe metadane techniczne podlegać innym zasadom. Dobra ocena nie kończy się więc na polu „training: no”. Musi objąć treść, załączniki, cache, logi, identyfikatory, telemetrykę, backup i procedurę wsparcia.

OpenAI opisuje architekturę, w której treść klienta dla ZDR pozostaje na infrastrukturze kontrolowanej przez klienta. Firma rozwija też wariant przechowywania po swojej stronie szyfrowany kluczami kontrolowanymi przez klienta; personel OpenAI nie ma otrzymywać kopii tych kluczy. Szczegóły dostępności, regionów, cyklu życia i mechanizmu odzyskiwania trzeba potwierdzić w dokumentacji oraz umowie konkretnego wdrożenia.

Czym ma być Private Safety Processing

Systemy bezpieczeństwa dostawcy mają trudne zadanie: wykrywać skoordynowane nadużycia, ale przy ZDR nie zachowywać treści, którą człowiek mógłby później przejrzeć. Private Safety Processing ma analizować relacje między interakcjami i emitować wąsko zdefiniowane sygnały bezpieczeństwa zamiast treści promptu lub odpowiedzi.

OpenAI deklaruje, że automatyczne systemy nie przekazują personelowi treści klienta. Sygnał może wskazywać prawdopodobny wzorzec, a klient bada zdarzenie we własnych systemach i opcjonalnie udostępnia dostawcy dodatkowe informacje. W ten sposób to klient pozostaje miejscem, w którym istnieje kontekst dochodzeniowy.

Koncepcyjnie przypomina to prywatne dopasowywanie lub ocenę cech, ale komunikat nie daje jeszcze wystarczająco dużo danych, aby przesądzać o konkretnej kryptografii, dokładności czy odporności. Dopóki nie pojawi się white paper, właściwe określenia to „preview”, „deklarowana architektura” i „wczesne wdrożenie”, nie „niezależnie zweryfikowana prywatność”.

Co może być sygnałem, jeśli nie treść

Sygnał bezpieczeństwa może reprezentować wynik klasyfikacji, związek między zdarzeniami, przekroczenie progu albo kategorię ryzyka. Ważne są jego granularność i możliwość reidentyfikacji. Nawet bez pełnego promptu kombinacja czasu, identyfikatora projektu, typu narzędzia, regionu i rzadkiego wzorca może mieć znaczenie dla prywatności.

Przed wdrożeniem należy ustalić:

• jakie dokładnie pola opuszczają środowisko klienta;
• czy sygnały są per użytkownik, projekt, organizację czy globalny klaster;
• jak długo są przechowywane i kto może je odczytać;
• czy model bezpieczeństwa widzi załączniki, obrazy, wywołania narzędzi i wyniki;
• jakie progi tworzą alert oraz jaki jest odsetek fałszywych trafień;
• czy klient może uzyskać log decyzji, wersję klasyfikatora i dowód konfiguracji;
• jak wygląda korekta, odwołanie i usunięcie błędnie powiązanego sygnału.

„Nie zawiera treści” jest właściwością projektu, ale nie automatycznie pełną anonimizacją. Ocena DPIA powinna uwzględniać metadane i możliwość powiązania z osobą w systemie klienta.

Wyjątek dotyczący CSAM

OpenAI wprost wskazuje wyjątek dla obrazów podejrzanych o przedstawianie seksualnego wykorzystywania dzieci. Flagi mogą prowadzić do zachowania obrazu w celu ręcznej weryfikacji i wymaganego prawem raportowania, również w trybie ZDR. Organizacja musi zatem zrozumieć, że obietnica braku retencji ma granicę prawną i bezpieczeństwa.

Nie oznacza to, że zwykłe dane klienta są dowolnie zachowywane. Oznacza, że architektura musi obsłużyć szczególną kategorię, dla której dostawca ma obowiązki ustawowe. W umowie i rejestrze przetwarzania należy wskazać podstawę, role stron, retencję, dostęp człowieka, jurysdykcję oraz sposób powiadomienia, jeśli prawo na to pozwala.

Firmy przetwarzające obrazy medyczne, moderacyjne, śledcze lub generowane syntetycznie powinny zapytać o ryzyko fałszywego alarmu oraz bezpieczną ścieżkę odwołania. Nie należy testować systemu przez przesyłanie materiałów zabronionych. Walidacja powinna używać zatwierdzonych, syntetycznych zestawów i dokumentacji dostawcy.

Klucz kontrolowany przez klienta nie rozwiązuje wszystkiego

Customer-managed lub customer-controlled key ogranicza ryzyko dostępu do danych przechowywanych. Musi jednak istnieć moment, w którym system odszyfrowuje treść do inference. Bezpieczeństwo zależy wtedy od attestation środowiska, dostępu workloadu do klucza, cache, pamięci procesu, logów awarii i możliwości administracyjnych.

Klucz powinien mieć rozdzielony zakres per środowisko lub tenant, kontrolowany rotation i jawny proces revocation. Organizacja musi wiedzieć, co dzieje się po utracie klucza, czy dostawca może przywrócić dane, jakie kopie są szyfrowane tym samym materiałem i czy usunięcie klucza jest technicznie równoważne crypto-shreddingowi.

Warto także oddzielić klucz przechowywania od poświadczenia API. Kradzież tokenu wywołującego model nie powinna dawać administracji kluczem, a kompromitacja konta KMS nie powinna automatycznie pozwalać generować żądań jako użytkownik. Logi KMS i API należy korelować w SOC.

Lista pytań przed podpisaniem ZDR

Klient powinien uzyskać pisemne odpowiedzi obejmujące kwalifikujące się modele, endpointy i funkcje. Tryb podstawowego tekstu może mieć inną ścieżkę niż pliki, batch, fine-tuning, background jobs, web search, computer use czy narzędzia zewnętrzne. Jeżeli jakaś funkcja nie jest objęta, aplikacja musi ją technicznie blokować albo klasyfikować dane przed routingiem.

Następne pytania dotyczą operacji:

1. Czy ZDR jest właściwością organizacji, projektu, klucza API czy pojedynczego żądania?
2. Jak klient potwierdza, że polityka była aktywna dla konkretnego request ID?
3. Jakie metadane i sygnały safety pozostają, w jakim regionie i przez jaki czas?
4. Czy podwykonawcy lub zewnętrzne narzędzia widzą treść?
5. Jak support diagnozuje błąd bez dostępu do promptu?
6. Jak wygląda legal hold, żądanie organu i konflikt jurysdykcji?
7. Jak klient otrzyma informację o zmianie zakresu lub modelu bezpieczeństwa?

DPA, opis środków technicznych, lista subprocesorów i warunki usługi powinny być zgodne z architekturą. Slajd marketingowy nie zastępuje kontroli kontraktowej ani dowodu konfiguracji.

Jak zaprojektować aplikację pod ZDR

Najbezpieczniejszy wzorzec zaczyna się od minimalizacji. Aplikacja usuwa niepotrzebne identyfikatory, sekrety i dane osobowe przed wywołaniem modelu. Klasyfikator po stronie klienta kieruje tylko dozwolone kategorie do właściwego endpointu. RAG pobiera minimalne fragmenty, a broker narzędzi nie przekazuje pełnej odpowiedzi, jeśli model potrzebuje wyłącznie wyniku logicznego.

Własne logi także wymagają uwagi. ZDR u dostawcy nie ma wartości, jeżeli API gateway klienta zapisuje pełny prompt, APM przechwytuje body, a narzędzie supportowe kopiuje odpowiedź do ticketa. Obserwowalność agentów AI powinna rozdzielać metryki i ślady od treści oraz używać redakcji przed eksportem.

Procedura incydentowa musi działać bez logu treści u dostawcy. Zachowuj identyfikatory żądania, wersję modelu, hash polityki, wywołane narzędzia i wynik kontroli. Wrażliwą treść przechowuj tylko po swojej stronie zgodnie z własną retencją i kontrolą dostępu.

Fakty i wnioski Breachroad

Faktem jest zapowiedź OpenAI dotycząca ZDR dla kwalifikujących się klientów, Private Safety Processing, sygnałów zamiast treści, kluczy kontrolowanych przez klienta, wczesnych wdrożeń i wyjątku CSAM. Szczegóły należy potwierdzić w dokumentacji, umowie i wrześniowym white paper. Pytania o KMS, DPIA, funkcje poza zakresem i dowód konfiguracji są analizą Breachroad.

Nie twierdzimy, że preview zapewnia formalną poufność dla każdego use case’u ani że usuwa obowiązki administratora danych. ZDR może istotnie zmniejszyć powierzchnię, ale najlepszy wynik daje z minimalizacją, kontrolą klienta i testem architektury.

Szkolenia z bezpieczeństwa AI i cyberbezpieczeństwa pomagają prawnikom, inżynierom i właścicielom danych mówić wspólnym językiem o retencji. Zakres ZDR, ścieżki logów, RAG, KMS i narzędzia można zweryfikować podczas audytu bezpieczeństwa AI.

Źródła

• OpenAI: Offering Zero Data Retention for frontier models
• OpenAI: Enterprise privacy
• OpenAI API: data controls