ZK vs FHE vs MPC vs TEE: Cómo Elegir en 2026

Cuatro tecnologías compiten ahora por la misma diapositiva de arquitectura: pruebas de conocimiento cero, cifrado totalmente homomórfico, computación multiparte segura y entornos de ejecución confiable. Se presentan de forma rutinaria como "tecnología de privacidad" intercambiable, y no lo son. Responden preguntas distintas, cuestan cantidades salvajemente distintas y fallan de formas distintas. Este post es la comparación que nos gustaría que existiera cuando los clientes preguntan "cuál necesitamos": modelos de confianza, cifras honestas de rendimiento de 2026, y las regulaciones de la UE que cada vez más fuerzan la elección. Para la metodología completa de construcción, empieza por nuestra guía pragmática de ZK y FHE.

Perspectiva de ingeniería, no un pitch de proveedor. Todas las cifras tienen fuente o están etiquetadas como reglas rápidas. Los puntos de referencia vienen del trabajo de Wavect en zero-knowledge y tecnología de frontera.

¿Qué hace realmente cada tecnología?

• Pruebas de conocimiento cero (ZK): demuestran que una afirmación es verdadera sin revelar la evidencia. El verificador aprende "esta persona es mayor de 18" o "esta computación se ejecutó correctamente", nada más. Mira nuestro glosario y el análisis a fondo de producción.
• Cifrado totalmente homomórfico (FHE): computa sobre datos cifrados. El servidor que procesa tu consulta nunca ve la consulta, los datos ni el resultado. Análisis a fondo: qué se lanza en FHE.
• Computación multiparte segura (MPC): varias partes computan conjuntamente un resultado sobre inputs que ninguna revela. Tres hospitales calculan una estadística conjunta; ningún hospital ve los pacientes de otro.
• Entornos de ejecución confiable (TEE): enclaves aislados por hardware (Intel TDX, AMD SEV-SNP, GPUs confidenciales de NVIDIA) que ejecutan computación en texto plano invisible incluso para el operador del cloud, con una atestación criptográfica de que corre el código esperado.

La forma más limpia de ordenarlas es por lo que se te pide confiar. ZK confía solo en la solidez de un sistema de pruebas. FHE confía en la criptografía de retículos. MPC confía en que un umbral de las partes participantes no colude. TEE confía en el diseño y la cadena de suministro de un fabricante de chips, más la ausencia continuada de rupturas por canal lateral. Cada paso de confianza añadida te compra entre uno y cuatro órdenes de magnitud de rendimiento. La arquitectura es elegir tu peldaño, no maximizar la seguridad en abstracto.

¿Qué cuatro preguntas eligen la tecnología?

1. ¿Quién no debe ver los datos? Si la respuesta es "nadie fuera de nuestra empresa", para: control de acceso, TLS y cifrado en reposo lo resuelven, y todas las tecnologías de esta página son excesivas. Si la respuesta es "el operador de la computación", sigue leyendo.
2. ¿La necesidad central es verificación o computación? Si un tercero necesita comprobar algo (una edad, una reserva, la integridad de una computación), eso es ZK, punto. Si una parte no confiable necesita computar algo sobre datos ocultos, es FHE, MPC o TEE.
3. ¿Cómo de grande es la computación oculta? Un lookup, un score, un modelo pequeño: FHE está sobre la mesa. Un pipeline de datos, un LLM, cualquier cosa que un usuario espera de forma interactiva: siendo realistas, TEE, porque el sobrecoste de FHE de 1.000x a 10.000x no cierra.
4. ¿Cuántas partes independientes tienen los inputs? Un cliente y un servidor favorece FHE o TEE. Varias organizaciones que desconfían mutuamente con buenos enlaces de red entre ellas favorece MPC, que se construyó exactamente para esa forma y sufre a través de la internet pública, donde sus costes de comunicación muerden.

¿Cómo se comparan lado a lado?

"A nadie lo despiden por elegir un TEE, y la mayoría de las veces aciertan. Los errores caros ocurren cuando un equipo elige FHE para un workload que debería cargar un TEE, o un TEE para una promesa que solo la matemática puede cumplir."

¿Cómo de buenos son los TEE ahora, con honestidad?

Lo bastante buenos como para ser la respuesta por defecto para cómputo confidencial a escala, que es exactamente por lo que las opciones criptográficas necesitan una justificación clara para desplazarlos:

