Seguridad en sistemas de IA: análisis del curso interactivo Basic Seguridad IA

Durante años, hablar de ciberseguridad significaba hablar de firewalls, contraseñas y parches. Ese mundo sigue existiendo, pero ha aparecido una capa nueva que la mayoría de profesionales todavía no domina: la seguridad de los sistemas de inteligencia artificial. No me refiero solo a que un modelo "se piratee", sino a algo mucho más cotidiano: prompts que filtran secretos, bases de conocimiento RAG envenenadas, agentes con permisos excesivos que ejecutan acciones reales, salidas generadas que se renderizan sin validar. El curso interactivo Basic Seguridad IA, disponible gratuitamente en GitHub Pages, es una de las mejores formas que he encontrado de interiorizar ese mapa mental sin montar infraestructura de pago ni accounts de proveedores cloud.

El curso está pensado para estudiantes de ciberseguridad, desarrollo, datos y administración, y en general para cualquier perfil técnico junior que empiece a integrar LLMs en productos reales. No necesitas saber entrenar modelos ni desplegar Kubernetes: necesitas entender qué piezas componen un sistema IA, qué puede fallar en cada una y qué control aplica. Quien completa el recorrido se lleva un vocabulario preciso (prompt injection, poisoning en RAG, agencia excesiva, salida insegura), una checklist de 14 puntos aplicable a prototipos reales y una orientación normativa sólida sobre AI Act, RGPD, ENS, NIS2 y ciberresiliencia en el contexto español y europeo.

Anatomía del curso, sección por sección

El curso es una sola página dividida en nueve secciones encadenadas que van de lo conceptual (el mapa del sistema) a lo operativo (checklist, quiz y referencias). Vamos a recorrerlas en el mismo orden en que aparecen en la navegación.

Hero y modelo mental: el sistema IA como conjunto de piezas

La primera decisión pedagógica del curso es romper la idea de que "la IA" es una caja negra indivisible. El hero presenta un sistema de IA como la composición de aplicación, modelo, datos, permisos, herramientas, evaluación y operación, resumida en una frase que funciona como tesis de todo el curso: un sistema IA es software, datos, decisiones y permisos trabajando juntos, y la seguridad aparece cuando cada pieza tiene límites claros, pruebas y trazabilidad.

Junto al titular, una franja de tres ideas clave fija lo esencial en diez segundos: las cuatro funciones del NIST AI RMF (gobernar, mapear, medir y gestionar), las 12 familias del estándar de verificación OWASP AISVS y un cero muy expresivo: secretos dentro del prompt: cero. Las claves viven fuera del contexto del modelo. Si solo te llevaras una idea del curso, esa sería una candidata seria.

Mapa de seguridad IA: un grafo navegable de activos, amenazas y controles

El corazón visual del curso es un grafo interactivo construido con Cytoscape.js donde conviven tres tipos de nodos: activos, amenazas y controles, más un anillo de marcos normativos que conectan con todo lo anterior. Los ocho activos definidos en el código son:

• Sistema IA: el conjunto completo, con la consigna de separar responsabilidades entre aplicación, modelo y datos.
• Prompt: instrucciones de sistema, plantillas y contexto; con la regla de oro de no guardar secretos ahí y de diferenciar instrucciones de datos recuperados y entrada de usuario.
• Datos: entrenamiento, evaluación, documentos RAG, memoria y logs, con clasificación de sensibilidad y minimización de datos personales.
• Modelo: modelo base o ajustado, endpoint de inferencia y parámetros, con inventario de proveedor y versión.
• RAG: búsqueda, embeddings, base vectorial y ensamblado de contexto, con validación de fuentes y aislamiento por usuario o tenant.
• Herramientas: funciones, plugins, conectores, MCP y APIs invocables, con mínimo privilegio por herramienta.
• Identidad: usuarios, roles, sesiones y claves de API, incluida una advertencia muy actual: no confundir permisos del usuario con permisos del agente.
• Monitorización: logs, métricas, trazas y alertas de abuso, fuga de datos y costes anómalos.

