Glosario de Seguridad de IA

Los términos que aparecen una y otra vez en el Curso de Seguridad de IA y en cualquier conversación sobre proteger sistemas construidos con LLM y agentes. Como todo glosario de la academia, crece con cada módulo del curso. Todo aquí es seguridad defensiva: sirve para blindar tus propios sistemas, no para atacar los ajenos.

El terreno

Superficie de ataque (attack surface) — El conjunto de todos los puntos por donde una entrada no confiable puede entrar al sistema: el prompt del usuario, los documentos del RAG, las respuestas de las herramientas, los pesos del modelo, las dependencias. En un sistema con LLM es mucho más grande que en software clásico porque el lenguaje mismo es ejecutable. Se desarrolla en El modelo de amenazas de la IA.

Modelo de amenazas (threat model) — El ejercicio de enumerar quién podría atacar el sistema, qué querría lograr, por dónde entraría y qué se pierde si lo logra. Sin él, la seguridad es una lista de trucos sueltos en vez de una defensa con prioridades.

STRIDE — El marco clásico para clasificar amenazas por categoría: suplantación (Spoofing), manipulación (Tampering), repudio (Repudiation), fuga de información (Information disclosure), denegación de servicio (Denial of service) y elevación de privilegios (Elevation of privilege). Sirve de checklist para no olvidar familias enteras de riesgo.

La confusión datos/instrucciones — El pecado original de los LLM: el modelo recibe instrucciones y datos por el mismo canal de texto y no distingue de forma confiable unas de otros. Es la raíz de la que nace toda la inyección de prompts, y por eso no se “arregla” del todo, solo se contiene.

OWASP Top 10 para LLM — La lista de referencia de los diez riesgos más comunes en aplicaciones con LLM, mantenida por OWASP y actualizada en 2025 con categorías nuevas como fuga de system prompt y consumo ilimitado; desde diciembre de 2025 tiene una lista hermana para agentes, el OWASP Top 10 for Agentic Applications 2026 (ASI01–ASI10). Es el punto de partida para no inventar la rueda. Se desarrolla en OWASP Top 10 para LLM.

Marco defensivo — La postura de todo el curso: cada técnica de ataque que se muestra existe para construir la defensa o el test que la detiene. Nunca instrucciones operables contra sistemas de terceros.

Red team / blue team — Los dos roles del ejercicio de seguridad: el equipo rojo ataca a propósito para encontrar cómo se rompe el sistema, el equipo azul defiende y corrige. La misma persona suele hacer ambos en un equipo chico.

Inyección y evasión

Prompt injection (inyección de prompts) — Meter instrucciones en el texto que el modelo procesa para que haga algo que el desarrollador no autorizó. Es el riesgo número uno del OWASP Top 10 y la consecuencia directa de la confusión datos/instrucciones. Se desarrolla en Prompt injection a fondo.

Injection directa — El propio usuario escribe las instrucciones maliciosas en su mensaje: “ignora tus reglas y…”. Es la familia más conocida y la más fácil de mitigar, porque atacante y víctima son la misma persona.

Injection indirecta — Las instrucciones vienen escondidas dentro de contenido que el sistema lee sin sospechar: un documento, una página web, un correo, un chunk del RAG. Es la crítica, porque el atacante y la víctima son personas distintas y el usuario legítimo no ve nada raro. Reaparece en Seguridad de RAG.

Jailbreak — Convencer al modelo de saltarse su política de contenido mediante roles, ficción, hipótesis o escalada gradual. Ataca la alineación del modelo más que la lógica de tu aplicación. Se desarrolla en Jailbreaks y evasión.

System prompt leakage (fuga del prompt de sistema) — Que el modelo revele sus instrucciones internas. Importa menos por el secreto en sí y más porque le entrega al atacante el mapa para el siguiente intento; la mitigación real es no poner secretos en el system prompt.

Delimitadores (delimiters) — Marcas explícitas (etiquetas, comillas triples, bloques) que separan el contenido no confiable de las instrucciones. Ayudan pero no bastan solos: un atacante puede imitar el delimitador si lo conoce.

Spotlighting / datamarking — Técnicas de Microsoft para marcar el texto no confiable de forma que el modelo lo trate como datos y no como órdenes: codificarlo, intercalar un token especial entre palabras (datamarking) o encerrarlo con delimitadores únicos. Reduce la inyección indirecta sin eliminarla.

