IA generativa, reglas deterministas e intervención humana: lo que aprendí modelando amenazas con un pipeline híbrido

Cuando uno termina un máster, como el Máster en IA aplicada a la Ciberseguridad del Campus de Cibersegurdiad, lo último que quiere (yo al menos) es que el TFM quede guardado en un cajón, así que contacté con Chema Alonso a través de MyPublicInbox para publicarlo, y aquí lo tienes. Una prueba de concepto de modelado de amenazas con IA local, validación humana y núcleo determinista, como excusa para hablar de dónde conviene poner cada tipo de IA en un proceso y dónde no poner ninguna.

Mi aporte en el proyecto está centrado en el modelado de amenazas en sistemas porque está vinculado a la gestión de riesgos, que es un poco a lo que me dedico, pero la pregunta que lo originó es más amplia y, creo, más interesante que el caso concreto: 

El modelado de amenazas resultó ser un buen banco de pruebas para esa pregunta al convivir tareas de naturaleza muy distinta dentro de un mismo flujo. 

Algunas tareas le sientan bien a un LLM; otras lo hacen picar el anzuelo y otras, directamente, no necesitan IA. Este artículo cuenta cómo quedó repartido ese trabajo y por qué. La PoC es la anécdota y el reparto (por así decirlo) es la idea.

El problema concreto: el modelado de amenazas no escala

El modelado de amenazas identifica riesgos y propone mitigaciones en fases tempranas del diseño de sistemas, cuando la arquitectura todavía es flexible y cambiar algo cuesta poco. Suena a buena práctica obvia, y lo es. El problema es que cuesta hacerlo de forma sistemática.

Para analizar un sistema con un modelo de clasificación de amenazas como STRIDE hay que partir de un diagrama de arquitectura y convertirlo en un inventario estructurado. En otras palabras, hay que determinar qué componentes hay, de qué tipo es cada uno, cómo fluyen los datos entre ellos, qué límites de confianza se cruzan, si el transporte va cifrado o en claro, etcétera. 

Esa conversión manual del dibujo al inventario lleva tiempo, depende de experiencia especializada y, sobre todo, varía según el analista que la haga. Dos expertos pueden tipificar el mismo diagrama de forma distinta, punto a partir del cual el análisis entero diverge. Si esa traducción no se apoya en reglas explícitas, la reproducibilidad se ve comprometida.

La tentación en 2026 es obvia: que un modelo multimodal lea el diagrama y escupa el análisis completo de punta a punta. Y aquí es donde aparece la primera decisión de diseño importante.

El marco: tres decisiones, no una regla

La respuesta a «¿uso IA o no?» depende de la tarea, de «qué pasa cuando el modelo se equivoca» y de «si el problema ya se puede resolver con reglas estables». Con estos criterios las tareas de mi pipeline se acomodaron en tres enfoques distintos.

• Primer enfoque – delegar en la IA, pero con supervisión y validación humana. 

• Segundo enfoque – no usar IA en absoluto. Una vez que tengo el inventario validado, decidir qué categorías STRIDE aplican a un `DataStore`, o qué controles mitigan la amenaza `Spoofing` sobre una entidad externa, ya es un problema resuelto.

• Tercer enfoque — la IA como ayudante, no como autor. Existe una tarea final donde la IA vuelve a ser útil pero de forma acotada, que es mejorar la redacción del informe y su lectura. Ahí puede sugerir texto más claro, siempre que no toque los hallazgos técnicos. Redacta, no decide. Eso sí, que no toque los datos no significa que la redacción salga siempre bien, ya que un modelo local puede introducir errores de interpretación al redactar una conclusión sin alterar un solo dato técnico. 

