- La IA en local no es segura por defecto: requiere segmentación de red, hardening y control de accesos.
- Es clave limitar el tráfico con VLANs y firewall, registrar interacciones y aplicar políticas DLP.
- Existen amenazas específicas de modelos locales como agentes durmientes y modelos trampa.
- Un enfoque en capas, alineado con RGPD y buenas prácticas de ciberseguridad, reduce drásticamente el riesgo.
La adopción de modelos de inteligența artificială locală se ha disparado en empresas y profesionales que manejan información delicada: datos personales, expedientes médicos, documentación legal, propiedad intelectual… Muchos piensan que, por el simple hecho de ejecutar la IA en sus propios servidores o equipos, la privacidad está garantizada. La realidad es bastante más compleja: un despliegue mal diseñado puede convertirse en una puerta de entrada a ciberataques o en una máquina de filtrar datos sin que nadie se dé cuenta.
Si quieres aprovechar al máximo la IA sin poner en riesgo tu negocio, es clave entender que la seguridad al usar IA en local no consiste solo en “quitarle internet” al modelo. Hay que pensar en arquitectura de red, întărirea sistemelor, control de accesos, cumplimiento normativo (como RGPD), monitorización continua y defensa frente a amenazas muy específicas de los modelos, desde agentes durmientes hasta modelos trampa entrenados para exfiltrar información.
Por qué la IA en local no es automáticamente segura
La IA ejecutada en servidores propios ofrece ventajas claras: más control, más personalización y, en teoría, más privacidad. Pero esos beneficios llevan asociados riesgos que muchas veces se pasan por alto, sobre todo cuando se reutilizan scripts o contenedores sin revisar la seguridad de contenedores ni su comportamiento real en la red.
Un modelo de lenguaje o un asistente de IA puede tener acceso a documentación interna, bases de datos con información personal, repositorios de código o informes estratégicos. Si el sistema que lo ejecuta está mal segmentado, si el firewall está abierto de más o si el propio modelo tiene comportamientos ocultos, esa IA que creías “offline” puede terminar enviando datos sensibles al exterior o exponiéndolos a usuarios no autorizados.
Además, los modelos locales dependen de un ecosistema de software de inferencia, librerías y servidores de aplicación (FastAPI, Uvicorn, frameworks web, runtimes de GPU, etc.) que, como cualquier otro software, requiere evaluar la seguridad del software y tiene vulnerabilidades, bugs y problemas de configuración. No actualizar estos componentes, o no aplicar un hardening adecuado, deja un blanco perfecto para atacantes.
Por si fuera poco, hoy en día es técnicamente posible que un modelo haya sido modificado para introducir comportamente rău intenționate que solo se activan bajo ciertas condiciones: prompts concretos, nombres de proyectos, fechas o incluso patrones de tráfico. Por eso, “bajar un modelo de internet y montarlo en local” sin más controles es una apuesta muy arriesgada.
Arquitectura segura para un chatbot de IA en la red corporativa
Un caz tipic este cel al unui chatbot de IA desplegado en la propia empresa para consultar documentación interna, gestionar un gestor documental o asistir a empleados. Para que este sistema no se convierta en un coladero de datos, hay que diseñar una arquitectura de red y seguridad específicamente pensada para aislarlo del exterior y controlar quién se conecta y qué puede hacer.
Imagina una empresa que monta un chatbot basado en un modelo como Llama 3 o DeepSeek en un servidor local. Este servidor procesa contratos, expedientes de clientes, políticas internas y datos de empleados. Si su tráfico no se segmenta ni se filtra, basta con un equipo interno infectado o una mala configuración de firewall para que ese bot acabe exponiendo información crítica.
La propuesta más robusta pasa por ubicar el servidor de IA en una VLAN específica y aislada, sin acceso directo a internet, y controlar todas las comunicaciones que entren y salgan de esa VLAN mediante un cortafuegos central. Además, el acceso de usuarios debe ir siempre autenticado contra un Directorio Activo (AD/LDAP) o sistema equivalente, para tener trazabilidad de quién hace qué.
Este enfoque de “IA en una burbuja” permite que el chatbot solo hable con los sistemas internos estrictamente necesarios: la base de datos que indexa la documentación, el servidor de autenticación y las estaciones de trabajo desde las que se conectan los empleados. Todo lo demás, incluida cualquier salida hacia internet, debe estar bloqueado por defecto.
Segmentación de red y VLANs: poner barreras físicas a la IA
La segmentación de red mediante VLANs es una de las medidas más efectivas para limitarea suprafeței de atac. En lugar de tener toda la empresa en una red plana, se separan las funciones críticas en diferentes segmentos con reglas de acceso muy precisas.
Un diseño de ejemplo podría ser el siguiente: una VLAN de usuarios donde se ubican los equipos de trabajo habituales; una VLAN de servidores de IA y bases de datos sin conectividad a internet; una VLAN de administración desde donde solo el personal técnico puede gestionar la infraestructura; y, si hace falta, una VLAN pentru oaspeți sin acceso al chatbot ni a recursos internos sensibles.
En términos de direccionamiento IP, cada VLAN opera con un rango distinto (por ejemplo, 192.168.10.0/24 para usuarios, 192.168.20.0/24 para servidores de IA, 192.168.30.0/24 para administración y 192.168.40.0/24 para invitados). El servidor del chatbot podría residir en una dirección como 192.168.20.10, la base de datos en 192.168.20.20 y el controlador de dominio en 192.168.30.10, mientras que los usuarios internos se sitúan en el segmento 192.168.10.0/24.
Con esta segmentación, un portátil infectado conectado a la red de invitados, por ejemplo, no podrá llegar al servidor de IA ni aunque conozca su IP. Y un usuario interno necesitará tanto estar en la VLAN correcta como autenticarse con sus credenciales para obtener acceso. De esta forma, incluso si un equipo es comprometido, el atacante se encontrará con múltiples capas de aislamiento antes de llegar a la IA y a los datos que maneja.
Puertos, firewall y reglas de tráfico: qué se permite y qué se bloquea
Una vez definida la segmentación, el siguiente paso es concretar qué porturi TCP/IP se van a permitir entre cada componente y bloquear todo lo demás. El principio es sencillo: solo se abre lo imprescindible para que la solución funcione.
Por ejemplo, los usuarios en la VLAN 10 pueden acceder al chatbot en la VLAN 20 a través del puerto 5000, donde suele exponerse una API (FastAPI, Uvicorn u otra tecnología similar). El servidor de IA se comunica con su base de datos en la misma VLAN mediante el puerto 5432, típico de PostgreSQL. Para autenticar usuarios, el chatbot se conecta con el Directorio Activo en la VLAN 30 usando el puerto 389 (LDAP).
Los administradores, únicamente desde la VLAN 30, pueden abrir sesiones SSH al servidor de IA a través del puerto 22, pero este acceso debe estar restringido por origen y autenticado con claves robustas. Cualquier otro tipo de tráfico entre VLANs se deniega, y especialmente se bloquea toda salida del servidor de IA hacia internet, de forma que, aunque el modelo o alguna herramienta intentase “llamar a casa”, el firewall lo impediría.
Las reglas básicas a aplicar serían: negar por defecto todas las conexiones entrantes desde el exterior hacia la red interna; impedir que el servidor del chatbot establezca conexiones de salida a internet; permitir solo las comunicaciones internas estrictamente necesarias entre VLANs; y registrar todos los accesos relevantes en el firewall o en una solución SIEM para poder auditar incidentes.
Control de accesos: Directorio Activo, roles y autenticación robusta
El aislamiento de red se complementa con un control estricto de quién puede interactuar con la IA y qué tipo de información puede solicitar. Aquí entra en juego el Directorio Activo o un servicio LDAP similar, que centraliza la autenticación y la autorización.
La idea es que cada empleado se identifique en el chatbot con sus credenciales corporativas, y que el sistema consulte al directorio para comprobar a qué grupos pertenece. Según esos grupos (por ejemplo, Recursos Humanos, Soporte, Dirección, Invitados), el chatbot limitará las consultas y acciones permitidas, de forma que un empleado de atención al cliente no pueda acceder a datos de nóminas o a reportes financieros internos.
Además, resulta muy recomendable aplicar una autentificare multifactor (MFA) al menos para los perfiles con más privilegios y para aquellos que puedan manejar información muy sensible. También conviene aplicar políticas de mínimo privilegio: dar a cada usuario solo el nivel de acceso imprescindible para su rol.
En paralelo, se pueden definir roles específicos dentro de la propia aplicación de IA, de manera que el modelo sepa qué tipo de respuestas puede ofrecer a cada grupo. Un ejemplo: el grupo de Recursos Humanos puede preguntar por políticas internas de vacaciones o por procedimientos de contratación; el equipo técnico por manuales y documentación de sistemas; la gerencia por paneles de indicadores internos agregados; y los usuarios invitados quedan simplemente sin acceso al chatbot.
Monitorización, registros y respuesta ante actividad sospechosa
Por muy bien diseñado que esté el entorno, siempre existe la posibilidad de que alguien intente abusar del sistema o que aparezca un comportamiento anómalo. Por eso es imprescindible contar con una monitorización continua de las interacciones con la IA y con un mecanismo de respuesta automatizada.
Lo ideal es registrar en detalle cada conversación o consulta: quién la ha realizado (usuario autenticado), desde qué dispositivo o IP, qué ha preguntado, qué ha respondido el modelo y en qué momento. Estos registros se envían a una plataforma SIEM como Splunk, ELK Stack, Wazuh o Graylog, que permite analizar grandes volúmenes de logs y detectar patrones sospechosos.
Entre los comportamientos a vigilar destacan: consultas repetitivas sobre temas extremadamente sensibles en cortos periodos; intentos reiterados de pedir datos personales concretos (números de cuenta, DNIs, contraseñas…); accesos fuera de horario laboral desde equipos poco habituales; o cambios súbitos en el tipo de preguntas de un usuario que antes tenía un uso normal.
Cuando se detecta una anomalía, el sistema debería generar de inmediato una alerta a los responsables de seguridad y, en función de la gravedad, desencadenar acciones automáticas: mostrar mensajes de advertencia al usuario, solicitar una autenticación extra, bloquear temporalmente el acceso o escalar el incidente a RRHH o al departamento legal si parece un intento deliberado de exfiltración.
Prevención de fuga de datos (DLP) aplicada a modelos de IA
Una de las mayores preocupaciones con la IA en local es que el propio modelo acabe devolviendo en sus respuestas datos que nunca deberían salir de ciertos sistemas: datos financieros, información personal identificable o secretos de negocio. Para evitarlo, se pueden aplicar políticas de Data Loss Prevention (DLP) directamente sobre las salidas del modelo.
Estas políticas consisten en analizar las respuestas generadas por la IA antes de mostrarlas al usuario. Si se detectan patrones sensibles (por ejemplo, formatos típicos de tarjetas de crédito, DNIs, cuentas bancarias, direcciones postales completas, contraseñas o tokens), la respuesta puede bloquearse, recortarse o desensibilizarse, sustituyendo los valores reales por marcadores genéricos.
También es útil clasificar previamente la información interna por niveles de sensibilidad y aplicar reglas de seguridad esenciales para carpetas compartidas y etiquetar los documentos que alimentan al modelo. Así, el sistema de IA sabrá qué contenidos puede manipular libremente y cuáles requieren una verificación adicional de permisos antes de ser mostrados. Esto reduce las probabilidades de que el asistente proporcione una información que, aunque técnicamente tenga en su base de conocimiento, el usuario que pregunta no está autorizado a ver.
Otro enfoque complementario es diseñar las plantillas de respuesta del chatbot de forma que, ante ciertas peticiones (por ejemplo, “dame el número de cuenta de X” o “dime la contraseña del servidor Y”), la IA tenga instrucciones claras de contestar con un “no puedo proporcionarte esa información” o con mensajes predefinidos que refuercen la política interna de protección de datos.
Amenazas específicas de los modelos locales: agentes durmientes y modelos trampa
Más allá de la infraestructura, hay que asumir que el propio modelo puede ser una fuente de riesgo en sí mismo. Ya se ha demostrado la posibilidad de crear LLMs con comportamientos ocultos que se activan solo ante ciertos estímulos. Estos llamados “agentes durmientes” pueden, por ejemplo, generar código con vulnerabilidades discretas cuando detectan nombres de proyectos concretos, o suavizar determinadas alertas para que pasen desapercibidas.
Si tú entrenas o ajustas un modelo con datos internos (fine-tuning), existe además el riesgo de que, si el modelo original fue manipulado, pueda aprovechar ese proceso para memorizar fragmentos de información sensible y reproducirlos luego cuando se le hacen preguntas adecuadas. Existen investigaciones sobre modelos trampa diseñados para recuperar parte de los datos del fine-tuning o de las fuentes utilizadas en sistemas de RAG (Retrieval Augmented Generation).
En entornos donde se utiliza RAG, es especialmente importante comprobar que el modelo no pueda reconstruir y soltar literalmente documentos completos o datos extremadamente delicados a partir de los embeddings almacenados. Algunas técnicas de ataque buscan precisamente extraer, a base de prompts elaborados, grandes bloques de texto pertenecientes a la base de conocimiento de la empresa.
Por eso, al desplegar IA en local, conviene auditar los modelos que se van a usar, revisar su procedencia, estudiar cómo han sido entrenados y, si es posible, analizar su comportamiento en escenarios controlados para detectar anomalías. En ocasiones, puede ser preferible utilizar modelos de código abierto bien auditados por la comunidad antes que binarios opacos de origen dudoso.
Riesgos de herramientas y capacidad de ejecutar código
Otra fuente de riesgo viene de la tendencia a dotar a los modelos de lenguaje de capacidades extra mediante herramientas: acceso a bases de datos, ejecución de Cod Python, llamadas HTTP, gestión de ficheros, etc. Estas funciones son muy potentes para automatizar tareas, pero también pueden ser un arma de doble filo.
Si el modelo puede ejecutar código o invocar APIs sin restricciones claras, nada impide que, bajo ciertas condiciones, use esa capacidad para enviar información al exterior, abrir conexiones no autorizadas, descargar scripts maliciosos o modificar configuraciones del sistema. Y si a eso le unimos la posibilidad de agentes durmientes, el escenario se complica aún más.
La mitigación pasa por definir con mucha precisión qué herramientas puede usar la IA, en qué contextos y con qué parámetros. Los entornos de ejecución de código deben estar aislados (sandbox), con permisos limitados sobre el sistema de ficheros y sin acceso directo a internet. Además, todas las llamadas a herramientas críticas deberían quedar registradas y, en muchos casos, requerir confirmación explícita de un humano.
Además, conviene revisar el tráfico de red “inesperado” del servidor que ejecuta la IA: si un modelo supuestamente local empieza a generar peticiones salientes que no estaban contempladas, puede ser una señal clara de que algo no va bien, ya sea un malware tradicional o una lógica oculta dentro del propio asistente.
Privacidad, RGPD y cumplimiento normativo con IA en local
Una de las grandes ventajas de la IA en local es que facilita el cumplimiento del RGPD y de otras leyes de protección de datos, siempre que se diseñe correctamente. Al mantener toda la información y el procesamiento dentro de tu propia infraestructura, eliminas gran parte del riesgo asociado a transferencias internacionales, subencargados externos y servicios en la nube.
Aun así, esto no te exime de cumplir con principios como la minimización de datos, la limitación de la finalidad, la seguridad desde el diseño (privacy by design y security by design) o los derechos de acceso, rectificación y supresión. El hecho de que la IA sea local solo facilita el control, pero no te libra de responsabilidades.
Medidas como la anonimización o pseudonimización de los conjuntos de entrenamiento, el cifrado de datos en reposo y en tránsito, el uso de contraseñas robustas, MFA, concienciación del personal y audituri periodice de securitate son igual de obligatorias en entornos locales que en la nube. De hecho, muchas brechas vienen más de malas prácticas internas que de fallos del proveedor.
También es importante verificar que toda la cadena de suministro (fabricantes, integradores, consultoras, proveedores de hardware) mantiene estándares de seguridad y privacidad comparables. Un fallo en cualquiera de estos eslabones puede terminar afectando a tu despliegue local de IA, tanto a nivel técnico como de cumplimiento legal.
IA para defender la propia IA: seguridad en capas
El panorama de ciberamenazas es cada vez más complejo, con superficies de ataque que se extienden a la nube, entornos híbridos y ahora también a infraestructuras de IA locales. Los atacantes, además, ya están utilizando herramientas de inteligencia artificial para descubrir vulnerabilidades, automatizar campañas de phishing y mejorar sus ataques.
En este contexto, resulta lógico apoyarse también en AI defensiv para proteger los sistemas. Modelos especializados en ciberseguridad pueden ayudar a identificar comportamientos anómalos en tiempo real, clasificar eventos, priorizar alertas y proponer respuestas automáticas. Esto es especialmente útil en organizaciones que sufren escasez de personal de seguridad.
La combinación de monitorización continua, análisis avanzado de logs y sistemas de respuesta automática permite reducir de forma notable el tiempo de detección y contención de incidentes. Diversos estudios han mostrado que las empresas que no invierten en seguridad basada en IA sufren brechas más costosas que aquellas que sí lo hacen, incluso cuando se trata de despliegues locales.
Eso sí, la IA para ciberseguridad no es una varita mágica. Hay que integrarla en una estrategia de defensa en profundidad: segmentación de red, hardening de sistemas, políticas de acceso, cifrado, formación de empleados y revisiones periódicas. Solo así se puede construir un entorno de IA local realmente blindado frente a amenazas externas e internas.
En última instancia, usar IA en local de forma segura implica ir mucho más allá de instalar un modelo en un servidor sin conexión a internet: exige diseñar una arquitectura cerrada y segmentada, controlar quién entra y qué puede ver, vigilar constantemente lo que hace el sistema, aplicar políticas estrictas de protección de datos y no olvidar que los propios modelos pueden ser un vector de ataque si no se auditan y gestionan bien; combinando prevención, detección y respuesta proactiva es como se consigue aprovechar todo el potencial de la inteligencia artificial sin poner en juego la privacidad ni la reputación de la organización.
Scriitor pasionat despre lumea octeților și a tehnologiei în general. Îmi place să îmi împărtășesc cunoștințele prin scriere și asta voi face în acest blog, să vă arăt toate cele mai interesante lucruri despre gadgeturi, software, hardware, tendințe tehnologice și multe altele. Scopul meu este să vă ajut să navigați în lumea digitală într-un mod simplu și distractiv.