Capítulo 19 — Seguridad de la IA y del aprendizaje automático: alcance y teoría | Grado Seguridad de IA y aprendizaje automático

Aprendizaje gratuito y abierto para quienes desean proteger a las personas y la tecnología. No se necesita una cuenta para estudiar ni consultar las respuestas.

Mapa de la lección

Lección 19 publicada. Mapa, ejemplo, EX055.

flowchart TD
  N0["Resultados de aprendizaje"]
  N1["19.1 Definiciones"]
  N2["19.2 La taxonomía"]
  N3["19.3 Por qué el aprendizaje automático es vulnerable"]
  N4["19.4 Marcos"]
  N5["Síntesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Ejemplo resuelto"]
  EX --> Q["Ejercicio EX055"]

Dibujo lógico

flowchart LR
  N0["Resultados de aprendizaje"]
  N1["19.1 Definiciones"]
  N2["19.2 La taxonomía"]
  N3["19.3 Por qué el aprendizaje automático es vulnerable"]
  N4["19.4 Marcos"]
  N5["Síntesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX055"]

[Resultados de aprendizaje]
    |
    v
[19.1 Definiciones]
    |
    v
[19.2 La taxonomía]
    |
    v
[19.3 Por qué el aprendizaje automático es vulnerable]
    |
    v
[19.4 Marcos]
    |
    v
[Síntesis]
    |
    v
[Ejemplo resuelto] --> [Ejercicio EX055]

Resultados de aprendizaje

Usted podrá (1) definir la seguridad de la IA y distinguirla de la seguridad funcional de la IA (AI safety) y de la IA responsable; (2) describir las clases de ataque de la taxonomía NIST AI 100-2 E2025; (3) explicar por qué el aprendizaje automático es vulnerable por principio; y (4) situar los principales marcos.

19.1 Definiciones

La seguridad de la IA protege los sistemas de IA y los procesos que los rodean frente a ataques deliberados y usos indebidos, y protege a terceros de los ataques facilitados por la IA. La seguridad funcional de la IA (AI safety) se ocupa del comportamiento dañino incluso sin atacante. La IA responsable abarca la equidad, la transparencia y la rendición de cuentas. Las áreas se solapan: una inyección de instrucciones es un ataque de seguridad que puede causar resultados inseguros o injustos. En LCH, las tres confluyen en un solo sistema. Un documento de un asociado que hace que Ask Lumen anuncie un falso cierre de una clínica es un ataque, así que pertenece a la seguridad; los pacientes que por ello pierden su atención son un resultado de seguridad funcional. Rina mantiene separados los términos en sus informes para que cada equipo sepa qué problemas le corresponden.

19.2 La taxonomía

NIST AI 100-2 E2025 clasifica los ataques a la IA predictiva por su objetivo —ruptura de la disponibilidad, violación de la integridad, compromiso de la privacidad— y añade el mal uso para la IA generativa. Las clases de ataque incluyen la evasión (entradas en el momento de la prueba), el envenenamiento (de los datos de entrenamiento o del modelo), los ataques a la privacidad (inferencia de pertenencia, reconstrucción de datos, extracción del modelo) y, para los sistemas generativos, la inyección de instrucciones directa e indirecta. Los atacantes se caracterizan por su conocimiento (caja blanca, gris o negra) y sus capacidades (control de los datos de entrenamiento, control del modelo, acceso por consultas). Rina sitúa en ella cada uno de los sistemas de LCH. Ask Lumen es generativo, así que se aplican la inyección de instrucciones y el mal uso; NoShow y DocSort son predictivos. Un atacante externo suele tener solo acceso por consultas de caja negra, mientras que un contratista que etiqueta cartas de DocSort tiene control de los datos de entrenamiento, una capacidad más fuerte.

19.3 Por qué el aprendizaje automático es vulnerable

Los modelos aprenden patrones estadísticos a partir de datos, no reglas; generalizan de forma imperfecta y son sensibles a cambios pequeños y cuidadosamente elegidos en la entrada (Szegedy et al., arXiv:1312.6199; Goodfellow et al., arXiv:1412.6572). Heredan todo lo que contienen sus datos, incluido el veneno. Los grandes modelos de lenguaje siguen las instrucciones que encuentran en cualquier parte de su entrada. Estas propiedades son inherentes, así que la seguridad se apoya en controles por capas y no en una única corrección. El laboratorio de evasión lo muestra de forma concreta: el mismo clasificador de juguete que obtiene 0,985 con entradas limpias cae a un nivel cercano al azar cuando el presupuesto de perturbación llega a uno, sin ningún cambio en el propio modelo.

