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.

Compara primero las fronteras concretas. ZK depende de los supuestos del sistema y de circuito, compilador, setup, implementación y verificador. FHE depende de esquema, parámetros, implementación y claves. MPC añade un umbral y no colusión específicos del protocolo. TEE añade hardware, firmware, attestation y canales laterales. No existe un multiplicador fijo de rendimiento; mide el stack concreto.

¿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, score o modelo pequeño puede permitir FHE. Para un pipeline grande o modelo interactivo, evalúa primero TEE salvo que un benchmark FHE end-to-end cierre latencia y coste.
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 aíslan VMs completas y reducen trabajo de integración frente a SGX. El sobrecoste publicado varía con virtualización, memoria, I/O, attestation y workload; una cifra de un solo dígito no es universal.
• 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?

Algunas arquitecturas de 2026 apilan estas herramientas en lugar de elegir solo 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. La composición solo reduce el riesgo del roadmap cuando las interfaces, la propiedad de claves, los formatos de datos y la semántica de fallback se diseñan para la sustitución desde el principio. Pasar de TEE a FHE no es un cambio automático.

¿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, finales de 2026. La revelación selectiva es central. El trabajo oficial evalúa BBS y construcciones ZK híbridas mientras avanzan estándares, hardware, assurance y despliegues nacionales. No infieras una aprobación o prohibición general.
• EHDS. El uso secundario exige acceso controlado, pseudonimización o anonimización y entornos seguros. HE, MPC, federated learning o TEE pueden ayudar, pero no están prescritos como implementación universal.
• 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.
• DORA y la Ley de IA crean obligaciones de resiliencia, evidencia y governance. No exigen TEE, ZK, FHE o MPC. Elige el control desde el proceso regulado y documenta la propiedad satisfecha.

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.

Fuentes y verificación

1. Mopro (2026). Circuit-specific proving and verification benchmarks. zkmopro.org
2. Apple Machine Learning Research (2024). Production HE and private information retrieval. machinelearning.apple.com
3. European Union (2025). Regulation (EU) 2025/327 on the European Health Data Space. eur-lex.europa.eu
4. European Digital Identity Wallet (2026). ZK proofs from multi-message signatures. github.com/eu-digital-identity-wallet
5. W3C (2026). Data Integrity BBS Cryptosuites v1.0, Candidate Recommendation Draft. w3.org
6. Confidential GPU research (2025). Performance analysis of confidential GPU workloads. arxiv.org