• Los enclaves de CPU maduraron. Intel TDX y AMD SEV-SNP movieron la unidad de aislamiento del proceso a la VM completa, recortando drásticamente el coste de integración frente al viejo modelo SGX. El sobrecoste en workloads típicos se sitúa en el rango bajo-medio de un solo dígito porcentual, con las cargas limitadas por memoria y las muy pequeñas pagando más.
• Las GPUs se sumaron. La H100 de NVIDIA fue la primera GPU de computación confidencial, extendida a través de las generaciones H200 y Blackwell. La inferencia confidencial de LLM ya se vende como producto cloud, con fine-tuning posible en las mismas VMs de GPU confidencial, y un sobrecoste a menudo dominado por las transferencias PCIe cifradas y no por el cómputo (arXiv 2505.16501).
• La pega de confianza permanece. Un TEE demuestra que estás corriendo el código esperado en hardware genuino. No puede protegerte de un vendor comprometido, de ciertos ataques físicos, ni del goteo constante de papers de canal lateral publicados. Para la mayoría de los modelos de amenazas comerciales, ese riesgo residual es aceptable. Para "debemos ser incapaces de cumplir una citación judicial por datos de usuarios", no lo es, y esa es precisamente la línea donde FHE y MPC se ganan su sobrecoste.

¿Por qué el patrón ganador es componer, no elegir?

Las arquitecturas más fuertes de 2026 apilan estas herramientas en lugar de elegir una:

• TEE para el grueso, criptografía para el núcleo. Corre el pipeline pesado en una VM confidencial, y reserva FHE o MPC para la computación pequeña de altas apuestas donde la confianza en el hardware es inaceptable.
• ZK encima para la verificabilidad. Un TEE o un cluster MPC computa; una prueba ZK convence a los de fuera de que la computación fue correcta sin re-ejecutarla. La verificación sigue siendo barata para todos aguas abajo.
• Formas de ejemplo reales: un servicio de inferencia en GPU confidencial que devuelve una atestación ZK de qué versión del modelo corrió; un consorcio MPC cuyo resultado viaja con una prueba que los reguladores pueden comprobar; un lookup FHE dentro de una app por lo demás convencional, que es literalmente como lo lanza Apple.

Proyectos como Nillion orquestan MPC, HE y ZK detrás de una sola superficie de desarrollo, y el patrón de "TEE como arnés barato alrededor de núcleos criptográficos" aparece en todos los despliegues serios. La composición también reduce el riesgo del roadmap: puedes empezar en un TEE este trimestre y cambiar el núcleo a FHE cuando las cifras cierren, sin reescribir el producto.

¿Qué fuerza la regulación de la UE, y cuándo?

Para productos orientados a la UE, la regulación está convirtiendo en silencio este menú en lectura obligatoria:

• eIDAS 2.0 / EUDI Wallet, fecha límite finales de 2026. Cada estado miembro debe ofrecer una wallet de identidad digital, construida en torno a la revelación selectiva. Ese es el terreno de casa de ZK. Un filo cortante: los esquemas avanzados desvinculables (familia BBS, credenciales ZK-SNARK) aún no están aprobados por SOG-IS, lo que por ahora los mantiene fuera de los despliegues del sector público; los detalles están en nuestro análisis a fondo de ZK.
• EHDS (European Health Data Space). El uso secundario de datos de salud se apoya explícitamente en tecnologías de mejora de la privacidad, empujando HE, MPC y patrones federados hacia las plataformas de datos sanitarios.
• RGPD. Si los datos procesados con FHE o verificados con ZK cuentan como anonimizados es un debate legal vivo, no doctrina asentada. Las PET refuerzan tu historia de protección de datos desde el diseño del artículo 25; no sacan automáticamente los datos del alcance del RGPD. Involucra a los abogados antes de que las afirmaciones de marketing adelanten a la ley. Nuestro post sobre residencia de datos en la UE para apps de IA cubre el territorio adyacente.
• Finanzas (DORA) y la Ley de IA añaden presión de resiliencia y governance que favorece la infraestructura confidencial y atestable, lo que en la práctica significa TEEs primero y mejoras criptográficas donde los supervisores exijan garantías más fuertes.

El patrón en todo ello: los reguladores no están exigiendo criptografía concreta, están exigiendo propiedades (minimización, revelación selectiva, confidencialidad) que esta caja de herramientas resulta ser la única forma de entregar a escala.

¿Cuándo gana el control de acceso normal?

Más a menudo de lo que la existencia de este post sugiere. Elige tecnología aburrida cuando:

• Todas las partes que manejan los datos ya confían entre sí contractualmente (una empresa, un DPA, un cloud).
• La promesa de privacidad es marketing, no arquitectura. Los usuarios rara vez pagan por garantías criptográficas que no pueden percibir; pagan por productos que funcionan.
• La computación sensible es grande, interactiva y limitada por latencia, y ninguna regulación fuerza el asunto. Un TEE más IAM estricto más logging de auditoría es una respuesta defendible y lanzable.
• Tu equipo aún no puede operar la observabilidad, la gestión de claves y la cadencia de auditoría que exigen los despliegues criptográficos. La matemática es la parte fácil; la madurez operativa es la parte dura.