Figura 1: IA generativa, reglas deterministas e intervención humana.
Lo que aprendí modelando amenazas con un pipeline híbrido
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:
"¿Cuándo conviene dejar que un modelo generativo haga el trabajo, cuándo conviene dejarlo trabajar pero con validación humana, y cuándo conviene no usar IA en absoluto?"
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.
Figura 2: Cómo ser un experto en Inteligencia Artificial aplicada a Ciberseguridad.
Fecha de Comienzo - 15 de Octubre 2026 - 12 meses de duración
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.
Figura 3: El mismo pipeline aplica tres criterios distintos.
IA con supervisión humana y validación (P1), reglas deterministas sin IA (P2-P3)
y la IA como capa auxiliar acotada (P4). Diagrama conceptual del autor.
- Primer enfoque - delegar en la IA, pero con supervisión y validación humana.
Interpretar una imagen es justo lo que un modelo de visión hace bien y una regla determinista hace mal. No voy a escribir un parser para reconocer cajas, flechas y etiquetas escritas a mano alzada en cualquier diagrama posible. Para esa tarea, la IA aporta valor real.
El problema no es usarla, es que un error suyo en este punto es silencioso y se propaga. Si tipifica mal un componente, todo el análisis posterior queda contaminado sin que nadie se entere. Por eso, en este enfoque, la IA trabaja pero no tiene la última palabra, y un humano valida antes de continuar.
- 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.
Existe una correspondencia conocida y estable entre el tipo de activo y las amenazas que le aplican, y entre cada amenaza y sus controles. Meter un LLM ahí no agregaría capacidad, sino variabilidad donde quiero exactamente lo contrario. Para esto alcanzan reglas fijas, las cuales tienen una propiedad que ningún modelo generativo garantiza, que el mismo input produce siempre el mismo output.
- 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.
Por eso el enriquecimiento es opcional y siempre queda sujeto a una última lectura humana. La diferencia con P1 es de gravedad, aquí un error se queda en la prosa y un lector atento lo detecta, mientras que allí un error de tipificación se propagaba sin ser percibido en todo el análisis.
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.
Figura 4: El diagrama de entrada del caso de estudio.
Nótese que el flujo hacia "Centralized Logs" va por HTTP en claro,
mientras que el resto va cifrado (ese detalle va a importar).
Para la evaluación usé un caso representativo: un frontend, dos microservicios, tres almacenes de datos y distintas configuraciones de seguridad de transporte, como se ve en el diagrama de la imagen anterior.
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`.
Figura 5: La extracción inicial del modelo de visión.
El `Frontend` aparece como `Process` (no como `UI`),
y el flujo de logs queda correctamente marcado como `Plain`.
El sistema todavía no permite continuar porque falta la validación.
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ó.
Figura 6: El inventario tras la corrección humana - el `Frontend` ahora es `UI`.
El checkbox de confirmación está marcado y recién entonces se habilita el botón
para continuar. Esa única corrección cambia las amenazas que se van a generar.
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.
Figura 7: El informe final. El inventario validado, las amenazas y los controles
quedan como tablas auditables. Los hallazgos técnicos son inmutables.
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.
Segundo, se hace amenaza por amenaza en vez de todo de una vez, porque pedirle al modelo que reescriba un bloque grande resultó frágil, y cualquier desvío de formato echaba a perder todo el lote. Si el enriquecimiento de un caso falla, el informe sale con el texto original y la ejecución no se interrumpe. Es la misma filosofía de P1 vista desde otra perspectiva. La IA puede ayudar a redactar, pero no a decidir. La fuente de verdad sigue siendo el inventario validado y los resultados deterministas.
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.
Figura 8: Tabla de Repetibilidad y variación controlada
(en las tres ejecuciones o runs: 7 componentes y 6 flujos).
Con la misma entrada y la misma validación humana,
el resultado es idéntico (Run 1 y Run 2). La diferencia
del Run 3 viene exclusivamente de una decisión distinta
en el punto de validación: dejar el `Frontend` como
`Process` en lugar de corregirlo a `UI`.
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.
Figura 9: Ejecución de un proceso paso a paso
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.
Figura 10: Modelado de Amenazas Automatizado con Inteligencia Artificial,Validación Humana y Núcleo Determinista
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 AdesReferencias
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.
Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
