Las empresas quieren aplicar inteligencia artificial a contratos, historias clínicas, información financiera, datos industriales y propiedad intelectual. Aunque el almacenamiento y las comunicaciones estén cifrados, esos datos suelen aparecer en memoria durante el procesamiento. En ese intervalo, un operador privilegiado, una infraestructura comprometida o una configuración errónea pueden ampliar la superficie de riesgo.
La IA confidencial combina inteligencia artificial y computación confidencial para reducir esa exposición. El trabajo se ejecuta dentro de un entorno de ejecución de confianza, o TEE, aislado por hardware. La organización puede verificar el estado del entorno antes de entregar claves y datos. El 21 de octubre de 2026, Google Cloud anunció la disponibilidad general de GPU G4 confidenciales, una señal de que la protección ya llega a cargas aceleradas de IA.
Los tres estados de los datos
Una arquitectura madura contempla tres situaciones. Los datos en reposo se encuentran en discos, bases y copias de seguridad. Los datos en tránsito circulan entre cliente, API y servicios. Los datos en uso se leen y procesan en memoria.
La computación confidencial se ocupa de este tercer estado. No pretende mantener cada byte cifrado durante todo el cálculo, sino confinar la forma descifrada a una región aislada, evitar accesos externos y liberar las claves únicamente cuando el entorno demuestra que ejecuta el código previsto.
Cómo funciona un entorno de ejecución de confianza
Aislamiento basado en hardware
El procesador crea una región protegida para código y datos. Según la tecnología, el aislamiento cubre una aplicación, un contenedor, una máquina virtual o una GPU. El sistema operativo, el hipervisor y los administradores de infraestructura tienen acceso reducido al contenido de memoria.
Atestación
Antes de entregar una clave, otro servicio comprueba pruebas criptográficas sobre hardware, firmware y software cargado. Esa verificación se denomina atestación. Si la medición no coincide con la política —por ejemplo, una imagen modificada o un componente no aprobado—, el almacén de claves no libera el material.
Liberación de claves vinculada al entorno
En lugar de confiar solo en una identidad, el gestor de claves condiciona el acceso a un entorno atestado. La clave llega al TEE por un canal protegido y permanece disponible únicamente mientras la carga autorizada está activa.
Qué protege y qué no protege la IA confidencial
Esta técnica reduce la exposición frente a operadores de nube, administradores de infraestructura, malware en el host y capturas de memoria externas. También permite que distintas organizaciones ejecuten un análisis conjunto sin entregarse entre sí los datos originales.
No corrige una aplicación vulnerable. Si el código autorizado registra información personal, acepta instrucciones maliciosas o envía la respuesta al destinatario equivocado, el TEE ejecutará ese comportamiento. Tampoco elimina riesgos del modelo, como memorización, extracción, prompt injection o una salida indebida.
Por eso debe complementar autenticación, mínimo privilegio, gestión de secretos, revisión de código, controles de entrada y salida, minimización y monitorización. Es una frontera adicional, no una garantía absoluta.
Ejemplo: análisis de documentos financieros
Una empresa necesita clasificar contratos y extraer importes, cláusulas y fechas mediante IA. Los documentos permanecen cifrados en almacenamiento. Al iniciar el trabajo, el orquestador solicita pruebas del entorno confidencial. El almacén valida la atestación y envía una clave temporal directamente al TEE.
Dentro del entorno se abre el documento, el modelo realiza la inferencia y solo salen los campos necesarios. El texto íntegro no aparece en logs, prompts de depuración ni cachés compartidas. Al terminar se descarta la clave. La telemetría externa registra identificador, versión del modelo, política y resultado de la atestación, no el contenido.
Si se modifica el modelo o la imagen sin autorización, cambia la medición y la clave deja de estar disponible. De esta forma, una configuración se convierte en una política verificable.
Casos en los que aporta valor
- Sanidad: resumir o estructurar información clínica dentro de un perímetro verificable.
- Finanzas: analizar operaciones, riesgo y documentación sin ampliar el acceso al dato bruto.
- Legal: trabajar con contratos y expedientes manteniendo separación entre clientes.
- Industria: utilizar telemetría y propiedad intelectual para predicción y mantenimiento.
- Colaboración: cruzar datos de varias entidades y devolver solo resultados agregados.
- Modelos propios: proteger pesos, instrucciones de sistema y reglas durante la inferencia.
Arquitectura de referencia
- El usuario o sistema llama a una API autenticada.
- El orquestador crea o selecciona una carga confidencial aprobada.
- Un servicio de atestación verifica identidad e integridad.
- El almacén libera claves temporales conforme a una política.
- Los datos se abren y procesan exclusivamente en el TEE.
- La salida se valida, minimiza y autoriza.
- La telemetría registra la operación sin revelar información sensible.
El modelo puede residir dentro del entorno o accederse mediante conexión privada, según el riesgo y la capacidad. Si parte del proceso sale del TEE, hay que documentar con precisión dónde termina la protección.
Soberanía no significa solo ubicación
Conservar datos en una región concreta cubre una parte del requisito. La computación confidencial añade control sobre quién puede ver el contenido durante el uso. Es relevante en entornos soberanos, híbridos y aislados donde se combinan residencia, control de claves y reducción del acceso de operadores.
No implica automáticamente cumplir el RGPD ni normas sectoriales. Apoya medidas técnicas, pero siguen siendo necesarias la finalidad, la base jurídica, la retención, los derechos de los interesados, los contratos y los procedimientos internos.
Cómo decidir si compensa
- ¿qué impacto tendría que un administrador viera los datos en uso?
- ¿existe una obligación contractual o regulatoria de aislamiento?
- ¿varias partes necesitan colaborar sin intercambiar datos brutos?
- ¿el modelo o las reglas de negocio también son confidenciales?
- ¿la carga necesita GPU y existe una oferta compatible?
- ¿latencia, coste y límites de observabilidad son aceptables?
Para información pública o aplicaciones de bajo riesgo, la complejidad puede no justificarse. El valor aumenta cuando la sensibilidad es alta y el modelo de amenazas incluye privilegios de infraestructura.
Errores frecuentes
- proteger la inferencia y guardar el prompt completo fuera del TEE;
- liberar claves antes de validar la atestación;
- utilizar imágenes mutables sin política de versiones;
- mezclar clientes en un mismo contexto sin aislamiento lógico;
- ignorar dependencias, drivers y artefactos del modelo;
- no preparar actualización, revocación y respuesta a incidentes.
Plan para un piloto
- seleccionar un flujo sensible con una salida bien definida;
- modelar amenazas y delimitar qué debe permanecer confidencial;
- reducir datos y componentes dentro de la base de confianza;
- configurar atestación y liberación de claves por política;
- probar imagen alterada, atestación inválida y caída del almacén;
- comparar latencia, coste y operación con la arquitectura actual;
- documentar fronteras y evidencias para seguridad y negocio.
De la prueba a producción
El éxito no consiste solo en que el modelo responda. Conviene medir ejecuciones atestadas, fallos de política, tiempo de liberación, latencia adicional, exposición en logs y cobertura de flujos sensibles. Las actualizaciones deben conservar evidencias reproducibles.
ProativaIA desarrolla soluciones de inteligencia artificial y automatización, software a medida e integraciones para operaciones con datos críticos. Podemos analizar el riesgo, diseñar la arquitectura confidencial y construir un piloto con atestación, claves, auditoría y controles de salida.