Cómo aislar en la red un equipo de IA con datos sensibles

Escrito por

en

Una empresa decide correr IA sobre sus propios datos para no mandarlos afuera. Compra el equipo, lo enchufa en la sala de servidores, lo conecta al switch que estaba libre y empieza a usarlo. Técnicamente funciona. Desde el punto de vista de seguridad, acaba de crear un activo que concentra información sensible y que es alcanzable desde cualquier notebook de la oficina.

Este artículo trata de la parte que se salta más seguido: dónde va el equipo en la red.

Por qué un equipo de IA merece tratamiento aparte

Un servidor de IA con datos propios tiene tres características que lo hacen distinto de un servidor de archivos cualquiera:

  • Concentra información que estaba dispersa. Un índice vectorial o un modelo afinado sobre documentos internos reúne, en un solo lugar, contenido que antes vivía repartido en varios sistemas con permisos distintos. El impacto de un acceso indebido es mayor que la suma de las partes.
  • Su interfaz natural es una API abierta en la red. Los servidores de inferencia habituales exponen un endpoint HTTP. Muchos vienen sin autenticación por defecto, porque están pensados para uso local en un escritorio, no para una red corporativa.
  • Los modelos y los pesos son archivos copiables. Un modelo afinado sobre información propietaria es, en la práctica, esa información en otro formato. Quien pueda copiar el archivo se lleva el trabajo y los datos.

El principio: el equipo no vive en la red plana

La regla es la misma que se aplica a cualquier activo crítico, y no tiene nada de nuevo: segmento propio, tráfico permitido explícitamente, todo lo demás denegado.

En términos concretos, sobre un firewall de próxima generación como los FortiGate que implementamos en TECDEX, esto se traduce en una VLAN dedicada con su propia interfaz y políticas escritas en positivo.

Las cuatro direcciones del tráfico

Conviene pensarlo como cuatro flujos separados, cada uno con su propia decisión:

1. Quién entra al equipo (usuarios → IA)

Solo los grupos que deben usarlo, y solo a los puertos del servicio. Nada de acceso a toda la subred. Si el firewall soporta políticas por identidad de usuario en vez de por dirección IP, ese es el camino: sobrevive a los cambios de red y produce registros que se entienden en una auditoría.

La administración del equipo —SSH, consola— es un flujo aparte, restringido a IT y separado del acceso de los usuarios.

2. A qué llega el equipo hacia adentro (IA → red interna)

Es la dirección que más se olvida y la que más importa. Si el sistema indexa un repositorio documental, necesita llegar a ese repositorio: solo a ese, solo a ese puerto, y con una cuenta de servicio de permisos mínimos y de solo lectura donde sea posible.

Un equipo de IA que puede alcanzar toda la red interna es un excelente punto de partida para moverse lateralmente. Y a diferencia de un servidor tradicional, aquí hay una superficie extra: si el sistema procesa documentos que vienen de afuera, esos documentos pueden contener instrucciones dirigidas al modelo. El control de red es la contención de fondo cuando esa capa falla.

3. A qué sale el equipo hacia internet (IA → exterior)

El punto entero de tener el modelo adentro es que los datos no salgan. Esa promesa hay que hacerla cumplir en el firewall, no confiarla al software.

Salida denegada por defecto. Lo que se necesita —repositorios de paquetes, descarga de modelos, actualizaciones del sistema— se habilita explícitamente hacia destinos conocidos, y lo razonable es abrirlo en ventanas de mantención en vez de dejarlo permanentemente abierto. Un equipo que descarga modelos también puede subirlos.

4. Quién llega desde afuera (exterior → IA)

Nadie, directamente. Si hay que dar acceso remoto, va por VPN con doble factor, y esa VPN aterriza en el mismo control de acceso del punto 1, no en un atajo.

Lo que hay que registrar

Para que esto sea auditable y no solo prolijo, hacen falta tres registros: quién accedió al servicio y cuándo, qué intentos fueron bloqueados —especialmente salidas denegadas, que son la señal temprana de que algo no está haciendo lo que debería— y quién administró el equipo.

Con eso, cuando llegue la pregunta de auditoría «¿cómo garantizan que esta información no sale de la organización?», la respuesta es una política y un log, no una afirmación.

Los cinco errores que más vemos

  1. Instalar primero y segmentar después. Nunca hay un buen momento para cortar un servicio que ya se está usando, así que el «después» no llega.
  2. Dejar el endpoint de inferencia sin autenticación porque «está en la red interna».
  3. Permitir salida total a internet para que las actualizaciones no den problemas.
  4. Usar una cuenta de administrador para que el sistema indexe documentos, en vez de una cuenta de servicio con permisos mínimos.
  5. No registrar nada, y descubrirlo el día que hay que demostrar algo.

Preguntas frecuentes

¿Basta con una VLAN?

Una VLAN separa el dominio de difusión, pero sin políticas de firewall entre segmentos el tráfico igual pasa. La separación útil es VLAN más reglas explícitas de qué puede hablar con qué.

¿Y si el equipo está sobre el escritorio de alguien?

Es el caso típico de un DGX Spark, y no cambia el principio. Si procesa información sensible, va en un puerto asignado a su propio segmento, aunque físicamente esté bajo un escritorio. Lo que define el tratamiento es el dato, no el mueble.

¿Necesito un firewall nuevo para esto?

No necesariamente. Si ya tienes un firewall de próxima generación con capacidad para VLANs, políticas por identidad y registro centralizado, probablemente alcanza. Lo que suele faltar no es equipamiento, es el diseño y las reglas escritas.

¿Esto aplica también a un servidor GPU en rack?

Aplica igual, y con más razón. En un servidor GPU compartido entre varias áreas hay que resolver además la separación entre inquilinos: quién ve qué modelos y qué datos dentro del mismo equipo.

Siguiente paso

Si estás evaluando un equipo de IA y quieres que la red quede resuelta desde el diseño y no como parche, TECDEX hace las dos cosas: la infraestructura de seguridad y el equipamiento de cómputo. Conviene conversarlo antes de comprar: solicita una asesoría.

El contexto normativo de esta decisión está en IA dentro de casa: cuando los datos no pueden salir.