Durante la mayor parte de la historia de la informática, los datos se protegían en dos estados: en reposo, con cifrado de disco, y en tránsito, con TLS. El tercer estado, los datos en uso, permanecía en texto plano en memoria desde el momento en que una CPU los tocaba. Cualquiera con control del host, del hipervisor o con acceso físico a la máquina podía leerlos. Para las cargas de trabajo reguladas y soberanas en Europa, esa brecha es el problema de fondo.
La computación confidencial la cierra. Combinada con primitivas de aislamiento modernas como las microVMs, cambia lo que puedes prometer de forma creíble sobre una carga de trabajo: que el operador de la infraestructura no puede leer los datos, que puedes demostrarlo criptográficamente y que todo el conjunto se ejecuta bajo la legislación de la UE en suelo europeo. Este artículo cubre ambas mitades de esa historia, los estándares y el hardware que las sustentan, y una lectura honesta de dónde está realmente la tecnología en 2026.
Qué es la computación confidencial
La computación confidencial protege los datos mientras se procesan ejecutándolos dentro de un Trusted Execution Environment (TEE) basado en hardware. El TEE cifra la memoria de forma transparente y aísla la carga de trabajo de todo lo que está fuera de ella, incluido el sistema operativo del host, el hipervisor, otros tenants y el propio personal del operador de la nube. Esto es cifrado en uso, el tercer estado que faltaba.
La consecuencia práctica importa más que el mecanismo. En un TEE correctamente atestiguado, la entidad que opera el hardware no puede ver tu texto plano. Un proveedor de hosting, un hyperscaler o un equipo de plataforma interno se vuelve técnicamente incapaz de leer lo que se ejecuta dentro del enclave, no solo contractualmente impedido de hacerlo. Para cargas de trabajo cuyo modelo de amenazas incluye al operador, o en las que una jurisdicción extranjera podría obligar a ese operador, esto supone un cambio categórico.
Por qué importa para la soberanía y el RGPD
La soberanía de datos y la residencia de datos son cosas distintas. La residencia es el lugar físico donde viven los bytes. La soberanía es qué leyes los rigen y quién puede obligar legalmente a acceder a ellos. La residencia de datos en la UE por sí sola no impide que una empresa matriz no comunitaria quede sujeta a exigencias legales extraterritoriales.
La computación confidencial refuerza el argumento de la soberanía en la capa técnica. Cuando los datos se procesan dentro de un TEE y las claves de descifrado solo se liberan tras la atestación frente a claves que están fuera del control del operador, este no puede producir texto plano legible con independencia de la exigencia legal que reciba. Sé preciso sobre el estatus regulatorio: ninguna autoridad de protección de datos de la UE ha avalado todavía la computación confidencial como medida complementaria autónoma del artículo 46(2) del RGPD. Trátala como una sólida defensa en profundidad que mejora materialmente una Evaluación de Impacto de Transferencias, no como una solución mágica de cumplimiento. El enfoque honesto es el creíble.
El hardware: SEV-SNP, TDX, CCA
Hoy hay tres fabricantes de CPU que ofrecen computación confidencial a nivel de VM, cada uno protegiendo una máquina virtual completa en lugar de pedirte que reescribas las aplicaciones para un enclave pequeño:
- AMD SEV-SNP (Secure Encrypted Virtualization with Secure Nested Paging) cifra la memoria de la VM por cada guest y añade protección de integridad para que un hipervisor malicioso no pueda remapear, reproducir ni manipular la memoria del guest. Ampliamente disponible en plataformas de servidor.
- Intel TDX (Trust Domain Extensions) crea “trust domains” aislados por hardware con memoria cifrada y aislamiento del hipervisor, además de atestación remota integrada. Disponible en las generaciones recientes de Xeon.
- ARM CCA (Confidential Compute Architecture) introduce los “Realms”, entornos aislados por hardware para código y datos. Es el más nuevo de los tres y apunta de lleno al edge y al ecosistema de servidores ARM, aunque su disponibilidad amplia aún va por detrás de x86.
El modelo de enclave más antiguo, Intel SGX, protege una pequeña porción de una aplicación en lugar de una VM completa. Sigue siendo relevante para secretos de alcance reducido, pero es más difícil de adoptar que los enfoques a nivel de VM anteriores. La elección correcta depende de tu silicio, de tu socio de nube o de hardware y de tu carga de trabajo, que es exactamente el tipo de decisión que una consultoría neutral respecto al proveedor debería tomar contigo y no en favor de un producto.
La atestación es la pieza que soporta el peso
Un TEE solo es útil si puedes demostrar que una carga de trabajo se ejecuta dentro de uno genuino y sin modificar antes de confiarle secretos. Esa prueba es la atestación remota, y es la parte que la mayoría de los equipos subestima.
El modelo mental neutral respecto al proveedor proviene de la arquitectura IETF RATS (RFC 9334), que define tres roles: el Attester produce evidencia firmada sobre su entorno, el Verifier comprueba esa evidencia frente a valores de referencia conocidos como correctos y la Relying Party libera claves o datos solo ante un resultado satisfactorio. En la práctica, el flujo es así: el TEE genera evidencia firmada por hardware, un verificador confirma el firmware y las mediciones, y solo entonces un broker de claves libera los secretos necesarios para descifrar datos o descargar un modelo. Sin atestación válida, no hay claves.
El stack de software de código abierto
El hardware confidencial necesita software para ser utilizable en entornos cloud-native. El esfuerzo de código abierto líder es Confidential Containers (CoCo), un proyecto de la CNCF que ejecuta cada pod de Kubernetes dentro de su propio TEE y estandariza la computación confidencial a nivel de pod. CoCo abarca los principales backends de hardware (SEV-SNP, TDX, SGX, IBM Secure Execution) y se combina con el proyecto Trustee para la atestación, incluido un Key Broker Service que condiciona la liberación de secretos a una atestación satisfactoria. CoCo se apoya en Kata Containers, que se trata más abajo, para su runtime aislado por VM. Existen otras implementaciones abiertas en el mismo espacio, y la fortaleza del ecosistema es que los patrones de atestación y de liberación de claves convergen hacia estándares compartidos en lugar de la API de un solo proveedor.
MicroVMs y aislamiento seguro
La computación confidencial responde a la pregunta “¿puede el operador leer esto?”. Las microVMs responden a una pregunta relacionada pero distinta: “si una carga de trabajo se ve comprometida, ¿puede alcanzar a las demás?”. Son complementarias, no intercambiables.
El contenedor estándar de Linux comparte el kernel del host. Un solo escape del kernel, como el CVE-2024-21626 en runc, y el radio de impacto es el nodo entero. Para código genuinamente multi-tenant o no confiable, un kernel compartido es un muro demasiado fino. Las alternativas:
- Firecracker es un VMM minimalista escrito en Rust, diseñado específicamente para serverless. Arranca una microVM en unos 125 ms con una huella de unos pocos MB por VM, reduciendo el modelo de dispositivos a lo esencial. Es famoso por impulsar AWS Lambda y Fargate.
- Cloud Hypervisor es otro VMM moderno en Rust, con un modelo de dispositivos más rico que Firecracker y amplio soporte de hardware. Es el backend por defecto de Kata Containers.
- Kata Containers hace que el aislamiento de nivel VM se sienta como contenedores: cada pod se ejecuta en una VM ligera detrás de una interfaz estándar OCI/Kubernetes. Soporta Cloud Hypervisor, Firecracker y QEMU como backends, así que ajustas el equilibrio entre aislamiento y compatibilidad.
- gVisor sigue otro camino, un kernel en espacio de usuario que intercepta las syscalls. Sin VM completa, menos overhead que la virtualización, aislamiento sólido para muchos casos multi-tenant, con algunas limitaciones de compatibilidad para cargas de trabajo intensivas en syscalls.
Dónde encaja cada uno
Empareja la herramienta con la carga de trabajo, no con el bombo publicitario:
- SaaS multi-tenant y Kubernetes compartido: Kata Containers o gVisor para contener a los tenants tras una frontera firme.
- Sandboxes de arranque rápido y funciones serverless: Firecracker, donde dominan los arranques en frío de menos de un segundo y la densidad.
- CI seguro y ejecución de código no confiable: microVMs para ejecutar builds arbitrarios o código de clientes sin confiar en ellos.
- Aislamiento de inferencia de IA: una frontera de VM dedicada por modelo o por tenant para que una ruta de inferencia comprometida no pueda pivotar.
Las dos capas se apilan. Puedes ejecutar un pod de Kata o de CoCo cuya VM subyacente sea ella misma una VM confidencial sobre SEV-SNP o TDX, obteniendo a la vez la ceguera del operador y el aislamiento de tenants con un solo despliegue.
Inferencia de IA confidencial
El impulsor de mayor crecimiento es la IA. Enviar prompts, documentos recuperados o datos de fine-tuning a un LLM significa exponer parte de tu material más sensible a quien sea que ejecute la inferencia. La IA confidencial reduce esa exposición.
La NVIDIA H100 fue la primera GPU con un TEE de hardware: en modo confidencial protege el código y los datos en la GPU con VRAM cifrada y una raíz de confianza on-die, y se empareja con una VM de CPU confidencial (SEV-SNP o TDX) para que los datos permanezcan cifrados de extremo a extremo entre CPU y GPU. La atestación se extiende a la GPU, de modo que una relying party puede verificar tanto el entorno de la CPU como el de la GPU antes de liberar los pesos del modelo o los datos. El overhead publicado es modesto, del orden de un porcentaje de un solo dígito bajo en throughput para muchas cargas de inferencia de LLM, más un coste único de atestación en el arranque. El resultado: los prompts y las salidas permanecen privados incluso frente al host, y la ejecución es verificable criptográficamente. Para las organizaciones europeas que quieren IA moderna sin enviar datos regulados a un entorno opaco, este es el puente.
Madurez honesta y compromisos
Esto es potente, pero ni es gratis ni está terminado:
- La madurez varía mucho. SEV-SNP y TDX están listos para producción; ARM CCA y partes del ecosistema de TEE en GPU son más tempranos. El tooling, especialmente la infraestructura de atestación, sigue madurando.
- La atestación es trabajo operativo. Los verificadores, los valores de referencia y los brokers de claves son la parte difícil, y los gestionas tú o tu socio.
- El overhead de rendimiento es real, pero suele ser pequeño. Cuenta con un pequeño porcentaje, más en patrones limitados por memoria o intensivos en E/S, y haz benchmark de tu propia carga de trabajo.
- No es una casilla de cumplimiento. Refuerza una postura de RGPD y soberanía; no sustituye la revisión legal, la gobernanza de claves ni una arquitectura global sólida.
- Las fronteras de confianza se desplazan, no desaparecen. Sigues confiando en la raíz de confianza del fabricante del silicio y en tu lógica de verificación. Conoce qué hay en tu base de computación de confianza.
Preguntas frecuentes
¿La computación confidencial sustituye al cifrado en reposo y en tránsito? No. Añade el tercer estado, en uso, y funciona junto a los otros dos.
¿Puede el operador de la nube seguir leyendo mis datos dentro de un TEE? Con una atestación correcta y control externo de las claves, no. El operador no puede producir texto plano legible, que es el beneficio central de soberanía.
¿Necesito hardware confidencial para usar microVMs? No. Firecracker, Cloud Hypervisor, Kata y gVisor ofrecen un aislamiento sólido en hardware estándar. La computación confidencial es una capa aparte que puedes añadir encima.
¿Cumple el RGPD de fábrica? Refuerza el cumplimiento y las Evaluaciones de Impacto de Transferencias como defensa en profundidad, pero ninguna autoridad de protección de datos de la UE la ha confirmado como medida complementaria autónoma. Trátala como un control sólido entre varios.
¿En qué CPU debería estandarizar? Depende de tu stack, tus socios y tu carga de trabajo. Evaluamos SEV-SNP, TDX y CCA frente a tus requisitos reales en lugar de empujar una única opción.
Dónde encaja Rapid Solutions
Somos una consultoría de ingeniería neutral respecto al proveedor y un socio de servicios gestionados, no un proveedor de nube. Diseñamos y operamos cargas de trabajo confidenciales y aisladas por hardware sobre fundamentos de código abierto, con residencia y soberanía de datos en la UE integradas desde el diseño, y nos adaptamos al stack que ya tienes en lugar de atarte al nuestro. Tanto si estás evaluando SEV-SNP frente a TDX, levantando Confidential Containers con una atestación adecuada, aislando cargas de trabajo multi-tenant con Kata o Firecracker, o ejecutando inferencia de IA confidencial, te ayudamos a hacerlo correctamente y a demostrar que funciona.