Zero Data Retention oślepiło OpenAI na nadużycia wieloetapowe

OpenAI stworzyło Zero Data Retention, aby uprawnieni klienci API mogli uniemożliwić firmie przechowywanie ich promptów lub odpowiedzi modelu po przetworzeniu zapytania, i ta obietnica nadal obowiązuje: żadnego wglądu ze strony pracowników OpenAI i żadnego wykorzystania do trenowania bez wyraźnej zgody. Koszt tej obietnicy ujawnia się po stronie bezpieczeństwa. W zapowiedzi z 19 sierpnia 2026 roku OpenAI wprost przyznaje, że w miarę jak modele podejmują dłuższe, wieloetapowe zadania agentowe, najgroźniejsze zachowania - napastnik testujący zabezpieczenia, koordynujący działania na wielu kontach, maskujący atak jako legalne badania, albo agent kontynuujący działanie mimo polecenia zatrzymania się - stają się widoczne dopiero przy obserwacji wielu interakcji naraz, nie w obrębie jednej.

Istniejące, zgodne z ZDR kontrole bezpieczeństwa oceniały każdą interakcję osobno, więc z założenia nie mogły wychwycić takiego wzorca. OpenAI idzie dalej, zauważając, że "niektóre niedawne wdrożenia modeli najnowszej generacji wymagały od klientów zgody na przechowywanie przez dostawcę AI wrażliwych treści na potrzeby monitorowania bezpieczeństwa" - to bezpośrednia, choć bez wskazania nazwy, uszczypliwość pod adresem konkurentów, którzy rozwiązali ten problem, przechowując więcej danych, nie mniej. Dla banku, grupy szpitali czy kancelarii prawnej związanych surowymi obowiązkami w zakresie danych taki kompromis nigdy nie był akceptowalny, i to właśnie tę lukę Private Safety Processing deklaruje chęć zamknięcia.

Rozwiązanie przenosi kontrole bezpieczeństwa za klucze klienta

Private Safety Processing, wciąż w fazie podglądu na dzień 19 sierpnia 2026 roku, rozszerza dotychczasowe kontrole bezpieczeństwa OpenAI dla pojedynczych interakcji, aby wykrywać wzorce w powiązanych interakcjach, bez udzielania pracownikom OpenAI dostępu do treści klienta. Mechanizm działa na dwa sposoby, zależnie od tego, gdzie znajduje się treść. Jeśli znajduje się na własnej infrastrukturze klienta w ramach prawdziwego wdrożenia ZDR, OpenAI nigdy jej nie dotyka. Jeśli znajduje się w pamięci dostarczonej przez OpenAI, treść jest szyfrowana kluczami kontrolowanymi przez klienta, a pracownicy OpenAI po prostu nie posiadają tych kluczy.

Gdy system wykryje ryzyko, OpenAI nie otrzymuje oznaczonego promptu, odpowiedzi ani rozumowania stojącego za oznaczeniem. Firma otrzymuje jedynie, jak sama to ujmuje, "ściśle określony sygnał wskazujący rodzaj związanej z tym aktywności" - wystarczający, by zdecydować, czy potrzebne jest działanie, ale niewystarczający, by odczytać, co faktycznie się wydarzyło. Klienci mogą badać każde oznaczenie lub działanie egzekucyjne za pomocą własnych systemów i mogą dobrowolnie udostępnić OpenAI więcej informacji tylko wtedy, gdy chcą odwołać się od decyzji lub wesprzeć dochodzenie - ujawnienie pozostaje dobrowolne po stronie klienta, nigdy automatyczne po stronie OpenAI.

Glean, Databricks, Abridge i Microsoft już testują system

Cztery wymienione z nazwy organizacje testują już Private Safety Processing przed szerszym wdrożeniem: Glean, Databricks, Abridge i Microsoft. Sunil Agrawal, dyrektor ds. bezpieczeństwa informacji w Glean, udzielił OpenAI dotąd najmocniejszego publicznego poparcia: "Enterprise AI adoption depends solely on customer control of data, with no direct or derivative use beyond the chosen service. OpenAI's no-training commitment and ZDR give Glean confidence to build with OpenAI. As models become more capable, OpenAI shows safety can advance without compromising the privacy and control that sustain enterprise trust." To klient korporacyjny publicznie broniący systemu, który jeszcze nie został wdrożony.

Jeden wyjątek utrzymuje się w każdej wersji tego rozwiązania: OpenAI jest prawnie zobowiązane zgłaszać domniemane materiały przedstawiające wykorzystywanie seksualne dzieci, więc zdjęcia oznaczone jako potencjalne CSAM nadal są przechowywane do ręcznej weryfikacji i zgłoszenia, nawet we wdrożeniach ZDR, dokładnie tak jak dziś. Private Safety Processing nie dotyka tego wyjątku. OpenAI zapowiada szersze wdrożenie wraz z technicznym raportem wyjaśniającym mechanizm dokładniej na wrzesień 2026 roku - to, co faktycznie trafi do użytku w przyszłym miesiącu, kształtowane w międzyczasie przez opinie klientów, może różnić się od tego, co jest testowane teraz.

Wrześniowy raport techniczny to prawdziwy test, nie ta zapowiedź

Nikt spoza OpenAI nie zweryfikował niezależnie deklaracji dotyczących szyfrowania i kontroli kluczy stojących za Private Safety Processing, i to właśnie ta luka powinna pozostać otwarta dla zespołu compliance w Polsce aż do września. "Ściśle określony sygnał", który opisuje OpenAI, jest z założenia nieprzejrzysty dla klienta, który go otrzymuje - przydatny, by zdecydować, czy działać na podstawie oznaczenia, ale niewystarczająco szczegółowy, by spełnić wymogi przeglądu na mocy art. 28 RODO albo pytania audytora o to, co dokładnie wywnioskowano z zaszyfrowanej treści i w jaki sposób. Do czasu obiecanego raportu technicznego uczciwa odpowiedź na pytanie "czy możemy to zweryfikować" wciąż brzmi: nie, jeszcze nie.

Zapowiedź pojawia się trzy dni po tym, jak dyrektor finansowa OpenAI wypowiedziała się o możliwym debiucie giełdowym w 2027 roku, i kilka dni po rozszerzeniu ChatGPT Ads na Europę; razem wzięte pokazują wzorzec, w którym OpenAI wyraźnie zabiega o zaufanie regulowanych branż przed dalszym wzrostem komercyjnym. Nie czyni to Private Safety Processing czystym zabiegiem marketingowym - lista klientów i mechanizm są realne -, ale oznacza, że ciężar dowodu spoczywa na raporcie technicznym, nie na tej zapowiedzi. Każda deklaracja dostawcy o "zero data retention" należy teraz czytać z dodatkowym pytaniem: jak dokładnie obsługuje monitorowanie bezpieczeństwa między sesjami.

Czytaj dalej: Przychody firmowe OpenAI wyprzedziły konsumenckie  |  IBM stawia swój dział doradztwa na jednego dostawcę AI