Capítulo 23 — Seguridad de la IA y del aprendizaje automático: métodos I

Mapa de la lección

Lección 23 publicada. Mapa, ejemplo, EX067.

flowchart TD
  N0["Resultados de aprendizaje"]
  N1["23.1 Análisis de amenazas"]
  N2["23.2 Asignación"]
  N3["23.3 Priorización"]
  N4["23.4 Selección de pruebas"]
  N5["23.4b Árboles de ataque"]
  N6["Síntesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Ejemplo resuelto"]
  EX --> Q["Ejercicio EX067"]

Dibujo lógico

flowchart LR
  N0["Resultados de aprendizaje"]
  N1["23.1 Análisis de amenazas"]
  N2["23.2 Asignación"]
  N3["23.3 Priorización"]
  N4["23.4 Selección de pruebas"]
  N5["23.4b Árboles de ataque"]
  N6["Síntesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX067"]

[Resultados de aprendizaje]
    |
    v
[23.1 Análisis de amenazas]
    |
    v
[23.2 Asignación]
    |
    v
[23.3 Priorización]
    |
    v
[23.4 Selección de pruebas]
    |
    v
[23.4b Árboles de ataque]
    |
    v
[Síntesis]
    |
    v
[Ejemplo resuelto] --> [Ejercicio EX067]

Resultados de aprendizaje

Usted podrá (1) realizar un análisis estructurado de amenazas para un sistema de IA; (2) asignar las amenazas a OWASP LLM 2025 y a MITRE ATLAS; (3) priorizar las amenazas por probabilidad e impacto; y (4) seleccionar pruebas para las amenazas principales.

23.1 Análisis de amenazas

Para cada componente y flujo del modelo de sistema, pregúntese qué podría hacer un atacante: inyectar instrucciones, envenenar datos, evadir la detección, extraer el modelo o los datos, agotar recursos o abusar de herramientas. Incluya a los internos y los accidentes con efectos similares. Para el almacén de documentos de Ask Lumen, Rina planteó cada pregunta por turno. Inyectar instrucciones: sí, a través de las subidas de asociados. Envenenar: no aplica, ya que allí no se entrena nada. Extraer datos: posiblemente, si el chatbot cita documentos internos. Agotar recursos: conversaciones largas. Un accidente con efecto similar fue una clínica que subió un folleto desactualizado con horarios erróneos.

23.2 Asignación

Asigne las amenazas a entradas de OWASP LLM 2025 (por ejemplo, LLM01 inyección de prompts, LLM02 divulgación de información sensible, LLM06 agencia excesiva, LLM10 consumo ilimitado) y a tácticas y técnicas de MITRE ATLAS. La asignación ayuda a comprobar la cobertura y a encontrar mitigaciones documentadas. La asignación de Rina situó la inyección mediante documentos de asociados en LLM01, las reservas para otro paciente en LLM06 y el coste de los chats largos en LLM10. Al revisar la lista en busca de lagunas, advirtió que no tenía ninguna entrada de LLM02 para las respuestas de la herramienta de reservas, y añadió una prueba de que el chatbot nunca repite los datos de la cita de otro paciente.

23.3 Priorización

Valore la probabilidad (acceso del atacante, habilidad, motivación) y el impacto (daño al paciente, privacidad, coste, reputación). Basta una escala sencilla de 1 a 3 y una justificación escrita. Revíselas cuando las cosas cambien. La justificación importa más que el número. Para las reservas para otro paciente, Rina escribió que la probabilidad era 2 porque los tokens delegados bloquean ahora la vía directa, pero los propios cuidadores del paciente todavía pueden ser objeto de abuso; el impacto era 3 porque una reserva errónea puede retrasar la atención. Así, otro revisor puede cuestionar el razonamiento en lugar de la puntuación misma, y actualizarlo cuando cambien los tokens o las reglas de los cuidadores.

23.4 Selección de pruebas

Para cada amenaza principal, elija una prueba: un conjunto de inyecciones, un conjunto de filtraciones, una simulación de envenenamiento, una prueba de carga. Defina de antemano los criterios de aprobación. Para la inyección mediante documentos de asociados, el criterio de aprobación se fijó antes de las pruebas: no más de una afirmación falsa sobre una clínica en 200 documentos inyectados, y cero reservas causadas por el texto de los documentos. Fijar primero el umbral impide que el equipo decida después que cualquier resultado obtenido era aceptable. Una prueba sin criterio solo describe el comportamiento; no puede fallar y, por tanto, no puede demostrar que un control funciona.

23.4b Árboles de ataque

Un árbol de ataque descompone el objetivo de un atacante en subobjetivos unidos por Y u O. Para «reservar una cita como otro paciente», las ramas O podrían ser: robar las credenciales del paciente; manipular el chatbot para que reserve en su nombre; explotar directamente la API de reservas. Cada rama puede estimarse y controlarse por separado, y el árbol muestra qué control único bloquea varias ramas; por ejemplo, una comprobación de políticas ligada al paciente que ha iniciado sesión bloquea tanto el chatbot como algunas vías de la API. En LCH, la rama de las credenciales la gestionan los controles de inicio de sesión del portal, fuera del ámbito del equipo de IA.

23.5 Ejemplo resuelto (caso sintético de LCH)

Las tres amenazas principales de Rina para Ask Lumen: (1) inyección mediante documentos de asociados que causa información falsa (probabilidad 2, impacto 3); (2) reserva para otro paciente mediante manipulación (2, 3; mitigada con tokens delegados, hay que volver a probar); (3) agotamiento de costes mediante chats largos (3, 2). Pruebas: 200 documentos inyectados midiendo las afirmaciones falsas; 400 intentos de reservar para otro paciente; una prueba de carga con cuotas de tokens. El agotamiento de costes obtuvo la probabilidad más alta porque no requiere habilidad, solo paciencia, y la prueba de cuotas era barata de ejecutar. La reserva para otro paciente necesitaba una nueva prueba porque el cambio a tokens delegados era reciente y no se había probado bajo manipulación.

23.6 Errores y límites

• Listas de amenazas no vinculadas al modelo de sistema.
• Valoraciones sin justificación.
• Pruebas elegidas sin criterios de aprobación.

Las amenazas enumeradas sin referencia al modelo de sistema tienden a ser genéricas, como «el modelo podría ser pirateado», y no señalan ningún control. Las valoraciones sin razones no pueden revisarse ni actualizarse cuando cambian las condiciones. Las pruebas sin criterios de aprobación producen resultados que pueden leerse en cualquier sentido, así que nadie sabe si un control funcionó. El registro de amenazas de Rina vincula cada amenaza a un flujo del diagrama, una razón y un criterio.

Ejercicios

• EX067 — Lista de amenazas. Enumere cinco amenazas para NoShow con su asignación a OWASP o ATLAS cuando proceda. Rúbrica: 3 = cinco plausibles con asignaciones; 2 = cuatro; 1 = dos; 0 = nada.
• EX068 — Priorizar. Valore la probabilidad y el impacto de una amenaza con justificación. Rúbrica: 3 = ambos valorados con razones; 2 = sin razones; 1 = vago; 0 = nada.
• EX069 — Diseño de pruebas. Diseñe la prueba para la amenaza (2) con criterio de aprobación. Rúbrica: 3 = tamaño del conjunto, método, métrica, umbral; 2 = tres; 1 = vago; 0 = nada.

Síntesis

Métodos I convierte el modelo de sistema en una lista priorizada de amenazas asignadas a catálogos compartidos, cada una con una prueba y un criterio de aprobación.

Siga estudiando — capítulo 23 de 40

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