IA con aislamiento de red: cómo funcionan los sistemas de IA sin acceso a Internet ni a la nube
La IA con aislamiento físico (air-gapped) es un sistema de IA desplegado dentro de un dominio de seguridad que no tiene conexión de red física con los sistemas externos de los que está separado, y cualquier transferencia a través de esa frontera se realiza mediante procedimientos deliberadamente controlados y no automatizados. Por lo tanto, el modelo de IA, el entorno de ejecución, los datos, los índices de recuperación, las herramientas y las dependencias operativas necesarias para la inferencia deben estar disponibles dentro del entorno aislado. La IA con aislamiento físico no es simplemente "un modelo local" o "un servidor local": la propiedad que la define es la frontera de red y de transferencia en torno al sistema completo.
Qué significa realmente la IA con aislamiento físico
La palabra IA no cambia el concepto básico de seguridad. Un air gap es una frontera entre dominios de seguridad. La IA simplemente hace que el lado aislado sea más exigente operativamente porque las pilas de IA modernas normalmente asumen modelos descargables, registros de paquetes, telemetría, API, hubs de modelos y actualizaciones de software frecuentes.
El entorno aislado aún puede contener muchas máquinas conectadas. Un clúster interno puede tener GPU, servidores de aplicaciones, almacenamiento, bases de datos, servicios de identidad y monitoreo conectados entre sí. El air gap existe entre ese enclave y el dominio externo.
Por lo tanto, la pregunta relevante no es "¿Esta GPU tiene Wi-Fi?" sino "¿Puede este entorno de IA intercambiar información con el dominio externo a través de una ruta física o lógica automatizada?"
El ejemplo más simple
Imagina que una empresa quiere un asistente interno para documentos técnicos confidenciales, pero no se permite que el entorno envíe esos documentos a internet.
La empresa descarga un LLM aprobado, un modelo de embeddings, imágenes de contenedores y paquetes de software en un entorno de preparación conectado. Tras la validación, los artefactos aprobados se transfieren al entorno aislado.
Dentro del enclave, el servidor de modelos, el analizador de documentos, la base de datos vectorial, la aplicación y los servicios de identidad se ejecutan localmente. Los usuarios pueden hacer preguntas y usar RAG sobre documentos internos sin un modelo en la nube ni un registro público de modelos.
Cuando se requiere una actualización, la actualización pasa de nuevo por el proceso de importación controlada en lugar de ser descargada directamente por el servidor de IA de producción.
Un ciclo operativo básico de IA con aislamiento físico
Dónde se detiene el ejemplo simple
Un entorno de producción con aislamiento físico puede ser mucho más grande que una sola estación de trabajo. Puede incluir Kubernetes/OpenShift, registros internos, almacenamiento de objetos, proveedores de identidad, bases de datos vectoriales, observabilidad, infraestructura de respaldo y varios nodos de servicio de modelos.
Cuantos más servicios existan dentro del enclave, más debe la organización reproducir capacidades que los entornos conectados normalmente consumen de internet.
Por lo tanto, el air-gapping desplaza la complejidad. Reduce la conectividad externa directa pero aumenta la gestión de artefactos, el parcheo, las dependencias, la cadena de suministro y la responsabilidad operativa dentro del dominio aislado.
IA con air-gap vs offline vs local vs on-premises vs privada vs soberana
| Término | Qué describe principalmente | ¿Requiere conectividad a internet/externa? |
|---|---|---|
| IA local | La inferencia/ejecución se ejecuta en hardware local | No; pero puede seguir llamando a servicios en la nube |
| IA con capacidad offline | Puede seguir operando sin internet | No durante la operación offline; la reconexión puede ser normal |
| Entorno desconectado | Sin ruta directa a internet externo desde el entorno de despliegue | Normalmente no; puede usar réplicas/bastiones controlados |
| IA on-premises | La infraestructura se ejecuta en el entorno propio/on-prem de una organización | Podría seguir teniendo conectividad completa a internet |
| IA privada | El procesamiento de IA está controlado para cumplir requisitos de privacidad/confidencialidad | Específico de la arquitectura; puede estar conectada o desconectada |
| IA con air-gap | Los dominios de seguridad están físicamente desconectados y la transferencia transfronteriza no es automatizada/manual bajo una definición estricta | Sin ruta externa automatizada |
| IA soberana | Control/jurisdicción sobre modelos, datos, infraestructura y dependencias | No necesariamente; la soberanía es más amplia que el aislamiento de red |
Estos términos pueden solaparse pero no son sinónimos. Un servidor Ollama local conectado a internet es IA local, no IA con air-gap. Una plataforma RAG on-premises que llama a un modelo en la nube es infraestructura de aplicación on-premises con inferencia en la nube, no IA con air-gap.
Un sistema con air-gap suele ser privado por diseño porque los datos permanecen dentro del enclave, pero la privacidad también depende de la autorización, el registro, el manejo de datos, la seguridad física y la política operativa.
Air gap estricto vs despliegue desconectado práctico
Dos significados frecuentemente llamados "air-gapped"
| Air gap estricto | Despliegue desconectado / sin internet | |
|---|---|---|
| Conexión física externa | ||
| Transferencia transfronteriza | ||
| Acceso a internet desde la carga de trabajo de IA | ||
| Redes internas | ||
| Usar el término cuando |
Una arquitectura práctica de IA con air-gap
| Capa | Qué debe existir dentro del entorno aislado |
|---|---|
| Capa de usuario/aplicación | Interfaz de chat, API, aplicación de negocio o interfaz de agente interno |
| Identidad y autorización | Autenticación local/interna, RBAC, permisos de inquilino/recurso |
| Puerta de enlace/tiempo de ejecución de IA | Enrutamiento de modelos, política de solicitudes, ensamblaje de contexto y controles de tiempo de ejecución |
| Servicio de modelos | Servidor(es) de modelos local(es), pesos, tokenizador/configuración y tiempo de ejecución del acelerador |
| RAG / conocimiento | Almacén de documentos, analizador, incrustaciones, índices vectoriales/léxicos, metadatos y procedencia |
| Herramientas/servicios | Solo API internas/locales y sistemas aprobados accesibles desde el enclave |
| Repositorios de artefactos | Registro de contenedores local, réplica de paquetes, almacén de modelos y opcionalmente repositorios de SO/actualizaciones |
| Observabilidad | Registros internos, métricas, trazas y registros de auditoría |
| Respaldo/recuperación | Proceso de respaldo local o controlado por separado apropiado para el dominio de seguridad |
| Límite de transferencia | Proceso de importación/exportación controlado con inspección y aprobación |
Una arquitectura completa debería poder iniciarse y operar sin consultas DNS, verificaciones de licencia, descargas de paquetes o llamadas API a servicios públicos, a menos que esas dependencias tengan reemplazos internos aprobados.
Una prueba de diseño útil es desconectar el despliegue de todos los servicios externos e iniciar en frío la pila. Las dependencias ocultas tienden a aparecer durante el inicio, la carga de modelos, la autenticación, la resolución de paquetes o la inicialización de telemetría.
Los modelos deben estar preconfigurados
Las API de modelos en la nube no están disponibles por definición si la carga de trabajo aislada no tiene ruta hacia ellas. Por lo tanto, el enclave necesita artefactos de modelos ejecutables localmente o un servicio de inferencia alojado internamente.
La documentación actual de air-gap de NVIDIA NIM utiliza explícitamente un patrón de dos fases: descargar y preparar los activos del modelo en una máquina conectada, transferirlos, luego ejecutar el NIM aislado desde el almacenamiento local sin acceso saliente al registro ni claves de API en la nube.
Los pesos del modelo son solo parte del conjunto de dependencias. Los tokenizadores, archivos de configuración, adaptadores, metadatos de cuantización y cualquier código de tiempo de ejecución requerido también deben estar presentes.
Los modelos con dependencias de código remoto son un peligro para el air-gap
Algunos repositorios de modelos contienen código Python personalizado o hooks de tiempo de ejecución que normalmente obtienen código o recursos adicionales.
La documentación actual de Red Hat AI Inference advierte explícitamente que algunos modelos de Hugging Face que requieren código remoto no pueden operar normalmente en entornos desconectados porque la biblioteca intenta acceder a la red incluso cuando se configura el modo sin conexión.
La lección práctica es probar toda la ruta de carga de un modelo sin conexión antes de aprobarlo para un despliegue aislado. "Descargué los pesos" no es prueba de que el modelo sea autocontenido.
Contenedores, paquetes y controladores se convierten en artefactos locales de la cadena de suministro
Los entornos conectados extraen habitualmente imágenes de contenedores, paquetes de Python, actualizaciones del sistema operativo y componentes de GPU de registros públicos. Un entorno con aislamiento de red no puede asumir ninguno de esos servicios.
El modelo de despliegue de IA desconectado de Red Hat utiliza registros espejo internos para imágenes de contenedores y catálogos de operadores. Los modelos se pueden replicar como artefactos OCI o transferir a almacenamiento persistente.
Para stacks más amplios, el mismo patrón suele aplicarse a paquetes de lenguaje, repositorios de Linux, paquetes de JavaScript y binarios internos: los artefactos aprobados entran una vez a través del proceso de transferencia y luego se sirven desde repositorios internos de confianza.
Conozca la factura completa de dependencias
| Clase de dependencia | Ejemplos |
|---|---|
| Artefactos del modelo | Pesos, tokenizador, configuración, adaptadores, metadatos de cuantización |
| Tiempo de ejecución de inferencia | vLLM, llama.cpp, Ollama, NIM u otro tiempo de ejecución de servicio |
| Stack de GPU/tiempo de ejecución | Controladores, bibliotecas CUDA/ROCm, tiempo de ejecución de contenedores |
| Paquetes de aplicación | Ruedas de Python, paquetes npm, bibliotecas del sistema |
| Contenedores | Aplicación, inferencia, BD, BD vectorial, imágenes de monitoreo |
| Modelos RAG | Modelo de embedding, reranker, modelos de OCR/visión |
| Datos | Corpus de conocimiento, metadatos, esquemas, conjuntos de datos de evaluación |
| Material de seguridad | Certificados, paquetes de CA, políticas/configuración, firmas de malware cuando corresponda |
| Artefactos operativos | Paneles, reglas de alerta, herramientas de respaldo, runbooks |
| Licenciamiento | Licencias/derechos compatibles con entornos sin conexión cuando sea necesario |
Los espejos internos son infraestructura, no una comodidad
Un despliegue desconectado se vuelve mantenible cuando el dominio aislado tiene fuentes internas conocidas para artefactos aprobados.
El enfoque documentado de Red Hat utiliza un registro espejo disponible para el clúster desconectado, de modo que las cargas de trabajo no necesitan registros públicos.
La misma idea arquitectónica se puede aplicar a almacenes de modelos y repositorios de paquetes. El objetivo es hacer explícitos el origen, la versión y la aprobación de los artefactos en lugar de copiar archivos aleatorios manualmente a cada servidor.
RAG puede funcionar completamente con aislamiento de red
RAG no requiere internet público. Requiere un corpus recuperable, una canalización de ingesta/indexación y un modelo que pueda usar el contexto recuperado.
Dentro de un entorno con aislamiento de red, el almacén de documentos, el analizador/OCR, el modelo de embedding, el índice vectorial o léxico, el reranker y el modelo de generación pueden ejecutarse localmente.
Lo que cambia es la adquisición de fuentes. La búsqueda web en vivo y los conectores de documentos en la nube no están disponibles a menos que se importen datos equivalentes a través del límite controlado.
Por lo tanto, el corpus se convierte en un artefacto gobernado. Cada importación debe preservar la identidad de la fuente, la fecha/versión y la procedencia para que los usuarios sepan qué conocimiento contiene realmente el sistema aislado.
Los agentes pueden ejecutarse con aislamiento de red, pero solo con herramientas accesibles
Un bucle de agente puede ejecutarse completamente dentro de un enclave aislado si el modelo/entorno de ejecución y las herramientas requeridas son locales o accesibles en la red interna.
Una herramienta que depende de GitHub, búsqueda web pública, correo electrónico en la nube o una API de SaaS externa fallará a menos que la arquitectura proporcione un equivalente interno aprobado o un proceso de intercambio asíncrono controlado.
Por eso el diseño de agentes con aislamiento de red debe comenzar con un inventario de capacidades: cada punto de conexión de herramienta debe clasificarse como interno, importado, no disponible o deliberadamente excluido.
MCP no elude el aislamiento de red
MCP puede exponer herramientas y recursos locales dentro de un entorno de IA aislado, pero el protocolo no crea conectividad a través del límite de seguridad.
Un servidor MCP local que lee documentos internos puede funcionar perfectamente sin conexión. No se puede acceder a un servidor MCP remoto en la internet pública desde un enclave estrictamente aislado.
El mismo principio se aplica a cualquier protocolo de conector: la interoperabilidad es independiente de la autoridad de red.
La identidad y la autenticación también deben funcionar sin conexión
Una aplicación de IA puede alojarse localmente y aun así depender de un proveedor de identidad en la nube. Esa dependencia oculta rompe el funcionamiento verdaderamente desconectado.
Por lo tanto, los diseños con aislamiento de red necesitan una arquitectura de identidad que funcione dentro del enclave: directorio local, proveedor de identidad interno, PKI interna, credenciales de servicio locales u otro mecanismo aprobado.
La autorización sigue siendo necesaria aunque no haya internet. Los aislamientos de red no reemplazan RBAC, el aislamiento de inquilinos ni el privilegio mínimo.
El tiempo, los certificados y los almacenes de confianza se convierten en dependencias locales
Muchos sistemas de autenticación y registro dependen de una hora fiable. Los certificados caducan. Los almacenes de confianza cambian. Los artefactos firmados necesitan validación.
Por lo tanto, un enclave desconectado debe tener sincronización horaria interna y un ciclo de vida de certificados/confianza que no dependa de alcanzar servicios públicos durante la operación ordinaria.
Estas son preocupaciones de infraestructura ordinarias que se vuelven visibles solo cuando se prueba una arquitectura sin acceso a internet.
La telemetría y los informes de fallos necesitan una política explícita
Muchas bibliotecas modernas intentan realizar análisis, comprobaciones de actualizaciones o informes de errores de forma predeterminada.
En un entorno aislado, esas llamadas deberían deshabilitarse o redirigirse a la observabilidad interna. Los intentos fallidos repetidos de telemetría pueden crear retrasos, registros ruidosos y un comportamiento de inicio inesperado.
Un despliegue con aislamiento de red debe saber qué componentes intentan salir a la red, incluso si el cortafuegos los bloqueara.
Los sistemas con aislamiento de red siguen necesitando parches
El aislamiento de red no impide que el software desarrolle vulnerabilidades. Solo cambia la forma en que los parches llegan al sistema.
NIST enmarca la gestión de parches como mantenimiento preventivo: las organizaciones aún necesitan identificar, adquirir, priorizar, instalar y verificar parches y actualizaciones.
Por lo tanto, las operaciones con aislamiento de red necesitan una cadencia de importación repetible para paquetes del sistema operativo, imágenes de contenedores, controladores, entornos de ejecución de IA y actualizaciones de seguridad. La disyuntiva está entre la estabilidad del aislamiento y la exposición a vulnerabilidades por software desactualizado.
Una ruta de actualización controlada
Ejemplo de ciclo de vida de actualización para un entorno de IA aislado
La frontera de transferencia es la interfaz operativa más sensible
Si información externa debe entrar en un sistema con aislamiento de red, el canal de importación se convierte en un punto de control de seguridad importante.
El Marco de Amenazas Cibernéticas Técnicas de Ciberseguridad de la NSA reconoce explícitamente la replicación a través de medios extraíbles como una vía que los adversarios pueden usar para cruzar hacia redes desconectadas o con aislamiento de red.
Por eso, el manejo controlado de medios, la inspección, la procedencia, el cifrado cuando sea necesario, el análisis de malware y la separación de roles pueden importar tanto como la propia pila de IA.
Los medios extraíbles no son un conducto neutral
Las unidades USB y otros medios portátiles pueden contener tanto artefactos legítimos de modelos/datos como contenido malicioso.
La guía de sanitización de medios de NIST trata los medios de almacenamiento como un objeto del ciclo de vida de la confidencialidad que puede requerir borrado, purga o destrucción según la sensibilidad y las necesidades de reutilización.
El procedimiento exacto de transferencia es específico de cada organización, pero el principio arquitectónico es estable: los medios que cruzan fronteras deben gobernarse como un activo de seguridad, no tratarse como una conveniencia informal.
El aislamiento de red aumenta la importancia de la cadena de suministro
Un sistema aislado recibe menos entradas externas activas, pero cada binario, modelo, contenedor y paquete importado adquiere mayor relevancia porque el enclave puede confiar en él durante mucho tiempo.
La guía de NIST sobre la cadena de suministro de software enfatiza la procedencia, el riesgo del proveedor, la gestión de vulnerabilidades, la verificación de software y las prácticas orientadas a SBOM. Estas preocupaciones se vuelven directamente relevantes para la importación de artefactos de IA sin conexión.
La cadena de suministro de modelos merece la misma atención que la cadena de suministro de aplicaciones: el origen del modelo, la licencia, el hash, el formato, el código requerido, el tokenizador, los adaptadores y el estado de evaluación deben conocerse antes de la importación.
La preparación para el air-gap debe probarse, no asumirse
| Prueba | Qué demuestra |
|---|---|
| Arranque en frío con toda la red saliente bloqueada | El entorno de ejecución no requiere servicios públicos durante el arranque |
| Cargar cada modelo aprobado desde el almacenamiento local | Los pesos/tokenizadores/configuraciones están completos |
| Reconstruir/redesplegar solo desde registros internos | Los espejos de contenedores/paquetes son suficientes |
| Autenticar usuarios mientras el IdP externo es inalcanzable | La identidad funciona dentro del enclave |
| Ejecutar la ingesta y consulta de RAG sin conexión | La pila de embedding/indexación/recuperación es local |
| Ejecutar herramientas de agente representativas | Las herramientas no dependen de API externas |
| Reiniciar tras eliminar la caché | La operación sin conexión no depende accidentalmente de descargas previamente almacenadas en caché |
| Avanzar el ciclo de vida simulado de certificados/actualizaciones | Las dependencias de confianza y mantenimiento se comprenden |
| Importar un nuevo modelo a través de la ruta de preparación | El procedimiento de transferencia/cambio es operativo |
| Restaurar desde copia de seguridad | La recuperación no requiere almacenamiento en la nube no disponible |
Almacenado en caché una vez no es lo mismo que listo para air-gap
Un sistema puede parecer sin conexión porque el modelo y los paquetes ya están en caché de un acceso previo a internet.
Eliminar las cachés o desplegar en un nodo limpio puede revelar archivos de tokenizador faltantes, paquetes de Python, manifiestos de modelos o dependencias de código remoto.
Por lo tanto, la preparación para el air-gap debe validarse a partir de artefactos internos limpios, no solo desde una estación de trabajo de desarrollador que estuvo conectada previamente.
¿Qué amenazas permanecen dentro de un air gap?
| Amenaza | Por qué el air gap no la elimina |
|---|---|
| Artefacto importado comprometido | El malware/modelo/paquete puede entrar a través de la ruta de transferencia autorizada |
| Medios extraíbles maliciosos | La transferencia física puede transportar cargas útiles ejecutables |
| Uso indebido por parte de personas internas | Ya existen usuarios autorizados dentro del enclave |
| Inyección de prompts en documentos importados | El contenido no confiable puede influir en RAG/agentes sin internet |
| Herramientas de agente con privilegios excesivos | Las herramientas locales aún pueden dañar sistemas locales |
| Fuga de datos entre inquilinos | Los errores de autorización internos siguen siendo posibles |
| Software interno vulnerable | La falta de conexión externa no elimina errores explotables |
| Movimiento lateral | Un nodo comprometido puede atacar otros nodos conectados internamente |
| Dependencias obsoletas | Una cadencia de actualización lenta puede dejar vulnerabilidades conocidas sin parchear |
| Robo/manipulación física | La seguridad del hardware y los medios sigue siendo crítica |
| Mal comportamiento del modelo | La alucinación, el sesgo y el fallo de tareas son independientes de la red |
| Envenenamiento de la cadena de suministro | Las fuentes de importación confiables aún pueden verse comprometidas |
Qué mejora realmente un air gap
Un air gap genuino puede reducir materialmente las rutas de ataque que dependen de la conectividad remota directa: comando y control externo, uso indebido de credenciales en la nube, explotación de servicios expuestos a internet y exfiltración accidental de datos a través de API salientes ordinarias.
También simplifica la residencia de datos en un sentido limitado: los datos de inferencia no pueden enviarse a un servicio en la nube externo si no existe una ruta.
Esos beneficios son más fuertes cuando el límite de transferencia y los controles de acceso internos son igualmente disciplinados. Un proceso de USB mal gestionado puede socavar el aislamiento previsto.
Qué dificulta un air gap
| Área | Consecuencia operativa |
|---|---|
| Actualizaciones de modelos | Transferencia manual/por etapas en lugar de extracción directa del centro de modelos |
| Parches de seguridad | Flujo de trabajo de importación retrasado y gobernado |
| Instalación de paquetes | Se requieren espejos internos o artefactos preconstruidos |
| API de IA en la nube | No disponibles |
| Búsqueda web/conectores | No disponibles a menos que los datos se importen por separado |
| Autenticación | Necesita servicios de identidad internos o con capacidad sin conexión |
| Monitoreo | Necesita observabilidad interna y exportación controlada |
| Licencias | Los productos que requieren activación en línea pueden no ser adecuados |
| Solución de problemas | No hay acceso en vivo fácil a recursos del proveedor desde el enclave de producción |
| Capacidad | Todo el cómputo de inferencia debe existir localmente |
| Recuperación ante desastres | Las copias de seguridad en la nube pueden no estar disponibles o estar restringidas por políticas |
| Actualidad del conocimiento | La información externa llega solo tan rápido como el proceso de importación |
IA con aislamiento físico vs IA privada
La IA privada se centra principalmente en controlar los datos sensibles y el procesamiento de IA. Una plataforma de IA privada puede estar en las instalaciones y aun así acceder a modelos en la nube aprobados o a servicios externos.
La IA con aislamiento físico es más estricta en cuanto a la conectividad. Un sistema puede ser privado sin estar aislado físicamente, y un sistema aislado físicamente puede seguir teniendo una privacidad deficiente si todos los usuarios internos tienen acceso sin restricciones.
El objetivo de seguridad debe determinar la arquitectura: la confidencialidad, la soberanía, la resiliencia y el aislamiento son requisitos relacionados pero distintos.
IA con aislamiento físico vs IA soberana
La IA soberana se refiere al control sobre la cadena de dependencias más amplia: datos, modelos, infraestructura, operadores, jurisdicción y dependencias estratégicas.
Un aislamiento físico puede respaldar la soberanía al reducir la dependencia externa en tiempo de ejecución, pero no garantiza el control soberano. El enclave puede seguir dependiendo de hardware extranjero, licencias de modelos propietarios o proveedores externos de actualizaciones.
El siguiente artículo canónico separa esas dimensiones de control de forma explícita.
Evidencia de la implementación original: qué demuestra el Aaasaasa AI Client y qué no
El AI Hub separa el agente/cliente, el proveedor, el modelo y la ubicación de la conexión. Admite la inferencia local con Ollama y la operación de Codex con proveedor local como opciones distintas, en lugar de asumir que todas las solicitudes de IA van a un modelo en la nube.
El repositorio señala explícitamente que un entorno de ejecución local puede seguir usando un modelo en la nube, mientras que el chat directo con Ollama es inferencia local. Esta distinción es directamente relevante para la arquitectura de aislamiento físico: la ejecución local no demuestra que el modelo o las dependencias que lo rodean estén desconectados.
La abstracción de proveedores, el descubrimiento de modelos locales y la inferencia local son, por lo tanto, componentes básicos para una arquitectura de producto capaz de soportar aislamiento físico, pero el límite de red, el espejo de dependencias sin conexión, el proceso de transferencia controlada y la identidad/operaciones sin conexión aún deben diseñarse por separado.
| Capacidad verificada del proyecto | Relevancia para el aislamiento físico |
|---|---|
| Inferencia local con Ollama | Admite la ejecución local de modelos |
| Rutas de proveedor/entorno de ejecución local | Reduce la dependencia de la inferencia en la nube |
| Separación de proveedor/modelo/entorno de ejecución | Hace explícitas las dependencias de la nube en lugar de ocultarlas |
| Permisos centrales | Admite el control de acceso local a herramientas y datos |
| También existe soporte para proveedores en la nube/remotos | Demuestra que el producto en sí es capaz de funcionar de forma híbrida, no inherentemente con aislamiento físico |
| No hay un límite de despliegue aislado verificado | Evita exagerar la madurez del aislamiento físico |
¿Cuándo está justificada la IA con aislamiento físico?
| El aislamiento físico puede estar justificado cuando | Una arquitectura privada conectada puede ser mejor cuando |
|---|---|
| La política de seguridad exige explícitamente dominios físicamente separados | El requisito principal es solo que los prompts y los datos no sean utilizados por servicios de consumo públicos |
| Los datos clasificados o extremadamente sensibles no pueden cruzar redes externas | Los endpoints aprobados de nube empresarial o privados satisfacen los controles de datos |
| El entorno operativo no tiene conectividad externa fiable | Hay internet disponible y la agilidad operativa es importante |
| La continuidad de la misión no debe depender de la disponibilidad de la nube o del proveedor | La calidad gestionada del modelo y las actualizaciones rápidas son más valiosas |
| Un entorno regulado o crítico exige una transferencia controlada | Los controles de seguridad estándar pueden satisfacer el modelo de amenaza real |
| El acceso externo a SaaS o API está prohibido | El flujo de trabajo empresarial depende en gran medida de conectores externos |
El aislamiento físico debe ser un requisito derivado de un modelo de amenaza o de una política, no una característica de prestigio. Tiene valor de seguridad real cuando la ruta de conectividad eliminada es en sí misma inaceptable.
Para muchos casos de uso empresariales, una red privada estrictamente controlada con restricciones de salida, inferencia local y canales de actualización aprobados puede ofrecer un mejor equilibrio entre seguridad y mantenibilidad que un aislamiento físico estricto.
Una secuencia práctica de diseño de IA con air gap
Diseñar desde el límite hacia adentro
Lista de verificación de arquitectura de IA con air gap
| Pregunta | Evidencia esperada |
|---|---|
| ¿Qué exactamente está aislado de qué? | Límite de dominio de seguridad documentado |
| ¿El límite está físicamente desconectado? | Evidencia de arquitectura de red/física si se afirma un air gap estricto |
| ¿Cómo cruzan los datos el límite? | Flujo de trabajo desconectado autorizado no automatizado/manual o explícitamente documentado |
| ¿Puede cada modelo arrancar en frío offline? | Prueba de carga offline |
| ¿Están completos los activos de tokenizer/config/runtime? | Paquete de modelo interno verificado |
| ¿De dónde vienen los contenedores/paquetes? | Espejo/repositorio interno confiable |
| ¿Puede la identidad funcionar sin servicios de nube? | Ruta de credenciales de servicio/IdP/PKI interna |
| ¿Puede RAG ingerir/consultar offline? | Ingesta, embeddings, índice y recuperación locales |
| ¿Qué herramientas de agente permanecen disponibles? | Inventario de capacidades internas |
| ¿Cómo se importan los parches? | Proceso de mantenimiento controlado |
| ¿Cómo se verifican los artefactos? | Controles de integridad/procedencia/malware/cadena de suministro |
| ¿Cómo se gobiernan los medios extraíbles? | Política de manejo y sanitización de medios |
| ¿Puede el sistema ejecutarse después de limpiar las cachés? | Prueba offline en entorno limpio |
| ¿Dónde se almacenan los registros y trazas? | Plataforma de observabilidad interna |
| ¿Cómo se aprueban las exportaciones? | Proceso de egreso controlado |
| ¿Qué prueba que esto es air-gapped en lugar de meramente local? | Evidencia de límite y transferencia, no la ubicación del modelo |
Modos de fallo comunes de IA con air gap
| Modo de fallo | Qué falló realmente |
|---|---|
| El modelo local aún descarga tokenizer/config al iniciar | El paquete del modelo estaba incompleto |
| El contenedor hace referencia a un registro público | El despliegue no era autocontenido |
| Se requiere identidad en la nube para iniciar sesión | La aplicación era local pero la identidad no |
| Se requiere servidor de licencias externo | La dependencia del proveedor contradecía la operación offline |
| Falta el modelo de embeddings | El chat funciona pero la ingesta de RAG falla |
| Las llamadas de herramientas del agente van a SaaS público | La arquitectura del agente no era compatible con air gap |
| Solo el nodo GPU está aislado | La base de datos, UI o monitoreo aún dependen de servicios externos |
| Las importaciones por USB son informales | El límite de transferencia se convierte en una ruta de ataque no controlada |
| Sin proceso de parches | El aislamiento crea una deuda de vulnerabilidad creciente |
| Se usa una máquina de desarrollador con caché como prueba | El despliegue nuevo falla sin internet |
| El air gap reemplaza el pensamiento de autorización | Los usuarios/servicios internos se vuelven sobreprivilegiados |
| Se usa la etiqueta air-gapped para un bloqueo de egreso solo con firewall | La documentación de seguridad exagera el límite real |
Conceptos erróneos comunes
| Concepto erróneo | Corrección |
|---|---|
| “La IA local es IA con air gap.” | Local describe dónde se ejecuta la inferencia; air gap describe el límite de seguridad/red. |
| “Air-gapped significa una sola PC independiente.” | Un enclave aislado puede contener toda una red interna o clúster. |
| “Sin internet equivale a air gap estricto.” | Según la definición de NIST, los sistemas separados también carecen de conexión física y la transferencia a través del límite no es automatizada. |
| “Los air gaps eliminan el riesgo cibernético.” | Persisten riesgos de cadena de suministro, medios extraíbles, insider, red interna y aplicación. |
| “RAG necesita la nube.” | RAG puede ejecutarse completamente con modelos, índices y datos locales. |
| “Los agentes no pueden trabajar offline.” | Los agentes pueden usar herramientas internas/locales; simplemente no pueden alcanzar servicios externos no disponibles. |
| “Una vez instalado, el sistema no necesita actualizaciones.” | Los parches, controladores, modelos y dependencias aún requieren gestión del ciclo de vida. |
| “Un modelo descargado es autocontenido.” | Los tokenizers, código remoto, bibliotecas o activos del modelo aún pueden desencadenar dependencias de red. |
| “La IA privada y la IA con air gap son idénticas.” | La IA privada es una propiedad de datos/control; el air gap es una propiedad de conectividad. |
| “El air gap garantiza la soberanía.” | El hardware externo, las licencias, los modelos y la cadena de suministro pueden seguir siendo dependencias. |
Limitaciones
Los air gaps estrictos hacen más lenta la actualización del conocimiento externo porque cada nueva fuente debe pasar por un proceso de transferencia.
Pueden restringir la elección de modelos cuando las licencias, los requisitos de código remoto, las necesidades de hardware o las APIs exclusivas del proveedor no pueden satisfacerse offline.
Aumentan el costo operativo porque la infraestructura que normalmente se consume como servicios en la nube debe poseerse y mantenerse internamente.
También pueden crear latencia de parches: un control de cambios más estricto puede mantener los sistemas estables mientras retrasa la remediación urgente de vulnerabilidades.
Por lo tanto, la IA con air gap debe evaluarse como una arquitectura de seguridad entre varias, no asumirse como universalmente superior.
Qué cambiaría esta respuesta
El soporte de proveedores para operación desconectada cambia rápidamente. Nuevos formatos de modelo, artefactos OCI firmados, mecanismos de licencia offline y registros de modelos integrados pueden reducir la fricción operativa.
La distinción entre air gap estricto y despliegue desconectado seguirá siendo importante incluso si los proveedores continúan usando los términos de manera flexible.
El principio estable es que las afirmaciones genuinas de air gap dependen del límite del sistema y del mecanismo de transferencia, no de si el LLM se ejecuta localmente.
Conocimiento canónico relacionado
La IA con aislamiento físico es un nodo de arquitectura de despliegue/seguridad. La IA privada, la IA soberana y la abstracción de proveedores responden a preguntas diferentes sobre confidencialidad, control y dependencia.
MLOps/LLMOps se vuelve más exigente dentro de un entorno desconectado porque los ciclos de vida de modelos, paquetes y actualizaciones deben operar a través de repositorios internos y transferencia controlada.
RAG y la IA agéntica siguen siendo patrones válidos dentro del enclave siempre que sus datos y herramientas estén disponibles internamente.
Preguntas frecuentes
Preguntas frecuentes sobre IA con aislamiento físico
¿Qué es la IA con aislamiento físico?
¿La IA con aislamiento físico necesita acceso a internet?
¿Un LLM local está automáticamente aislado físicamente?
¿Puede funcionar RAG en una red con aislamiento físico?
¿Pueden funcionar los agentes de IA con aislamiento físico?
¿Cómo se actualizan los modelos en un entorno con aislamiento físico?
¿La IA on-premises es lo mismo que la IA con aislamiento físico?
¿La IA privada es lo mismo que la IA con aislamiento físico?
¿Un aislamiento físico hace que la IA sea segura?
¿Cuál es la mejor prueba para la preparación para el aislamiento físico?
Glosario
Términos clave de IA con aislamiento físico
- Aislamiento físico
- Interfaz de dominio de seguridad donde los sistemas no están físicamente conectados y cualquier transferencia lógica transfronteriza es no automatizada/manual según la definición del glosario de NIST.
- IA con aislamiento físico
- Sistema de IA desplegado dentro de un dominio de seguridad con aislamiento físico con dependencias de inferencia y operativas disponibles localmente.
- Entorno desconectado
- Entorno de despliegue sin acceso directo a internet externo; las implementaciones pueden usar flujos de trabajo controlados de espejo o bastión.
- IA con capacidad offline
- Aplicación de IA capaz de operar para algunas o todas sus funciones sin conectividad a internet, sin estar necesariamente aislada de forma permanente.
- IA local
- Inferencia o runtime de IA que se ejecuta en hardware local en lugar de un endpoint de modelo remoto; no implica aislamiento de red.
- Registro espejo
- Repositorio interno que contiene copias aprobadas de imágenes de contenedores u otros artefactos necesarios para un despliegue desconectado.
- Entorno de staging
- Zona conectada o controlada donde los artefactos se adquieren, verifican y preparan antes de la transferencia a un dominio aislado.
- Transferencia controlada
- Movimiento gobernado de datos o software a través del límite de aislamiento utilizando medios/procesos aprobados y verificación.
- Procedencia de artefactos
- Información que muestra de dónde proviene un modelo, paquete, contenedor u otro artefacto importado y cómo se produjo o verificó.
- Medios extraíbles
- Almacenamiento portátil utilizado para transferir datos entre sistemas; una posible vía de seguridad a través de dominios desconectados.
- Almacén interno de modelos
- Repositorio dentro del entorno aislado desde el cual se sirven o despliegan artefactos de modelos aprobados.
- Preparación para el aislamiento físico
- Capacidad demostrada de todo el stack de IA para instalarse, iniciarse, operar, actualizarse y recuperarse sin conectividad externa no aprobada.
Conclusión
La IA con aislamiento físico no es un tipo especial de modelo. Es una arquitectura de IA que opera dentro de un dominio de seguridad deliberadamente aislado.
El modelo puede ser la parte fácil. La preparación para producción depende de si cada dependencia circundante — activos de modelos, paquetes, registros, identidad, RAG, herramientas, monitoreo, actualizaciones y recuperación — puede funcionar sin una ruta externa automatizada.
La regla confiable más breve es: la inferencia local demuestra dónde se ejecuta el modelo; la evidencia de aislamiento físico demuestra cómo se separa el sistema completo y cómo cada transferencia permitida cruza ese límite.
Fuentes primarias y referencias de implementación actuales
Las fuentes a continuación establecen la definición de seguridad, los patrones actuales de despliegue de IA desconectada y los riesgos del ciclo de vida. El uso que hacen los proveedores de “air-gapped” se distingue intencionalmente de la definición más estricta de NIST.
NIST CSRC — Air gapDefinición del glosario de NIST: sistemas físicamente desconectados con transferencia lógica no automatizada y controlada manualmente a través del límite.
NVIDIA NIM — Despliegue con aislamiento físicoGuía operativa actual para preparar activos de modelos en un sistema conectado y ejecutar NIM desde almacenamiento local sin internet, registros públicos ni claves de API en la nube.
Red Hat AI Inference — Despliegue desconectadoGuía actual de Red Hat para servir LLM en entornos desconectados con artefactos espejo e infraestructura interna.
Red Hat AI Inference — Almacenamiento de modelos en entornos desconectadosGuía actual que cubre imágenes de modelos OCI, almacenamiento persistente de modelos y limitaciones de modelos que requieren código remoto.
NSA — Marco técnico de amenazas cibernéticasMarco de amenazas que identifica explícitamente la replicación mediante medios extraíbles como una vía de entrada a redes desconectadas o aisladas.
NIST SP 800-88 Rev. 1 — Directrices para el saneamiento de mediosGuía para gestionar y sanear medios de almacenamiento de acuerdo con los requisitos de confidencialidad de la información.
NIST SP 800-40 Rev. 4 — Planificación de la gestión de parches empresarialGuía que enmarca la aplicación de parches y actualizaciones como mantenimiento preventivo en sistemas empresariales.
NIST — Seguridad del software en las cadenas de suministroGuía del NIST que cubre el riesgo de la cadena de suministro de software, la procedencia, la verificación, las prácticas relacionadas con SBOM y la gestión de vulnerabilidades.
Related Articles
Arquitectura de IA empresarial: qué cambia cuando la IA entra en una empresa
La arquitectura de IA empresarial explica cómo la IA cambia los sistemas de la empresa en materia de autoridad sobre los datos, identidad, permisos, proveedores, riesgo, gobernanza, evaluación, cumplimiento y operaciones.
¿Qué es un arquitecto de soluciones de IA? Límites del sistema, responsabilidades y compensaciones
Un Arquitecto de Soluciones de IA convierte los requisitos empresariales en un sistema de IA listo para producción que abarca datos, modelos, herramientas, seguridad, tiempo de ejecución, evaluación y operaciones.
IA generativa explicada: modelos, recuperación, herramientas y aplicaciones no son lo mismo
La IA generativa es más que un modelo. Aprende cómo los modelos, la recuperación, las herramientas, el contexto, los entornos de ejecución y las aplicaciones encajan en los sistemas de IA en producción.
La memoria del agente de IA no es RAG: cómo separar memoria, recuperación, estado y contexto
La memoria del agente, RAG, el estado y el contexto a menudo se usan como si fueran intercambiables. No lo son. Este modelo práctico de arquitectura separa las cuatro capas, muestra dónde pertenece cada una y explica qué se rompe cuando los sistemas las colapsan en una sola.
Arquitectura Multi-Inquilino de Grado Empresarial para una Plataforma Internacional
Loving Rocks es una plataforma de bodas de nivel empresarial diseñada con una verdadera arquitectura multiinquilino, bases de datos aisladas por inquilino e internacionalización integrada para escalabilidad global, seguridad y estabilidad operativa a largo plazo.
Bases de datos vectoriales, embeddings y reranking: tres partes diferentes de la recuperación
Las incrustaciones representan el significado, las bases de datos vectoriales recuperan candidatos y los rerankers refinan los resultados. Aprende en qué se diferencian y cómo trabajan juntas estas tres capas de recuperación en RAG.
RBAC vs Aislamiento de Inquilinos: Dos Límites de Seguridad Diferentes
El RBAC controla lo que un usuario puede hacer; el aislamiento de inquilinos controla a qué recursos de qué inquilino puede llegar esa acción. Descubre por qué la seguridad SaaS multiinquilino requiere ambos límites.
¿Qué debería recordar, olvidar, recalcular o volver a recuperar un agente de IA?
Los agentes de larga duración no deberían recordarlo todo. Este artículo proporciona un modelo práctico de ciclo de vida para decidir qué pertenece a la memoria duradera, qué se debería recuperar de nuevo, qué es más seguro recalcular y qué debería expirar o ser sustituido.
¿Qué es un arquitecto de plataforma de IA? Modelos, datos, entorno de ejecución, seguridad y operaciones
Un Arquitecto de Plataformas de IA diseña fundamentos de IA reutilizables a través de modelos, proveedores, recuperación, agentes, identidad, seguridad, evaluación, observabilidad y operaciones.
IA soberana: control de modelos, datos, infraestructura y dependencias
La IA soberana se trata del control efectivo sobre los modelos, los datos, la infraestructura, el software, las operaciones y las dependencias estratégicas, no simplemente de dónde está alojado un modelo de IA.
La GPU no es el producto: arquitectura de IA privada a prueba de futuro
La infraestructura de IA privada no debe diseñarse en torno a una sola GPU o un solo modelo. Un enfoque más resiliente combina GPUs de inferencia rápida, sistemas de IA ricos en memoria, nodos de IA física y modelos en la nube frontier opcionales detrás de una capa de enrutamiento consciente de las capacidades.
Fuente de verdad en los sistemas de IA: de dónde proviene realmente el conocimiento fiable
Una fuente de verdad define qué fuente es autoritativa para un hecho o estado específico. Aprende en qué se diferencia de RAG, la procedencia, la memoria, el contexto, las bases de datos vectoriales y los sistemas de registro.