19.4 Marcos

El NIST AI RMF (AI 100-1) y su perfil de IA generativa (AI 600-1) organizan la gestión del riesgo; OWASP LLM 2025 enumera los riesgos de las aplicaciones; MITRE ATLAS cataloga técnicas de adversarios con estudios de casos; la ISO/IEC 42001 especifica un sistema de gestión de la IA; el Reglamento de IA de la UE fija obligaciones legales para algunos sistemas. Responden a preguntas distintas. Rina usa OWASP para comprobar los riesgos de aplicación de Ask Lumen, ATLAS para encontrar ejemplos de ataques reales para su sesión informativa con el personal y el AI RMF para estructurar el proceso general de riesgos de LCH. Que el Reglamento de IA de la UE se aplique depende del uso de cada sistema, así que registra esa evaluación por separado en lugar de suponer que una sola respuesta cubre los tres sistemas.

19.5 Ejemplo resuelto (caso sintético de LCH)

Rina clasificó los riesgos de LCH: Ask Lumen — inyección indirecta de instrucciones a través de documentos (integridad), divulgación de información sensible (privacidad); NoShow — inferencia de pertenencia (privacidad), manipulación de campos controlados por los pacientes (integridad, evasión); DocSort — cartas elaboradas para provocar un encaminamiento erróneo (evasión), envenenamiento mediante cartas de entrenamiento reetiquetadas (integridad). La clasificación mostró que cada sistema tenía riesgos de privacidad y de integridad, pero por vías distintas. La exposición principal de Ask Lumen era lo que lee; la de NoShow, lo que revela; la de DocSort, quién daba forma a sus datos de entrenamiento. Esa diferencia llevó a Rina a asignar responsables distintos: el equipo del chatbot, el delegado de protección de datos y el equipo de documentación clínica.

19.6 Errores y límites

Tratar la seguridad de la IA como si fuera solo el jailbreak de chatbots.
Esperar que un solo control corrija vulnerabilidades inherentes.
Confundir los términos de seguridad funcional y de seguridad.

Centrarse en los jailbreaks habría pasado por alto por completo el riesgo de envenenamiento de DocSort, ya que nadie conversa con DocSort. Ningún control aislado cubre la evasión, el envenenamiento y la inyección, así que LCH necesita varias capas. Usar «seguridad funcional» cuando se quiere decir «seguridad» deja sin aclarar si se supone un atacante, lo que cambia las pruebas que deben ejecutarse y quién es responsable de corregir el problema. Los informes de Rina mantienen separados los términos, de modo que un falso cierre de clínica causado por un documento de un asociado se archiva como ataque y la atención que perdieron los pacientes, como resultado de seguridad funcional.

Ejercicios

EX055 — Definiciones. Clasifique: un chatbot da un consejo erróneo sobre medicación sin que haya ningún atacante; un atacante le hace revelar los datos de otro paciente. Rúbrica: 3 = seguridad funcional frente a seguridad, con razones; 2 = solo etiquetas; 1 = una; 0 = incorrecto.
EX056 — Taxonomía. Clasifique la elaboración de cartas contra DocSort por objetivo, fase y conocimiento. Rúbrica: 3 = integridad, despliegue/evasión, caja negra o gris; 2 = dos; 1 = uno; 0 = nada.
EX057 — Inherente. Dé dos razones por las que el aprendizaje automático es vulnerable por principio. Rúbrica: 3 = generalización/sensibilidad estadística, dependencia de los datos, seguimiento de instrucciones presentes en la entrada; 2 = una; 1 = vago; 0 = incorrecto.

Síntesis

La seguridad de la IA tiene un alcance preciso y un vocabulario compartido. Sus vulnerabilidades son estructurales, y por eso el resto del libro construye defensas por capas y medidas.

Siga estudiando — capítulo 19 de 40

← Capítulo 18 (borrador) · Índice de capítulos del curso · Capítulo 20 (borrador) →