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, das Google Private AI Compute Team in einem Google DeepMind-Blogbeitrag ankündigte, der am 23. September 2026 veröffentlicht wurde, zusammen mit einem aktualisierten technischen Dossier, einem öffentlichen Verzeichnis seiner Server‑Software und Zusammenfassungen unabhängiger Audits neben der Ankündigung.

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, von der Google sagt, dass sie die Daten für niemanden, auch nicht für Google selbst, zugä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, ein 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 die 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 nie außerhalb der vertrauenswürdigen Computing‑Basis des Systems oder der Google‑Infrastruktur sichtbar sind, und ein Orchestrator vermittelt zwischen dem KI‑Modell und dem Speicherserver, sodass Klartext das Enclave 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 vom Enclave 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 sämtlicher flüchtiger Prompt‑Kontext, Tokens und Zwischenergebnisse nach der Auslieferung der Antwort gelöscht werden.

Die Schlüsselweitergabe an den Speicherserver ist an eine Attestierung geknüpft. Laut dem Dossier kann ein Enclave, das keinen gültigen Attestierungsnachweis vorlegen kann, der einer beglaubigten Speicher‑Binärdatei entspricht (einschließlich einer modifizierten oder unautorisierten Build), 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, können laut Unternehmen verifizieren, 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 die geschäftliche Unterstützung 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.