Google Research presentó el 2 de octubre de 2026 un sistema de aprendizaje federado que ejecuta el entrenamiento dentro de entornos de ejecución confiables (TEE) y publica pruebas para que terceros puedan revisar qué código accede a los datos. La compañía ya lo utiliza para entrenar modelos de predicción de palabras en inglés y japonés para Gboard.
Google afirma que el sistema permite verificar desde fuera las garantías de privacidad diferencial centralizada, incluida la aplicación del ruido que protege los modelos. Esto reduce cuánto hay que confiar en el operador del servicio, pero no elimina la confianza por completo: la desplaza hacia el hardware, la configuración de las políticas y el código que se ejecuta dentro de los TEE.
El problema no era solo enviar datos cifrados
Google introdujo el aprendizaje federado en 2017 para entrenar modelos a partir de datos repartidos entre dispositivos. En vez de subir conversaciones o textos completos, los teléfonos procesan ejemplos localmente y participan en la mejora de un modelo compartido. La tecnología se utiliza en funciones como la predicción de la siguiente palabra y Smart Compose de Gboard, las sugerencias de respuesta de Google Messages y Smart Text Selection en Android.
Comprobar que el sistema funciona como se describe es más difícil. En diseños anteriores, los dispositivos enviaban información para que el servidor la agregara, pero un observador externo no podía confirmar que Google no la hubiera registrado, inspeccionado o reutilizado. Secure Aggregation añadió protecciones criptográficas: el servidor podía obtener una suma de actualizaciones sin ver las contribuciones individuales. Sin embargo, esa técnica no encajaba bien con algoritmos de privacidad diferencial centralizada de última generación, como DP-FTRL con factorización matricial.
También quedaba por verificar que el ruido de privacidad se añadiera correctamente. En un esquema centralizado, el servidor recibe las contribuciones y aplica mecanismos para limitar cuánto puede revelar el modelo sobre una persona. Si el operador controla el código y nadie puede verificar su ejecución, la garantía depende en buena medida de que cumpla lo prometido. Una política de privacidad puede describirlo, pero no demuestra que el programa real la respete.
El nuevo diseño aborda esa brecha trasladando el cálculo de gradientes de los dispositivos al servidor, dentro de TEE verificables. Google sostiene que así puede usar algoritmos centrales más potentes sin pedir a los usuarios que acepten el proceso a ciegas. Los teléfonos siguen aportando ejemplos de entrenamiento, pero el servidor solo debería procesarlos mediante cargas de trabajo aprobadas y atestadas.
¿Qué ocurre desde que el teléfono sube un ejemplo?
El teléfono cifra localmente los ejemplos de entrenamiento antes de subirlos y autoriza de antemano una política de acceso. Esta especifica qué cálculos dentro de un TEE pueden recibir los datos. Se publica en Rekor, el registro de transparencia de Sigstore, para que pueda consultarse y auditarse.
Un sistema de gestión de claves (KMS), compuesto por TEE que ejecutan el protocolo de consenso RAFT, decide si se entrega una clave. Cuando una carga de trabajo solicita descifrar datos, el KMS comprueba la atestación remota del TEE y la compara con la política autorizada. Si el código coincide, libera la clave; si no, deniega el acceso. Un servidor que intentara ejecutar una versión modificada para guardar datos sin procesar tendría un hash distinto y no debería obtenerla.
Una vez autorizado, un TEE raíz ejecuta el bucle de entrenamiento escrito en Python y puede delegar tareas en TEE trabajadores. La orquestación se apoya en Federated Language, derivado de TensorFlow Federated. Los datos se procesan dentro de ese entorno aislado, y el operador no recibe las contribuciones individuales. El sistema entrega los pesos del modelo protegidos con privacidad diferencial y determinadas métricas de operación.
El diseño también contempla la recuperación. Cada ronda guarda un estado cifrado por el KMS para que el entrenamiento pueda reanudarse si falla el TEE raíz o alguno de los trabajadores. Además, las claves de descifrado solo pueden utilizarse durante un periodo limitado después de la subida.
La auditoría mejora; la confianza no desaparece
La publicación de las políticas en Rekor permite a auditores externos rastrear qué cargas de trabajo podían recibir datos de los dispositivos. Google afirma que tanto los binarios del KMS como los de procesamiento de datos pueden compilarse de forma reproducible a partir de código abierto. Así, un tercero puede comprobar que el programa desplegado corresponde al código publicado.
Las políticas describen directamente el programa de entrenamiento en Python, lo que permite relacionar el código fuente, la política de acceso y la carga ejecutada. Sin embargo, los TEE dependen de garantías de hardware y de la implementación de la atestación; también hay que comprobar que las políticas publicadas sean las que se aplican. La criptografía reduce el margen para hacer trampas, pero no vuelve infalible el sistema.
Las arquitecturas de los modelos pueden ser propietarias, por lo que Google permite cargar cierta lógica serializada en tiempo de ejecución sin revelar todo el diseño. Según la descripción técnica, la lógica relevante para la privacidad debe permanecer codificada en el programa atestado. Si pudiera modificarse sin verificación la parte que decide qué datos se leen o cómo se aplica la privacidad, el resto del sistema serviría de poco.
El diseño combina la apertura del código que controla el acceso con la protección de algunos detalles del modelo. Permite verificar cómo se usan los datos, pero no da acceso necesariamente a todos los secretos comerciales. La auditoría de un sistema complejo requiere conocimientos, tiempo y acceso a registros; que sea verificable no significa que cualquier usuario vaya a comprobarlo desde el móvil.
Gboard ganó velocidad y margen para ajustar la privacidad
Google ha desplegado el sistema para modelos de predicción de la siguiente palabra en inglés y japonés. Según la compañía, los modelos lograron mayor precisión junto con garantías de privacidad más fuertes. La información publicada no incluye una cifra única de mejora ni un multiplicador concreto de velocidad, por lo que no es posible medir con precisión la magnitud de los resultados.
El sistema reúne primero las cargas de los dispositivos y ejecuta después el entrenamiento en el servidor. En el aprendizaje federado tradicional, la disponibilidad cambia según la hora del día: por la noche hay otros teléfonos conectados que durante la jornada, y esas variaciones pueden alargar una ronda. Separar la recogida del cálculo permite preparar los datos y elegir un calendario de participación más predecible, además de ajustar los parámetros de privacidad en función de ese calendario.
Google comparó las curvas de privacidad y utilidad entrenando un modelo inglés durante 5.000 rondas, con cohortes de 6.500 dispositivos en ambos sistemas. La compañía no publica una tabla completa con tiempos, recursos y márgenes de error. También señala que los modelos anteriores podían tardar entre uno y dos meses en entrenarse. Con el nuevo enfoque, el trabajo se paraleliza entre máquinas y el límite pasa a ser la capacidad disponible de los TEE.
El cuello de botella se traslada así a la infraestructura especializada, la capacidad de cómputo y la disponibilidad de hardware compatible. La arquitectura mejora la planificación, pero no aumenta por sí sola los recursos disponibles.
¿Y frente a FLARE, Flower o pfl-research?
Estos proyectos no son productos idénticos. Google desarrolló su sistema para entrenamiento federado de producción a escala de dispositivos y ya lo utiliza en Gboard. NVIDIA FLARE es un SDK de aprendizaje federado pensado para despliegues con herramientas de contenedores, Kubernetes y nube; incluye soporte para tecnologías de computación confidencial como AMD SEV-SNP, Intel TDX y computación confidencial en GPU de NVIDIA. Flower ofrece un marco para construir sistemas federados y admite mecanismos de privacidad central y local. pfl-research, en cambio, está orientado a la simulación y no se presenta como plataforma de despliegue para terceros.
También difiere el lugar donde se calculan las actualizaciones. En la propuesta de Google, el cálculo se ejecuta en TEE del servidor. FLARE puede operar con componentes en cada sitio participante; Flower suele llevar parte del trabajo a los clientes, y pfl-research simula el proceso. La arquitectura adecuada depende del caso: un hospital con datos repartidos entre instituciones puede necesitar controles distintos de los de un teclado instalado en millones de móviles.
La diferencia más marcada es la combinación de privacidad diferencial central, políticas públicas en Rekor y compilaciones reproducibles de los binarios sensibles. FLARE ofrece otras herramientas, entre ellas cifrado homomórfico y unión privada de conjuntos; Flower incorpora Secure Aggregation y SecAgg+. Son enfoques con objetivos parcialmente distintos. La propuesta de Google destaca por combinar entrenamiento centralizado dentro de TEE con pruebas públicas sobre el código autorizado, no por cubrir todos los usos federados posibles.
El código central y Federated Language están disponibles bajo Apache 2.0, según la información publicada por Google. Esto permite inspeccionar y reutilizar componentes, aunque desplegar un sistema equivalente exige infraestructura de TEE, gestión de claves, auditoría y capacidad operativa. La disponibilidad del código no garantiza por sí sola la privacidad.
Una mejora seria, con preguntas todavía abiertas
La propuesta hace que la privacidad no dependa únicamente de una promesa interna: las políticas se registran públicamente, el código sensible puede reconstruirse y las solicitudes de descifrado pasan por comprobaciones de atestación. Para una función cotidiana como la predicción de texto, esto eleva el estándar técnico de lo que significa usar datos para entrenar un modelo sin exponerlos directamente.
La información publicada no permite juzgar el coste completo. Google no ofrece una cifra de aceleración ni un desglose detallado del consumo de recursos. También sería útil conocer cómo varían las métricas según el idioma, el tamaño de la cohorte y los parámetros de privacidad. La comparación de 5.000 rondas y 6.500 dispositivos por cohorte aporta una base, pero no responde a todas esas preguntas.
Los TEE añaden aislamiento y verificación, pero también complejidad operativa y dependencia de hardware específico. Quien quiera replicar el enfoque tendrá que decidir cuánto código expone, cómo mantiene sus políticas y quién revisa los registros. Para Google, que controla tanto el servicio como la infraestructura, la integración tiene sentido; para equipos pequeños, puede resultar más pesada que el problema que buscan resolver.
En Gboard, la propuesta ya está en uso: los modelos en inglés y japonés se entrenan con este sistema. Queda por ver cuánta verificación externa habrá en la operación cotidiana y qué resultados concretos publicará Google cuando lleve más tiempo funcionando.
