El nuevo flujo comienza en el dispositivo: cada dispositivo cifra localmente los ejemplos de entrenamiento y adjunta una política de acceso que especifica qué cargas de trabajo del lado del servidor pueden descifrar y procesar los datos. Estas políticas se publican en un registro público de transparencia. En el servidor, un clúster de TEE implementa un KMS que exige atestación remota y una política coincidente antes de entregar claves de descifrado a un TEE raíz. El TEE raíz ejecuta un ciclo de entrenamiento en Python y distribuye tareas en paralelo entre los TEE de trabajo. Como los datos en texto claro solo existen dentro de los TEE atestados y las claves están sujetas a las políticas, los auditores pueden rastrear el acceso a los datos desde la carga del dispositivo hasta su procesamiento dentro del TEE.

Publicar las políticas de acceso y permitir compilaciones reproducibles son los elementos que hacen posible una auditoría efectiva. Los auditores pueden consultar las entradas del registro público para ver qué cargas de trabajo estaban autorizadas a acceder a los datos, y reconstruir por su cuenta, a partir del código fuente, los binarios del KMS y del procesamiento para verificar que coinciden bit a bit con las imágenes atestadas. Esto reduce significativamente el problema de la «caja negra» que dificultaba los primeros enfoques de FL del lado del servidor y proporciona un registro público que vincula el consentimiento del dispositivo, el código autorizado y los binarios que se ejecutan dentro de los TEE.

Aunque la ejecución del código esté atestada y sea auditable, las garantías de privacidad también requieren limitar los resultados que se publican. El sistema de Google restringe los elementos visibles a métricas y pesos de modelos protegidos mediante privacidad diferencial; los datos de los dispositivos en texto claro y los gradientes intermedios permanecen dentro de los TEE. Este doble enfoque —ejecución confidencial y privacidad diferencial en los resultados publicados— ayuda a conciliar la utilidad con una privacidad demostrable, pero depende de que la privacidad diferencial esté implementada correctamente dentro del programa atestado y de que se ajusten cuidadosamente el ruido, el tamaño de las cohortes y las estrategias de muestreo.

Los TEE refuerzan la confidencialidad y la integridad, pero no son una solución infalible. Los TEE actuales son vulnerables a ciertas observaciones mediante canales laterales, y la carga dinámica de componentes —que se utiliza para mantener privados elementos propietarios del modelo— amplía la superficie de ataque si no se limita cuidadosamente. Google reconoce estas limitaciones y sostiene que es necesario mantener toda la lógica relevante para la privacidad dentro del programa Python susceptible de atestación y reservar la carga dinámica para entradas debidamente auditadas. Por eso, los auditores deben verificar no solo el programa atestado, sino también la procedencia y el alcance previsto de los componentes cargados dinámicamente.

Para los equipos de producto, esta arquitectura ofrece una guía clara para entrenar modelos útiles con datos sensibles sin tener que confiar ciegamente en quien opera el sistema: publicar las políticas de acceso, permitir compilaciones reproducibles, condicionar las claves a la atestación y publicar únicamente resultados procesados con privacidad diferencial. Los auditores deberían crear herramientas que comparen automáticamente las entradas del registro, las atestaciones y los artefactos reconstruidos. Las organizaciones que evalúen diseños similares deberían prever la capacidad necesaria de TEE, invertir en medidas contra los canales laterales y establecer una gobernanza que vincule el consentimiento del dispositivo con el significado de las políticas de acceso.