Google introducerer vedvarende server‑side hukommelse til Private AI Compute

Google vil introducere privat, vedvarende hukommelse på serversiden til Private AI Compute, deres cloud‑AI‑behandlingsplatform, meddelte Google Private AI Compute‑teamet i et Google DeepMind blogindlæg offentliggjort den 23. september 2026, hvor de frigav en opdateret teknisk brief, en offentlig registrering af deres serversoftware og resuméer af uafhængige revisioner sammen med meddelelsen.

En model med en sikker boks og nøgler opbevaret på enhederne

Teamet sagde, at det nye vedvarende hukommelseslag er designet til at fungere som en sikker digital boks i skyen. Under denne model er information, der er nødvendig for at hjælpe en bruger, indkapslet i dedikeret, krypteret lagring, mens de kryptografiske nøgler, der kræves for at låse den op, udelukkende opbevares på brugerens personlige enheder — en ordning, som Google hævder gør dataene utilgængelige for andre, inklusive Google selv.

Når en model har brug for gemt information for at håndtere en forespørgsel, forbinder en autentificeret, ende-til-ende-krypteret kanal enheden med et beskyttet, isoleret miljø i skyen. Dette rum, kaldet en sikker enklave, dekrypterer midlertidigt data i isoleret hukommelse, gemmer ny kontekst og krypterer den straks igen. Google beskriver designet som en kombination af hardwarehåndhævede sikre enklaver, krypterede kanaler og brugerspecifikke databaser beskyttet af krypteringsnøgler afledt af enhederne.

Meddelelsen præsenterer funktionen som et svar på et langvarigt dilemma: at give en assistent langsigtet kontinuitet på tværs af enheder, samtidig med at de strenge privatlivsstandarder, som typisk er begrænset til behandling på enheden, opretholdes. Som eksempler på den tilsigtede kontinuitet beskriver teamet at hente samlevejledninger på en bærbar computer, som tidligere blev vist gennem smarte briller, eller genoptage en kompleks samtale mellem mobil og web.

Fra en tilstandsløs platform til vedvarende hukommelse

Google introducerede Private AI Compute den 11. november 2025, i et indlæg af Jay Yagnik, vicepræsident for AI‑innovation og -forskning, der beskriver det som en platform, der kombinerer deres Gemini‑cloud‑modeller med sikkerheds‑ og privatlivsgarantier fra on‑device‑behandling. Platformen kører på Googles specialdesignede Tensor Processing Units sikret af Titanium Intelligence Enclaves. Ved lanceringen sagde Google, at Private AI Compute ville gøre Magic Cue mere nyttig på Pixel 10‑telefoner og lade Pixel Recorder‑appen opsummere transskriptioner på et bredere sprogudvalg.

Indtil denne opdatering var teknologien strengt tilstandsløs og slettede al kontekst, så snart en opgave var afsluttet. Google siger, at løsninger som at lade AI’en gemme lister over personlige fakta og præferencer ikke var tilstrækkelige til at understøtte de kontinuerlige oplevelser, som de forventer af personlig AI.

Hukommelsesarkitektur og anmodningslivscyklus

Den opdaterede Private AI Compute Technical Brief, fra Googles Platforms and Devices, DeepMind, Core og Cloud‑teams, beskriver funktionen som en tilstandsbevarende udvidelse af platformen: en vedvarende, per‑bruger‑hukommelse, der lever i skyen, men forbliver ulæselig for Google og opererer fuldstændigt inden for platformens beskyttede eksekveringsmiljø.

