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 poście 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 Jaya Yagnika, 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 Titanium Intelligence Enclaves. 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 dla infrastruktury 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. Odtwarzalne kompilacje łączą opublikowane źródło z binariami wdrożonymi w produkcji, a powstałe skróty są publicznie zatwierdzane w rejestrze pozwalającym wyłącznie na dopisywanie danych 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 we 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 w momencie dostarczenia odpowiedzi.

Uwolnienie kluczy do serwera pamięci jest uzależnione od poświadczenia. Według dokumentu, enklawa (w tym uruchamiająca zmodyfikowaną lub nieautoryzowaną wersję), która nie może przedstawić ważnych dowodów poświadczenia odpowiadających zatwierdzonemu binarium pamięci, 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, dlatego system stanowy nie deklaruje niemożności kierowania zapytań do konkretnego użytkownika 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 zweryfikowanej enklawy.

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 polityki wyjścia oparte na domyślnej odmowie obejmujące 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 na szczeblu kierowniczym uznano Four Flynn, Jay Yagnik i Davida Kleidermachera.

Raport kończy się planowanymi kolejnymi krokami: weryfikacją poświadczenia 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 zakresem odtwarzalnych kompilacji w dodatkowych komponentach systemu oraz regularnymi audytami zewnętrznymi.