Patrón dual-LLM / CaMeL — La defensa estructural contra la inyección: un LLM privilegiado que ve la petición del usuario y llama herramientas, y un LLM en cuarentena que procesa el contenido no confiable sin poder actuar. CaMeL lo refina con un intérprete que rastrea el flujo de información y aplica políticas por origen de los datos. Se desarrolla en Prompt injection a fondo.

Adversarial suffix / GCG (Greedy Coordinate Gradient) — Un sufijo de tokens aparentemente sin sentido, optimizado con gradientes, que anexado a un prompt fuerza al modelo a obedecer aunque debiera negarse. Su rasgo peligroso es la transferibilidad: un sufijo entrenado en un modelo abierto suele funcionar en otros. Se desarrolla en Jailbreaks y evasión.

Payload splitting (fragmentación de la carga) — Partir la instrucción maliciosa en trozos inocuos que el sistema recompone más adelante, para esquivar filtros que buscan la frase completa.

Ofuscación (obfuscation) — Esconder el ataque cambiando su forma sin cambiar su significado: base64, homoglifos, otro idioma, espacios invisibles. Obliga a que el filtro entienda intención y no solo cadenas literales.

Agentes y tools

Excessive agency (agencia excesiva) — El riesgo de darle al agente más poder del que su tarea necesita. OWASP lo descompone en tres: exceso de funcionalidad (tools que no debería alcanzar), exceso de permisos (tools con más privilegios de los necesarios) y exceso de autonomía (acciones de alto impacto sin humano que las apruebe). Se desarrolla en Seguridad de agentes con tools.

Confused deputy (delegado confundido) — Un componente con permisos legítimos ejecuta, engañado, una orden en beneficio del atacante. El agente es el delegado perfecto: tiene acceso a tus sistemas y obedece texto que puede venir de un tercero. Es la razón por la que la inyección indirecta es tan grave.

Mínimo privilegio (least privilege) — Darle al agente exactamente los permisos que su tarea exige y nada más. Es lo que convierte un jailbreak exitoso en un incidente sin consecuencias. Ver también Observabilidad y seguridad.

Intersección de permisos (usuario ∩ agente) — La regla de que el agente solo puede hacer lo que el usuario final tiene permitido Y lo que el agente tiene permitido: la intersección de ambos conjuntos, nunca la unión. Evita que un usuario escale privilegios a través del agente.

Human-in-the-loop (humano en el bucle) — Insertar una aprobación humana antes de las acciones irreversibles o de alto impacto. Es la mitigación directa del exceso de autonomía; su implementación está en Human in the loop.

Allowlist / denylist (lista de permitidos / de bloqueados) — Dos filosofías opuestas: la allowlist permite solo lo enumerado y niega el resto (segura por defecto); la denylist niega lo enumerado y permite el resto (siempre incompleta). En seguridad se prefiere allowlist salvo casos muy acotados.

Separación lectura/escritura — Distinguir las tools que solo consultan de las que modifican el mundo, y aplicarles controles distintos. Una tool de lectura mal usada filtra datos; una de escritura mal usada causa daño permanente.

Rate limiting (limitación de tasa) — Poner un techo a cuántas veces por unidad de tiempo el agente puede llamar una tool o el usuario puede llamar al agente. Contiene tanto el abuso como el bucle descontrolado.

Presupuesto de acciones (action budget) — Un límite duro de pasos, tokens o costo por tarea, tras el cual el agente se detiene. Es la contención contra el agente que se pasea de más y contra el consumo ilimitado.

Guardrails

Guardrail (barrera de protección) — Una verificación que se ejecuta antes o después del modelo y puede bloquear, reescribir o marcar la entrada o la salida. Es la capa de defensa que rodea al LLM sin depender de que el modelo se porte bien. Se desarrolla en Guardrails.

Input / output filtering (filtrado de entrada / salida) — Revisar lo que entra al modelo (para atrapar ataques) y lo que sale (para atrapar contenido dañino, fugas o alucinaciones) antes de que llegue al usuario. Son dos guardrails distintos con objetivos distintos.

Llama Guard — El modelo de Meta que clasifica prompts y respuestas como seguros o inseguros según una taxonomía de riesgos, y si son inseguros indica qué categoría se violó. Llama Guard 3 (8B, 14 categorías, solo texto) y Llama Guard 4 (12B, texto e imagen). Se usa como filtro de entrada y de salida.

Prompt Guard — El clasificador chico de Meta (86M de parámetros) entrenado para detectar inyecciones y jailbreaks antes de cada llamada al LLM. A diferencia de Llama Guard, no juzga el contenido dañino sino los intentos de esquivar las defensas.

