DataQubeDataQube
Blog

Agentes de IA en air gap: lo que exige de verdad el egreso cero

El despliegue de IA en air gap no es un interruptor - es una restricción para la que se diseñó o no. Dónde corre el modelo (su nube con retención cero de datos, o totalmente dentro), cómo funcionan la entrega y las licencias sin ruta al exterior, y qué significa soporte cuando nadie puede entrar por SSH.

PE
Platform Engineering
DataQube · 12 de mayo de 2026 · 5 min de lectura
Ingeniería

Toda conversación seria de despliegue con una institución consciente de la seguridad llega al mismo punto de control, y lo dirige el equipo de red, no el de datos: "¿Qué necesita alcanzar?" La mayoría de los productos de IA empresarial responde con una lista - API del modelo, servidor de licencias, endpoint de telemetría, canal de actualizaciones - y luego negocia qué entradas son realmente necesarias. DataQube está construido para que la negociación no haga falta: la plataforma en sí no alcanza nada, y la única dependencia que de verdad necesita un modelo - el modelo - corre donde usted decida.

Qué sale hacia fuera — y qué no sale nunca
Dentro de su perímetro
telemetría
ninguna, en cualquier modo
licencias
archivo local firmado — sin llamadas
actualizaciones
por su espejo de registro
soporte
registros exportados — sin túnel
endpoint del modelo
su elección — el mismo producto en ambos casos
GPUs en el clúster · air gap total
retención cero de datos
Fuera
su nube

Dos aclaraciones honestas antes de la ingeniería. Primera: el air gap total es una forma soportada de ejecutar DataQube, no la única. La mayoría de los clientes elige modelos frontier comerciales en su huella de nube existente - su propia tenencia, bajo términos de retención cero de datos, dentro de acuerdos que su equipo de seguridad ya revisó. Segunda: el techo del air gap sigue dando forma al producto. Diseñar para el caso más duro es la razón de que los casos más fáciles queden limpios: una plataforma sin telemetría, sin llamadas de licencia y sin canal de actualizaciones se comporta igual tanto si el endpoint del modelo está al otro lado del clúster como al otro lado de su nube. Este artículo trata de ese techo - lo que exige de verdad.

Dónde corre el modelo es su dial, no el nuestro

El endpoint del modelo es configuración, y la configuración abarca un espectro. En un extremo: un endpoint compatible con OpenAI en su propia tenencia de nube - los modelos frontier que sus equipos ya conocen, con retención cero de datos en vigor, es decir, los prompts y las salidas no se almacenan ni se usan para entrenar, y el tráfico nunca sale de los acuerdos que usted ya gobierna. Aquí aterriza la mayoría de los clientes, porque compra calidad frontier sin crear una sola relación de datos nueva.

En el otro extremo: un despliegue totalmente en air gap, con un servicio de inferencia en el clúster sobre sus propias GPUs sirviendo modelos de pesos abiertos que usted eligió y validó. Ninguna ruta al exterior - la configuración para redes cerradas, y el modo que el resto de este artículo pone a prueba.

Lo que ambos extremos comparten es la propiedad que le importa a un auditor: la elección del modelo está bajo su control de cambios. Una actualización de modelo es un ticket de cambio - probado, aprobado, reversible -, no un proveedor cambiando pesos en silencio bajo una API. Cuando alguien pregunte "¿qué modelo produjo exactamente las cifras del trimestre pasado, y quién lo aprobó?", la respuesta está en su historial de cambios - en ambos casos.

Entrega: un único camino aprobado para todo

Meter software en una red sin internet es un problema logístico resuelto - toda institución en air gap ya opera un camino de artefactos aprobados con un espejo de registro detrás. La obligación de diseño del proveedor es necesitar solo ese camino, para cada artefacto, sin excepciones que aparezcan después como sorpresas:

