Nvidia y Azure impulsan la Computación Confidencial al mainstream

La computación confidencial pasó una década como una curiosidad de conferencias de criptografía — una característica de hardware que los arquitectos empresariales archivaban como «interesante, no urgente». Eso cambió en 2026. La inferencia de IA multi-tenant puso datos sensibles y pesos de modelos propietarios en los mismos clusters compartidos de GPU, y el cifrado estándar en reposo y en tránsito dejó de ser suficiente, porque en cuanto un modelo se ejecuta, tanto los datos de entrada como los pesos residen en texto plano en memoria.

El mercado refleja el cambio: los analistas sitúan el mercado de computación confidencial en aproximadamente 16.700 millones de dólares en 2026, frente a unos 12.300 millones en 2025, una tasa de crecimiento superior al 35% anual. Los servicios financieros representan casi la mitad de la adopción empresarial, la salud más de un tercio, y alrededor de tres cuartas partes de las agencias federales estadounidenses ya usan alguna forma de tecnología de enclaves seguros para cargas de trabajo sensibles. Esto ya no es una casilla de cumplimiento normativo de nicho — se está convirtiendo en un requisito básico para cualquiera que ejecute IA sobre datos que no puede exponer legal o contractualmente.

Qué cambió realmente

El detonante no fue una sola filtración o regulación. Fue la llegada de cargas de trabajo de IA que requieren dos cosas simultáneamente: los datos sensibles del cliente (historiales médicos, posiciones de trading, datos biométricos) y los pesos del modelo propietario del proveedor, colocalizados en el mismo hardware, sin ser propiedad de ninguna de las partes por separado. Un hospital que envía datos de pacientes a un modelo de diagnóstico de terceros necesita la garantía de que el proveedor de la nube y el proveedor del modelo no puedan ver los datos. El proveedor del modelo necesita la garantía de que el hospital no pueda extraer los pesos. Ninguna de las partes confía en la infraestructura de la otra, y ninguna puede simplemente «cifrar y descifrar» para salir del paso, porque la computación en sí misma debe ocurrir sobre datos no cifrados en algún momento — a menos que ese momento esté dentro de un hardware que ninguna de las partes controla.

Ese es el problema específico que resuelven los Entornos de Ejecución Confiables (TEEs): regiones de memoria aisladas y cifradas por hardware donde el código y los datos están protegidos incluso frente a un hypervisor comprometido, un operador de nube o un usuario root. En 2026, esa raíz de confianza basada en hardware se extiende más allá de la CPU y llega a la GPU por primera vez a escala.

El hardware: tanto CPUs como GPUs ya hacen esto

Cuatro arquitecturas TEE dominan los despliegues actuales:

Intel TDX (Trust Domain Extensions) — aísla VMs completas, muy usado en instancias de VM confidenciales de Azure y Google Cloud.
AMD SEV-SNP (Secure Encrypted Virtualization – Secure Nested Paging) — la opción más desplegada en AWS, Azure y Google Cloud, preferida por su menor sobrecarga en cómputo gracias al cifrado de memoria acelerado por hardware AES-NI.
ARM CCA (Confidential Compute Architecture) — más reciente, orientado a dispositivos móviles y edge donde la inferencia confidencial debe ocurrir fuera del centro de datos.
Nvidia Hopper confidential computing — la H100 fue la primera GPU con un TEE basado en hardware anclado en una raíz de confianza en el dado; la H200 lo extiende. Esta es la pieza que hizo viable la inferencia de IA confidencial, porque protege los datos y los pesos del modelo mientras la GPU está computando activamente, no solo mientras están en la memoria de la CPU.

El rendimiento aquí es mejor de lo que la mayoría de los ingenieros suponen. En cargas de trabajo de CPU intensivas en cómputo, SEV-SNP y TDX tienen una sobrecarga de aproximadamente 1-5%. En el modo de GPU confidencial de Nvidia, benchmarks independientes sitúan la inferencia típica de LLM entre el 95% y el 99% del rendimiento nativo — para la mayoría de las consultas, la sobrecarga se mantiene por debajo del 5%, y se acerca a cero para modelos grandes y secuencias largas, ya que el costo del cifrado se amortiza en más cómputo por byte transferido a través del límite CPU-GPU.

Quién está ejecutando esto en producción

Los tres grandes hiperescaladores ya ofrecen infraestructura confidencial de IA hoy, no como un elemento de roadmap. Azure Confidential Computing combina Intel TDX y AMD SEV con VMs de GPU confidenciales basadas en H100, orientadas específicamente al despliegue de LLM en industrias reguladas. AWS ofrece Nitro Enclaves junto con familias de instancias EC2 respaldadas por SEV-SNP. Google Cloud, con Confidential Space y Confidential VMs, apunta al mismo caso de uso, posicionado para la colaboración de datos entre múltiples partes donde ninguna puede ver las entradas de las otras.

