Włączyliście zero retencji i najnowszy model zniknął z listy. Tryb retencji jako warunek dostępu

Ustawienie trybu retencji na none na koncie Amazon Bedrock odbiera dostęp do najnowszych modeli Claude. Dokumentacja Bedrocka mówi to wprost: Claude Fable 5 i Claude Fable 5.1 mają allowed_modes ograniczone do aws_review i provider_data_share, więc przy trybie none albo default model pojawia się na liście ze statusem unavailable, a zapytanie do niego kończy się błędem ValidationException (AWS, dokumentacja Bedrock, sprawdzone 24 października 2026).

To jest nowa jakość w tym temacie i warto ją nazwać precyzyjnie. Dotychczas retencja była parametrem, który się czyta: dostawca deklaruje okres, wy go zapisujecie i opisujecie klientowi. Teraz na części platform jest parametrem, który się ustawia — a ustawienie go na zero wyłącza wam modele z katalogu. Rozdzielenie treningu, retencji, miejsca przechowywania i miejsca inferencji oraz sposób wyczytania ich z dokumentacji opisuje osobny tekst o tym, w którym regionie liczy się odpowiedź waszego asystenta. Ten tekst dotyczy wyłącznie jednej rzeczy: trybu retencji na platformie, przez którą uruchamiacie modele, i tego, jak go ustawić, wymusić i sprawdzić.

Tryby retencji na skali dostępu do modelu

Bedrock nie ma przełącznika „przechowuj / nie przechowuj”. Ma skalę czterech trybów, uporządkowaną od najmniej do najbardziej dopuszczającej: none < default < aws_review < provider_data_share. Model jest dla was dostępny wtedy, gdy wasz tryb efektywny stoi na poziomie wymaganym przez ten model albo wyżej. Każdy model deklaruje swój wymóg polem allowed_modes, które wymienia wszystkie tryby spełniające jego minimum.

Co się dzieje przy trybie aws_review, dokumentacja podaje bez ogródek: prompty i odpowiedzi są przechowywane w granicy AWS do 30 dni i mogą być przeglądane przez AWS, żeby spełnić wymóg przeglądu ludzkiego postawiony przez dostawcę modelu jako warunek dostępu. Treść nie jest przy tym przekazywana dostawcy modelu. Tryb provider_data_share jest oznaczony jako przestarzały i — wbrew nazwie — nie powoduje dziś przekazania treści dostawcy modelu, bo takie udostępnianie nie jest obecnie obsługiwane; stoi po prostu wyżej na skali, więc spełnia wymóg modeli żądających przeglądu.

Dwie rzeczy z tej mechaniki są nieoczywiste i obie mają znaczenie operacyjne. Pierwsza: bardziej dopuszczający tryb nie powoduje przechowywania treści modeli, które go nie wymagają. Dokumentacja podaje tu Claude Opus 4.8 jako model, którego allowed_modes zawiera none — przy takim modelu nic nie zostaje przechowane niezależnie od tego, co ustawiliście na koncie. Ustawienie aws_review nie jest więc zgodą hurtową, tylko podniesieniem pułapu tego, co wolno. Druga: wymóg jest własnością modelu, nie waszą. Nowy model wprowadzony do projektu może przyjść z innym wymogiem niż poprzedni, a wtedy nie zmienia się nic w waszej konfiguracji i mimo to zmienia się to, co dzieje się z danymi.

Tabela zestawia, co każdy tryb znaczy w praktyce. Stan dokumentacji sprawdzony 24 października 2026.

Dla modeli OpenAI innych niż warianty gpt-oss ruch oznaczony przez klasyfikator jest przechowywany do 30 dni na potrzeby automatycznego wykrywania nadużyć, a o pełne zero retencji uprawnieni klienci wnioskują przez swój zespół obsługi konta AWS (AWS, Amazon Bedrock abuse detection, sprawdzone 24 października 2026). Dokumentacja dodaje, że przechowywane wejścia i wyjścia są przetwarzane przez AWS i nie są udostępniane zewnętrznym dostawcom modeli, a dla modeli Claude o kwalifikacji do zera retencji decyduje Anthropic, nie AWS.