Al pulsar cualquier nodo del grafo, un panel lateral muestra su descripción, sus detalles prácticos y las amenazas y controles relacionados. La idea pedagógica es que aprendas las relaciones por exploración: que descubras, por ejemplo, que el prompt conecta con la amenaza de prompt injection y esta a su vez con los controles de separar instrucciones y datos, validar contexto externo, limitar herramientas y exigir aprobación humana.

              MAPA DEL SISTEMA IA (extracto del grafo del curso)

   [Sistema IA]---+-[Prompt]--------> (Prompt injection)
                  +-[Datos]---------> (Divulgación sensible)
                  +-[RAG]-----------> (Poisoning en RAG)
                  +-[Modelo]--------> (Cadena de suministro)
                  +-[Herramientas]--> (Agencia excesiva)
                  +-[Identidad]
                  +-[Monitorización]>(Abuso del modelo)

   cada amenaza --> controles: separar instrucciones/datos,
   mínimo privilegio, aprobación humana, validación de salidas

Un detalle técnico interesante: si Cytoscape.js no carga (por ejemplo, sin conexión), el curso degrada a un modo alternativo con botones planos que permite seguir navegando los mismos nodos. El contenido no depende de la librería; la librería solo mejora la experiencia.

Riesgos que conviene nombrar: ocho amenazas con severidad y controles

La sección de riesgos presenta las ocho amenazas que el curso considera imprescindibles, cada una con categoría, severidad, activos afectados, descripción, impacto y lista de controles recomendados:

• Prompt injection (categoría Entrada, severidad Alta): una entrada maliciosa intenta alterar instrucciones o convertir contexto no fiable en órdenes; puede provocar fuga de datos o acciones no autorizadas.
• Divulgación sensible (Datos, Alta): exposición de datos personales, secretos o prompts internos a través de respuestas o logs.
• Cadena de suministro (Modelo, Media): modelos, datasets, librerías o conectores que introducen código o comportamiento no fiable, con puertas traseras incluidas.
• Poisoning en RAG (RAG, Alta): documentos manipulados que contaminan la base de conocimiento y hacen que el modelo cite contenido falso o siga instrucciones ocultas.
• Agencia excesiva (Agentes, Alta): el sistema ejecuta acciones sin límites claros ni confirmación, con permisos demasiado amplios.
• Salida insegura (Aplicación, Media): la aplicación confía en la salida del modelo y la renderiza o ejecuta sin validación, abriendo la puerta a XSS o inyección SQL.
• Abuso del modelo (Operación, Media): scraping, extracción o consumo excesivo del endpoint que eleva costes y degrada el servicio.
• Sobreconfianza (Gobernanza, Media): personas o procesos aceptan salidas sin revisión cuando el impacto lo exige.

Un filtro por categorías (Entrada, Datos, RAG, Agentes, Aplicación, Operación, Gobernanza) permite aislar cada familia, y cada tarjeta incluye un botón que salta al nodo correspondiente del grafo, reforzando la conexión entre amenaza y activo. Fíjate en que la taxonomía bebe directamente del OWASP GenAI LLM Top 10 y de MITRE ATLAS: es vocabulario de industria, no inventado para la ocasión.

Laboratorio de exposición: riesgos que cambian con el contexto

Para mí, esta es la sección más didáctica del curso. El laboratorio te plantea un caso de uso con cuatro desplegables: datos usados (públicos, internos o personales), fuente de contexto (sin RAG, RAG curado o RAG abierto), acciones del sistema (solo responde, sugiere cambios o ejecuta herramientas) y supervisión (aprobación humana y logs, logs parciales o sin revisión definida).

Cada combinación puntúa y el panel lateral recalcula en vivo el nivel de riesgo (bajo, medio, alto o crítico) con una barra de medición, un resumen del caso y la lista de controles prioritarios. La puntuación interna es reveladora: la ejecución de herramientas suma 3 puntos por sí sola, los datos personales 2 y el RAG abierto 2, mientras que una supervisión fuerte resta 1. Es decir, el modelo pedagógico dice exactamente lo que dice la práctica: los agentes que ejecutan acciones son el multiplicador de riesgo más grande, y la supervisión humana es el único factor que lo compensa.

   LABORATORIO DE EXPOSICIÓN - pesos del modelo de riesgo

   Datos         público 0   interno 1   personal 2
   Contexto      sin RAG 0   curado  1   abierto 2
   Acciones      responde 0  sugiere 1   ejecuta 3
   Supervisión   fuerte -1   parcial 1   débil   2

   0-2 bajo | 3-4 medio | 5-6 alto | 7+ crítico

