La inteligencia artificial ya no está en la ciberseguridad como observadora de fondo. Está entrando en procesos reales: interpreta salidas de escáneres, ayuda a revisar configuraciones, resume hallazgos, prioriza riesgos y propone remediaciones. El artículo de LockLLM publicado el 7 de marzo de 2026 parte precisamente de esa idea: los LLM están pasando de ser asistentes genéricos a formar parte del flujo operativo de auditoría y pentesting.

Y aquí aparece el primer error habitual: pensar que el valor está en “tener prompts”. No. El valor está en construir un sistema de trabajo donde la IA reciba contexto suficiente, responda dentro de límites claros y nunca actúe como una autoridad incuestionable. Un prompt mediocre devuelve texto bonito. Un prompt bien diseñado devuelve señales útiles para tomar decisiones. Pero incluso así, la salida del modelo sigue siendo un dato no confiable hasta que alguien la valida. Eso también lo subraya la pieza original: el output del modelo debe tratarse como una variable no confiable y revisarse de forma continua.

La gran promesa de la IA en seguridad no es “hacer hacking más rápido”

La promesa real es otra: reducir tiempo muerto, aumentar cobertura y mejorar la capacidad de análisis humano. En seguridad, una parte enorme del trabajo se pierde entre ruido, repetición y contexto disperso. Salidas de Nmap, resultados de escáneres de vulnerabilidades, reglas de cloud, hallazgos de revisión de código, tickets, logs, documentación interna, cambios de arquitectura, dependencias y excepciones de negocio. Un analista puede entenderlo. Un equipo experto también. Pero cuesta tiempo. Y el tiempo es una de las cosas más caras en seguridad.

Por eso tiene sentido usar IA como capa de apoyo: no para sustituir el criterio técnico, sino para ordenar información, proponer hipótesis, detectar patrones y acelerar la primera lectura. El problema es que mucha gente intenta hacerlo con instrucciones ambiguas del tipo “revísame esto” o “busca vulnerabilidades”. Ese enfoque sirve para una demo, no para una operación seria.

Qué hace que un prompt de seguridad sea realmente útil

LockLLM plantea cinco piezas que convierten una instrucción normal en un prompt de alto rendimiento: definir el rol experto que debe asumir el modelo, aportar contexto rico del proyecto, enseñar ejemplos de salida, dar instrucciones específicas y fijar restricciones de formato. Esa estructura tiene mucho sentido porque obliga al modelo a salir del modo “asistente genérico” y entrar en un modo más analítico y acotado.

Traducido a un lenguaje de empresa: si quieres que la IA sea útil, tienes que explicarle quién “es”, dónde está trabajando, qué problema concreto debe analizar y en qué formato debe devolverte la respuesta. Dicho de otro modo, el prompt no es un atajo. Es una especificación. Cuanto más se parece a una especificación, más valor suele generar.

Aquí hay una lección que va más allá de la seguridad: cuando una organización falla usando IA, muchas veces no falla el modelo; falla el contexto. Falta arquitectura, falta delimitación del caso de uso y sobran expectativas mágicas. En tu empresa no necesitas que el modelo “sepa de todo”. Necesitas que entienda muy bien una tarea concreta dentro de un marco concreto. Ese enfoque conecta, además, con una línea editorial muy presente en tonidomenech.space: IA aplicada con base técnica real, aterrizada a procesos, datos y negocio, no como humo de presentación.

El contexto inicial cambia por completo la calidad de la revisión

Uno de los puntos más interesantes del artículo base es la idea de arrancar la sesión con un “context dump” del proyecto: stack, módulos críticos, foco de auditoría, restricciones y archivos clave. Esto evita lo que el texto llama una especie de “amnesia del modelo”: recomendaciones que ignoran por completo las condiciones reales del sistema.

Tiene lógica. No es lo mismo revisar una aplicación SaaS con login passwordless y multi-tenant que una intranet heredada con LDAP, VPN y procesos batch. No es lo mismo un flujo de subida de ficheros a S3 que una API financiera con reglas regulatorias. Si el modelo desconoce eso, puede producir respuestas técnicamente plausibles pero operativamente inútiles. Y ese es uno de los peligros más caros de la IA en entornos reales: la respuesta parece buena, pero no sirve.

Un ejemplo seguro y útil de prompt defensivo podría ser este:

Actúa como Application Security Engineer senior.Voy a darte el contexto exacto de una revisión de seguridad autorizada.Proyecto: plataforma SaaS B2BStack: React, FastAPI, PostgreSQLFlujos prioritarios: autenticación, subida de archivos y panel de administraciónRestricciones: no propongas cambios que rompan compatibilidad con SSO ni el sistema actual de rolesQuiero que hagas tres cosas:1. Identificar riesgos lógicos y de autorización.2. Señalar validaciones de entrada o de archivo que falten.3. Devolver el resultado en tabla con: riesgo, impacto, evidencia probable y propuesta de mitigación.No inventes hallazgos. Si algo no puede inferirse con seguridad, indícalo como hipótesis.

La clave aquí no es el texto bonito. La clave es que delimita alcance, reduce ambigüedad y obliga al modelo a diferenciar entre evidencia e hipótesis. Esa diferencia, en seguridad, vale oro.

Donde la IA brilla de verdad: modelado de amenazas y priorización

Otro punto potente del artículo de LockLLM es el uso de prompts estructurados para modelado de amenazas con STRIDE. Ahí la IA puede aportar muchísimo porque ayuda a traducir una funcionalidad nueva en una lista ordenada de escenarios plausibles, controles afectados y mitigaciones técnicas. El texto pone como ejemplo un login sin contraseña mediante enlaces mágicos por email y pide analizarlo contra las seis categorías de STRIDE, con escenarios concretos y medidas de mitigación.

