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 una afirmación sin revelar los datos witness seleccionados. El verificador puede saber "esta persona es mayor de 18" o "esta computación se ejecutó correctamente", además de los inputs públicos y metadatos observables. Mira nuestro glosario y el análisis a fondo de producción.
• Cifrado totalmente homomórfico (FHE): computa sobre inputs cifrados para que el evaluador procese ciphertext en lugar del texto plano protegido. Lo que queda oculto depende de la función, los inputs públicos, el destinatario del resultado y la custodia de claves. Análisis a fondo: qué se lanza en FHE.
• Computación multiparte segura (MPC): varias partes computan conjuntamente sobre inputs privados. Cada una conoce su propio input y aprende el output autorizado; la privacidad depende del umbral y los supuestos de corrupción del protocolo.
• Entornos de ejecución confiable (TEE): entornos aislados por hardware como Intel TDX, AMD SEV-SNP y GPUs confidenciales de NVIDIA. Están diseñados para proteger código y datos en uso frente al host fuera de la frontera confiable; la atestación aporta evidencia del estado medido de hardware y software, sujeta a la cadena de confianza de la plataforma.

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. La atestación puede mostrar que el código esperado corre en hardware reconocido, bajo los supuestos de atestación y cadena de suministro de la plataforma. No elimina todo riesgo de vendor, firmware, operador, ataque físico o canal lateral. La aceptación del riesgo residual depende de la arquitectura y jurisdicción. Las afirmaciones de resistencia legal requieren revisión jurídica y un análisis completo del flujo de datos, no solo elegir un producto TEE.

¿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, disponibilidad prevista para finales de 2026. Cada Estado miembro debe proporcionar al menos una wallet dentro de los 24 meses posteriores a los actos de ejecución pertinentes. El trabajo oficial evalúa rutas ZK basadas en BBS y circuitos; las modificaciones de julio de 2026 muestran que siguen evolucionando estándares, hardware certificado, assurance y despliegues nacionales. No infieras una aprobación o prohibición general de una especificación exploratoria.
• 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. European Union (2026). July 2026 amendments to EUDI Wallet standards and specifications. eur-lex.europa.eu
7. NVIDIA (2026). Supported confidential-computing GPU platforms and modes. docs.nvidia.com
8. Google Cloud (2026). Supported confidential VM and GPU configurations. docs.cloud.google.com
9. Confidential GPU research (2025). Performance analysis of confidential GPU workloads. arxiv.org