Moderación de contenido (content moderation) — El guardrail que detecta y bloquea categorías prohibidas (odio, violencia, autolesión, contenido sexual). Suele apoyarse en una API de moderación o en un modelo como Llama Guard.

Validación de esquema (schema validation) — Comprobar que la salida cumple una estructura declarada, típicamente con Pydantic o JSON Schema. Es el guardrail más barato: atrapa una familia entera de fallos con pocas líneas y sin llamar a un modelo.

Groundedness (fundamentación) — Verificar que la respuesta está respaldada por el contexto entregado y no inventada. Es el guardrail central contra la alucinación en un sistema de RAG.

NeMo Guardrails — El framework de NVIDIA para definir guardrails conversacionales con un lenguaje propio (Colang), que controla temas permitidos, flujos y verificaciones de entrada y salida.

Guardrails AI — El framework de Python que define validadores declarativos sobre la salida del modelo (formato, PII, toxicidad, competidores mencionados) y puede reintentar o corregir cuando fallan.

Falso positivo / negativo — Los dos errores de todo guardrail: el falso positivo bloquea algo legítimo (mata utilidad), el falso negativo deja pasar un ataque (mata seguridad). Ajustar un guardrail es elegir el balance entre ambos, no eliminarlos.

Datos y privacidad

PII (Personally Identifiable Information, información personal identificable) — Cualquier dato que permita identificar a una persona: nombre, correo, teléfono, dirección, identificador nacional. Es lo primero que hay que evitar que aparezca donde no corresponde. Se desarrolla en Datos, privacidad y PII.

Memorización / training data extraction (extracción de datos de entrenamiento) — Que el modelo reproduzca literalmente fragmentos de sus datos de entrenamiento, incluyendo secretos o PII, cuando se le induce con el prompt correcto. Es un riesgo tanto del modelo base como de uno afinado con datos privados.

Minimización de datos (data minimization) — El principio de recolectar y retener solo los datos estrictamente necesarios para la tarea. Menos datos guardados es menos superficie para filtrar.

Redacción / pseudonimización (redaction / pseudonymization) — Quitar o reemplazar los datos sensibles antes de mandarlos al modelo o de guardarlos: tachar el número real, sustituir el nombre por un token estable. Reduce el daño de una fuga sin perder la utilidad.

Metadata filtering (filtrado por metadatos) — Restringir qué documentos puede recuperar el RAG según etiquetas de acceso, para que un usuario nunca reciba un chunk que no le corresponde. Es el control de acceso llevado a la recuperación.

Aislamiento por tenant (tenant isolation) — Garantizar que los datos de un cliente jamás se mezclen con los de otro, ni en la base vectorial, ni en la caché, ni en el contexto del modelo. Su fallo es la fuga cross-tenant.

Derecho al borrado (right to erasure) — La obligación legal de eliminar los datos de una persona cuando lo pide. Se complica con los embeddings y con un modelo afinado, donde “borrar” no es simplemente borrar una fila.

GDPR (Reglamento General de Protección de Datos) — El reglamento europeo de privacidad que impone consentimiento, minimización, derecho al borrado y multas por incumplimiento. Es el marco legal que convierte la privacidad de un buen deseo en un requisito.

RAG y corpus

Data / knowledge poisoning (envenenamiento de datos / de conocimiento) — Inyectar contenido malicioso en el corpus que el RAG recupera, de modo que el modelo lo lea como fuente confiable. Sirve para plantar instrucciones (inyección indirecta) o para sesgar respuestas. Se desarrolla en Seguridad de RAG.

Vector & embedding weaknesses (debilidades de vectores y embeddings) — Los riesgos propios de la capa de recuperación: envenenamiento del índice, inversión de embeddings para recuperar el texto original, o consultas diseñadas para traer documentos ajenos.

Cross-tenant leakage (fuga entre inquilinos) — Que una consulta de un cliente recupere documentos de otro por falta de aislamiento en la base vectorial. Es uno de los fallos más graves y más silenciosos del RAG multi-inquilino.

Sanitización de ingesta (ingestion sanitization) — Limpiar los documentos antes de indexarlos: quitar instrucciones ocultas, texto invisible, HTML activo y contenido sospechoso. Es la primera línea contra el envenenamiento.

Procedencia de documentos (document provenance) — Registrar de dónde vino cada documento del corpus y con qué nivel de confianza, para poder rastrear un envenenamiento hasta su fuente y tratar distinto lo confiable de lo abierto.

Supply chain