Zgoda zamiast przełącznika u pozostałych dostawców

Mechanika jest inna na Azure i w API OpenAI, ale wniosek operacyjny ten sam: zejście do zera jest przedmiotem wniosku i zgody, nie ustawienia w panelu. Microsoft dopuszcza do modyfikacji monitoringu nadużyć klientów spełniających dodatkowe kryteria Limited Access, na wniosek składany formularzem, i zastrzega, że część zaawansowanych modeli może mieć ostrzejsze kryteria wyłączenia monitoringu (Microsoft Learn, abuse monitoring, sprawdzone 24 października 2026). Po zatwierdzeniu wniosku przechowywanie i przegląd ludzki nie są wykonywane, ale przegląd automatyczny może nadal działać — a przy wykryciu poważnego lub powtarzalnego nadużycia klient może zostać poproszony o ponowne włączenie monitoringu z przeglądem ludzkim, żeby uniknąć ograniczeń dostępu.

Tu trafia się na lukę, której w zestawieniach zwykle nie widać, a która jest istotna przy odpowiadaniu klientowi: dokumentacja Microsoftu nie podaje okresu przechowywania w magazynie przeznaczonym do przeglądu ludzkiego. Opisuje za to dokładnie, gdzie ten magazyn stoi i kto ma do niego dostęp — jest logicznie rozdzielony per zasób klienta, osobny w każdej geografii, a dla modeli wdrożonych w Europejskim Obszarze Gospodarczym upoważnieni recenzenci znajdują się w EOG i sięgają po dane przez stacje o podwyższonym bezpieczeństwie, z zatwierdzeniem na żądanie (Microsoft Learn, Data, privacy, and security, sprawdzone 24 października 2026). Brak liczby w dokumentacji nie znaczy, że okresu nie ma. Znaczy, że nie wyczytacie go ze strony publicznej i musicie go dostać na piśmie, zanim wpiszecie cokolwiek do rejestru.

W API OpenAI zarówno zero data retention, jak i modified abuse monitoring wymagają uprzedniej zgody, a przyznawane są per endpoint, nie per konto (OpenAI, Data controls in the OpenAI platform, sprawdzone 24 października 2026). Doszły do tego warianty z automatycznym nadzorem bezpieczeństwa: w trybie zera retencji z prywatnym przetwarzaniem bezpieczeństwa klient musi skonfigurować magazyn pod własną kontrolą, a w wariancie z prywatną retencją treść leży w szyfrowanych logach monitoringu nadużyć po stronie dostawcy i jest wyłączona z przeglądu ludzkiego, o ile prawo nie wymaga inaczej. Dla osoby odpowiadającej za dane to trzy różne odpowiedzi na pytanie „gdzie leży nasz prompt”, podpisane jedną nazwą handlową.

Zakres ustawienia: region, konto, projekt

Najczęstszy błąd w tej konfiguracji nie polega na wybraniu złego trybu, tylko na założeniu, że wybrany tryb obowiązuje wszędzie. Na Bedrocku ustawienie jest per region i nie propaguje się na pozostałe. Region, którego nikt nie ustawił, zostaje na wartości inherit i spada do domyślnej wartości modelu. Tryb efektywny wyznacza pierwsza wartość różna od inherit w kolejności: projekt, konto, domyślna wartość modelu. Projekt ustawiony na inherit przy koncie ustawionym na none daje więc none dla wszystkich modeli wywoływanych z tego projektu — ale tylko w tym jednym regionie.

