Google está haciendo práctica la IA privada con cifrado homomórfico
El impulso de Google para usar cifrado homomórfico totalmente (FHE) para “IA privada” busca permitir que los modelos en la nube funcionen con datos cifrados por el usuario, de modo que los proveedores nunca vean el texto plano, lo que potencialmente habilitaría casos de uso regulados en sanidad, finanzas y otros ámbitos sensibles. Los comentaristas reconocen la solidez criptográfica y el valor de nicho de FHE, pero subrayan su enorme sobrecoste de rendimiento —a menudo de varios órdenes de magnitud— y señalan que ejecutar modelos localmente sigue siendo la forma más directa de obtener privacidad. Muchos también son escépticos de que una empresa impulsada por anuncios como Google despliegue esta tecnología de formas que realmente prioricen la privacidad del usuario por encima de la recopilación y monetización de datos.
Sentimiento general
- Mixto a negativo sobre Google como custodio; más positivo sobre la criptografía subyacente.
- Muchos consideran que esto es técnicamente impresionante pero comercialmente de nicho y potencialmente mal presentado como “IA privada” mientras se mantiene el control en la nube.
Confianza, motivos y encuadre de la privacidad
- Fuerte desconfianza hacia Google como empresa publicitaria; temor de que FHE se use para justificar un uso de datos más ubicuo (“nunca vemos tus datos, solo las señales”).
- Algunos argumentan que el proyecto es de código abierto, por lo que la tecnología puede beneficiar a otros y no necesita depender de confiar en Google.
- Varios señalan que el cifrado solo resuelve la confidencialidad; aún pierdes disponibilidad/control si tu cuenta es bloqueada o el servicio se apaga.
Qué proporciona realmente FHE (y qué no)
- FHE permite que los servidores calculen sobre texto cifrado sin ver el texto plano, asumiendo supuestos estándar de dureza (p. ej., LWE/RLWE).
- Garantiza el secreto de las entradas/salidas, pero no que el servidor haya ejecutado la computación prevista. La computación verificable/atestiguada es un problema aparte.
- Aclaraciones de que un FHE adecuado todavía puede satisfacer la indistinguibilidad respecto del ruido (IND-CPA); varios comentaristas corrigen aquí malentendidos.
Rendimiento y practicidad
- Se citan sobrecostes de ~10×–100× (optimistas para ML afinado) hasta 10³–10⁶× en muchas configuraciones reales; latencias medidas de segundos a minutos por inferencia u operación.
- Ordenar, ramificar y dividir son especialmente lentos; el álgebra lineal y las cargas simples de suma/multiplicación son relativamente más favorables.
- Se menciona trabajo en curso sobre aceleración con GPU y ASIC, pero muchos siguen viendo esto como muy lejos de ser viable para grandes LLMs.
Casos de uso frente a la computación local
- Aplicaciones sugeridas: autenticación biométrica, comprobación de filtraciones de contraseñas, consultas médicas y de ADN, detección de fraude financiero, transferencias interbancarias, publicidad privada dirigida, comprobaciones tipo “have I been pwned”.
- Algunos sostienen que la mayoría de estos casos se resuelven mejor con computación local, TEEs o controles legales/contractuales, especialmente dado el coste.
- Otros señalan que FHE puede desbloquear cargas de trabajo reguladas (sanidad, finanzas) donde la computación local o on-prem no siempre es viable o donde se necesita agregación de datos multiparte.
Modelos alternativos y ecosistema
- Comparaciones con enclaves seguros/TEEs: más baratos y rápidos, pero dependen de la confianza en el proveedor del hardware y en el operador, y a menudo se rompen mediante canales laterales.
- Varios ven esto como investigación necesaria de “criptografía programable”, incluso si el despliegue a corto plazo es limitado. Otros lo desestiman como “teatro de investigación” de Google para impresionar a ejecutivos centrados en IA.