Google ha introdotto una nuova memoria persistente lato server per Private AI Compute, la propria piattaforma cloud progettata per eseguire modelli Gemini mantenendo garanzie di privacy simili a quelle dell’elaborazione locale sul dispositivo. La nuova architettura consente ai sistemi AI di conservare nel tempo informazioni, preferenze e contesto relativi a un singolo utente, superando il funzionamento completamente stateless adottato fino a oggi, nel quale ogni informazione temporanea veniva eliminata al termine della richiesta. La memoria viene trattata come una sorta di vault cifrato nel cloud: i dati persistenti sono memorizzati in storage dedicato e protetto, ma le chiavi necessarie per decifrarli derivano dai dispositivi personali dell’utente e, secondo Google, non sono disponibili alla propria infrastruttura ordinaria. Quando una richiesta necessita di informazioni già memorizzate, il dispositivo apre un canale autenticato e cifrato end-to-end verso un ambiente protetto nel cloud; i dati vengono decifrati temporaneamente soltanto all’interno di un secure enclave, utilizzati dal modello insieme al prompt corrente ed eventualmente aggiornati con nuove informazioni, quindi nuovamente cifrati prima di essere riscritti nello storage persistente. Google propone questa architettura per consentire esperienze AI realmente continue tra dispositivi differenti, per esempio recuperare su un laptop istruzioni consultate in precedenza tramite smart glasses oppure proseguire sul web una conversazione complessa iniziata da smartphone, evitando di affidarsi a semplici elenchi separati di fatti e preferenze salvati dall’assistente. Private AI Compute era stato introdotto nel novembre 2025 come piattaforma capace di combinare la potenza dei modelli Gemini nel cloud con protezioni tipiche dell’elaborazione on-device, basandosi sulle TPU proprietarie di Google e sui Titanium Intelligence Enclaves; nelle prime implementazioni veniva utilizzato, tra l’altro, per migliorare Magic Cue sui Pixel 10 e ampliare le capacità di riepilogo delle trascrizioni nell’app Recorder.
Il componente centrale della nuova memoria persistente è Memory Oak Server, un database stateful dedicato al singolo utente che viene eseguito all’interno di un trusted execution environment hardware. Ogni record è cifrato attraverso chiavi specifiche per l’utente e un orchestratore media tutte le comunicazioni tra modello e server di memoria, impedendo che il contenuto in chiaro esca dall’enclave. L’applicazione di memoria è scritta in Rust e gira attraverso Oak Containers; sia il runtime sia il server sono open source e vengono utilizzate build riproducibili per collegare il codice sorgente pubblico ai binari effettivamente distribuiti in produzione. Gli hash risultanti vengono registrati in un ledger append-only e devono essere riconosciuti e attestati dall’enclave prima che possano essere rese disponibili le chiavi di cifratura. Il ciclo di una richiesta che necessita di memoria storica inizia con la creazione di una sessione cifrata mediante Noise Protocol; la richiesta raggiunge quindi un’enclave di orchestrazione eseguita all’interno di una confidential virtual machine protetta da AMD SEV-SNP. Da qui viene aperto un canale ALTS con autenticazione reciproca verso Memory Oak Server e soltanto dopo la verifica hardware dell’identità e dello stato dell’enclave vengono rese disponibili al database le chiavi necessarie a decifrare i record. La decifratura avviene esclusivamente nella memoria volatile dell’ambiente protetto, il contesto recuperato viene combinato con il prompt attivo e l’inferenza viene eseguita all’interno della piattaforma TPU rafforzata. Se durante la sessione emergono nuove informazioni da conservare, come preferenze aggiornate, fatti utili o ulteriori elementi contestuali, questi vengono cifrati nuovamente con la chiave dell’utente e salvati nel database persistente, mentre prompt temporanei, token e attivazioni intermedie vengono eliminati dopo la consegna della risposta.
Il rilascio delle chiavi verso il server di memoria dipende interamente dall’attestation dell’enclave. Un’istanza che non riesca a dimostrare di stare eseguendo un binario autorizzato e corrispondente a una versione pubblicamente approvata non può ottenere le chiavi e quindi non può leggere la memoria dell’utente; questo vale anche per build modificate o non autorizzate. Google riconosce tuttavia che l’introduzione di uno storage persistente modifica inevitabilmente il modello di minaccia della piattaforma. Nel percorso stateless originario, Private AI Compute puntava infatti anche alla non-targetability a livello di rete, cioè alla difficoltà di associare in modo stabile una singola richiesta a uno specifico utente. Una memoria persistente richiede invece necessariamente un identificatore stabile per recuperare il database corretto e questa proprietà non può quindi essere mantenuta nello stesso modo. L’azienda sostiene che anche nel caso in cui un attaccante riuscisse a individuare lo storage associato a uno specifico utente, troverebbe soltanto ciphertext opaco, poiché le chiavi restano accessibili esclusivamente agli enclave attestati. Tra gli obiettivi espliciti di sicurezza figurano inoltre l’assenza di qualsiasi percorso amministrativo verso i dati in chiaro, anche nelle procedure di emergenza cosiddette break-glass, il contenimento di eventuali istanze compromesse attraverso confidential virtual machine e politiche di egress basate su default-deny che includono anche monitoraggio, logging e core dump.
Google accompagna il nuovo sistema con meccanismi di verifica pubblica e audit esterni. L’azienda ha pubblicato un record del software utilizzato dai server, un aggiornamento del technical brief di Private AI Compute e sintesi degli audit indipendenti effettuati sia sulla versione originaria del 2025 sia sull’estensione stateful del 2026. I dispositivi che utilizzano Private AI Compute potranno verificare che il software remoto corrisponda alla versione autentica e non modificata prima di inviare dati personali, sfruttando i record pubblici delle build e l’attestazione hardware. Il progetto è stato sviluppato congiuntamente dai team Google DeepMind, Platforms and Devices, Core e Cloud, con Four Flynn, Jay Yagnik e David Kleidermacher indicati come sponsor esecutivi. La roadmap prevede ulteriori rafforzamenti dell’architettura, tra cui verifica dell’attestation direttamente lato client per permettere ai dispositivi dell’utente di controllare autonomamente le prove fornite dal server prima di trasmettere dati sensibili, un transparency log append-only osservato e controfirmato anche da soggetti indipendenti, l’estensione delle build riproducibili a un numero maggiore di componenti e audit periodici di terze parti. In questo modo Google sta cercando di costruire una memoria cloud permanente che possa essere utilizzata da assistenti AI sempre più personali senza rinunciare a un modello nel quale dati e chiavi restano separati e l’accesso al contenuto in chiaro è subordinato alla verifica crittografica dell’ambiente di esecuzione.
Questo articolo è stato redatto con il supporto di strumenti di intelligenza artificiale (AI)