Der neue Ablauf beginnt auf dem Gerät: Die Geräte verschlüsseln Trainingsbeispiele lokal und fügen eine Zugriffsrichtlinie hinzu, die festlegt, welche serverseitigen Workloads die Daten entschlüsseln und verarbeiten dürfen. Diese Richtlinien werden in einem öffentlichen Transparenzprotokoll veröffentlicht. Auf der Serverseite betreibt ein Cluster aus TEEs ein KMS, das vor der Ausgabe von Entschlüsselungsschlüsseln an eine Root-TEE eine Remote-Attestierung und die Übereinstimmung mit den Richtlinien verlangt. Die Root-TEE führt eine Python-Trainingsschleife aus und delegiert parallele Aufgaben an Worker-TEEs. Da Klartext ausschließlich innerhalb attestierter TEEs vorliegt und die Schlüsselvergabe an Richtlinien gebunden ist, können Auditoren den Datenzugriff vom Upload des Geräts bis zur Verarbeitung in der TEE nachvollziehen.

Veröffentlichte Zugriffsrichtlinien und reproduzierbare Builds bilden die entscheidende Grundlage für wirksame Audits. Auditoren können anhand der öffentlichen Protokolleinträge nachvollziehen, welche Workloads für den Zugriff auf Daten autorisiert waren. Außerdem können sie KMS- und Verarbeitungsbinärdateien unabhängig aus dem Quellcode neu erstellen und bitgenau mit den attestierten Images vergleichen. Dadurch wird das undurchsichtige „Black-Box“-Problem, das frühere serverseitige FL-Ansätze erschwerte, erheblich verringert. Zugleich entsteht ein öffentlich einsehbarer Nachweis, der die Einwilligung auf dem Gerät mit dem autorisierten Code und den in den TEEs laufenden Binärdateien verknüpft.

Auch wenn die Codeausführung attestiert und überprüfbar ist, erfordern Datenschutzgarantien eine Begrenzung der veröffentlichten Ergebnisse. Googles System beschränkt sichtbare Artefakte auf Metriken und mit Differential Privacy geschützte Modellgewichte; Klartextdaten von Geräten und Zwischengradienten bleiben innerhalb der TEEs. Dieser doppelte Ansatz – vertrauliche Ausführung plus DP-geschützte Veröffentlichungen – hilft, den Zielkonflikt zwischen Nutzen und nachweisbarem Datenschutz zu überbrücken. Er setzt jedoch eine korrekte DP-Implementierung im attestierten Programm sowie eine sorgfältige Abstimmung von Rauschen, Kohortengrößen und Stichprobenverfahren voraus.

TEEs stärken Vertraulichkeit und Integrität, sind aber kein Allheilmittel. TEEs der aktuellen Generation sind anfällig für bestimmte Seitenkanalbeobachtungen, und dynamisches Sideloading – mit dem proprietäre Modellelemente geschützt werden – vergrößert die Angriffsfläche, wenn es nicht sorgfältig eingeschränkt wird. Google erkennt diese Grenzen an und argumentiert, dass die gesamte datenschutzrelevante Logik im attestierbaren Python-Programm verbleiben muss. Nur sorgfältig geprüfte Eingaben sollten per Sideloading eingebunden werden. Auditoren sollten daher nicht nur das attestierte Programm prüfen, sondern auch die Herkunft der per Sideloading geladenen Artefakte und deren vorgesehenen Einsatzbereich.

Produktteams bietet die Architektur einen klaren Leitfaden, um nützliche Modelle mit sensiblen Daten zu trainieren, ohne dem Betreiber blind vertrauen zu müssen: Zugriffsrichtlinien veröffentlichen, reproduzierbare Builds unterstützen, Schlüssel durch Attestierung absichern und ausschließlich DP-geschützte Ergebnisse freigeben. Auditoren sollten Werkzeuge entwickeln, die Protokolleinträge, Attestierungen und neu erstellte Artefakte automatisch miteinander abgleichen. Organisationen, die ähnliche Konzepte bewerten, sollten Kapazitäten für TEEs einplanen, in Maßnahmen gegen Seitenkanäle investieren und Governance-Prozesse schaffen, die die Einwilligung auf dem Gerät mit der Bedeutung der Zugriffsrichtlinien verknüpfen.