Google führt persistenten serverseitigen Speicher für Private AI Compute ein

Google wird privaten, persistenten serverseitigen Speicher für Private AI Compute, seine Cloud‑KI‑Verarbeitungsplattform, einführen, wie das Google Private AI Compute Team in einem Google DeepMind-Blogbeitrag ankündigte, der am 23. September 2026 veröffentlicht wurde, wobei das Team zusammen mit der Ankündigung ein aktualisiertes technisches Dossier, ein öffentliches Verzeichnis seiner Server‑Software und Zusammenfassungen unabhängiger Audits veröffentlichte.

Ein sicheres Tresormodell mit geräteinternen Schlüsseln

Das Team erklärte, dass die neue persistente Speicherschicht so konzipiert ist, dass sie wie ein sicherer digitaler Tresor in der Cloud funktioniert. Nach diesem Modell werden Informationen, die zur Unterstützung eines Nutzers benötigt werden, in dediziertem, verschlüsseltem Speicher versiegelt, während die kryptografischen Schlüssel, die zum Entschlüsseln nötig sind, ausschließlich auf den persönlichen Geräten des Nutzers gehalten werden – eine Anordnung, die die Daten nach Angaben von Google für alle anderen, einschließlich Google selbst, unzugänglich macht.

Wenn ein Modell gespeicherte Informationen benötigt, um eine Anfrage zu bearbeiten, verbindet ein authentifizierter, Ende‑zu‑Ende‑verschlüsselter Kanal das Gerät mit einer geschützten, isolierten Umgebung in der Cloud. Dieser Bereich, eine Secure Enclave genannt, entschlüsselt die Daten vorübergehend im isolierten Speicher, speichert neue Kontextinformationen und verschlüsselt sie sofort wieder. Google beschreibt das Design als Kombination aus hardware‑erzwungenen Secure Enclaves, verschlüsselten Kanälen und benutzerspezifischen Datenbanken, die durch gerätebasierte Verschlüsselungsschlüssel geschützt sind.

Die Ankündigung stellt die Fähigkeit als Antwort auf ein langjähriges Dilemma dar: einem Assistenten langfristige Kontinuität über Geräte hinweg zu ermöglichen und gleichzeitig die strengen Datenschutzstandards einzuhalten, die normalerweise nur bei der Verarbeitung auf dem Gerät gelten. Als Beispiele für die beabsichtigte Kontinuität beschreibt das Team das Abrufen von Montageanleitungen auf einem Laptop, die zuvor über Smart‑Brillen angesehen wurden, oder das Fortsetzen einer komplexen Unterhaltung zwischen Mobil‑ und Web‑Plattformen.

Von einer zustandslosen Plattform zu persistentem Speicher

Google führte Private AI Compute am 11. November 2025 ein in einem Beitrag von Jay Yagnik, Vice President für KI‑Innovation und -Forschung, der es als eine Plattform beschreibt, die seine Gemini‑Cloud‑Modelle mit den Sicherheits‑ und Datenschutzgarantien der Verarbeitung auf dem Gerät kombiniert. Die Plattform läuft auf Googles eigenen Tensor Processing Units, gesichert durch Titanium Intelligence Enclaves. Bei der Einführung erklärte Google, dass Private AI Compute Magic Cue auf Pixel‑10‑Handys hilfreicher machen und es der Pixel Recorder‑App ermöglichen würde, Transkriptionen in einem breiteren Sprachenumfang zusammenzufassen.

Bis zu diesem Update war die Technologie strikt zustandslos und löschte jeglichen Kontext, sobald eine Aufgabe beendet war. Google sagt, dass Umgehungslösungen, wie das Speichern von Listen persönlicher Fakten und Präferenzen durch die KI, nicht ausreichten, um die kontinuierlichen Erlebnisse zu unterstützen, die von einer persönlichen KI erwartet werden.

Speicherarchitektur und Anforderungslebenszyklus

Der aktualisierte Private AI Compute Technical Brief der Teams von Google Platforms and Devices, DeepMind, Core und Cloud beschreibt die Funktion als zustandsbehaftete Erweiterung der Plattform: einen persistenten, benutzerspezifischen Speicher, der in der Cloud lebt und für Google unlesbar bleibt und vollständig innerhalb der geschützten Ausführungsumgebung der Plattform arbeitet.

