Las organizaciones llevan meses metiendo modelos de lenguaje en producción: un chatbot de soporte que lee tickets, un asistente interno que consulta documentos propios, un agente que decide qué herramienta invocar para completar un pedido. La seguridad de esas aplicaciones no es una variante de la seguridad web que ya conoces, porque instrucciones y datos viajan por el mismo canal de texto dentro de un modelo, sin la separación estructural que existe, por ejemplo, entre una consulta SQL parametrizada y el valor que se le pasa.
Ese problema atraviesa cada componente que se añade encima del modelo: una base de recuperación que no hereda los permisos del documento original, un agente que ejecuta una herramienta con más autoridad de la que debería tener quien escribió el mensaje que puso el proceso en marcha, una salida que otro sistema procesa como si fuera un dato de confianza. Ninguno se corrige con un parche único, se corrige entendiendo cada componente y diseñando la arquitectura alrededor de esa asimetría. Este curso construye ese conocimiento módulo a módulo, con un laboratorio gratuito y apoyado en los marcos que ya existen (OWASP, MITRE ATLAS, NIST) en vez de inventar una taxonomía nueva.
¿A quién va dirigido?
A desarrolladores y arquitectos que están integrando un modelo de lenguaje o un agente en una aplicación real. A analistas de seguridad a los que les han puesto encima la etiqueta de «la seguridad de la IA» y necesitan un punto de partida con criterio, no una colección de artículos sueltos. Y a responsables técnicos que deciden qué controles exigir antes de aprobar el paso a producción de una aplicación con modelo.
No es un curso de aprendizaje automático ni de ciencia de datos: ningún módulo entrena un modelo ni entra en el diseño interno de una red neuronal. Tampoco es un curso de ingeniería de prompts para conseguir mejores respuestas. El foco está en qué puede salir mal y cómo se cierra, no en cómo sacarle más partido al modelo.
¿Qué aprenderás y qué sabrás hacer al terminar?
Al terminar los catorce módulos vas a poder:
- Dibujar el modelo de amenaza de una aplicación con modelo de lenguaje, recuperación de contexto y agentes, componente a componente.
- Explicar y aplicar los diez riesgos del OWASP Top 10 for LLM Applications 2025 con su control correspondiente.
- Diseñar herramientas de agente con permisos acotados y reconocer qué acciones exigen confirmación humana.
- Cerrar una fuga de autorización en un índice de recuperación vectorial entre departamentos o inquilinos distintos.
- Verificar la procedencia de un modelo abierto y documentar qué partes de esa procedencia no se pueden comprobar.
- Construir un registro operativo que sirva a la vez para detectar abuso e investigar un incidente ya ocurrido.
- Montar un banco de pruebas de red teaming propio y documentar un hallazgo de forma reproducible.
Requisitos previos
Hace falta poder leer y adaptar código en Python: ningún módulo pide escribir un programa complejo desde cero, pero varios ejercicios parten de un script que hay que entender y modificar. Ayuda tener nociones generales de una aplicación web y una API (peticiones HTTP, JSON, autenticación) y los conceptos de seguridad de cualquier otro curso de la casa. No hace falta experiencia previa en IA ni en aprendizaje automático, ni tarjeta gráfica, ni cuenta de pago en ningún proveedor de modelos: el módulo 1 y el 5 explican desde cero los conceptos de IA que el resto del curso da por sabidos.
El laboratorio
Todo el curso se apoya en un laboratorio que no cuesta un euro. El módulo 1 explica cómo instalar Ollama, herramienta de código abierto que ejecuta modelos de pesos abiertos en tu propio equipo, sin llamada a ninguna API de pago:
curl -fsSL https://ollama.com/install.sh | shSobre esa base, cada módulo añade su ejercicio. Algunos se apoyan en Damn Vulnerable LLM Agent, una aplicación deliberadamente vulnerable para practicar inyección de prompt contra el bucle de un agente. Otros construyen algo más pequeño y propio con unas pocas líneas de Python: un índice vectorial con documentos de dos departamentos, un esquema de registro con eventos de prueba, un banco de casos de ataque contra tu propia aplicación de laboratorio.
Temario
| Módulo | Qué cubre |
|---|---|
| 1. Anatomía de una aplicación con modelos de lenguaje y su superficie de ataque | Los componentes de una aplicación con LLM, por qué instrucciones y datos comparten canal, los modos de despliegue, agente frente a asistente, MCP y el montaje del laboratorio con Ollama. |
| 2. Los marcos de referencia: OWASP, ATLAS y NIST | Qué documento consultar según la pregunta: OWASP Top 10 for LLM Applications 2025, el Top 10 agéntico 2026, MITRE ATLAS, el AI RMF de NIST, las guías de NCSC y CISA e ISO/IEC 42001. |
| 3. Inyección de prompt: directa, indirecta y sin solución completa | LLM01:2025, inyección directa frente a indirecta, cómo se oculta texto malicioso en un documento, por qué fallan las defensas ingenuas, y la separación de privilegios entre quien decide y quien procesa contenido no confiable. |
| 4. La salida del modelo es entrada no confiable | LLM05:2025 y LLM02:2025: por qué la salida de un modelo es entrada no confiable, validación real de una salida estructurada, aislamiento para ejecutar código generado, y vías de fuga de información sensible. |
| 5. Recuperación de contexto (RAG), bases vectoriales y control de acceso al conocimiento | Las cuatro fases de una recuperación aumentada, por qué un índice vectorial no hereda los permisos del documento de origen, el envenenamiento del corpus, y por qué un vector no es un dato anónimo. |
| 6. Agencia excesiva: agentes, herramientas y delegado confundido | LLM06:2025 y sus tres causas, el delegado confundido aplicado a un agente, diseño de herramientas seguras, confirmación humana, límites del bucle de un agente, y por qué la confianza entre agentes no es transitiva. |
| 7. Cadena de suministro de modelos y datos | LLM03:2025 y LLM04: el modelo como dependencia de software, por qué el formato de los pesos puede ejecutar código, verificación de procedencia, fases de envenenamiento, puertas traseras, y el registro de modelos de una organización. |
| 8. El prompt de sistema no es un control, y la alucinación es un vector | LLM07:2025 y LLM09:2025: qué debe y qué no debe vivir en un prompt de sistema, paquetes de software alucinados como vector de ataque, citas judiciales inventadas, y los controles que cortan cada uno. |
| 9. Consumo sin límites y extracción del modelo | LLM10:2025: los vectores que disparan el coste de una petición, los controles y en qué capa viven, la amplificación, y la diferencia que traza NIST entre inferencia de pertenencia y extracción de modelo. |
| 10. Identidad, autorización y aislamiento | Identidad delegada frente a una única identidad de servicio, intercambio de token, autorización por herramienta y por usuario, lo que advierte MCP sobre servidores intermediarios, y aislamiento de ejecución y de memoria entre usuarios. |
| 11. MLSecOps: seguridad del ciclo de vida | NIST SP 800-218A aplicado a IA generativa, versionado de prompts como cambio de comportamiento, evaluación continua como control de regresión, guardrails y dónde se colocan, y qué registrar de cada versión que responde. |
| 12. Red teaming de aplicaciones de IA | La diferencia entre probar un modelo y probar una aplicación, metodología por objetivos a partir de OWASP y ATLAS, alcance y reglas del ejercicio por escrito, y cómo documentar un hallazgo reproducible. |
| 13. Detección, respuesta e IA en la sombra | Qué campos conservar en el registro de una aplicación con modelo, patrones de abuso, respuesta a un incidente de filtración, por qué «vuelve a ejecutarlo» no es una prueba válida, y la IA en la sombra. |
| 14. Gobierno y cumplimiento: el Reglamento europeo de IA | Qué obligaciones caen sobre quien pone en producción un sistema con modelos de lenguaje según el Reglamento europeo de IA vigente, y cómo encaja con el resto de controles técnicos de este curso. |
Cómo encaja con los otros cursos
Este curso comparte terreno con otros cuatro de la casa y traza la frontera con cada uno en el propio contenido. Cuando un agente de IA ejecuta una acción indebida, alguien tiene que detectarlo con el curso de SOC y responder al incidente con el curso de DFIR: aquí se cubre qué campos hay que dejar registrados para que ese trabajo sea posible, no cómo escribir la regla de detección en sí. Cuando una inyección de prompt termina en una inyección SQL o en un XSS a través de una salida mal saneada, el curso de Hacking Web cubre esa explotación clásica desde cero; aquí solo aparece como el impacto final de una cadena que empieza en el modelo. Y cuando hay que documentar la postura de cumplimiento frente al Reglamento europeo de IA, el curso de GRC cubre el marco general de gobierno de riesgo; aquí solo lo específico de una aplicación con modelos de lenguaje.
Preguntas frecuentes
¿Hace falta pagar por una API de un modelo comercial?
No. El laboratorio del módulo 1 corre sobre Ollama y un modelo abierto en tu propio equipo, sin coste por token. Ningún ejercicio obligatorio depende de una cuenta de pago en un proveedor.
¿Sirve si no tengo experiencia previa en inteligencia artificial?
Sí, siempre que vengas con una base de seguridad de aplicaciones o de desarrollo. No se entrena ningún modelo, y los conceptos propios de IA se explican desde cero antes de entrar en ningún ataque.
¿Prepara para alguna certificación de seguridad de IA?
Cubre materia que aparece en certificaciones que ya existen, como GIAC AI Platform Security (GAIPS), asociada al curso SEC545 de SANS, o Advanced in AI Security Management (AAISM) de ISACA, y en la que ISC2 tiene en construcción con sus propios miembros. No es una preparación de examen para ninguna de ellas ni promete que vayas a aprobar nada: cada una tiene su propio temario y su propio examen de pago.
¿Cuánto tiempo lleva completarlo?
No hay una cifra de horas fijada de antemano. Algunos módulos, como el de agencia excesiva o el de identidad y autorización, piden montar y probar algo, no solo leer. Cuenta con varias sesiones de trabajo por módulo, no una lectura de sobremesa.
¿El contenido caduca?
Los marcos de referencia (OWASP, NIST, MITRE ATLAS) se actualizan con calendario propio, y el curso está escrito sobre la categoría del problema y del control, no sobre qué modelo está de moda esta temporada. Por eso tampoco hay cifras de eficacia de defensas ni comparativas entre modelos: caducan en semanas y casi ninguna es reproducible fuera del entorno donde se midió.
¿Tengo que seguir los catorce módulos en orden?
El módulo 1 fija un vocabulario que el resto da por conocido, y el módulo 2 construye el mapa de marcos de referencia: esos dos conviene hacerlos primero. A partir de ahí, cada módulo desarrolla un riesgo concreto con bastante independencia, así que puedes saltar al que te toque resolver esta semana.