Google introduit une mémoire persistante côté serveur pour Private AI Compute

Google introduira une mémoire privée et persistante côté serveur à Private AI Compute, sa plateforme de traitement d’IA cloud, l’équipe Google Private AI Compute l’a annoncé dans un article de blog Google DeepMind publié le 23 septembre 2026, en publiant un brief technique mis à jour, un registre public de son logiciel serveur, ainsi que des résumés d’audits indépendants avec l’annonce.

Un modèle de coffre-fort sécurisé avec des clés détenues par l’appareil

L’équipe a déclaré que la nouvelle couche de mémoire persistante est conçue pour fonctionner comme un coffre-fort numérique sécurisé dans le cloud. Dans ce modèle, les informations nécessaires pour aider un utilisateur sont scellées dans un stockage dédié et chiffré, tandis que les clés cryptographiques nécessaires pour les déverrouiller sont conservées exclusivement sur les appareils personnels de l’utilisateur — une disposition que Google affirme rendre les données inaccessibles à quiconque, y compris à Google lui‑même.

Lorsqu’un modèle a besoin d’informations stockées pour traiter une requête, un canal authentifié et chiffré de bout en bout connecte l’appareil à un environnement protégé et isolé dans le cloud. Cet espace, appelé enclave sécurisée, déchiffre temporairement les données dans une mémoire isolée, enregistre tout nouveau contexte, puis les re‑chiffre immédiatement. Google décrit la conception comme combinant des enclaves sécurisées imposées par le matériel, des canaux chiffrés et des bases de données par utilisateur protégées par des clés de chiffrement dérivées de l’appareil.

L’annonce présente cette capacité comme une réponse à un dilemme de longue date : offrir à un assistant une continuité à long terme entre les appareils tout en respectant les normes de confidentialité strictes habituellement limitées au traitement sur l’appareil. À titre d’exemples de la continuité recherchée, l’équipe décrit la récupération de consignes de montage sur un ordinateur portable qui avaient été précédemment consultées via des lunettes intelligentes, ou la reprise d’une conversation complexe entre le mobile et le web.

De la plateforme sans état à la mémoire persistante

Google a introduit Private AI Compute le 11 novembre 2025, dans un article de Jay Yagnik, vice‑président de l’innovation et de la recherche en IA, le décrivant comme une plateforme qui combine ses modèles cloud Gemini avec les garanties de sécurité et de confidentialité du traitement sur l’appareil. La plateforme fonctionne sur les unités de traitement tensoriel personnalisées de Google, sécurisées par les enclaves d’intelligence Titanium. Lors du lancement, Google a déclaré que Private AI Compute rendrait Magic Cue plus utile sur les téléphones Pixel 10 et permettrait à l’application Pixel Recorder de résumer les transcriptions dans un plus large éventail de langues.

Jusqu’à cette mise à jour, la technologie était strictement sans état, effaçant tout contexte dès la fin d’une tâche. Google affirme que les solutions de contournement, comme faire enregistrer à l’IA des listes de faits et de préférences personnels, n’étaient pas suffisantes pour soutenir les expériences continues attendues d’une IA personnelle.

Architecture de la mémoire et cycle de vie d’une requête

Le brief technique mis à jour de Private AI Compute, provenant des équipes Platforms and Devices, DeepMind, Core et Cloud de Google, décrit la fonctionnalité comme une extension à état persistant de la plateforme : une mémoire persistante, par utilisateur, qui réside dans le cloud tout en restant illisible par Google, fonctionnant entièrement au sein de l’environnement d’exécution protégé de la plateforme.

