RHETRA / Guías / Atestación

Atestación de IA y computación confidencial, en términos claros

La atestación remota permite que una CPU pruebe — con una firma que usted mismo puede verificar — exactamente qué código ejecuta su IA, dentro de memoria que el operador no puede leer. Es la tecnología que convierte «confíe en nosotros, se ejecuta on-premise» en una afirmación matemática comprobable, y es el cimiento de toda promesa seria de soberanía. Así funciona, sin la niebla de los whitepapers.

1 · El problema: hay que confiar en el operador

En la infraestructura clásica, quien opera el host es dueño de facto de lo que hay en él. Un hipervisor puede leer la memoria de cualquier invitado; un administrador del centro de datos con los permisos adecuados puede volcar cualquier proceso. Los contratos y las certificaciones lo regulan — pero son promesas, y para un banco o un ministerio que usa IA sobre datos sensibles, «el operador promete no mirar» es un cimiento débil. Por eso dónde está un servidor dice tan poco: la ubicación es un código postal, no una propiedad del sistema.

2 · Memoria cifrada: el operador queda fuera

La computación confidencial cambia el modelo de confianza en el hardware. Tecnologías como AMD SEV-SNP e Intel TDX ejecutan una VM dentro de memoria que la CPU cifra con claves que el host nunca ve. El hipervisor sigue planificando la VM — pero solo lee texto cifrado. El «Secure Nested Paging» de SEV-SNP protege además el mapa de memoria de la VM frente a manipulaciones de un hipervisor malicioso.

Resultado: el operador — proveedor de nube, personal del centro de datos, incluso un sistema operativo host comprometido — queda eliminado de la ecuación de confianza técnicamente, no contractualmente.

3 · Atestación: probar qué se ejecuta

La memoria cifrada por sí sola deja una pregunta abierta: cifrada o no — ¿qué se está ejecutando ahí dentro? La atestación la responde:

• En el arranque, la CPU mide el código cargado en la VM confidencial — un hash criptográfico de cada byte.
• A petición, genera un informe de atestación con esa medición más el estado de la plataforma (versiones de firmware, configuración de seguridad).
• El informe va firmado con una clave grabada en la propia CPU, encadenada hasta las claves raíz del fabricante (en AMD: la cadena VCEK/ASK/ARK).

Si el software se construye de forma reproducible, cualquiera puede recompilarlo, comparar los hashes y saber — no creer — que el código fuente auditado es el binario en ejecución.

4 · Cómo verificar un informe usted mismo

• 1. Obtenga el informe de atestación del sistema en ejecución (una llamada a la API).
• 2. Descargue los certificados públicos del fabricante de la CPU (AMD los publica en línea).
• 3. Verifique la cadena de firmas: informe → clave del chip → raíz del fabricante. Existe tooling open source; no hace falta la cooperación del proveedor.
• 4. Compare la medición con el hash de build esperado.

Cuatro pasos, criptografía estándar, sin confiar en el operador ni en el fabricante del software. Esta es la lista de comprobación detrás de nuestra tesis «Soberano es una prueba, no un código postal» — y exactamente lo que un proveedor debería poder demostrar en una sesión en vivo.

5 · Firmas post-cuánticas: evidencia que perdura

La atestación prueba el entorno de ejecución ahora. Los registros de auditoría deben seguir siendo verificables durante años — auditorías, litigios, revisiones del regulador. Las firmas RSA/ECC clásicas tienen fecha de caducidad: un ordenador cuántico criptográficamente relevante las rompe, lo que permitiría falsificar retroactivamente evidencia «histórica». El NIST ha estandarizado firmas post-cuánticas precisamente para ese horizonte: ML-DSA (FIPS 204), la forma estandarizada de Dilithium.

Por eso la pasarela KRONOS de RHETRA firma hoy cada decisión de política con Dilithium5 y se ejecuta dentro de memoria atestiguada con SEV-SNP: decisiones que son demostrables ahora y siguen siéndolo después. Cómo satisface eso obligaciones regulatorias concretas se explica en la guía del EU AI Act.