Google wprowadza trwałą pamięć po stronie serwera do Private AI Compute

Google wprowadzi prywatną, trwałą pamięć po stronie serwera do Private AI Compute, swojej platformy przetwarzania AI w chmurze, zespół Google Private AI Compute ogłosił to w post na blogu Google DeepMind opublikowanym 23 września 2026 r., udostępniając zaktualizowany dokument techniczny, publiczny zapis oprogramowania serwera oraz podsumowania niezależnych audytów wraz z ogłoszeniem.

Model bezpiecznej skrytki z kluczami przechowywanymi na urządzeniu

Zespół powiedział, że nowa warstwa trwałej pamięci została zaprojektowana tak, aby działała jak bezpieczna cyfrowa skrytka w chmurze. W ramach tego modelu informacje niezbędne do pomocy użytkownikowi są zamknięte w dedykowanym, zaszyfrowanym magazynie, podczas gdy kryptograficzne klucze potrzebne do ich odblokowania są przechowywane wyłącznie na osobistych urządzeniach użytkownika — rozwiązanie, które według Google sprawia, że dane są niedostępne dla kogokolwiek innego, w tym samego Google.

Gdy model potrzebuje przechowywanych informacji do obsługi żądania, uwierzytelniony, szyfrowany od końca do końca kanał łączy urządzenie z chronionym, odizolowanym środowiskiem w chmurze. Przestrzeń ta, zwana bezpieczną enklawą, tymczasowo odszyfrowuje dane w odizolowanej pamięci, zapisuje nowy kontekst i natychmiast ponownie je szyfruje. Google opisuje projekt jako połączenie sprzętowo wymuszonych bezpiecznych enklaw, zaszyfrowanych kanałów oraz baz danych per‑użytkownik chronionych kluczami szyfrującymi pochodzącymi z urządzenia.

Ogłoszenie przedstawia tę funkcję jako odpowiedź na odwieczny dylemat: zapewnienie asystentowi długoterminowej ciągłości pomiędzy urządzeniami przy jednoczesnym zachowaniu surowych standardów prywatności, które zwykle ograniczają się do przetwarzania na urządzeniu. Jako przykłady zamierzonej ciągłości zespół opisuje wyświetlenie instrukcji montażu na laptopie, które wcześniej były oglądane przez inteligentne okulary, lub wznowienie skomplikowanej rozmowy między urządzeniem mobilnym a przeglądarką internetową.

Z platformy bezstanowej do trwałej pamięci

Google wprowadziło Private AI Compute 11 listopada 2025, w poście autorstwa Jay Yagnik, wiceprezesa ds. innowacji i badań AI, opisując go jako platformę łączącą modele Gemini w chmurze z zapewnieniami bezpieczeństwa i prywatności charakterystycznymi dla przetwarzania na urządzeniu. Platforma działa na własnych jednostkach przetwarzania Tensor (TPU) Google zabezpieczonych przez enclawy Titanium Intelligence. Przy uruchomieniu Google oświadczyło, że Private AI Compute uczyni Magic Cue bardziej użytecznym na telefonach Pixel 10 oraz umożliwi aplikacji Pixel Recorder podsumowywanie transkrypcji w szerszym zakresie języków.

Do tej aktualizacji technologia była ściśle bezstanowa, usuwając cały kontekst w momencie zakończenia zadania. Google twierdzi, że obejścia, takie jak zapisywanie przez AI listy faktów i preferencji osobistych, nie były wystarczające, aby wspierać ciągłe doświadczenia, których oczekuje od osobistej sztucznej inteligencji.

Architektura pamięci i cykl życia żądania

zaktualizowany Private AI Compute Technical Brief, pochodzący z zespołów Google Platforms and Devices, DeepMind, Core i Cloud, opisuje funkcję jako stanowe rozszerzenie platformy: trwałą pamięć per‑użytkownika, która istnieje w chmurze, pozostając nieczytelną dla Google, działającą w pełni w chronionym środowisku wykonawczym platformy.

