Die Datenschutzgarantien für Trainingsdaten beim föderierten Lernen beruhten lange weitgehend darauf, dass Nutzer dem Serverbetreiber vertrauen. Am 2. Oktober 2026 stellte Google Research in einem offiziellen Blogbeitrag ein föderiertes Lernsystem der nächsten Generation vor: Das Training läuft in Trusted Execution Environments (TEEs), sodass die Datenverarbeitung aus der Ferne überprüfbar und auditierbar ist — und welche Berechnungen auf die Daten zugreifen dürfen, muss zuvor in einem öffentlichen Transparenz-Log festgehalten werden. Die Tastatur-App Gboard nutzt das neue System bereits, beginnend mit den Modellen zur Wortvorhersage für Englisch und Japanisch.
Die Schwäche des alten Systems war nicht der Algorithmus, sondern die Unsichtbarkeit
Google führte föderiertes Lernen 2017 ein; es steckt unter anderem in der Wortvorhersage von Gboard und in den Antwortvorschlägen von Google Messages. Im frühen Design wurden Gerätedaten hochgeladen und sofort aggregiert, doch Außenstehende konnten nicht überprüfen, ob Daten protokolliert oder eingesehen wurden. Die später ergänzte Secure Aggregation schützte die Uploads kryptografisch, war aber mit den stärksten zentralen Garantien der differenziellen Privatsphäre nicht vereinbar. Das Ergebnis: Der Betreiber fügte das Rauschen hinzu — und der Betreiber bestätigte auch, dass er es getan hatte. Datenschutz blieb ein Versprechen.
Wie das neue System „Vertrauen“ durch „Überprüfung“ ersetzt
Geräte verschlüsseln Trainingsbeispiele lokal vor dem Upload und autorisieren vorab eine Zugriffsrichtlinie: Nur die darin aufgeführten TEE-Berechnungen dürfen die Daten verarbeiten, und sie dürfen nur anonymisierte Ergebnisse freigeben. Die Richtlinien müssen in Rekor, einem öffentlichen Transparenz-Log, veröffentlicht werden, sodass externe Prüfer die Gesamtheit der serverseitigen Workloads nachvollziehen können, an denen ein Gerät beteiligt sein könnte. Das Schlüsselverwaltungssystem besteht aus einem Cluster von TEEs, die das RAFT-Konsensprotokoll ausführen, und übergibt Entschlüsselungsschlüssel nur an Workloads, die der Richtlinie entsprechen. Das Training selbst läuft als Python-Programm in TEEs: Eine Root-TEE verteilt parallelisierbare Teilaufgaben an einen Cluster von Worker-TEEs, und Betreiber sehen nur Kennzahlen sowie differentiell private Modellgewichte. Die Binärdateien für Schlüsselverwaltung und Datenverarbeitung lassen sich aus dem Open-Source-Code im GitHub-Repository Confidential Federated Compute reproduzierbar erstellen.
Was sich bereits verändert hat — und wo die Grenzen bleiben
Die Umstellung bei Gboard brachte zwei direkte Veränderungen. Früher dauerte das Training eines solchen Modells ein bis zwei Monate, gebremst durch Geräteverfügbarkeit, Rechenleistung auf den Geräten und mehrere Trainingsjobs, die um dieselben Geräte konkurrierten. Das neue System sammelt die Uploads zuerst und trainiert dann parallel auf dem Server; der Engpass verlagert sich auf die Verfügbarkeit von TEE-Ressourcen, die Trainingszeit ist deutlich gesunken, und laut Google ist auch die Genauigkeit gestiegen. Weil die Gradientenberechnung vom Gerät auf den Server wandert, steigt die Obergrenze für Modellgrößen im föderierten Lernen; Google experimentiert zudem damit, andere Python-Workloads wie synthetische Datengenerierung auf derselben Infrastruktur laufen zu lassen, und arbeitet an der Kombination von TEEs mit Beschleunigern.
Auch die Grenzen gehören dazu: TEE-Hardware der aktuellen Generation hat bekannte Einschränkungen, Seitenkanal-Beobachtungen sind ein ungelöstes Problem, und Google verortet die Arbeit selbst als Schritt hin zu beweisbar privatem Lernen, nicht als Zielankunft. Für normale Nutzer liegt die Bedeutung nicht in einer etwas schnelleren Tastatur, sondern darin, dass sich die Beweislast beim Datenschutz zu drehen beginnt — von „Wir sagen, wir haben Ihre Daten nie angesehen“ zu „Die Liste des Codes, der Ihre Daten verarbeiten darf, wird vorher veröffentlicht, und Sie können sie selbst prüfen.“