Jugar cinco minutos con el laboratorio enseña más que leer cinco artículos: compruebas cómo un asistente inocente con datos públicos y sin RAG es riesgo bajo, y cómo el mismo asistente con RAG abierto, ejecución de herramientas y supervisión débil escala a crítico sin que cambie ni una línea de código.

Un matiz que aprecio especialmente: el curso evita el sensacionalismo. Las amenazas se presentan con severidad calibrada (no todo es «alto»), los controles son los que encontrarías en una revisión real y la sección normativa advierte explícitamente que la evaluación definitiva depende del caso, rol, sector y datos tratados. Esa mezcla de rigor y sobriedad es justo la actitud que conviene llevar a un proyecto con IA, y verla modelada en el material de estudio tiene más valor pedagógico de lo que parece.

Controles por ciclo de vida: seis etapas, de gobernanza a operación

La siguiente sección organiza los controles según el ciclo de vida del sistema, con seis tarjetas: Gobernanza (propósito, política de uso, inventario IA, modelo de responsabilidad), Datos (clasificación, minimización, etiquetado de sensibilidad, revisión de fuentes), Diseño (threat modeling, límites de prompt, permisos por acción), Construcción (SSDF, pruebas AISVS, revisión de dependencias), Despliegue (rate limiting, aislamiento, gestión de claves, rollback) y Operación (logs mínimos, alertas, evaluaciones periódicas).

El mensaje de fondo es que la seguridad de un sistema IA no es un checkpoint final sino una distribución de trabajo a lo largo de todo el ciclo: las decisiones de gobernanza de la semana uno determinan qué tan doloroso es el despliegue del mes seis.

Marco UE y España: siete marcos normativos conectados

Aquí el curso aterriza la parte regulatoria con siete marcos seleccionables en un tablero lateral: Reglamento Europeo de IA (AI Act, en vigor desde agosto de 2024 con aplicación general desde agosto de 2026), RGPD y LOPDGDD, guías de la AEPD, Esquema Nacional de Seguridad (RD 311/2022), AESIA (la autoridad española de supervisión de IA, RD 729/2023), NIS2 y el Reglamento de Ciberresiliencia (aplicación principal en diciembre de 2027).

Cada marco muestra estado normativo, resumen, obligaciones concretas (por ejemplo, para el AI Act: clasificar el sistema por riesgo y rol, evitar prácticas prohibidas, informar cuando una persona interactúa con IA, y documentar modelos de propósito general), etiquetas de ámbito y un enlace a la fuente oficial en el BOE, EUR-Lex o el organismo correspondiente. Además, al seleccionar un marco el grafo superior ilumina los nodos relacionados: la norma deja de ser texto abstracto y se conecta con activos y controles concretos.

El curso es honesto con sus límites: incluye la nota de que el contenido es de uso educativo y que la evaluación definitiva depende del caso, rol, sector y datos tratados. Ese matiz, lejos de restar valor, modela la actitud correcta ante cumplimiento.

Checklist mínima: catorce puntos persistentes

La checklist operativa resume el curso en catorpe puntos verificables, del inventario de modelos, proveedores, datasets, prompts y herramientas hasta el aviso claro a las personas cuando interactúan con IA. Entre medias: los secretos viven fuera de prompts, RAG, logs y ejemplos; el RAG filtra por identidad y tenant; las herramientas aplican mínimo privilegio; las acciones sensibles requieren confirmación humana; la salida se valida antes de renderizar o ejecutar; hay pruebas específicas contra prompt injection, fuga de datos y errores de autorización; y los cambios de modelo, prompt o dataset tienen evaluación y rollback. Los tres últimos puntos cubren clasificación según el AI Act, base jurídica y posible EIPD si hay datos personales, y trazabilidad a ENS, NIS2 o ciberresiliencia cuando aplique.

