El cifrado en reposo protege datos almacenados. TLS protege datos en tránsito. Confidential computing apunta a la fase faltante: datos en uso, cuando prompts, embeddings, pesos de modelo, vectores de features y registros regulados se están procesando.
Los pipelines tradicionales descifran datos antes de que la lógica de negocio pueda usarlos. Eso es normal, pero IA sube el riesgo. Un pipeline RAG puede exponer documentos sensibles a un servicio de embeddings. Un job de inferencia puede combinar prompts privados, notas clínicas, datos de pago o código fuente con un modelo hospedado en infraestructura que el cliente no controla por completo.
Confidential computing usa trusted execution environments con respaldo de hardware y attestation para hacer una pregunta más precisa: ¿este workload exacto está corriendo en el ambiente protegido esperado antes de liberar claves, secretos o datos sensibles?
El patrón importante no es "poner el modelo en una caja mágica". Es confianza condicional. El servicio de claves debería liberar una clave de descifrado solo después de que la attestation pruebe que código, imagen, runtime, TEE y política coinciden con el estado esperado. Si la imagen cambia, la medición cambia. Si la plataforma no es confiable, las claves no llegan.
Para equipos cloud-native, confidential containers hacen esto familiar: sigues pensando en Pods, imágenes, políticas y Kubernetes, pero el runtime puede lanzar workloads dentro de VMs confidenciales y conectar entrega de secretos con attestation.
Confidential computing es más valioso cuando los datos son sensibles y la frontera de infraestructura incomoda: analytics de salud, modelos de fraude financiero, asistentes de código enterprise, RAG privado, inferencia regulada, analytics entre empresas y SaaS multi-tenant que procesa datos de clientes.
| Riesgo en pipeline IA | Control de confidential computing | Artefacto de ingeniería |
|---|---|---|
| Exposición de prompt o documento | Descifrar prompts y chunks recuperados solo dentro de ambiente atestado. | Política de attestation y regla de liberación de clave. |
| Robo de modelo | Cargar pesos solo cuando runtime y medición de imagen pasan verificación. | Artefacto de modelo firmado y loader protegido. |
| Filtración de embeddings | Generar y almacenar embeddings con política por tenant y memoria cifrada. | Pipeline vectorial por tenant y audit log. |
| Acceso operacional indebido | Reducir visibilidad de host, hypervisor y operador sobre memoria. | Runtime con TEE y política de acceso operacional. |
| Evidencia débil en incidente | Registrar attestation, liberación de clave, digests y clase de output. | Stream de eventos de seguridad y audit store inmutable. |
Construiría un gateway RAG confidencial. Cada request llevaría tenant, clase de datos, política de modelo y scope de retrieval. El gateway atestaría el confidential container, pediría claves solo después de verificar, descifraría chunks dentro de la frontera confiable, llamaría al modelo, aplicaría política de redaction y emitiría auditoría.
La experiencia de desarrollo importa: contratos OpenAPI, mock local de attestation, checks de imagen firmada, vectores de prueba para mediciones rechazadas y dashboards que muestran cuántas veces se negaron claves. Confidential computing debería sentirse como un gate de deploy, no como proyecto de investigación.
Confidential computing no reemplaza cifrado, IAM, seguridad de red ni seguridad de aplicación. Es otra frontera. En pipelines de IA, esa frontera se vuelve útil porque los datos más valiosos aparecen exactamente donde los modelos antiguos de cifrado son más débiles: durante la computación.
Artículo sobre confidential computing para pipelines de IA que cubre seguridad de datos en uso, trusted execution environments, remote attestation, confidential containers, políticas de liberación de claves, RAG protegido, embeddings, pesos de modelo, privacidad y audit logs.