IA generativa para analistas de seguridad: qué aporta y dónde se queda corta
Lo esencial, en breve
- Un modelo generativo rinde donde el volumen es alto y el contexto se repite: líneas de registro, código fuente, salidas de herramientas.
- En nuestra investigación, varios LLM combinados con MobSF y Semgrep clasificaron vulnerabilidades de aplicaciones Android según el OWASP Mobile Top 10.
- Sobre registros de Suricata y Sysmon, el tiempo hasta un hallazgo calificado bajó de forma clara; los ataques muy ofuscados se colaron igual.
- Tres límites que se tratan antes del primer piloto, no después: los falsos positivos, el coste por volumen y la salida de tus datos hacia un tercero.
- Pegar un extracto de registro o un informe de auditoría en un modelo en línea es una cuestión de encargo del tratamiento —art. 28 del RGPD—, no un detalle de herramienta.
- La conclusión no se ha movido: el modelo absorbe el volumen, el analista conserva el criterio.
La inteligencia artificial ha dejado de ser una promesa en el trabajo de seguridad: es una herramienta más encima de la mesa. Nuestra investigación, publicada con el título Using Generative AI Models to Support Cybersecurity Analysts, se ocupó de una pregunta bastante concreta: ¿qué gana de verdad un flujo de análisis cuando se le añade un gran modelo de lenguaje (LLM), y dónde deja de servir?
Este artículo resume el montaje, los resultados y, sobre todo, los límites. Y añade lo que la versión original no podía tratar: qué pasa en España con los registros y los informes que alguien decide pegar en un modelo alojado por un tercero. Es la segunda pregunta que aparece en cualquier comité, justo detrás de «¿esto funciona?».
Qué cambia la IA generativa en el trabajo del analista
Quien analiza seguridad trabaja sobre una masa de datos que ninguna persona recorre entera: registros de eventos, configuraciones, resultados de un análisis de vulnerabilidades, análisis de malware y la salida de una docena de herramientas que se solapan a medias. Recoger y normalizar ya se hace bien. Interpretar sigue siendo manual, y ahí se van las horas.
El modelo generativo mueve esa proporción en cuatro puntos:
- desbrozar los registros de seguridad para que las anomalías salgan antes,
- describir y clasificar con más eficacia las vulnerabilidades halladas en una aplicación,
- apoyar un test de intrusión sopesando de antemano qué caminos de explotación son plausibles,
- añadir contexto a partir de marcos ya asentados como el OWASP Mobile Top 10 y MITRE ATT&CK.
A esa lista le falta un verbo: sustituir. Un modelo que clasifica una línea de registro no decide que haya incidente. Formula una propuesta con su justificación, y esa propuesta vale exactamente lo que valga quien la contraste con el entorno real.
Nuestra investigación: dos casos concretos
El estudio se centró en dos usos donde un LLM puede quitarle trabajo medible a un especialista.
1. Detectar vulnerabilidades en aplicaciones Android
Montamos una cadena que combina LLM con herramientas de seguridad ya asentadas —MobSF (Mobile Security Framework) y Semgrep— para examinar aplicaciones Android. En lugar de fiarlo todo al análisis estático, aprovechamos el análisis contextual del modelo para:
- recorrer el código fuente de la aplicación,
- localizar los fallos de seguridad con reglas definidas de antemano,
- clasificar los hallazgos según el OWASP Mobile Top 10.
Hallazgo principal: los LLM mejoraron a la vez la velocidad y la precisión de la detección, y a la vez introdujeron falsos positivos. La verificación humana siguió siendo necesaria en todos los casos.
Coincide con lo que vemos en encargos reales de pentesting de aplicaciones móviles: una herramienta que devuelve doscientos hallazgos vale menos que alguien que se queda con doce y sabe explicar, uno por uno, qué haría un atacante con cada uno. Nuestro trabajo con las metodologías OWASP está construido sobre esa reducción.
2. Analizar registros de seguridad para calificar un incidente
El segundo caso trabajó sobre registros de red y de sistema procedentes de Suricata (IDS/IPS) y de Sysmon (monitorización de Windows). El objetivo era correlacionar alertas con amenazas reales, apartar parte del ruido y enganchar los eventos retenidos al marco MITRE ATT&CK.
Hallazgo principal: el análisis asistido acortó de forma notable el tiempo necesario para identificar y clasificar una amenaza, pero los modelos tropezaron con los ataques muy ofuscados o construidos en varias etapas.
Conviene medir qué contienen esos datos. Un registro de Sysmon expone por construcción elementos identificativos: nombres de cuenta, nombres de equipo, marcas de tiempo. Quien le aplica un modelo está tratando datos personales. Por eso mantenemos una línea constante, en investigación y en encargo: los resultados se entregan de forma agregada y no se identifica ni se evalúa a nadie individualmente. Un análisis de registros comprueba si tu detección y tu respuesta funcionan, no si alguien de tu plantilla hizo clic donde no debía.
Lo que el modelo hace bien y lo que se le escapa
La investigación abrió espacio, no firmó un cheque en blanco. Hay tres límites que conviene tratar antes del primer piloto.
| Límite | Qué sale mal | Qué pones enfrente |
|---|---|---|
| Falsos positivos | El modelo interpreta de través una línea de registro o un fragmento de código y genera alertas sin objeto; o, lo que molesta más, clasifica como ruido un evento real | Una verificación humana sobre cada hallazgo y una medición de acierto por categoría, no una media general que lo tapa todo |
| Coste por volumen | Pasar grandes conjuntos de datos por un LLM sale caro, y los volúmenes de registro crecen más deprisa que los presupuestos | Un filtrado previo con reglas clásicas, de modo que el modelo solo intervenga sobre lo que queda |
| Tratamiento de datos y ataques contra el modelo | Los registros y el código salen de tu entorno; además, la prompt injection y el envenenamiento de los datos de entrenamiento son técnicas de ataque reales contra el propio modelo | Un encargo del tratamiento por escrito y una minimización efectiva, y después probar la integración como lo que es: superficie de exposición |
La última fila no es teórica. En cuanto un modelo accede a tus datos o dispara una acción en tu entorno, se convierte en un componente con permisos, o sea, en algo que se prueba. Es un servicio aparte: el pentesting de integraciones de IA y LLM.
No pegues tus registros ni tus informes en un modelo ajeno
Es el punto por el que primero te van a llamar la atención y, a la vez, el más fácil de resolver si se aborda al principio.
Cuando envías un extracto de registro, un fichero de configuración, código de un cliente o un informe de test de intrusión a un servicio de modelo en línea, no estás «haciendo una consulta». Estás comunicando datos a un tercero que los trata por cuenta tuya. Si ahí hay información personal —y un registro de autenticación casi siempre la lleva—, ese tercero actúa como encargado del tratamiento en el sentido del art. 28 del RGPD. Tres consecuencias prácticas:
- Hace falta un contrato por escrito. El art. 28.3 exige que el tratamiento por cuenta del responsable se rija por un contrato que fije el objeto, la duración, la naturaleza y la finalidad del tratamiento, el tipo de datos personales y las obligaciones del encargado. Unas condiciones de uso aceptadas con un clic rara vez cumplen esa función; y cuando el proveedor sí ofrece un anexo de tratamiento de datos, alguien de tu organización tiene que haberlo firmado.
- Un subencargado no se contrata en silencio. Si tú mismo actúas como encargado de tu cliente —que es la posición de cualquier empresa de auditoría—, el art. 28.2 te impide recurrir a otro encargado sin autorización previa por escrito del responsable. Meter a un proveedor de modelos en mitad de un encargo sin decírselo al cliente es exactamente eso.
- La minimización también alcanza al portapapeles. El principio del art. 5.1.c) del RGPD no hace excepciones con las herramientas de apoyo. Si el modelo no necesita los nombres de cuenta para reconocer un patrón de ataque, esos nombres no pintan nada en la petición.
Con el informe de auditoría el problema es el mismo y trae uno añadido: describe debilidades explotables en un cliente identificable. Ahí el secreto empresarial de la Ley 1/2019 y el compromiso de confidencialidad firmado antes del encargo zanjan la cuestión por sí solos, al margen del RGPD.
La regla que aplicamos se enuncia en una línea y se puede comprobar: ningún dato de cliente, ningún extracto de informe y ninguna evidencia se envían a un servicio de IA de terceros. Los usos generativos que conservamos se apoyan en contenido público, en juegos de prueba que generamos nosotros, o se ejecutan sobre una instancia que controlamos. Haxoris es una empresa establecida en la Unión Europea: los datos de auditoría se quedan en la Unión, sin transferencia internacional del capítulo V del RGPD, y la lista de encargados se comunica antes de empezar, no después.
El marco aplicable en España
La IA no crea una obligación nueva que sustituya a las anteriores. Lo que cambia es el recorrido de tus datos y la lista de preguntas que te van a hacer un cliente o quien te audite.
El único texto europeo que nombra de forma expresa el control periódico es el art. 32.1.d) del RGPD: cuando proceda, las medidas de seguridad incluyen «un proceso de verificación, evaluación y valoración regulares de la eficacia de las medidas técnicas y organizativas para garantizar la seguridad del tratamiento». Fíjate en la redacción: lo que se pide es acreditar eficacia. Desplegar una herramienta de IA no acredita nada; comprobar lo que produce, sí. Y meter un LLM en la cadena de detección amplía de forma mecánica el perímetro de lo que hay que evaluar.
Si se produce una brecha de datos personales —por ejemplo, porque unos registros identificativos han acabado en un proveedor de modelos sin base contractual—, la notificación a la AEPD va en 72 horas por el art. 33 del RGPD, y si el riesgo para las personas afectadas es alto hay que comunicárselo también a ellas (art. 34). La AEPD es además la autoridad que publica criterio sobre la adecuación al RGPD de los tratamientos que incorporan inteligencia artificial: es la primera fuente que conviene mirar antes de autorizar un uso interno. En el plano operativo, INCIBE-CERT es el punto de referencia para la gestión del incidente en el tejido empresarial, e INCIBE publica avisos y material divulgativo sobre seguridad de la IA. Ni una ni otro avalan proveedores ni expiden sellos: publican criterio, y ese criterio es el que se te aplicará si hay reclamación.
Si trabajas para el sector público, el Esquema Nacional de Seguridad (RD 311/2022) ya nombra buena parte de lo que aquí se discute, aunque no lo llame IA. La medida op.exp.8 «Registro de la actividad» obliga a registrar; op.mon.1 «Detección de intrusión» es justo el control donde vive un Suricata; y las pruebas de penetración aparecen en [op.mon.3.r6.3], dentro del refuerzo R6 «Inspecciones de seguridad» de la medida op.mon.3 «Vigilancia», que entra solo en categoría ALTA. Lo desarrollamos en qué exige realmente el ENS sobre pentesting. Un modelo que lee esos registros no releva de ninguna de esas medidas: se suma a ellas, y hay que evaluarlo como parte del sistema.
El Reglamento (UE) 2024/1689 de inteligencia artificial se suma al conjunto y se dirige sobre todo a quien proporciona y a quien despliega sistemas de IA. No sustituye al RGPD: la base jurídica, el encargo del tratamiento y la minimización se siguen planteando en los mismos términos.
Sobre NIS2, una frase y seguimos: la Directiva (UE) 2022/2555 no está transpuesta en España a 12 de septiembre de 2026, de modo que hoy no nace de ella ninguna obligación directa para las empresas aquí; el estado de la cuestión, en NIS2 en España: qué obliga hoy y qué no. Sí es directamente aplicable el Reglamento de Ejecución (UE) 2024/2690, que para determinadas entidades digitales exige una política de pruebas de seguridad y un procedimiento documentado de gestión de vulnerabilidades.
Y el fundamento del trabajo de prueba no ha cambiado. El acceso no autorizado a un sistema de información ajeno se castiga en el art. 197 bis del Código Penal; el daño a datos o programas y la obstaculización de sistemas ajenos, en el art. 264 y siguientes. Lo que hace lícita una intervención es un mandato por escrito y un alcance definido en contrato, también cuando el objetivo es un asistente conversacional que has puesto tú mismo en producción. Nuestros tests de intrusión se realizan sobre esa base, sin excepción.
Este artículo es informativo y no constituye asesoramiento jurídico. Haxoris es un proveedor europeo de seguridad ofensiva: emitimos informes técnicos, no certificaciones ni dictámenes de conformidad. La aplicación de las normas citadas depende de tu sector, de tu tamaño y de tu papel en la cadena de tratamiento. Última comprobación de las referencias normativas: 12 de septiembre de 2026.
Prueba la integración, no solo el modelo
Lo que viene ya se ve venir. Modelos afinados sobre datos de seguridad, agentes capaces de encadenar acciones, canalizaciones RAG conectadas a la documentación interna: cada uno de esos montajes aumenta a la vez la utilidad de la herramienta y su superficie de exposición.
Las clases de fallo que aparecen entonces no figuran en ninguna base de vulnerabilidades publicadas, porque dependen de tu implementación: prompt injection directa e indirecta, jailbreak, fuga de información por el contexto, envenenamiento de los datos de entrenamiento, herramientas y servidores MCP expuestos con permisos demasiado amplios. Un análisis de vulnerabilidades no las ve; un test de intrusión conducido sobre la integración las busca de forma explícita. El recorrido está detallado en pentesting de integraciones LLM.
La línea que sostenemos cabe en una frase: deja que el modelo procese el volumen y quédate tú con el criterio. Un LLM es excelente reduciendo diez mil líneas de registro a quince candidatas. Es malo estimando qué significan esas quince candidatas para tu entorno, tus proveedores y tus obligaciones de notificación. Esa ponderación es justo el trabajo por el que se contrata a alguien de fuera, y también lo que conviene comprobar antes de elegir, como explicamos en cómo elegir una empresa de pentesting.
Para leer la investigación completa (en inglés):
A medida que la IA se vuelve una herramienta corriente en los equipos de seguridad, es el equilibrio entre automatización y criterio humano lo que decidirá si seguimos siendo rápidos y certeros a la vez frente a quien ataca.
Preguntas frecuentes
01¿Puede la IA generativa sustituir a un analista de seguridad?
No. Un modelo generativo produce una propuesta acompañada de una justificación, no una decisión. Reduce diez mil líneas de registro a quince candidatas, y eso vale mucho; lo que no sabe es qué significan esas quince candidatas en tu entorno, con tus proveedores y frente a tus obligaciones de notificación. Calificar un incidente sigue siendo un acto humano, y por eso mismo es defendible ante quien te pida cuentas.
02¿Se puede pegar un registro o un informe de pentesting en un modelo en línea?
No sin un marco contractual. Un registro de Windows contiene nombres de cuenta, nombres de equipo y marcas de tiempo: son datos personales. Enviarlos a un proveedor de modelos supone incorporar un encargado del tratamiento en el sentido del art. 28 del RGPD, lo que exige un contrato por escrito y, si tú mismo actúas como encargado de tu cliente, autorización previa por escrito del responsable antes de recurrir a un subencargado. Con un informe de auditoría el problema es el mismo, agravado por el secreto empresarial.
03¿Qué aporta en concreto un LLM al análisis de registros?
Acorta el tiempo que va de una alerta en bruto a un hallazgo calificado. En nuestras pruebas sobre registros de Suricata y Sysmon, el modelo correlacionaba alertas dispersas, apartaba parte del ruido y enganchaba los eventos retenidos a técnicas del marco MITRE ATT&CK. La ganancia está en el triaje y en la puesta en contexto, no en el descubrimiento de ataques desconocidos: los escenarios muy ofuscados o construidos en varias etapas se le escapaban.
04¿Por qué un LLM produce falsos positivos sobre código o sobre registros?
Porque razona sobre la verosimilitud de una secuencia de texto, no sobre la ejecución real del programa o de la red. Un fragmento de código que se parece a un fallo conocido se señala aunque una comprobación anterior lo neutralice. El riesgo simétrico molesta más: un evento real clasificado como ruido. Por eso cada hallazgo producido por un modelo pasa por verificación humana antes de entrar en un informe.
05¿Hay que probar una integración LLM como el resto del sistema de información?
Sí. En cuanto un modelo accede a tus datos o dispara una acción, se convierte en un componente con permisos y con superficie de exposición propia: prompt injection directa e indirecta, jailbreak, envenenamiento de los datos de entrenamiento, fuga de información por el contexto, herramientas y servidores MCP expuestos. Esas clases de fallo no figuran en ninguna base de vulnerabilidades publicadas, porque dependen de tu implementación.
06¿Basta con desplegar IA generativa para cumplir el art. 32 del RGPD?
No por sí sola. El art. 32.1.d) del RGPD pide un proceso de verificación, evaluación y valoración regulares de la eficacia de las medidas técnicas y organizativas. Desplegar una herramienta de IA no acredita eficacia: es una medida más, que además amplía el perímetro que hay que evaluar. Lo que responde al art. 32 es la comprobación documentada de lo que esas medidas producen de verdad.
¿Estás pensando en meter un LLM en tu cadena de detección, o ya tienes uno en producción? Descríbenos el alcance en cuatro líneas y solicita tu presupuesto: te diremos qué cubriría un pentesting de integraciones de IA y LLM, qué no cubriría y en qué plazo. La reverificación de los hallazgos tras aplicar tus correcciones va incluida.