Una aclaración importante, porque es fácil sacar la conclusión equivocada. «Delegar sin control» no está mal en general. Hay tareas de bajo riesgo donde el costo de un error es trivial y revisar todo a mano no compensa. La decisión depende del riesgo, no de un principio absoluto. Lo que pasa es que en este caso de uso concreto siempre conviene controlar la extracción, porque el modelo puede equivocarse (y más todavía cuando, por privacidad, uno corre modelos locales más pequeños que los de la nube). Volveré sobre esto al final con un ejemplo que me pasó de verdad.

Y hay un requisito que atraviesa todo lo anterior: la privacidad por diseño. Un diagrama de arquitectura es información sensible. Mandarlo a una API en la nube para que lo analice significa sacarlo de la organización. Por eso, toda la inferencia de la PoC corre en local. Esa restricción es la que vuelve la pregunta del reparto todavía más aguda, porque los modelos locales pequeños son justamente los que más se benefician de esa supervisión humana con validación. 

Veamos cómo se ve esto en la práctica.

El caso de uso, paso a paso

El sistema se organiza en cuatro procesos secuenciales: extracción y validación (P1), identificación de amenazas (P2), recomendación de controles (P3) y generación del informe (P4). El punto de partida es una imagen de un diagrama de flujo de datos (DFD) de cajas y flechas. 

P1 — La IA extrae, el humano valida

Un modelo de visión local analiza el diagrama y devuelve un inventario inicial en formato JSON, es decir, componentes normalizados a una taxonomía acotada (`ExternalEntity`, `Process`, `DataStore`, `UI`, `API Gateway`, `Queue`) y flujos con sus atributos, incluido si el transporte va cifrado o claro.

Esta es la fase más frágil de todo el sistema, y conviene hablar con franqueza sobre el motivo. Los modelos generativos son probabilísticos. Pueden alucinar, devolver el JSON cortado a la mitad cuando la salida es larga, o tipificar un componente de una forma una vez y de otra a la siguiente. Buena parte del desarrollo fue destinada precisamente a domar esa variabilidad.

Por un lado, fijé la generación a `temperature = 0`, con `seed` fijo y muestreo restringido para favorecer la reproducibilidad. Por otro, evité el truncado de la respuesta y monté un mecanismo de reintento en el que, si el JSON no parsea o no valida contra el esquema, lanza un segundo intento de reparación y, si vuelve a fallar, corta con error explícito en vez de seguir con datos corruptos.

Pero ningún ajuste de parámetros elimina del todo la posibilidad de que el modelo se equivoque al interpretar el dibujo. Y aquí está lo que comentaba. En la primera extracción del caso de estudio, el modelo tipificó el `Frontend` como `Process`.

No es un error catastrófico ni una alucinación grosera; es una interpretación razonable que, sin embargo, cambia el análisis porque un `Process` y una `UI` no tienen el mismo conjunto de categorías STRIDE aplicables. Si ese inventario pasara directo a las fases siguientes, generaría un conjunto de amenazas distinto del correcto y nadie lo notaría.

Por eso P1 termina en una instancia de validación humana obligatoria (human-in-the-loop, HITL). El sistema bloquea el acceso a las fases deterministas hasta que el analista revisa el inventario y confirma explícitamente que es correcto. La revisión se hace mediante un chat de comandos estructurados acotado a renombrar componentes y corregir sus tipos, y la confirmación se persiste en el artefacto de trabajo para dejar traza de que la validación ocurrió.

Este HITL no es un detalle de usabilidad, es la supervisión humana con validación que hace que tenga sentido usar un modelo generativo en P1. La IA aporta la velocidad de no transcribir el diagrama a mano y el humano aporta la garantía de que el análisis no arranca sobre una premisa equivocada. Ni el modelo solo, ni el humano transcribiendo todo a mano. Cada uno donde rinde.

P2 y P3 — El núcleo determinista, sin una sola línea de IA

Con el inventario validado como «contrato de entrada«, arrancan las dos fases que no usan IA.