Kernen er hukommelsessystemet Oak Server, en tilstandsbevarende, brugerspecifik database, der kører i et hardwarebaseret betroet eksekveringsmiljø. Poster er krypteret under per‑bruger‑nøgler, som briefen siger aldrig er synlige uden for systemets betroede beregningsbase eller for Googles infrastruktur, og en orkestrator medierer mellem AI‑modellen og hukommelsesserveren, så klartekst aldrig forlader enklaven. Hukommelsesapplikationen er skrevet i Rust og kører i Oak Containers‑runtime, og både serveren og runtime’en er open source. Reproducerbare builds knytter den offentliggjorte kilde til de binære filer, der er implementeret i produktion. De resulterende hashværdier er offentligt godkendt i en log, som kun kan føjes til, og attesteres af enklaven, før nogen nøgle frigives.

For en anmodning, der kræver historisk kontekst, begynder livscyklussen med, at klienten etablerer en krypteret session via Noise‑protokollen; anmodningen når derefter en orkestreringsenklave i en AMD SEV‑SNP fortrolig virtuel maskine. Orkestratoren åbner en gensidigt attesteret ALTS‑kanal til hukommelsesserveren, og efter hardware‑verifikation af enklavens måling frigøres brugerens dekrypteringsnøgler til database‑motoren, og de relevante poster dekrypteres udelukkende i flygtig enklavehukommelse. Den hentede kontekst flettes sammen med den aktive prompt og evalueres fuldstændigt inden for den forstærkede TPU‑platform. Hvis sessionen producerer nye hukommelsesposter, fakta eller opdaterede præferencer, krypteres de igen under brugerens nøgle og skrives til vedvarende lagring, og al flygtig promptkontekst, tokens og mellemliggende aktiveringer slettes ved svarlevering.

Frigivelse af nøgler til hukommelsesserveren er betinget af attestation. Ifølge briefen kan en enklave, der ikke kan fremvise gyldigt attesteringsbevis, som matcher en godkendt binær fil til hukommelsesserveren, ikke få nøglerne og dermed ikke læse en brugers hukommelse. Det gælder også enklaver med en modificeret eller uautoriseret build.

Trusselsmodel og ekstern verifikation

Briefen anerkender, at opbevaring af data ændrer platformens sikkerhedsposition. En vedvarende lagring skal slå en stabil brugerspecifik identifikator op for hver anmodning, så det tilstandsbevarende system ikke hævder at opfylde kravet om, at forespørgsler på netværksniveau ikke kan målrettes mod en bestemt bruger. Denne egenskab er beregnet til at forhindre, at en enkelt forespørgsel kan knyttes til en bruger på den tilstandsløse inferenssti. Google siger, at målretning af en specifik brugers hukommelse kun giver uigennemskuelig krypteret tekst, fordi de nøgler, der kræves for at læse den, kun er tilgængelige inden for en attesteret enklave.

De angivne sikkerhedsmål for den vedvarende lagring omfatter ingen administrativ vej til klartekst‑brugerdata selv i nødsituationer med break‑glass, indkapsling af en kompromitteret instans gennem fortrolige virtuelle maskiner og politikker, der som standard afviser udgående trafik, og som dækker overvågning, logning og core‑dumps.

Google siger, at eksterne revisorer har valideret systemdesignet både for den første udgivelse og opdateringen af server‑side‑hukommelsen, og at de har offentliggjort sammenfatninger af revisionsrapporter fra 2025 og 2026. Enheder, der kører Private AI Compute, vil kunne bekræfte, at softwaren er autentisk og uændret i forhold til den offentlige registrering, inden de sender personlige data, ifølge virksomheden.

Arbejdet blev medudviklet af Google DeepMind sammen med Platforms and Devices, Core, og Cloud teams, med Four Flynn, Jay Yagnik og David Kleidermacher anerkendt for deres ledelsesmæssige støtte.

Briefen afslutter med planlagte næste skridt: attesteringsverifikation på klientsiden, som vil gøre det muligt for bruger‑enheder at validere serverbeviser uafhængigt inden de overfører følsomme data, en transparenslog, som kun kan føjes til, og som observeres og medunderskrives af uafhængige tredjeparter, bredere dækning af reproducerbare builds på yderligere systemkomponenter samt tilbagevendende tredjepartsrevisioner.