Cada casilla marcada se guarda en el almacenamiento local del navegador bajo la clave basic-seguridad-ia-checklist, así que puedes volver días después y retomar la revisión donde la dejaste, con un mensaje de progreso que evoluciona ("Empieza por inventario, datos y permisos" → "Buen avance…" → "Base revisada. Toca convertirla en pruebas y responsables").

Quiz rápido, referencias y glosario

El quiz de seis preguntas comprueba si reconoces el control adecuado para cada riesgo: dónde no deben vivir los secretos (respuesta: en prompts o documentos RAG), qué ocurre cuando documentos manipulados entran en una base RAG, qué práctica encaja con NIST AI RMF, qué marco revisar con datos personales, cómo verificar una salida generada y qué control reduce el riesgo de un agente destructivo. Las opciones incorrectas son deliberadamente verosímiles (subir la temperatura, más tokens de contexto, "una respuesta más creativa"), lo que obliga a razonar en lugar de descartar lo absurdo.

La sección de referencias es una biblioteca de 21 fuentes primarias filtrables por categoría (Gobernanza, GenAI, LLM, Verificación, Amenazas, Desarrollo, Aplicación, Normativa UE, Normativa España, Guías oficiales, Estándares) y buscables por texto libre: NIST AI RMF, NIST AI 600-1, OWASP GenAI LLM Top 10 2026, OWASP AISVS 1.0, MITRE ATLAS, ISO/IEC 42001, NIST SSDF, OWASP Top 10:2025, y todo el bloque normativo español y europeo ya mencionado, cada una con su enlace directo.

El curso cierra con un glosario esencial de cuatro términos en formato desplegable: prompt injection, RAG, agente y evaluación. Definiciones cortas y precisas, suficientes para leer documentación técnica sin perder el hilo.

Cómo está construido: mecánica interactiva sin frameworks

Todo el curso es una aplicación estática de tres ficheros: index.html (251 líneas), styles.css y un script.js de unas 1.280 líneas de JavaScript plano, sin frameworks, sin build, sin backend y sin base de datos. Puedes verlo y clonarlo en el repositorio de GitHub.

La arquitectura es la clásica de "datos como constantes + funciones de render". El contenido vive en arrays de objetos al principio del script (assets, threats, lifecycle, checklist, references, complianceFrameworks, quiz, labProfiles) y una familia de funciones render* pinta cada sección en su contenedor del HTML. Estado mínimo global (nodo seleccionado, filtros activos, índice del quiz) y una función init() que arranca todo al cargar el DOM.

Los detalles de interacción están cuidados con APIs nativas del navegador:

• Mapa: Cytoscape.js 3.34.1 cargado desde CDN con versión fijada, coloreado dinámico leído de las variables CSS del tema, rearranque cuando cambia el tamaño del contenedor mediante ResizeObserver, y un modo alternativo plano si la librería no está disponible.
• Quiz: una pregunta visible, respuesta única, botones que se deshabilitan al responder y se marcan con clases is-correct/is-wrong, feedback inmediato con la explicación del porqué ("Correcto. La supervisión explícita limita decisiones automatizadas con impacto real"), contador de aciertos y reinicio automático de puntuación al completar la vuelta.
• Laboratorio: recálculo en vivo con cada cambio de los cuatro selectores, agregación de puntuaciones, deduplicación de controles y barra de nivel animada.
• Persistencia: checklist y tema claro/oscuro guardados en localStorage, con respeto a la preferencia del sistema cuando no hay elección explícita.
• Accesibilidad y pulido: secciones con aparición al hacer scroll mediante IntersectionObserver, enlaces de saltar al contenido, paneles con aria-live que anuncian los cambios, y tema oscuro completo.

Para quien aprende desarrollo además de seguridad, el propio código es material de estudio: es un ejemplo compacto y legible de cómo construir una experiencia interactiva rica sin una sola dependencia de npm.