Los despliegues concretos lo respaldan. NTT DATA e IBM construyeron SimpliZCloud, una plataforma de nube híbrida para instituciones financieras indias que usa computación confidencial para proteger los datos durante el procesamiento, no solo en el almacenamiento. El Departamento de Defensa de EE.UU. ha autorizado infraestructura de nube respaldada por computación confidencial para operaciones críticas en múltiples departamentos federales. Estos no son pilotos — son sistemas financieros y gubernamentales en producción donde «ciframos la base de datos» ya no satisface la barra de cumplimiento o contractual.

El problema no resuelto: la atestación

Aquí es donde la narrativa mainstream se adelanta a la tecnología. El modelo de confianza de la computación confidencial depende de la atestación remota — una prueba criptográfica de que una carga de trabajo realmente se está ejecutando dentro de un TEE genuino y sin modificar antes de enviarle datos sensibles. Para un TEE solo de CPU, un solo proveedor emite esa prueba. Para la inferencia confidencial de IA, ahora se necesita atestación del proveedor de la CPU y del proveedor de la GPU simultáneamente, cada uno con su propia cadena de suministro, raíz de confianza y herramientas de verificación separadas. Los investigadores de seguridad llaman a esto un problema de «atestador compuesto», y todavía no hay un estándar único para verificarlo de extremo a extremo.

Y se pone peor: una investigación de The Register publicada el 4 de julio de 2026 detalló cómo varios esquemas propuestos de «atestación intra-handshake» — donde el TEE se prueba a sí mismo durante el handshake TLS — siguen siendo vulnerables a ataques de relay, donde un cliente verifica con éxito un enclave genuino y confiable pero termina enviando tráfico cifrado a uno diferente y malicioso. Ninguno de los siete enfoques criptográficos probados hasta ahora cierra esa brecha por completo. Eso no es un bug menor de implementación; es una debilidad estructural en cómo se establece la confianza, y significa que «usamos computación confidencial» no es por sí solo una afirmación de seguridad completa sin preguntar también cómo se verifica la atestación y quién lo hace.

Cuándo realmente lo necesitas

La computación confidencial resuelve un problema específico: proteger los datos mientras se están computando, por una parte en la que no confías plenamente con el hardware. El cifrado estándar en reposo y en tránsito sigue siendo suficiente cuando tu propia infraestructura ejecuta el cómputo y controlas el hypervisor. Necesitas TEEs cuando se aplica alguno de estos casos:

Estás ejecutando inferencia en una GPU de nube de terceros y necesitas excluir al propio proveedor de la nube de tu modelo de amenazas — no solo a atacantes externos.
Estás sirviendo un modelo propietario a clientes que de otro modo podrían extraer los pesos de la memoria de la GPU durante la inferencia.
Varias partes (por ejemplo, dos hospitales, o un banco y un proveedor de detección de fraude) necesitan computar conjuntamente sobre datos combinados sin que ninguna vea las entradas en bruto de la otra.
Requisitos regulatorios o contractuales exigen explícitamente un procesamiento aislado por hardware, algo común hoy en acuerdos de intercambio de datos de salud y en algunos contratos de servicios financieros.

Probablemente no lo necesitas para análisis internos en tu propia infraestructura, para conjuntos de datos públicos o ya anonimizados, ni como sustituto del control de acceso básico y la higiene del cifrado — esos problemas son más baratos de resolver de forma convencional, y los TEEs añaden un costo operativo real: límites de aplicación refactorizados, infraestructura de atestación y dependencia de generaciones específicas de hardware CPU/GPU.

Conclusiones

La inferencia confidencial de IA está lista para producción en las tres grandes nubes hoy, con TEEs de GPU basados en H100/H200 que ofrecen más del 95% del rendimiento nativo para la mayoría de las cargas de trabajo — el rendimiento ya no es el bloqueador que era hace dos años.
La atestación, no la sobrecarga de cómputo, es el verdadero problema de ingeniería no resuelto. Antes de adoptar computación confidencial, pregunta a tu proveedor específicamente cómo manejan la atestación compuesta CPU+GPU y si dependen de alguno de los esquemas intra-handshake señalados como vulnerables a ataques de relay.
Reserva los TEEs para casos donde debas excluir al operador de infraestructura de tu modelo de amenazas — inferencia de GPU de terceros sobre datos regulados, o computación entre múltiples partes. No los despliegues como una actualización de propósito general al cifrado en reposo; el costo operativo no está justificado allí.
Presupuesta para la capa de atestación, no solo para el hardware TEE. Los servicios de atestación independientes y las herramientas de verificación open source del Confidential Computing Consortium son actualmente la forma práctica de evitar construir esto desde cero.