Google lleva aprendizaje federado a TEEs y mejora la privacidad de Gboard, DP verificable

Google Research ha puesto en marcha una versión de aprendizaje federado que se ejecuta dentro de entornos de ejecución confiables (TEEs) y permite auditar externamente las garantías de privacidad diferencial que protege a Gboard.
Google ha anunciado una evolución del aprendizaje federado (FL) que se apoya en TEEs (Trusted Execution Environments) para ofrecer garantías de privacidad diferencial (DP) verificables por terceros. El cambio no es meramente técnico: elimina la necesidad de confiar ciegamente en los servidores de Google y permite que auditorías independientes comprueben que los datos de los usuarios nunca se registran ni se inspeccionan.
El salto de confianza que necesitaba el aprendizaje federado
Desde su introducción en 2017, FL ha alimentado funciones como la predicción de la siguiente palabra en Gboard, la redacción automática en Google Messages y la selección inteligente de texto en Android. El modelo original enviaba gradientes cifrados a un servidor central, pero la arquitectura dejaba una brecha de confianza: los usuarios no podían verificar que sus datos se usaran exclusivamente para el entrenamiento y que el ruido necesario para DP se aplicara correctamente.
Los intentos anteriores de cerrar esa brecha, como la agregación segura (Secure Aggregation), ofrecían protección criptográfica pero no eran compatibles con los algoritmos de DP más avanzados, como matrix factorization DP‑FTRL. Además, la responsabilidad de añadir el ruido recayó en Google, lo que generaba dudas sobre la veracidad de las garantías.
Arquitectura basada en TEEs y privacidad verificable
El nuevo diseño traslada la computación de gradientes al servidor, pero lo hace dentro de un entorno TEE cuya ejecución puede ser atestiguada. La arquitectura se compone de cuatro bloques clave:
- Subida de datos cifrados: Cada dispositivo encripta localmente los ejemplos de entrenamiento y los asocia a una política de acceso pública. Esa política enumera los cálculos permitidos dentro del
TEEy se registra en un log de transparencia. - Sistema de gestión de claves (
KMS) y verificación de políticas: UnKMSbasado enTEEque ejecuta el protocolo de consensoRAFTentrega claves solo a cargas de trabajo que coincidan con la política publicada. - Ejecución del workload: Un
TEEraíz ejecuta un bucle de entrenamiento en Python y delega subtareas aTEEworkers medianteFederated Language, una capa derivada deTensorFlow Federated. Sólo los pesos del modelo ya perturbados porDPsalen del enclave. - Recuperación tolerante a fallos: Cada ronda guarda un estado cifrado por
KMSque permite reanudar el proceso si el nodo raíz o algún worker falla.
Las políticas de acceso se publican en Rekor, el registro de transparencia de Sigstore. Cualquier auditor externo puede seguir, de forma inmutable, qué workloads han tenido permiso para procesar datos de un dispositivo concreto. Además, los binarios de KMS y del código de entrenamiento son reproducibles a partir de repositorios de código abierto, lo que refuerza la verificabilidad.
Impacto concreto en Gboard y en la industria
Gboard ha aprovechado este sistema para lanzar modelos de predicción de palabras en inglés y japonés con dos ventajas claras:
- Los datos se recopilan antes de iniciar el entrenamiento, lo que elimina la dependencia de la disponibilidad diurna de los dispositivos y permite planificar la participación de forma óptima. En pruebas internas, el entrenamiento de un modelo inglés en 5.000 rondas con cohortes de 6.500 dispositivos redujo el tiempo de entrenamiento de varios meses a unas pocas semanas.
- Al trasladar el cuello de botella al servidor, el proceso se paraleliza en múltiples máquinas, aumentando la velocidad y la precisión del modelo sin sacrificar la privacidad.
En términos de métricas, Google reporta una mejora de precisión de alrededor del 2 % frente a la versión anterior, mientras que los parámetros de DP (epsilon) se reducen en un 15 % gracias a la capacidad de optimizar el ruido bajo una visión global del entrenamiento.
Implicaciones para desarrolladores y reguladores
Para los equipos de IA que operan fuera del ecosistema de Google, la propuesta abre una ruta clara para combinar FL con DP verificable sin depender de infraestructura propietaria. La publicación de políticas en un log de transparencia y la disponibilidad de componentes de código abierto (por ejemplo, Federated Language) reducen la barrera de entrada y facilitan auditorías regulatorias.
Los reguladores, que cada vez exigen pruebas de cumplimiento de privacidad, encontrarán en este modelo una herramienta que permite validar, de forma independiente, que los datos de los usuarios no se utilizan más allá del entrenamiento y que el ruido añadido cumple con los límites legales.
Sin embargo, la solución no está exenta de retos. Los TEE requieren hardware especializado (por ejemplo, Intel SGX o ARM TrustZone) y su despliegue masivo implica costes de actualización de servidores. Además, la confianza se traslada del software a la integridad del propio hardware, lo que abre la puerta a ataques de nivel físico o a vulnerabilidades descubiertas en futuras versiones de los enclaves.
En síntesis, Google ha demostrado que es posible cerrar el círculo de confianza en FL mediante entornos verificables, pero la adopción general dependerá de la disponibilidad de TEE en la infraestructura de los proveedores y de la capacidad de los reguladores para interpretar los logs de transparencia.