Im Kern befindet sich der Oak Server‑Speicher, eine zustandsbehaftete, benutzerspezifische Datenbank, die in einer hardware‑basierten Trusted Execution Environment läuft. Laut dem Dossier werden Datensätze mit benutzerspezifischen Schlüsseln verschlüsselt, die weder außerhalb der vertrauenswürdigen Computing‑Basis des Systems noch für die Google‑Infrastruktur sichtbar sind, und ein Orchestrator vermittelt zwischen dem KI‑Modell und dem Speicherserver, sodass Klartext die Enklave niemals verlässt. Die Speicheranwendung ist in Rust geschrieben und läuft in der Oak Containers‑Runtime, wobei sowohl der Server als auch die Runtime Open Source sind. Reproduzierbare Builds verknüpfen den veröffentlichten Quellcode mit den in der Produktion eingesetzten Binärdateien, wobei die resultierenden Digests öffentlich in einem nur anhängbaren Ledger bestätigt und von der Enklave attestiert werden, bevor ein Schlüssel freigegeben wird.

Für eine Anfrage, die historischen Kontext erfordert, beginnt der Lebenszyklus damit, dass der Client über das Noise‑Protokoll eine verschlüsselte Sitzung etabliert; die Anfrage gelangt anschließend zu einem Orchestrierungs‑Enclave innerhalb einer AMD SEV‑SNP‑vertraulichen virtuellen Maschine. Der Orchestrator öffnet einen gegenseitig attestierten ALTS‑Kanal zum Speicherserver, und nach der hardwareseitigen Verifizierung der Messung des Enclaves werden die Entschlüsselungsschlüssel des Nutzers für die Datenbank‑Engine freigegeben und die relevanten Datensätze ausschließlich im flüchtigen Enclave‑Speicher entschlüsselt. Der abgerufene Kontext wird mit dem aktiven Prompt zusammengeführt und vollständig innerhalb der gehärteten TPU‑Plattform ausgewertet. Wenn die Sitzung neue Erinnerungen, Fakten oder aktualisierte Präferenzen erzeugt, werden diese erneut unter dem Schlüssel des Nutzers verschlüsselt und in persistenten Speicher geschrieben, während der gesamte flüchtige Prompt‑Kontext, sämtliche Tokens und Zwischenaktivierungen bei der Auslieferung der Antwort gelöscht werden.

Die Schlüsselweitergabe an den Speicherserver ist an eine Attestierung geknüpft. Laut dem Dossier kann eine Enklave (auch eine, die einen modifizierten oder unautorisierten Build ausführt), die keinen gültigen Attestierungsnachweis vorlegen kann, der einer beglaubigten Speicher‑Binärdatei entspricht, die Schlüssel nicht erhalten und somit den Speicher eines Nutzers nicht lesen.

Bedrohungsmodell und externe Verifizierung

Das Dokument stellt fest, dass das Behalten von Daten die Sicherheitslage der Plattform verändert. Ein persistenter Speicher muss für jede Anfrage einen stabilen Benutzer‑Identifikator auflösen, sodass das zustandsbehaftete System nicht die netzwerkweite Nicht‑Zielbarkeit beansprucht, eine Eigenschaft, die verhindern soll, dass eine einzelne Anfrage auf dem zustandslosen Inferenzpfad einem Nutzer zugeordnet werden kann. Google sagt, dass das Anvisieren des Speichers eines bestimmten Nutzers nur undurchsichtigen Ciphertext liefert, weil die zum Entschlüsseln benötigten Schlüssel ausschließlich innerhalb einer attestierten Enklave verfügbar sind.

Die angegebenen Sicherheitsziele für den persistenten Speicher umfassen, dass es keinen administrativen Pfad zu Klartext‑Nutzerdaten gibt, selbst in Notfallsituationen (Break‑Glass), die Eindämmung einer kompromittierten Instanz durch vertrauliche virtuelle Maschinen sowie standardmäßig verweigernde Ausgangsrichtlinien für Monitoring, Protokollierung und Speicherabbilder.

Google gibt an, dass externe Prüfer das Systemdesign sowohl für die Erstveröffentlichung als auch für das Server‑Seiten‑Speicher‑Update validiert haben und dass Zusammenfassungen der Prüfberichte für 2025 und 2026 veröffentlicht wurden. Geräte, die Private AI Compute ausführen, werden laut Unternehmen verifizieren können, dass die Software authentisch und unverändert gegenüber dem öffentlichen Register ist, bevor persönliche Daten gesendet werden.

Die Arbeit wurde gemeinsam von Google DeepMind zusammen mit den Teams Platforms and Devices, Core und Cloud entwickelt, wobei Four Flynn, Jay Yagnik und David Kleidermacher für ihre Unterstützung auf Führungsebene genannt werden.

Das Dokument schließt mit den geplanten nächsten Schritten: eine clientseitige Attestations‑Verifizierung, die Nutzergeräten ermöglicht, Servernachweise eigenständig zu prüfen, bevor sensible Daten übertragen werden; ein nur‑anhängbares Transparenz‑Log, das von unabhängigen Dritten beobachtet und mitunterzeichnet wird; eine erweiterte Abdeckung reproduzierbarer Builds für weitere Systemkomponenten sowie wiederkehrende Audits durch Dritte.