P2 recorre cada activo del inventario y, según su tipo, determina qué categorías STRIDE aplican mediante un mapeo fijo. Un `ExternalEntity` recibe `Spoofing` y `Repudiation`. Un `Process` recibe las seis categorías. Un `DataStore` recibe `Tampering`, `Repudiation` e `Information Disclosure`. Los flujos reciben `Tampering`, `Information Disclosure` y `Denial of Service`.  Por cada combinación «tipo de activo – amenaza STRIDE» aplicable se genera un escenario de riesgo, y se le estima una severidad combinando probabilidad e impacto en una escala de 1 a 5, con reglas que se apoyan en el tipo de activo y en señales del propio diagrama (por ejemplo, si un flujo va cifrado o en claro). La severidad sale de multiplicar ambos factores y se clasifica por umbrales que van de informativa a crítica.

P3 toma cada escenario priorizado y lo mapea a controles concretos mediante otra correspondencia determinista en la que cada par «tipo de activo – amenaza STRIDE» tiene asociados sus controles del catálogo local, y la severidad gradúa cuántos se recomiendan (más para los críticos, menos para los de baja severidad). Si una combinación no tiene entrada directa, hay un mecanismo de respaldo que también es determinista.

Lo importante no es el detalle de los mapeos, sino que toda esta lógica es conocida, estable y reproducible. No hay nada que «interpretar«. Meter un modelo generativo aquí no resolvería ningún problema que las reglas no resuelvan ya, y a cambio reintroduciría justo la variabilidad que tanto trabajo costó sacar de P1. Para el caso de estudio, estas dos fases produjeron 44 escenarios de riesgo y 83 recomendaciones de control a partir de un catálogo de 15 controles únicos, siempre igual ante la misma entrada.

P4 — El informe, y la IA de vuelta, pero atada

La última fase consolida todo en un informe en Markdown con la arquitectura detectada, las amenazas clasificadas y el plan de mitigación. Acá la IA reaparece, pero en su tercer enfoque, como ayudante de redacción opcional. El sistema puede pedirle a un LLM local que mejore la prosa de las descripciones (impacto, mitigación, etcétera) para que el informe se lea mejor, pero con dos límites estrictos. 

Primero, no puede alterar los hallazgos, de modo que el inventario, las amenazas y los controles que vienen del núcleo determinista permanecen intactos. Eso protege los datos, pero no la prosa, ya que el texto enriquecido es lenguaje libre y nada impide que el modelo afirme en una descripción algo que el inventario no dice. Por eso esa capa es prescindible y la versión sin enriquecer del informe sigue siendo la fuente de verdad.

La evidencia: dónde vive la variabilidad

Todo el argumento anterior se puede resumir en una sola tabla, que para mí es el resultado más contundente del trabajo. Ejecuté el pipeline varias veces sobre el mismo diagrama.

Las dos primeras ejecuciones son idénticas hasta el último número porque el núcleo determinista no fluctúa. La tercera difiere (47 escenarios en vez de 44, 92 recomendaciones en vez de 83) y la diferencia tiene una sola causa. En esa ejecución no se aplicó la corrección humana y el `Frontend` quedó como `Process`, que arrastra más categorías STRIDE. La variabilidad no aparece dispersa por todo el sistema, sino confinada al punto exacto donde decidí que viviera**, el HITL. 

Esa es la prueba de que el reparto funciona. La parte que debe ser estable, lo es, y la que legítimamente depende del criterio humano está aislada y es trazable. En este vídeo dejo las capturas de una ejecución, una tras otra, como apoyo visual al recorrido descrito arriba.  

Una nota sincera sobre la fragilidad de los modelos

Hay un detalle que prefiero contar antes que esconder porque ilustra mejor que cualquier argumento por qué el HITL no sobra. Al preparar el material de este artículo, meses después de la evaluación original, volví a mirar las ejecuciones y el modelo de visión extraía los componentes de forma algo distinta a como lo había hecho la primera vez y yo no había tocado una sola línea de código. En ese lapso solo había habido actualizaciones de herramientas del entorno. No tengo una explicación cerrada de la causa exacta, y no voy a inventarla.