Deserialización insegura (insecure deserialization / pickle) — Cargar un archivo que, al deserializarse, ejecuta código. El formato pickle de Python (usado por torch.load) puede correr código arbitrario al abrir un checkpoint, lo que lo vuelve un vector de supply chain. Se desarrolla en Supply chain de modelos.

safetensors — El formato de Hugging Face que guarda solo los tensores de pesos, sin permitir código embebido. Es la alternativa segura a pickle y el que hay que exigir al descargar modelos; se volvió el formato por defecto en el Hub.

weights_only — El parámetro de torch.load (por defecto en PyTorch 2.6) que restringe la deserialización a un conjunto acotado de tipos y bloquea los callables peligrosos. Reduce el riesgo, pero no es una frontera de seguridad formal: cargar solo safetensors sigue siendo lo correcto.

Modelo troyanizado / backdoor (trojaned model / backdoor) — Un modelo que se comporta normal salvo cuando ve un disparador (trigger) específico, ante el cual ejecuta la conducta que el atacante plantó durante el entrenamiento. No se detecta con evals normales porque el disparador es raro a propósito.

Typosquatting — Publicar un modelo o paquete con un nombre casi idéntico a uno legítimo (llama-3 vs llama_3) para que alguien lo descargue por error. Es un ataque de nombre, no de contenido.

SBOM (Software Bill of Materials, lista de materiales de software) — El inventario completo de todo lo que compone tu sistema: modelos, datasets, librerías y versiones. Es lo que permite saber si te afecta una vulnerabilidad recién descubierta sin adivinar.

Model card (ficha del modelo) — El documento que describe un modelo: para qué sirve, con qué datos se entrenó, sus límites y sus riesgos conocidos. Es la fuente para decidir si un modelo es apto y confiable antes de usarlo.

Verificación de hash / firma (hash / signature verification) — Comprobar que el archivo descargado coincide con un hash publicado o lleva una firma criptográfica válida. Es lo que garantiza que nadie manipuló el modelo en tránsito.

Ejecución y contención

Sandboxing (aislamiento) — Ejecutar código no confiable (el que genera o corre un agente) dentro de un entorno cerrado que no puede tocar el sistema anfitrión ni la red. Es la contención de último recurso cuando todo lo demás falla. Se desarrolla en Sandboxing y ejecución de código.

Contenedor vs microVM — Los dos niveles de aislamiento: un contenedor comparte el kernel del anfitrión (más rápido, frontera más débil); una microVM da un kernel propio con virtualización por hardware (más lento de arrancar, frontera mucho más dura). Para código no confiable, la microVM gana.

gVisor / Firecracker — Las dos tecnologías de referencia: gVisor (Google) intercepta las llamadas al sistema en un kernel de espacio de usuario, reduciendo la superficie sin una VM completa; Firecracker (AWS) arranca microVMs con kernel propio en unos 125 ms. Firecracker aísla más fuerte; gVisor integra más fácil con contenedores.

Control de egress (egress control) — Restringir a qué destinos de red puede conectarse el sandbox, idealmente con una allowlist cerrada. Sin él, el código aislado igual puede exfiltrar datos hacia afuera.

Gestión de secretos (secrets management) — Nunca poner claves, tokens ni credenciales en el prompt, el código del agente ni el sandbox; inyectarlas desde un gestor y solo cuando se necesitan.

Tokens de corta vida (short-lived tokens) — Credenciales que expiran en minutos u horas, de modo que un token filtrado sirve poco tiempo. Es lo que limita el daño de una fuga inevitable.

RCE (Remote Code Execution, ejecución remota de código) — El peor desenlace: el atacante consigue ejecutar su propio código en tu infraestructura. Muchas cadenas de ataque (inyección, deserialización insegura) tienen como meta final el RCE.

Sistema de archivos efímero (ephemeral filesystem) — Un disco que se borra al terminar cada ejecución, para que nada persista entre tareas y un atacante no deje trampas para la siguiente.

Unbounded consumption (consumo ilimitado / DoS) — El riesgo (LLM10 de OWASP) de que alguien fuerce al sistema a gastar recursos sin límite: tokens, cómputo, dinero. Se contiene con rate limiting y presupuesto de acciones.

Ofensiva y descubrimiento

Red teaming ofensivo — Atacar el sistema propio de forma sistemática y a escala para descubrir cómo se rompe antes de que lo haga alguien más. Se corre como una suite propia con umbrales distintos al resto. Se desarrolla en Red teaming ofensivo y desde el lado de la medición en el glosario de Evals.