Usado con cabeza, esto es muy valioso. No porque el modelo “descubra la verdad”, sino porque te obliga a pensar antes de desplegar. En muchas empresas el modelado de amenazas se hace tarde, deprisa o no se hace. La IA puede rebajar esa fricción y convertirlo en un paso más barato y repetible. Para mí, ese es uno de los usos más inteligentes de los LLM en seguridad: no solo revisar lo que ya existe, sino mejorar la conversación técnica antes de que el problema llegue a producción.

También puede ayudar a resumir salidas densas de herramientas y a separar ruido de prioridad. El artículo menciona precisamente esa utilidad en la interpretación de escaneos y resultados masivos, donde los equipos suelen sufrir fatiga de alertas. Ahí el modelo puede servir como capa de triage, siempre que la organización no confunda “priorización sugerida” con “verdad confirmada”.

El gran riesgo: cuando el auditor de IA también puede ser engañado

Aquí es donde el artículo de LockLLM se pone realmente interesante: recuerda que el propio sistema que analiza código, logs, tráfico o contenido web puede ser manipulado mediante prompt injection. Es decir, la IA que tú usas para revisar seguridad puede recibir instrucciones maliciosas escondidas dentro del material que está analizando. Y como los modelos actuales no separan de forma fiable la instrucción legítima de la entrada hostil, pueden acabar obedeciendo al atacante.

Este punto cambia totalmente la conversación. Ya no hablamos solo de “usar IA para encontrar fallos”, sino de “proteger a la IA para que no se convierta en parte del fallo”. Si tu sistema de auditoría traga contenido no confiable y lo pasa directamente a un modelo con permisos, memoria o capacidad de disparar acciones, has creado una nueva superficie de ataque. Y es una superficie especialmente peligrosa porque parece invisible: el flujo sigue funcionando, pero la lógica interna ya está contaminada.

Esto se agrava todavía más en entornos con RAG o con ingestión de documentación externa. El artículo lo vincula claramente con el envenenamiento de documentos y con la influencia silenciosa que puede ejercer contenido no confiable sobre el comportamiento del modelo. Dicho de forma sencilla: no basta con proteger tu aplicación; tienes que proteger también la cadena de contexto que alimenta al modelo.

La regla más importante: la salida del modelo nunca debe gobernar sola

Hay una idea del artículo que me parece obligatoria para cualquier empresa que quiera usar IA en seguridad: la supervisión humana no es un extra, es parte del diseño. El texto insiste en varios patrones de endurecimiento: verificación humana obligatoria, exigencia de pruebas antes de aceptar un hallazgo y validación normalizada del resultado antes de permitir acciones posteriores.

Traducido a una política práctica, esto significa varias cosas. Primero, que la IA no debería abrir tickets críticos, tocar infraestructura o modificar controles por sí sola. Segundo, que un hallazgo no debería aceptarse únicamente porque “lo dijo el modelo”. Tercero, que cualquier integración con CI/CD o con automatizaciones internas debe tratar la salida del LLM como entrada no confiable. Igual que no ejecutarías ciegamente cualquier input de usuario, tampoco deberías ejecutar ciegamente cualquier output de un modelo.

Añado una más, muy de mundo real: si una empresa quiere usar LLMs en seguridad, debe decidir por adelantado dónde termina la ayuda analítica y dónde empieza la decisión humana. Esa frontera tiene que estar escrita, no improvisada.

Privacidad, ética y cumplimiento: la parte que se olvida demasiado

El artículo también dedica un bloque a la responsabilidad ética y operativa. Y hace bien. Porque en el momento en que metes IA generativa en una auditoría aparecen preguntas serias: quién responde por errores, qué datos se comparten con terceros, si se están subiendo evidencias sensibles a servicios externos y cómo se documenta el uso de IA dentro de un informe de seguridad.

Sobre privacidad, el mensaje es claro: introducir datos corporativos identificables o sensibles en modelos externos implica riesgo, y para revisiones delicadas conviene anonimizar, pseudonimizar o usar modelos privados/locales. Esa recomendación es especialmente relevante para empresas con datos regulados, propiedad intelectual crítica o exigencias sectoriales fuertes.

También es importante la transparencia. Si una parte del análisis, del borrador del informe o de la priorización se ha apoyado en IA, eso debería quedar documentado. No para hacer marketing, sino para mantener trazabilidad y honestidad metodológica. En seguridad, la confianza no depende solo del hallazgo; depende del proceso.

Mi conclusión: el futuro no es “pentesting con prompts”, sino seguridad aumentada con criterio

La mejor lectura del artículo de LockLLM no es que “la IA va a sustituir al pentester”. Es justo la contraria: la IA va a obligar a los buenos equipos a trabajar con más método. Va a premiar a quienes sepan especificar bien, validar bien y blindar bien sus propios flujos. Y va a castigar a quienes usen modelos potentes dentro de pipelines ingenuos.

En la práctica, esto abre una oportunidad enorme para empresas y equipos técnicos. Un LLM bien encajado puede acelerar revisiones, ordenar contextos complejos, mejorar el modelado de amenazas y ayudar a estandarizar reporting. Pero el verdadero salto no vendrá de pedirle más cosas al modelo. Vendrá de diseñar mejor el sistema que lo rodea.

La IA no elimina la necesidad de criterio. La multiplica. Y en ciberseguridad eso significa una sola cosa: menos fascinación por la herramienta y más disciplina en el proceso.

Toni Domenech