Google introduce memoria persistente lato server per Private AI Compute

Google introdurrà memoria privata e persistente lato server per Private AI Compute, la sua piattaforma cloud di elaborazione AI, il Team Google Private AI Compute ha annunciato in un post del blog di Google DeepMind pubblicato il 23 settembre 2026, rilasciando un Technical Brief aggiornato, un registro pubblico del suo software server e riepiloghi di audit indipendenti insieme all’annuncio.

Un modello di cassaforte sicura con chiavi custodite sul dispositivo

Il team ha dichiarato che il nuovo strato di memoria persistente è progettato per funzionare come una cassaforte digitale sicura nel cloud. In questo modello, le informazioni necessarie per assistere un utente sono sigillate in uno storage dedicato e crittografato, mentre le chiavi crittografiche necessarie per sbloccarle sono conservate esclusivamente sui dispositivi personali dell’utente — una configurazione, secondo Google, rende i dati inaccessibili a chiunque, incluso Google stesso.

Quando un modello necessita di informazioni archiviate per gestire una richiesta, un canale autenticato e crittografato end‑to‑end collega il dispositivo a un ambiente protetto e isolato nel cloud. Tale spazio, chiamato enclave sicura, decritta temporaneamente i dati in memoria isolata, salva qualsiasi nuovo contesto e lo ricifra immediatamente. Google descrive il design come una combinazione di enclave sicure enforce da hardware, canali crittografati e database per utente protetti da chiavi di crittografia derivate dal dispositivo.

L’annuncio inquadra la funzionalità come risposta a un dilemma di lunga data: fornire a un assistente continuità a lungo termine tra dispositivi mantenendo gli standard di privacy rigorosi tipicamente limitati all’elaborazione sul dispositivo. Come esempi della continuità prevista, il team descrive il recupero di istruzioni di montaggio su un laptop che erano state visualizzate in precedenza tramite occhiali intelligenti, o la ripresa di una conversazione complessa tra mobile e web.

Da una piattaforma senza stato a memoria persistente

Google ha introdotto Private AI Compute l’11 novembre 2025, in un post di Jay Yagnik, vicepresidente dell’innovazione e ricerca AI, che lo descrive come una piattaforma che combina i modelli cloud Gemini con le garanzie di sicurezza e privacy dell’elaborazione sul dispositivo. La piattaforma gira sulle Tensor Processing Units personalizzate di Google, protette da Titanium Intelligence Enclaves. Al lancio, Google ha affermato che Private AI Compute renderebbe Magic Cue più utile sui telefoni Pixel 10 e consentirebbe all’app Pixel Recorder di riassumere le trascrizioni in un più ampio ventaglio di lingue.

Fino a questo aggiornamento, la tecnologia era rigorosamente senza stato, cancellando tutto il contesto nel momento in cui un compito terminava. Google afferma che le soluzioni alternative, come far salvare all’AI elenchi di fatti e preferenze personali, non erano sufficienti a supportare le esperienze continue che si attendono da un’AI personale.

Architettura della memoria e ciclo di vita della richiesta

Il Technical Brief aggiornato di Private AI Compute, proveniente dai team Platforms and Devices, DeepMind, Core e Cloud di Google, descrive la funzionalità come un’estensione con stato della piattaforma: una memoria persistente per utente che risiede nel cloud pur rimanendo illeggibile da parte di Google, operando interamente all’interno dell’ambiente di esecuzione protetto della piattaforma.

Al suo nucleo c’è Oak Server, una memoria database per utente con stato che gira all’interno di un ambiente di esecuzione hardware fidato. I record sono crittografati con chiavi per utente che, secondo il brief, non sono mai visibili al di fuori della base di calcolo fidata del sistema o all’infrastruttura di Google, e un orchestratore media tra il modello AI e il server di memoria in modo che il testo in chiaro non lasci mai l’enclave. L’applicazione di memoria è scritta in Rust e gira nel runtime Oak Containers, e sia il server che il runtime sono open source. Build riproducibili collegano il codice sorgente pubblicato ai binari distribuiti in produzione, con i digest risultanti approvati pubblicamente in un registro solo aggiuntivo e attestati dall’enclave prima del rilascio di qualsiasi chiave.

Per una richiesta che richiede contesto storico, il ciclo di vita inizia con il client che stabilisce una sessione crittografata tramite il Noise Protocol; la richiesta arriva quindi a un’enclave di orchestrazione all’interno di una macchina virtuale confidenziale AMD SEV‑SNP. L’orchestratore apre un canale ALTS mutuamente attestato verso il server di memoria e, dopo la verifica hardware della misurazione dell’enclave, le chiavi di decrittazione dell’utente vengono sbloccate per il motore del database e i record pertinenti vengono decrittati esclusivamente nella memoria volatile dell’enclave. Il contesto recuperato viene unito al prompt attivo e valutato interamente all’interno della piattaforma TPU rinforzata. Se la sessione genera nuove memorie, fatti o preferenze aggiornate, questi vengono ricifrati con la chiave dell’utente e scritti su storage persistente, e tutto il contesto volatile del prompt, i token e le attivazioni intermedie vengono cancellati al momento della consegna della risposta.

Il rilascio delle chiavi al server di memoria è vincolato all’attestazione. Secondo il brief, un’enclave che non può presentare prove di attestazione valide corrispondenti a un binary di memoria approvato (inclusa una build modificata o non autorizzata) non può ottenere le chiavi e quindi non può leggere la memoria di un utente.

Modello di minaccia e verifica esterna

Il documento riconosce che la conservazione dei dati modifica la postura di sicurezza della piattaforma. Un archivio persistente deve risolvere un identificatore stabile per utente per ogni richiesta, in modo che il sistema con stato non affermi la non‑targetabilità a livello di rete, proprietà intesa a impedire che una singola query possa essere collegata a un utente nel percorso di inferenza senza stato. Google afferma che mirare alla memoria di uno specifico utente produce solo ciphertext opaco, poiché le chiavi necessarie per leggerla sono disponibili solo all’interno di un enclave attestata.

Gli obiettivi di sicurezza dichiarati per l’archivio persistente includono l’assenza di un percorso amministrativo verso i dati utente in chiaro anche in scenari di emergenza break‑glass, il contenimento di un’istanza compromessa tramite macchine virtuali confidenziali e politiche di egress predefinite di tipo deny che coprono monitoraggio, logging e core dump.

Google afferma che revisori esterni hanno convalidato il design del sistema sia per il rilascio iniziale sia per l’aggiornamento della memoria lato server, e ha pubblicato riassunti dei rapporti di audit del 2025 e del 2026. I dispositivi che eseguono Private AI Compute potranno verificare che il software sia autentico e non modificato rispetto al registro pubblico prima di inviare qualsiasi dato personale, secondo l’azienda.

Il lavoro è stato co‑sviluppato da Google DeepMind insieme ai team Platforms and Devices, Core e Cloud, con Four Flynn, Jay Yagnik e David Kleidermacher accreditati per la sponsorizzazione esecutiva.

Il documento si chiude con i prossimi passi pianificati: verifica di attestazione lato client che consentirebbe ai dispositivi degli utenti di convalidare in modo indipendente le prove del server prima di trasmettere dati sensibili, un registro di trasparenza a sola aggiunta osservato e co‑firmato da terze parti indipendenti, una copertura più ampia di build riproducibili su componenti di sistema aggiuntivi e audit ricorrenti da parte di terze parti.