Privacidad diferencial, agregación segura y agregación robusta protegen propiedades diferentes de un sistema federado. Combinarlas exige comprobar qué información necesita cada mecanismo y qué información oculta el anterior. Una lista de técnicas activadas no demuestra que sus garantías sean compatibles.
En DFL, esta pregunta se complica porque cada participante puede observar una vecindad distinta. Este artículo propone una forma de diseñar y evaluar la combinación, sin presentar una implementación criptográfica ni un resultado experimental nuevo.
Qué protege cada mecanismo
| Mecanismo | Pregunta que aborda | Propiedad que no aporta por sí solo |
|---|---|---|
| Cifrado del transporte | ¿Quién puede leer el canal? | Honestidad del participante receptor |
| Agregación segura | ¿Se oculta una contribución individual durante la agregación? | Robustez frente a una contribución maliciosa |
| Privacidad diferencial | ¿Cuánto cambia la salida por una unidad de datos? | Autenticidad de datos o ausencia de poisoning |
| Agregación robusta | ¿Cómo se limita la influencia de contribuciones anómalas? | Confidencialidad de las actualizaciones |
El protocolo de Bonawitz y colaboradores y el entrenamiento privado de Abadi y colaboradores son referencias para propiedades distintas. En un despliegue concreto, sus supuestos deben documentarse con la arquitectura y el adversario.
La tensión entre ocultar e inspeccionar
Una defensa puede necesitar distancias entre actualizaciones individuales para detectar valores anómalos. Si otro mecanismo solo revela una suma, esa información ya no está disponible. No se puede asumir que el filtrado seguirá funcionando igual después de ocultar sus entradas.
Existen distintas líneas de diseño: inspecciones compatibles con computación segura, validaciones previas, agregación por grupos o defensas que utilicen otra evidencia. Cada opción cambia el modelo de confianza. Agrupar participantes, por ejemplo, puede reducir la resolución de la defensa y modificar qué colusiones importan. La elección requiere un protocolo explícito, no simplemente ejecutar dos módulos en secuencia.
Definir la unidad y la vista del adversario
Antes de publicar un epsilon, especifica si se protege un ejemplo, una persona, un dispositivo o un cliente completo. En telemetría, muchos registros pueden pertenecer al mismo dispositivo. Una garantía por registro no se convierte automáticamente en una garantía por dispositivo.
Describe además si el adversario observa un mensaje, varias rondas, nodos coludidos, métricas o cambios de membresía. El presupuesto de privacidad debe contabilizar publicaciones relevantes. La cadencia de envío y los metadatos pueden exponer información que no aparece en el tensor protegido.
Robustez local y datos non-IID
La fracción global de participantes maliciosos no determina la fracción que ve cada nodo. Una vecindad pequeña puede concentrar un adversario. Registra el soporte local antes y después del filtrado y qué ocurre cuando resulta insuficiente.
También deben existir clientes legítimos con datos diferentes. Si la defensa elimina sistemáticamente sus contribuciones, puede mejorar la estabilidad aparente mientras perjudica la representación de clases raras. Yin y colaboradores estudian mediana y media recortada bajo condiciones estadísticas; cualquier transferencia a este escenario necesita revisar esas condiciones.
Un protocolo factorial de evaluación
Propongo comenzar con configuraciones comparables: referencia sin mecanismos adicionales, privacidad únicamente, robustez únicamente y combinación. Conserva partición, topología y presupuesto de ajuste. Repite las condiciones con datos limpios y bajo un ataque de laboratorio definido.
En cada ejecución registra calidad por cliente, falsos rechazos, bytes, tiempo, exposición observada y garantía formal cuando exista. Una prueba empírica que no consigue reconstruir datos no demuestra privacidad diferencial. Del mismo modo, una garantía de privacidad no demuestra utilidad ni resistencia al poisoning.
Incluye desconexiones y conjuntos pequeños de participantes. Si un protocolo exige un umbral mínimo, comprueba que se detiene o entra en el modo previsto cuando no se cumple. Continuar silenciosamente puede invalidar el supuesto que protege las contribuciones.
Una dirección reciente: añadir compresión
Li y colaboradores, AISTATS 2026 investigan comunicación comprimida y aprendizaje distribuido bizantino. El trabajo conecta eficiencia y robustez; no valida automáticamente privacidad diferencial, agregación segura ni protocolos DFL multimodales.
Como siguiente experimento, estudia si cuantización y ruido cambian el comportamiento de una defensa basada en distancias. Compara la combinación con cada transformación aislada. Los umbrales calibrados sobre actualizaciones sin ruido pueden rechazar de más cuando cambia la distribución legítima.
Criterio para una afirmación verificable
Una conclusión útil podría declarar: qué unidad se protege, frente a qué observador, durante cuántas publicaciones, qué vecindad tolera el protocolo y qué coste introduce. Evita reducirlo a «federado y privado» o «resistente a ataques» sin esas condiciones.
Los fundamentos de privacidad en FL, la agregación bizantina y la comunicación con prototipos desarrollan los componentes por separado. El paso de investigación consiste en demostrar qué propiedades sobreviven cuando se conectan.