U podstaw znajduje się pamięć Oak Server, stanowa baza danych per‑użytkownik działająca wewnątrz sprzętowego zaufanego środowiska wykonawczego. Rekordy są szyfrowane przy użyciu kluczy per‑użytkownik, które, jak podaje dokument, nigdy nie są widoczne poza zaufaną bazą obliczeniową systemu ani przed infrastrukturą Google, a orchestrator pośredniczy między modelem AI a serwerem pamięci, tak aby tekst jawny nigdy nie opuszczał enklawy. Aplikacja pamięciowa jest napisana w języku Rust i działa w środowisku wykonawczym Oak Containers, przy czym zarówno serwer, jak i runtime są otwarto‑źródłowe. Reproduktywne kompilacje łączą opublikowane źródło z binariami wdrożonymi w produkcji, a powstałe skróty są publicznie zatwierdzane w niezmiennym rejestrze i poświadczane przez enklawę przed wydaniem jakiegokolwiek klucza.

W przypadku żądania wymagającego kontekstu historycznego cykl życia rozpoczyna się od ustanowienia przez klienta zaszyfrowanej sesji przy użyciu protokołu Noise; żądanie trafia następnie do enklawy orkiestracji wewnątrz poufnej wirtualnej maszyny AMD SEV‑SNP. Orchestrator otwiera wzajemnie poświadczony kanał ALTS do serwera pamięci, a po weryfikacji sprzętowej pomiaru enklawy klucze deszyfrujące użytkownika są odszyfrowywane dla silnika bazy danych i odpowiednie rekordy są odszyfrowywane wyłącznie w nietrwałej pamięci enklawy. Uzyskany kontekst jest łączony z aktywnym zapytaniem i oceniany w pełni w wzmocnionej platformie TPU. Jeśli sesja generuje nowe wspomnienia, fakty lub zaktualizowane preferencje, są one ponownie szyfrowane pod kluczem użytkownika i zapisywane w trwałym magazynie, a cała nietrwała pamięć kontekstu promptu, tokeny i pośrednie aktywacje są usuwane po dostarczeniu odpowiedzi.

Uwolnienie kluczy do serwera pamięci jest uzależnione od poświadczenia. Według dokumentu, enklawa, która nie może przedstawić ważnych dowodów poświadczenia odpowiadających zatwierdzonemu binarium pamięci (w tym zmodyfikowanej lub nieautoryzowanej wersji), nie może uzyskać kluczy i w konsekwencji nie może odczytać pamięci użytkownika.

Model zagrożeń i weryfikacja zewnętrzna

Raport przyznaje, że przechowywanie danych zmienia postawę bezpieczeństwa platformy. Trwałe magazynowanie musi ustalić stabilny identyfikator per‑użytkownik dla każdego żądania, tak aby system stanowy nie rościł sobie prawa do niecelowalności na poziomie sieci, właściwości mającej na celu uniemożliwienie powiązania dowolnego pojedynczego zapytania z użytkownikiem w bezstanowej ścieżce wnioskowania. Google twierdzi, że celowanie w pamięć konkretnego użytkownika daje jedynie nieprzezroczysty szyfrogram, ponieważ klucze potrzebne do jego odczytu są dostępne wyłącznie wewnątrz zweryfikowanego enclave.

Określone cele bezpieczeństwa trwałego magazynu obejmują brak administracyjnej ścieżki do niezaszyfrowanych danych użytkownika, nawet w sytuacjach awaryjnych typu break‑glass, izolację skompromitowanej instancji przy użyciu poufnych maszyn wirtualnych oraz domyślne odrzucanie polityk wyjścia obejmujących monitorowanie, logowanie i zrzuty pamięci.

Google twierdzi, że zewnętrzni audytorzy zweryfikowali projekt systemu zarówno dla początkowego wydania, jak i aktualizacji pamięci po stronie serwera, a firma opublikowała streszczenia raportów audytowych z lat 2025 i 2026. Urządzenia działające w ramach Private AI Compute będą mogły zweryfikować, że oprogramowanie jest autentyczne i niezmienione w stosunku do publicznego rejestru, zanim wyślą jakiekolwiek dane osobowe, według firmy.

Projekt został współopracowany przez Google DeepMind wraz z zespołami Platforms and Devices, Core i Cloud, a za wsparcie wykonawcze uznano Four Flynn, Jay Yagnik i Davida Kleidermachera.

Raport kończy się planowanymi kolejnymi krokami: weryfikacja attestation po stronie klienta, która pozwoliłaby urządzeniom użytkowników samodzielnie potwierdzać dowody serwera przed przesłaniem wrażliwych danych, dziennikiem przejrzystości typu append‑only, obserwowanym i współpodpisanym przez niezależne podmioty trzecie, szerszym pokryciem reproducible build w dodatkowych komponentach systemu oraz regularnymi audytami zewnętrznymi.