La IA se ejecuta en su servidor. ¿A dónde se conecta?
Ha trasladado su sistema de IA a un servidor Linux propio. El modelo se ejecuta en su tarjeta gráfica, los documentos se guardan en una base de datos bajo su control y el acceso al sistema está protegido mediante autenticación.
Entonces surge una pregunta sencilla: ¿a qué servicios externos se conectó este sistema ayer?
La respuesta no siempre está disponible.
Un sistema de IA puede incluir un servidor de modelos, una interfaz de chat, un componente para procesar documentos, una plataforma de automatización y herramientas que acceden a servicios externos. Cada componente tiene su propia configuración y puede generar conexiones de red.
Ejecutar el modelo en su servidor deja claro dónde se realiza su procesamiento. Para saber a dónde puede llegar la información, también hay que conocer la actividad del resto del sistema.
¿Qué ocurre antes de llegar al modelo?
Tomemos como ejemplo un asistente de análisis de documentos basado en un modelo de lenguaje local. Un usuario sube un archivo PDF y pide un resumen.
Según la configuración, el sistema puede enviar páginas escaneadas a un servicio externo de reconocimiento de texto, usar un servicio en la nube para crear representaciones numéricas del contenido —Embeddings— o enviar una consulta a un motor de búsqueda. El modelo puede seguir generando la respuesta final en su servidor.
Este es un ejemplo de cómo podría estar construido un sistema de este tipo. La consecuencia es sencilla: antes de que el documento llegue al modelo local, otros componentes pueden procesarlo o enviar información extraída de él a otros destinos.
A veces, estas opciones se detallan en la documentación de las propias herramientas. Por ejemplo, la documentación de Ollama indica que, cuando el modelo se ejecuta localmente, Ollama no ve sus solicitudes ni sus datos. Al mismo tiempo, el software también ofrece modelos en la nube y búsqueda web, y permite desactivar las funciones en la nube desde la configuración.
De forma similar, la documentación de n8n describe la recopilación de datos de uso y funcionamiento, activada por defecto incluso en instalaciones propias, y explica cómo desactivarla. El envío de datos de uso, el procesamiento en la nube y el acceso a un servicio externo dentro de un proceso de automatización son usos distintos. Cada uno requiere una revisión por separado.
Conviene saber cuáles de estas opciones están activas en su sistema y si se ajustan al uso que tenía previsto.
Las conexiones salientes también deben estar bajo su control
El tráfico saliente, o Egress, es el tráfico que sale del servidor o de un servicio que se ejecuta en él hacia otro destino.
La política de acceso entrante determina quién puede conectarse a su servicio. También hay que decidir a qué servicios externos puede conectarse ese servicio. Incluso un sistema con acceso restringido puede iniciar conexiones hacia el exterior si la configuración de red lo permite.
En el caso de los agentes de IA, esta cuestión tiene una implicación adicional. Un agente capaz de leer archivos, acceder a direcciones de red o ejecutar comandos puede afectar a sistemas e información más allá de la propia conversación. El alcance del daño que podría causar una acción incorrecta depende, entre otras cosas, de sus permisos y de los destinos a los que puede acceder.
Las directrices de OWASP sobre permisos y capacidades excesivos en agentes de IA explican cómo conceder capacidades innecesarias para la tarea puede aumentar el riesgo.
Las restricciones de red pueden reducir ese margen de actuación. También se necesitan controles de permisos en la aplicación, permisos limitados para las claves de acceso y aprobación para las acciones sensibles. Esto es especialmente importante porque incluso un servicio externo autorizado puede usarse para transferir información sensible.
El tráfico total del servidor solo cuenta una parte de la historia
Supongamos que, durante una hora, su servidor se conectó a un servicio de almacenamiento, a un repositorio de descarga de modelos y a una dirección HTTPS que no reconoce.
El volumen total de tráfico no le dirá qué componente creó cada conexión. Cuando se puede asociar una conexión a un servicio concreto, la revisión resulta más precisa: una copia de seguridad programada que accede a un servicio de almacenamiento es una cosa; un asistente de análisis de documentos que accede a ese mismo destino por primera vez requiere otra explicación.
Una revisión útil debe responder a cuatro preguntas:
- ¿Qué servicio creó la conexión? Es importante identificar el proceso o contenedor responsable.
- ¿A dónde se conectó? ¿Cuál es la dirección de destino y qué información contrastada hay sobre su función?
- ¿Cuánta información se envió? Es importante distinguir entre la información enviada al exterior y la recibida.
- ¿Cuándo se observó el destino por primera vez? ¿Fue después de una actualización, un cambio de configuración o una tarea programada?
La dirección del tráfico es especialmente importante al examinar su volumen. Descargar un modelo grande supone principalmente recibir información en el servidor. Subir una copia de seguridad supone principalmente enviar información al exterior. Ambas operaciones pueden generar mucho tráfico, pero su significado es distinto.
Una transferencia pequeña también puede justificar una revisión. Una clave de API o un documento confidencial breve no ocupan gigabytes.
¿Cómo se interpretan los resultados?
El nombre de un proveedor conocido puede ayudar a entender una conexión, pero las infraestructuras compartidas dan servicio a muchos clientes. Una dirección IP por sí sola no siempre revela a qué cuenta, recurso o entidad concreta se envió la información.
Una conexión recurrente tampoco es necesariamente una conexión que haya autorizado. Un componente con una configuración no deseada puede funcionar durante todo el periodo de seguimiento y parecer parte de la actividad habitual.
Los datos de red también tienen límites. La dirección de destino, la hora de conexión y la cantidad de bytes enviados no revelan el contenido de una solicitud cifrada. Para determinar si se ha expuesto información sensible, puede ser necesario revisar también los registros de la aplicación, su configuración u otras fuentes de información.
También es importante saber qué ha podido observar el sistema de seguimiento. Si la monitorización no estuvo activa durante parte del tiempo, faltará información sobre ese periodo. Cuando el seguimiento se basa en muestreos, algunas conexiones breves pueden pasar inadvertidas. Las conclusiones del informe deben ajustarse a su cobertura.
Revisar, entender y después cambiar
Puede empezar por un servicio que gestione información sensible. Defina a qué servicios externos debería conectarse y examine su actividad durante un periodo que incluya el trabajo habitual, las tareas programadas y el mantenimiento.
Revise los destinos para los que no tenga una explicación clara. Si una conexión no deseada se debe a una opción que no necesita, empiece por revisar la configuración de esa opción. Si hace falta una restricción de red, aplíquela de forma específica al servicio y al destino correspondientes. Compruebe qué efecto tendrá y asegúrese de poder retirarla fácilmente.
Conviene repetir la revisión después de añadir herramientas o cambiar las conexiones a servicios externos. Las necesidades de red del sistema pueden cambiar aunque el modelo local siga siendo exactamente el mismo.
¿Cómo ayuda nuDefend?
nuDefend permite realizar esta revisión en el propio servidor Linux. Identifica las herramientas de IA compatibles y muestra los destinos de conexión observados para ellas, el volumen de tráfico enviado y el momento en que se vio cada destino por primera vez. Cuando se identifica el destino, también se muestra información que ayuda a entender su función.
En un servidor con nuDefend instalado, puede empezar con los siguientes comandos:
sudo nudefend workloads
sudo nudefend egress
sudo nudefend egress review Ollama
El último comando es un ejemplo de revisión de un servicio Ollama identificado en el sistema. Estos comandos muestran los resultados y no modifican la política de red.
Si decide restringir un destino concreto, nuDefend permite bloquearlo para el servicio correspondiente, con una vista previa del efecto del bloqueo y la opción de retirarlo. Este control funciona junto con el bloqueo automático de direcciones maliciosas conocidas.
El seguimiento de las herramientas en contenedores se basa en muestreos, por lo que algunas conexiones breves pueden no registrarse. Los periodos sin cobertura se indican de forma explícita, y el volumen de tráfico por sí solo no se clasifica como una filtración de información. Los informes de actividad y el historial de tráfico se guardan en su servidor. Encontrará detalles sobre las funciones y la cobertura en la documentación.
Ejecutar un sistema de IA en un servidor propio le da control sobre la infraestructura. El seguimiento de las conexiones salientes ayuda a ejercer ese control y a tomar decisiones fundamentadas sobre los destinos a los que el sistema puede transferir información.
Consulte a dónde se conectan sus herramientas de IA con nuDefend