Drugi haczyk w tym samym miejscu dotyczy tego, gdzie ląduje to, co już zostało zatrzymane. Przy włączonej inferencji międzyregionalnej przechowywane wejścia i wyjścia leżą w regionach docelowych, czyli tam, gdzie zapytanie zostało faktycznie przetworzone — nie tam, gdzie je wysłaliście. Zdanie „retencja wyłączona w naszym regionie” traci wtedy sens, bo region przechowywania nie jest już regionem, który kontrolujecie ustawieniem. To pytanie do zadania przed włączeniem inferencji międzyregionalnej, a nie po.

Domyślne przechowywanie w funkcjach stanowych i cache

Tryb retencji nie obejmuje wszystkiego. Obok niego działają funkcje, które przechowują dane, bo tak mają ustawione domyślne wartości, a nie bo ktoś o to poprosił.

Na Bedrocku w trybie default parametr store w Responses API domyślnie przyjmuje true. Co ważniejsze, dokumentacja zastrzega wprost, że ustawienie store=false nie gwarantuje zera retencji: część modeli może nadal przechowywać dane do przeglądu bezpieczeństwa, przy czym nie są one wtedy dostępne dla klienta przez GET /v1/responses/{id}. Dane przechowywane i jednocześnie dla was nieodczytywalne to najgorszy możliwy stan w rozmowie, w której klient pyta, co stało się z jego dokumentem. Jeśli zależy wam na zerze, dokumentacja kieruje do trybu none, nie do parametru zapytania.

Na Vertex AI domyślne wartości idą w tę samą stronę. Cache niejawny jest domyślnie włączony dla publikowanych modeli Gemini, żeby skrócić czas odpowiedzi, i ma dwa poziomy: cache w pamięci, nieprzechowywany na dysku, usuwany nie później niż 24 godziny od zapisu, oraz cache trwały, szyfrowany, również usuwany nie później niż po 24 godzinach i często wcześniej. Żaden z nich, według tej samej dokumentacji, nie służy do trenowania ani dostrajania modeli, a wyłącza się je ustawieniami disableCache i retentionConfig (Google Cloud, Data governance, sprawdzone 24 października 2026). W Interactions API niepodanie wartości store oznacza true dla wszystkich modeli — domyślnie przechowuje. Logowanie zapytań i odpowiedzi oraz wznawianie sesji są z kolei domyślnie wyłączone, więc zero retencji na tej platformie wymaga działań w kilku obszarach naraz, a nie jednego ustawienia.

Są też wyjątki, których według dokumentacji wyłączyć nie można wcale: przy ugruntowaniu odpowiedzi wyszukiwaniem Google logi są trzymane do 3 dni, a przy ugruntowaniu Mapami Google wygenerowana treść przez 30 dni. Jeśli produkt korzysta z ugruntowania, „zero retencji” jest w tym miejscu nieprawdą niezależnie od waszych ustawień i lepiej napisać to klientowi samemu, niż usłyszeć to od jego audytora.

Po stronie Azure ta warstwa wygląda korzystniej i to też należy zapisać: dane funkcji stanowych — Responses API, wątków Assistants, zapisanych uzupełnień, plików — leżą w zasobie Foundry w waszym tenancie Azure, w tej samej geografii co zasób, są domyślnie szyfrowane AES-256 z opcją klucza zarządzanego przez klienta i mogą być przez was usunięte w dowolnym momencie.

Weryfikacja i wymuszenie trybu

Deklaracja handlowa nie jest odpowiedzią na pytanie o stan faktyczny. Każda z trzech platform daje sposób odczytania go z systemu i to jest jedyna odpowiedź warta pokazania klientowi.

Na Bedrocku da się przejść o krok dalej, od sprawdzania do wymuszania. Akcje zapisu publikują klucz warunku bedrock-mantle:DataRetentionMode, więc polityką SCP albo IAM można odrzucić w całej organizacji ustawienie trybu innego niż none. Istnieje też wariant pośredni, przydatny częściej, niż się wydaje: polityka dopuszczająca przechowywanie na potrzeby wykrywania nadużyć, ale blokująca tryby z przeglądem ludzkim. To jedyna konstrukcja z tej listy, która nie opiera się na tym, że nikt nie kliknie inaczej — i jednocześnie ta, która odbierze wam modele wymagające przeglądu, zgodnie z pierwszym akapitem tego tekstu.

