IA en un entorno totalmente aislado

Qué significa realmente un entorno totalmente aislado

Un entorno totalmente aislado significa que la implementación no tiene ninguna ruta hacia internet. Ni llamadas a la API de un modelo, ni telemetría, ni verificación de licencia, ni descargas de paquetes en tiempo de ejecución, sin excepciones. Todo lo que el sistema necesita se replica de antemano dentro de tu red: imágenes de contenedores, pesos de modelos, modelos de embeddings y cada dependencia.

Esto es mucho más estricto que “en tus instalaciones” o “nube privada”, que normalmente conservan alguna salida a internet y a menudo dependen de ella. Es aislamiento de red total, y vale la pena el esfuerzo porque se puede demostrar: puedes mostrárselo a un auditor con una política de red, en lugar de describirlo con un diagrama.

La consecuencia para la arquitectura es que el aislamiento tiene que ser la primera restricción, no una configuración posterior. Casi todas las decisiones de diseño que siguen parten de ahí.

Orquestación: la base

Empieza por lo que programa y escala las cargas de trabajo. Los contenedores empaquetan cada componente en una imagen portable; Kubernetes, u OpenShift como su distribución empresarial reforzada, orquesta esas imágenes en tus propios servidores y GPU.

El detalle crítico es el registro de imágenes. Ejecutas un registro privado de contenedores dentro de tu red y replicas en él cada imagen, para que ningún pod intente nunca descargar nada de fuera. Suena trivial, y es donde fallan primero la mayoría de los intentos de aislamiento total, casi siempre por una imagen base o un sidecar que nadie sabía que estaba ahí. OpenShift se gana su lugar en entornos regulados porque usa por defecto contextos de seguridad restringidos, firma de imágenes integrada y políticas incorporadas, así que el endurecimiento que viene después parte de una mejor posición.

Servir modelos: pesos abiertos, dentro del clúster

Como no hay un modelo alojado al que llamar, tú mismo sirves modelos de pesos abiertos. Un servidor de inferencia como vLLM o Text Generation Inference de Hugging Face funciona como un servicio dentro del clúster, con programación de GPU, procesamiento de solicitudes por lotes y escalado automático.

Los pesos se cargan desde almacenamiento en tus instalaciones, preparado de antemano, y nunca se descargan en tiempo de ejecución. Dimensiona los pods de GPU según el modelo y la concurrencia que realmente necesitas, no según el modelo más grande disponible, y deja la inferencia accesible solo desde la red interna del clúster, para que nada se pueda alcanzar desde fuera de tu red, ni siquiera en teoría.

Recuperación que se queda dentro de tu red

Un modelo solo es tan útil como el material en el que puede basar sus respuestas, así que la pila de recuperación también tiene que estar dentro de tu red: una base de datos vectorial, un modelo de embeddings servido dentro del clúster y un pipeline de ingesta que indexa tus documentos.

Cada paso (embeddings, almacenamiento, consulta) ocurre dentro de tu red, así que el material de origen nunca se transmite a ningún lugar en ningún momento. Esa es la diferencia entre un chatbot genérico sin conexión, de utilidad limitada, y un sistema que puede responder a partir de material clasificado o regulado, que es la razón de ser de la implementación.

Endurecimiento: que se pueda defender, no solo que esté aislado

El aislamiento te lleva casi todo el camino. El endurecimiento es lo que te permite demostrarlo, punto por punto, a alguien cuyo trabajo es no creerte.

• Limita el tráfico este-oeste con políticas de red, para que solo se comuniquen los componentes que lo necesitan y un pod comprometido no pueda llegar al modelo ni al índice.
• Exige el origen verificado de las imágenes con firma y control de admisión, para que una imagen no verificada no pueda ejecutarse aunque llegue al registro.
• Guarda los secretos en un almacén sellado dentro del clúster, no en variables de entorno ni en manifiestos, donde terminan en registros y copias de seguridad.
• Activa un registro de auditoría completo para que cada inferencia y cada cambio de configuración se puedan atribuir a una identidad y a un momento.

La capa en la que se detienen la mayoría de las guías

Ejecutar el modelo es el problema de infraestructura, y es el más fácil. Gobernarlo no deja de ser necesario porque la red esté aislada. Un asistente en un entorno totalmente aislado puede igual responder con seguridad a partir de una recuperación débil, mostrar el material de una unidad de negocio a otra, dejar una credencial en un registro y dejarte sin forma de reconstruir lo que hizo en marzo pasado.

Por eso dentro de tu red se aplican los mismos controles que fuera de ella: un umbral mínimo de confianza por debajo del cual el sistema se abstiene en lugar de responder, aislamiento de documentos entre entornos o unidades de negocio, enmascaramiento de datos sensibles y un registro completo de las interacciones. NeuralSeek se implementa en el mismo clúster, con el mismo contenedor, y aporta esa capa sin una sola llamada saliente, incluida la posibilidad de comparar los modelos de pesos abiertos que preparaste con tu propio material en lugar de con un ranking público.

La infraestructura hace posible la IA en un entorno totalmente aislado. La gobernanza es lo que permite ponerla de verdad frente a alguien con seguridad.