Au cœur du système se trouve le serveur de mémoire Oak Server, une base de données à état, par utilisateur, fonctionnant à l’intérieur d’un environnement d’exécution sécurisé matériel. Les enregistrements sont chiffrés avec des clés propres à chaque utilisateur, que le brief indique ne jamais être visibles en dehors de la base de confiance du système ou de l’infrastructure de Google, et un orchestrateur assure la médiation entre le modèle d’IA et le serveur de mémoire afin que le texte en clair ne quitte jamais l’enclave. L’application de mémoire est écrite en Rust et s’exécute dans le runtime Oak Containers, et le serveur ainsi que le runtime sont open source. Les builds reproductibles lient le code source publié aux binaires déployés en production, les résumés résultants étant publiquement validés dans un registre à ajout uniquement et attestés par l’enclave avant toute libération de clé.

Pour une requête nécessitant un contexte historique, le cycle de vie débute avec le client établissant une session chiffrée via le protocole Noise ; la requête atteint ensuite une enclave d’orchestration à l’intérieur d’une machine virtuelle confidentielle AMD SEV‑SNP. L’orchestrateur ouvre un canal ALTS mutuellement attesté vers le serveur de mémoire, et après la vérification matérielle de la mesure de l’enclave, les clés de déchiffrement de l’utilisateur sont débloquées pour le moteur de base de données et les enregistrements pertinents sont déchiffrés strictement dans la mémoire volatile de l’enclave. Le contexte récupéré est fusionné avec l’invite active et évalué entièrement au sein de la plateforme TPU renforcée. Si la session génère de nouveaux souvenirs, faits ou préférences mises à jour, ils sont re‑chiffrés sous la clé de l’utilisateur et écrits dans le stockage persistant, et tout le contexte d’invite volatile, les jetons et les activations intermédiaires sont effacés lors de la remise de la réponse.

La libération des clés vers le serveur de mémoire est conditionnée à l’attestation. Selon le brief, une enclave qui ne peut pas présenter une preuve d’attestation valide correspondant à un binaire de mémoire approuvé (y compris une version modifiée ou non autorisée) ne peut pas obtenir les clés et ne peut donc pas lire la mémoire d’un utilisateur.

Modèle de menace et vérification externe

Le brief reconnaît que la conservation des données modifie la posture de sécurité de la plateforme. Un stockage persistant doit résoudre un identifiant stable par utilisateur pour chaque requête, afin que le système à état ne revendique pas la non-ciblabilité au niveau du réseau, propriété destinée à empêcher qu’une requête unique soit associée à un utilisateur sur le chemin d’inférence sans état. Google indique que cibler la mémoire d’un utilisateur spécifique ne produit qu’un texte chiffré opaque, car les clés nécessaires à sa lecture ne sont disponibles qu’à l’intérieur d’une enclave attestée.

Les objectifs de sécurité déclarés pour le stockage persistant incluent l’absence de voie administrative vers les données utilisateur en clair même dans des scénarios d’urgence de type break‑glass, le confinement d’une instance compromise grâce à des machines virtuelles confidentielles, et des politiques de sortie par défaut refusant tout accès couvrant la surveillance, la journalisation et les vidages de mémoire.

Google affirme que des auditeurs externes ont validé la conception du système tant pour la version initiale que pour la mise à jour de la mémoire côté serveur, et que l’entreprise a publié des résumés des rapports d’audit de 2025 et 2026. Selon la société, les appareils exécutant Private AI Compute pourront vérifier que le logiciel est authentique et non modifié par rapport au registre public avant d’envoyer des données personnelles.

Le travail a été co‑développé par Google DeepMind avec les équipes Platforms and Devices, Core et Cloud, Four Flynn, Jay Yagnik et David Kleidermacher étant crédités du parrainage exécutif.

Le brief se conclut par les prochaines étapes prévues : une vérification d’attestation côté client qui permettrait aux appareils des utilisateurs de valider de façon indépendante les preuves du serveur avant de transmettre des données sensibles, un journal de transparence en mode ajout uniquement, observé et co‑signé par des tiers indépendants, une couverture plus étendue des builds reproductibles sur des composants système supplémentaires, et des audits récurrents réalisés par des tiers.