Zostaje pytanie, kto to u was trzyma. Ta konfiguracja żyje w trzech miejscach naraz, jest ustawiana osobno dla każdego regionu i zmienia swój skutek przy każdym nowym modelu wprowadzonym do projektu — bez żadnej zmiany po waszej stronie. To nie jest zgłoszenie do zamknięcia raz, tylko ustawienie z imiennym właścicielem i rytmem przeglądu. W firmach, które nie mają takiej roli obsadzonej wewnątrz, bywa to przedmiotem zewnętrznego kierownictwa technologicznego — tak działa dyrektor AI na wynajem, rozliczany z decyzji o kierunku, a nie z przepracowanych godzin. Z tego samego powodu podmiana wersji modelu pod spodem wymaga zestawu kontrolnego po waszej stronie: lista rzeczy do sprawdzenia, gdy dostawca podmienia model, dotyczy jakości wyników, ale powinna obejmować również allowed_modes.

Ten tekst opisuje dokumentację techniczną platform i nie jest poradą prawną. Ocena, czy dany tryb retencji wystarcza przy waszym rodzaju danych i waszych umowach powierzenia, wymaga kontrasygnaty prawnika znającego te umowy.

Decyzja: model czy zero retencji

Konflikt, który trzeba rozstrzygnąć świadomie, brzmi tak: „wymagamy zera retencji” i „chcemy najnowszego modelu” mogą być w danym kwartale żądaniami wzajemnie sprzecznymi. To nie jest szczegół zakupowy ani temat na spotkanie o cenniku — to decyzja architektoniczna, bo przesądza o katalogu modeli dostępnym dla produktu. Kolejność jej podejmowania ma znaczenie, bo punkt drugi potrafi unieważnić pracę zrobioną w pierwszym.

• Odczytajcie allowed_modes modeli, których chcecie używać, zanim ustawicie tryb. Jeden odczyt na model. Jeśli którykolwiek wymaga przeglądu, wybór jest jawny: ten model albo zero retencji. Odłożenie go nie sprawia, że znika — wraca błędem ValidationException na produkcji.
• Ustawcie tryb w każdym regionie, którego używacie, nie w jednym. Potem odczytajcie go z powrotem razem z polem source. Region pozostawiony na inherit jest regionem bez waszej decyzji, nie regionem bezpiecznym.
• Przejrzyjcie domyślne wartości funkcji stanowych i cache osobno od trybu. Parametr store na dwóch platformach domyślnie przechowuje, cache na Vertexie jest domyślnie włączony, a ugruntowanie ma wyjątki bez wyłącznika. Tryb retencji tego nie przykrywa.
• Zażądajcie na piśmie okresu przechowywania tam, gdzie dokumentacja go nie podaje. Dotyczy to co najmniej magazynu monitoringu nadużyć na Azure. Pytanie do zespołu obsługi konta brzmi: ile dni, w jakim regionie, kto ma dostęp i jak sprawdzimy to po stronie technicznej.
• Powiążcie przegląd z wprowadzeniem modelu, nie z kwartałem. Model wchodzi częściej, niż kończy się kwartał, a wchodzi ze swoim własnym wymogiem.

Jeśli dziś, bez otwierania konsoli, nie potraficie powiedzieć, jaki tryb retencji obowiązuje w którym waszym regionie i jakie modele ten tryb dopuszcza, to jest pierwsza rzecz do zrobienia w tym tygodniu — przed następnym zbiorem danych klienta, który przez ten endpoint przejdzie. Odczyt zajmuje trzy wywołania API i daje dokładnie tę odpowiedź, o którą poprosi audytor klienta.