garak — El escáner de vulnerabilidades de LLM de NVIDIA, con una biblioteca amplia de probes (sondas) que barren el modelo buscando jailbreaks, fugas y alucinaciones. Barre la superficie de forma estática y exhaustiva.

PyRIT (Python Risk Identification Tool) — El framework de red teaming de Microsoft, orientado a ataques multiturno: un modelo atacante genera prompts adversariales, los manda al objetivo y un juez puntúa si hubo violación. Es la contraparte dinámica de garak: no barre, persigue.

Ataque asistido por LLM — Usar un modelo para generar variantes de ataque, refinarlas según la respuesta del objetivo o traducir un ataque de una familia a otra. Es lo que hace que el red teaming escale más allá de lo manual.

Dataset adversarial — El conjunto de casos de ataque, cada uno con su familia, severidad, comportamiento esperado y contenido prohibido en la salida. Es la materia prima de la suite de red teaming.

Tasa de resistencia (resistance rate) — La proporción de ataques que el sistema aguantó. Se reporta por familia y nunca como promedio global, porque el promedio esconde la familia crítica en la que estás fallando.

Severidad (severity) — La escala que dice cuánto importa cada fallo, para que no todos bloqueen igual. Un jailbreak que filtra datos no pesa lo mismo que uno que dice una grosería, y la gobernanza depende de esa distinción.

Gobernanza

Respuesta a incidentes (incident response) — El plan de qué hacer cuando el sistema es vulnerado: detectar, contener, erradicar, recuperar y aprender. Sin plan escrito de antemano, el incidente se improvisa en el peor momento. Se desarrolla en Incidentes y gobernanza.

Kill switch (interruptor de apagado) — El mecanismo para apagar en caliente una tool, un grupo de tools o el sistema entero ante un incidente grave, sin redeploy. Debe existir, estar probado y ser accesible antes de necesitarlo, no diseñarse en caliente.

Revocación en caliente (hot revocation) — Poder invalidar al instante un token, una clave o el acceso de una herramienta sin reiniciar el sistema. Es lo que corta el acceso del atacante mientras el incidente sigue vivo.

Audit log encadenado (registro de auditoría encadenado) — Un registro donde cada entrada incluye el hash de la anterior, de modo que alterar o borrar un evento pasado se vuelve detectable. Es lo que hace confiable la reconstrucción de un incidente.

Riesgo aceptado (accepted risk) — La decisión explícita y documentada de convivir con un riesgo que no se mitiga, firmada por alguien con autoridad. Convierte un agujero silencioso en una elección consciente con dueño.

NIST AI RMF (AI Risk Management Framework) — El marco voluntario del NIST estadounidense para gestionar el riesgo de la IA, organizado en las funciones gobernar, mapear, medir y gestionar. Es un manual operativo de referencia, aunque no sea ley.

EU AI Act (Reglamento de IA de la UE) — La ley europea, obligatoria y basada en riesgo, que clasifica los sistemas de IA por nivel de peligro e impone requisitos según el uso, con multas por incumplimiento. Es el marco que fija el mínimo legal.

ISO/IEC 42001 — La norma internacional certificable para un sistema de gestión de IA: acredita que la organización tiene las estructuras y procesos para gobernar la IA de forma responsable. Es lo que vuelve demostrable ante terceros lo que el NIST AI RMF ayuda a operar.

Modelo de madurez (maturity model) — La escala que describe en qué nivel está tu programa de seguridad, de reactivo y ad hoc a medido y optimizado. Sirve para saber dónde estás y cuál es el siguiente paso realista, no para presumir.

Material relacionado

• El modelo de amenazas de la IA — superficie de ataque, STRIDE y por qué el lenguaje es ejecutable.
• OWASP Top 10 para LLM — los diez riesgos de referencia y cómo se mapean a tu sistema.
• Prompt injection a fondo — directa, indirecta y la defensa dual-LLM / CaMeL.
• Seguridad de agentes con tools — excessive agency, confused deputy y mínimo privilegio.
• Guardrails — Llama Guard, Prompt Guard y el balance entre falso positivo y negativo.
• Supply chain de modelos — pickle vs safetensors, backdoors, SBOM y firmas.
• Sandboxing y ejecución de código — contenedor vs microVM, gVisor, Firecracker y egress.
• Incidentes y gobernanza — kill switch, audit log y los tres marcos de gobernanza.
• Glosario de Evals — el red teaming desde el lado de la medición y las métricas.
• Observabilidad y seguridad — mínimo privilegio y monitoreo en producción.