Pero el fenómeno, sea cual sea su origen, es exactamente la fragilidad que el trabajo documenta como limitación, esto es, que la salida de la fase generativa puede cambiar entre sesiones por motivos que están fuera del control del analista. Y ese es justamente el argumento a favor de no confiar ciegamente en ella. Si el comportamiento del modelo puede derivar con el tiempo aunque tu código sea idéntico, quieres un punto de control humano entre esa salida y todo lo que depende de ella. La fragilidad no es un contratiempo del proyecto, sino la mejor evidencia de por qué se diseñó así.

Qué queda fuera

Esto es una prueba de concepto, con su alcance acotado (aplicaciones web de tres capas, APIs y microservicios ligeros, partiendo de un DFD de cajas y flechas). No pretende ser una herramienta lista para producción. Aquí tienes el TFM completo publicado en Slideshare.

Quedan muchas líneas abiertas por si a alguien le sirven de punto de partida, como la ampliación de la corrección humana a flujos y atributos, la validación de que la imagen de entrada sea realmente un DFD antes de procesarla, la incorporación de activos y amenazas propios de IA/LLM, o la conexión del sistema a bases de conocimiento (OWASP, NIST) vía RAG para justificar cada control con evidencia documental. El detalle de todo esto está en el TFM.

Conclusión

El modelado de amenazas funcionó aquí como el escenario idóneo para poner a prueba el concepto del reparto. Un mismo proceso puede, y a veces debe, alternar el uso de la IA generativa, es decir, emplearla en un paso, prohibirla en el siguiente y acotarla en el último. La decisión en cada etapa responde a dos preguntas pragmáticas: 

• ¿qué impacto tiene un error del modelo en esta instancia?
• ¿Puede resolverse este paso mediante reglas tradicionales?

Este pipeline situó a la IA donde aporta valor, interpretando imágenes bajo validación humana; la excluyó de donde solo hacen falta reglas conocidas, porque ahí solo agregaría ruido; y la incorporó como redactora del informe sin permitirle modificar un solo hallazgo. La tabla de repetibilidad muestra que este reparto se sostiene porque los componentes deterministas producen resultados idénticos en cada ejecución, y la única variabilidad se concentra, deliberadamente, en el punto de validación humana.

En definitiva, no he inventado nada espectacular; no obstante, la lógica de dónde poner cada cosa me parece que trasciende el caso del modelado de amenazas y por eso vale la pena insistir en ella.

Autor: Matias Daniel Ades

Referencias

Las referencias completas están en el TFM. Estas son las que más sostienen las ideas de este artículo.

• I. Elsharef, Z. Zeng y Z. Gu, *Facilitating Threat Modeling by Leveraging Large Language Models*, Workshop on AI Systems with Confidential Computing (AISCC), 2024.
• S. Berger et al., *Efficient and Extensible Security Analysis with Enhanced Data Flow Diagrams*, Proc. ESSoS, 2016.
• Microsoft, *Microsoft Threat Modeling Tool* (documentación técnica), 2022.
• OWASP, *Threat Dragon Documentation*.
• AWS, Accelerate threat modeling with generative AI (AWS Threat Designer), 2025.
• A. Crossman et al., *Auspex: Building Threat Modeling Tradecraft into an Artificial Intelligence-based Copilot, arXiv:2503.09586, 2025.
• E. Bandara et al., *ASTRIDE: A Security Threat Modeling Platform for Agentic-AI Applications*, arXiv:2512.04785, 2025.
• R. Troncoso, *Módulo 6. Seguridad de Aplicaciones y Desarrollo Seguro*, Máster en IA Aplicada a la Ciberseguridad, ENIIT & UCAM, 2025.
• S. Bai et al., *Qwen2.5-VL Technical Report*, arXiv:2502.13923, 2025.