Despliegue soberano y confidencial: VPC, on-prem, air-gapped y TEEs
Pregúntale a la mayoría de los equipos dónde corre su IA y obtienes una única respuesta: la cloud, o on-premises, o, si son cautos, aislado de la red. Una topología, elegida una vez, aplicada a todo. Es una decisión ordenada y, para un negocio no regulado, suele estar bien.
Solo que, en una empresa regulada, una única topología de despliegue es o derrochadora o peligrosa, y a menudo las dos a la vez. La topología de despliegue no es una elección que haces para todo el sistema. Es una regla de enrutado gobernada por la sensibilidad de los datos, y tiene que fallar cerrada. Elige una topología para todo y o sobrerrestringes trabajo barato y no sensible encerrándolo en un air-gap que nunca necesitó o, mucho peor, dejas que datos regulados fluyan a un sitio al que nunca debieron ir porque ese sitio era cómodo para otra cosa. El modelo correcto es un espectro de topologías, y una regla que enruta cada carga al entorno menos expuesto que su clase de datos permite.
Hay además un punto más reciente en ese espectro que la mayoría de las arquitecturas de referencia se salta, y es el que resuelve el caso más difícil: cómo procesar datos regulados en infraestructura que no controlas físicamente sin exponerlos, usando computación confidencial y entornos de ejecución confiables. Ahí es donde esto se pone genuinamente interesante.
El espectro de topologías, enrutado por sensibilidad
Piensa en el despliegue como una escalera de exposición decreciente, y en la sensibilidad de los datos como lo que decide cuánto tienes que subir para cada carga.
En el extremo tolerante a la exposición está una cuenta de cloud que traes tú, que da elasticidad y la menor carga operativa, al coste de que los datos salgan de tu cuenta hacia la región del modelo si lo permites. Por encima, un VPC fijado a una región mantiene los datos dentro de tu propio perímetro de cloud y de tu zona de residencia exigida, a cambio de que seas tú quien opere la frontera y el enrutado. Más arriba, el despliegue on-premises da control físico total cuando las normas vetan del todo el procesamiento externo, y te entrega a cambio la planificación de capacidad y la operación de GPUs. En la cima, un entorno air-gapped elimina por completo la vía de salida para el trabajo de máxima sensibilidad, y pagas ese aislamiento con actualizaciones de modelo y operaciones manuales y deliberadas.
El error es leer esa escalera como un menú y elegir un peldaño para toda la organización. No es un menú. Es una tabla de enrutado. Clasificas los datos que transporta una carga dada, y la clasificación te dice el peldaño más bajo en el que esa carga puede correr. Un mismo proceso de negocio abarca rutinariamente varias clases: un paso lee un expediente regulado y pertenece a lo alto de la escalera, otro redacta una notificación genérica y puede estar abajo. Así que el enrutado ocurre paso a paso, no una vez para el sistema, y el mismo proceso puede tocar dos topologías en una sola ejecución.
Computación confidencial: procesar datos regulados que no puedes aislar del todo
Aquí está el caso que la escalera clásica maneja mal. A veces necesitas la elasticidad o el hardware especializado de infraestructura que no posees físicamente, pero los datos son demasiado sensibles para exponerlos a quien opera esa infraestructura. El air-gap dice que no. El VPC dice "confía en los operadores de tu proveedor de cloud". Ninguno satisface cuando el modelo de amenaza incluye a la propia plataforma.
Esto es lo que aborda la computación confidencial, y el mecanismo es un entorno de ejecución confiable, un TEE. Un TEE es un enclave impuesto por hardware en el que los datos se descifran y se procesan permaneciendo cifrados en todo lo demás: en memoria, el enclave los guarda en una región que el sistema operativo anfitrión, el hipervisor y el operador de cloud no pueden leer físicamente. Los datos quedan protegidos no solo en reposo y en tránsito, los dos estados que todo el mundo ya protege, sino en uso, el estado que históricamente ha sido el hueco. La carga corre, los datos regulados se procesan, y el operador de la máquina donde corrió nunca tuvo la posibilidad de verlos.
Dos propiedades hacen de esto un control en lugar de una promesa. El enclave lo impone el hardware de la CPU, no una configuración de software que un operador privilegiado pudiera desactivar. Y la atestación remota te deja verificar criptográficamente, antes de enviar ningún dato, que el código que corre dentro del enclave es exactamente el que esperas y que está corriendo de verdad en un TEE real. No confías en la garantía del operador de que tus datos están protegidos. Verificas el enclave, luego le liberas los datos, y la verificación es una firma que puedes guardar como evidencia.
Para una organización regulada, esto replantea una decisión que era binaria. La pregunta antigua era "posee el hardware, o expón los datos". La computación confidencial añade una tercera respuesta para una porción concreta y valiosa de cargas: correr en hardware que no posees, sobre datos que de otro modo no podrías exponer, porque el entorno está atestiguado y el operador queda criptográficamente fuera. No sustituye a on-prem ni al air-gap en los casos más extremos. Extiende el alcance de la soberanía a sitios a los que antes no podía llegar.
Enrutado por soberanía que falla cerrado
Un espectro de topologías es solo tan seguro como la regla que le asigna cargas, y la propiedad que hace defendible esa regla es concreta: falla cerrada.
La política de enrutado clasifica los datos por sensibilidad y fija cada clase a las topologías en las que puede correr. Los datos regulados y personales se quedan dentro de tu perímetro por defecto, sea ese perímetro un VPC fijado a una región, on-prem, un air-gap o un enclave atestiguado. Solo las cargas explícitamente no sensibles pueden alcanzar un modelo en región externa, y solo cuando una política ha permitido que esa clase salga. La parte decisiva es qué pasa bajo incertidumbre: cuando una clasificación es ambigua, el sistema trata los datos como sensibles y los mantiene en el entorno más protegido que sus clases posibles permiten. El valor por defecto te protege. Relajarlo exige una decisión deliberada y registrada, no un descuido.
Esa es la diferencia entre "tus datos nunca salen de casa" como frase de marketing y como arquitectura. Como arquitectura, la salida se deniega por defecto y se permite solo por política explícita, por clase de datos, por paso, con cada relajación registrada. Una mala configuración no abre una puerta en silencio, porque la puerta está cerrada salvo que algo la abriera deliberadamente. Fallar cerrado es toda la razón por la que un supervisor puede creerse la afirmación de soberanía, porque significa que el modo de fallo del sistema es la sobreprotección, no la fuga.
DORA y la residencia son los motores, no el papeleo
Nada de esto es ingeniería por sí misma. Es la forma que impone la obligación regulatoria, y dos obligaciones en particular la conducen.
La residencia de datos es la directa. Las normas que exigen que ciertos datos permanezcan dentro de una jurisdicción convierten "¿dónde corre el modelo?" en una pregunta jurídica con respuesta física. Un VPC fijado a una región, un clúster on-prem o un enclave atestiguado en la jurisdicción correcta no son una preferencia; son cómo satisfaces una norma que una región por defecto cómoda incumpliría. Los regímenes de resiliencia operativa como DORA empujan en paralelo: les importa el riesgo de concentración y tu capacidad de mantener un proceso crítico corriendo e inspeccionable, que es exactamente lo que da una postura enrutada, agnóstica y con despliegue en cualquier sitio, y lo que no da una topología única cableada. Cuando tu despliegue es una regla de enrutado de la que eres dueño en lugar del valor por defecto de un proveedor, puedes demostrarle a un supervisor tanto dónde se quedan los datos regulados como cómo sobrevive el proceso a que un proveedor o una región queden inutilizables.
Así que la pregunta que llevar a tu próxima revisión de arquitectura no es "¿cloud u on-prem?". Es para cada clase de datos de este proceso, cuál es el entorno menos expuesto en el que puede correr, el enrutado la manda ahí por defecto, y el sistema falla cerrado cuando no está seguro. Si puedes responder a eso clase a clase, y si la computación confidencial ha extendido tu alcance a las cargas que antes forzaban una elección imposible, tienes una arquitectura de soberanía. Si tu respuesta es una topología para todo, tienes la esperanza de que nada sensible tome nunca el camino cómodo.
Si quieres mapear tus clases de datos a las topologías permitidas, y descubrir dónde un enclave atestiguado cambia la respuesta, reserva una reunión y tráenos el proceso con los datos más sensibles desde el punto de vista jurisdiccional.