Un único camino aprobado para cada artefacto
1Release
imágenes · charts · pesos · licencia — con digest fijado
2Revisión en frontera
su proceso, sus escáneres
3Espejo de registro
dentro del perímetro
4Despliegue
digests verificados — los bytes revisados
sha256:9f2c41…e7 · verificado en el clúster = revisado en la frontera

Un release son imágenes de contenedor, charts de despliegue, pesos de modelo donde los suministremos - y la licencia, que es deliberadamente aburrida: un archivo firmado, validado localmente contra nuestra clave pública, sin servidor de licencias, sin llamada de activación, con renovaciones como un intercambio de archivo por el mismo camino. Nada del conjunto espera descargar nada más: egreso cero significa que todo el cierre de dependencias - hasta artefactos incómodos como motores de navegador - aflora en tiempo de compilación y se envía fijado, en lugar de llegar por una descarga que nadie revisó. La fijación por digest es lo que hace fiable todo el camino: lo que su equipo revisó en la frontera es byte a byte lo que corre dentro, y los digests del registro de despliegue responden "qué está corriendo exactamente" para cualquier auditoría, para siempre. Las compilaciones reproducibles cierran el círculo - un digest en ejecución se remonta a un release de código fuente sin fiarse de nuestra palabra.

Soporte sin túnel

La pregunta que sigue a la entrega: "Cuando algo se rompa, ¿cómo nos ayudan si no pueden conectarse?" Merece una respuesta concreta, porque "ya lo resolveremos" es como nacen las excepciones de acceso remoto.

Nuestra respuesta tiene tres partes. Primera: los registros de auditoría y diagnóstico son estructurados y exportables por diseño - los mismos registros que sirven al cumplimiento sirven al soporte, y nunca contienen datos, credenciales ni información personal, así que exportarlos a través de un proceso de revisión es viable. Segunda: las compilaciones reproducibles hacen que un problema reportado contra un digest sea un problema reproducible en nuestro laboratorio - ejecutamos los mismos bytes, no una suposición. Tercera: las correcciones viajan por el camino de artefactos como cualquier release - según su calendario de cambios, no el nuestro.

Esa última cláusula es un coste real, así que debe estar sobre la mesa. El egreso cero nos hizo renunciar a cosas que a los proveedores les gustan: actualizaciones automáticas silenciosas (los clientes actualizan deliberadamente, según su calendario), analítica de uso (aprendemos de socios de diseño y simulacros, no de telemetría) y depuración remota (los registros tienen que ser lo bastante buenos - lo que los obliga a serlo). Consideramos cada intercambio una funcionalidad vestida de coste - cada uno elimina un canal que su revisión de seguridad tendría que modelar.

La lista de comprobación para cualquier proveedor que afirme soportar air gap

"Apto para air gap" abarca desde "diseñado de verdad para ello" hasta "funcionó una vez en una demo con el Wi-Fi apagado". Cinco preguntas separan los extremos de ese rango. ¿Dónde puede correr el modelo - y es totalmente dentro una respuesta soportada, no un punto del roadmap? ¿Las licencias llaman alguna vez al exterior, aunque sea una? ¿Puede cada artefacto de un release espejarse y verificarse por digest - incluidos los incómodos, como motores de navegador y pesos de modelo? ¿Qué recibe exactamente el soporte cuando algo se rompe, y alguna respuesta implica un túnel? Y la pregunta resumen que el equipo de red hará de todos modos: ¿qué necesita alcanzar la plataforma en sí?

Nuestras respuestas están en la página de seguridad, y el espectro de despliegue - de la tenencia de nube con retención cero de datos hasta el air gap total - es para lo que existe el nivel Sovereign de nuestra página de precios. Una demo funciona perfectamente con el internet desenchufado - que es más bien la gracia del asunto.

Se despliega en su clúster; nada sale fuera

Vea sus datos responder preguntas sin salir de su infraestructura

Treinta minutos con un ingeniero: producto en vivo, opciones de despliegue y respuestas claras para su equipo de seguridad.