También conviene situar el curso dentro del ecosistema formativo. Existen muchos recursos sobre seguridad de LLMs, pero la mayoría o bien son listas de amenazas sin mecánica interactiva, o bien laboratorios de explotación que requieren entornos dedicados. Basic Seguridad IA ocupa el punto medio: no enseña a explotar nada, enseña a razonar como un revisor de seguridad. Por eso funciona igual para un estudiante de primer año que para un responsable técnico evaluando si el piloto de IA de su departamento puede pasar a producción.

Por qué la seguridad de sistemas IA es la nueva alfabetización profesional

Hace una década, "saber algo de seguridad" era un plus. Hoy, cualquier profesional que construye o usa IA en su trabajo está tomando decisiones de seguridad, le guste o no: decide qué datos pegan en un prompt, qué documentos indexan en el RAG de su equipo, qué permisos le dan al agente que "solo va a leer el CRM", y si revisa la salida antes de que llegue a un cliente. La superficie de ataque se ha democratizado y con ella la responsabilidad.

El prompt injection es el ejemplo perfecto de por esto ya no es territorio de especialistas. Un empleado pega un correo sospechoso en un asistente interno que tiene acceso a documentos corporativos, y ese correo puede contener instrucciones que el sistema ejecuta como propias. No hace falta explotar una vulnerabilidad de red: la vía de entrada es el propio lenguaje natural. Frente a eso, las contramedensias son arquitectónicas y culturales (separar instrucciones de datos, mínimo privilegio, aprobación humana), exactamente lo que este curso enseña a razonar.

Lo mismo ocurre con la exfiltración por contexto: cada documento RAG, cada conector y cada log es una potencial vía de salida de datos, y la ley ya está aquí. El AI Act impone transparencia y clasificación por riesgo, el RGPD aplica a cualquier tratamiento de datos personales aunque el procesador sea un LLM, y en España el ENS, la AESIA y NIS2 completan el cuadro para sector público y entidades esenciales. El profesional que hoy no sabe responder "¿qué marco se activa si este asistente trata datos personales en su RAG?" está tan expuesto como el que hace diez años no sabía qué era HTTPS.

Ahí está el valor diferencial de este curso: convierte esa alfabetización en algo tangible y verificable. No promueve miedo ni listas de marketing; enseña a nombrar riesgos, valorar exposición y elegir controles, con las fuentes oficiales a un clic. Para equipos que están empezando con IA generativa, además, la checklist de catorce puntos es un punto de partida de conversación excelente entre desarrollo, seguridad y legal.

Cómo usar el curso: un plan de estudio en cuatro sesiones

El curso se completa en unas dos o tres horas de lectura atenta, pero rinde más si lo conviertes en un plan corto. Mi propuesta, empezando en la página del curso:

• Sesión 1. Mapa y vocabulario (45 min): recorre el hero y el grafo interactivo, pulsando los ocho activos uno a uno y leyendo sus detalles. Después pasa por la sección de riesgos y filtra por cada categoría. Objetivo: salir sabiendo nombrar las ocho amenazas y asociarlas a sus activos.
• Sesión 2. Laboratorio (30 min): abre el laboratorio y prueba combinaciones extremas. Empieza por el caso más benigno, sube un factor cada vez y observa cómo cambia el nivel y qué controles aparecen. Repite el caso "agente con ejecución de herramientas" variando solo la supervisión. Objetivo: interiorizar que el riesgo es una función del contexto, no del modelo.
• Sesión 3. Controles, normativa y checklist (45 min): lee las seis etapas del ciclo de vida, explora los siete marcos normativos y sus obligaciones, y luego usa la checklist sobre un proyecto real tuyo (aunque sea un prototipo personal). Marca lo que cumplies y anota los huecos. Objetivo: convertir la teoría en una brecha concreta y accionable.
• Sesión 4. Verificación (20 min): haz el quiz sin prisa, leyendo la explicación de cada respuesta incluida la de las que aciertes, y elige dos o tres referencias de la biblioteca (sugiero OWASP GenAI LLM Top 10 y NIST AI RMF) para profundizar. Objetivo: consolidar y dejar sembrada la siguiente capa de estudio.

Un consejo final: comparte la checklist resultante con tu equipo. Catorce casillas son pocas para una auditoría y suficientes para empezar a hablar el mismo idioma sobre seguridad de IA, que es, al final, de lo que se trata.