Capítulo 28 — Seguridad de la IA y del aprendizaje automático: análisis de fallos | 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 28 publicada. Mapa, ejemplo, EX082.

flowchart TD
  N0["Resultados de aprendizaje"]
  N1["28.1 Tipos de causas"]
  N2["28.2 Evidencia y cronologías"]
  N3["28.3 Métodos de causa raíz"]
  N4["28.4 Revisiones sin culpables"]
  N5["28.5 ¿Deriva o ataque?"]
  N6["28.7b Convertir las causas en correcciones"]
  N7["Síntesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Ejemplo resuelto"]
  EX --> Q["Ejercicio EX082"]

Dibujo lógico

flowchart LR
  N0["Resultados de aprendizaje"]
  N1["28.1 Tipos de causas"]
  N2["28.2 Evidencia y cronologías"]
  N3["28.3 Métodos de causa raíz"]
  N4["28.4 Revisiones sin culpables"]
  N5["28.5 ¿Deriva o ataque?"]
  N6["28.7b Convertir las causas en correcciones"]
  N7["Síntesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX082"]

[Resultados de aprendizaje]
    |
    v
[28.1 Tipos de causas]
    |
    v
[28.2 Evidencia y cronologías]
    |
    v
[28.3 Métodos de causa raíz]
    |
    v
[28.4 Revisiones sin culpables]
    |
    v
[28.5 ¿Deriva o ataque?]
    |
    v
[28.7b Convertir las causas en correcciones]
    |
    v
[Síntesis]
    |
    v
[Ejemplo resuelto] --> [Ejercicio EX082]

Resultados de aprendizaje

Usted podrá (1) analizar fallos e incidentes de IA para encontrar sus causas raíz; (2) distinguir causas del modelo, de los datos, de la integración y del proceso; (3) usar cronologías y evidencia; y (4) redactar revisiones posteriores al incidente sin culpables, con acciones.

28.1 Tipos de causas

Los fallos de la IA pueden proceder del modelo (comportamiento), de los datos (envenenados, desplazados o filtrados), de la integración (herramientas, permisos, análisis sintáctico) o del proceso (revisión, gestión de cambios, formación). La mayoría de los incidentes tienen varias causas contribuyentes. El incidente del falso cierre del ejemplo resuelto que sigue lo muestra: una causa de proceso (ninguna revisión de las subidas), una causa de integración (fuentes mezcladas en la recuperación) y una causa de diseño (ninguna comprobación de fundamentación) tenían que estar presentes a la vez. Eliminar cualquiera de ellas habría evitado o limitado el daño, y por eso las acciones abordaron las tres y no solo la más visible.

28.2 Evidencia y cronologías

Recoja los registros de la aplicación, de la pasarela del modelo, del servicio de políticas y de las herramientas; anote las versiones del modelo, del prompt y de los datos; construya una cronología desde la primera causa hasta la detección y la resolución. Preserve la evidencia antes de modificar los sistemas. En el incidente del cierre, el primer paso fue exportar los registros de recuperación y la copia indexada del folleto antes de que nadie lo borrara, porque el folleto era la evidencia principal. La cronología iba después desde la subida, a la indexación nocturna, a la primera respuesta falsa y al aviso de la recepcionista, lo que mostró cuánto duró la exposición.

28.3 Métodos de causa raíz

Pregunte «por qué» repetidamente hasta llegar a causas sobre las que pueda actuar; use árboles de fallos para los fallos complejos. Evite detenerse en «el modelo hizo algo mal»: pregunte por qué ese comportamiento tuvo impacto (permisos excesivos, falta de confirmación). En el incidente del cierre, la cadena fue: ¿por qué oyeron los pacientes lo del cierre? El modelo repitió un folleto. ¿Por qué leyó el folleto? Las subidas de asociados se indexaban sin revisión. ¿Por qué? El proceso de subida era anterior al chatbot y nadie lo actualizó cuando Ask Lumen empezó a leer el mismo almacén. Esa última respuesta apuntaba a la gestión de cambios, una acción que LCH podía emprender.

28.4 Revisiones sin culpables

Céntrese en los sistemas y las condiciones, no en las personas. Registre lo que ocurrió, el impacto, las causas, lo que salió bien y las acciones con responsables y fechas. Difunda ampliamente las lecciones. El asociado que subió el folleto había seguido el proceso que se le había dado, y la recepcionista que advirtió el problema recibió reconocimiento en la revisión. Tratar el incidente como un fallo del sistema mantuvo la disposición del personal a comunicar respuestas extrañas del chatbot, que fue precisamente como se descubrió el problema. Culpar a alguien habría enseñado al personal a callar.

28.5 ¿Deriva o ataque?

Los cambios en las tasas de error pueden deberse a la deriva (nuevos patrones en los datos) o a un ataque. Busque agrupamientos por origen, momento y correlación con entradas concretas. El laboratorio de monitorización marca a un cliente sintético cuyo patrón de consultas difiere marcadamente del de los demás.

"""Lab A: spotting extraction-style abuse in a synthetic API log.
Flags clients whose query volume or input diversity is anomalous."""
import random, statistics
rng = random.Random(21)
log = []
for c in range(12):
    for _ in range(rng.randint(40, 90)):
        log.append((f"client{c:02d}", round(rng.gauss(0, 1), 1)))
for i in range(600):                      # synthetic scraper: many, grid-like inputs
    log.append(("client99", round(-3 + 6*(i % 61)/60, 1)))
by = {}
for c, x in log: by.setdefault(c, []).append(x)
vol = {c: len(v) for c, v in by.items()}
med = statistics.median(vol.values()); mad = statistics.median(abs(v-med) for v in vol.values())
for c in sorted(by):
    z = (vol[c]-med)/(1.4826*mad); uniq = len(set(by[c]))/len(by[c])
    flag = "FLAG" if z > 3.5 else "ok"
    print(f"{c} queries={vol[c]:3d} robust_z={z:6.2f} distinct_ratio={uniq:.2f} {flag}")

Salida esperada:

client00 queries= 50 robust_z= -0.34 distinct_ratio=0.56 ok
client01 queries= 64 robust_z=  0.45 distinct_ratio=0.52 ok
client02 queries= 81 robust_z=  1.41 distinct_ratio=0.44 ok
client03 queries= 46 robust_z= -0.56 distinct_ratio=0.52 ok
client04 queries= 52 robust_z= -0.22 distinct_ratio=0.48 ok
client05 queries= 40 robust_z= -0.90 distinct_ratio=0.57 ok
client06 queries= 42 robust_z= -0.79 distinct_ratio=0.57 ok
client07 queries= 87 robust_z=  1.74 distinct_ratio=0.48 ok
client08 queries= 56 robust_z=  0.00 distinct_ratio=0.52 ok
client09 queries= 50 robust_z= -0.34 distinct_ratio=0.62 ok
client10 queries= 68 robust_z=  0.67 distinct_ratio=0.50 ok
client11 queries= 89 robust_z=  1.85 distinct_ratio=0.42 ok
client99 queries=600 robust_z= 30.58 distinct_ratio=0.10 FLAG

En el laboratorio, client99 envió 600 consultas con una proporción de entradas distintas de 0,10, mientras que los clientes normales enviaron entre 40 y 89 con proporciones cercanas a 0,5; esa combinación de volumen y patrón repetitivo sugiere un sondeo sistemático más que una deriva. La deriva normalmente desplazaría un poco a muchos clientes, no mucho a un solo cliente, y no reduciría la variedad de las consultas.

28.6 Ejemplo resuelto (caso sintético de LCH)

A varios pacientes se les dijo que una clínica había cerrado. Cronología: un asociado subió un folleto con texto oculto; se indexó durante la noche; Ask Lumen repitió el cierre 23 veces antes de que una recepcionista lo comunicara. Causas: subidas de asociados indexadas sin revisión (proceso), recuperación que mezclaba fuentes de asociados y de LCH (integración), ninguna comprobación frente a los datos estructurados de las clínicas (diseño). Acciones: cola de revisión para las subidas de asociados, etiquetado de las fuentes, comprobación de fundamentación. Las 23 respuestas falsas se contaron a partir de los registros de conversación, y el personal de la clínica llamó por teléfono a cada paciente afectado para confirmar su cita.

28.7 Errores y límites

Culpar al modelo o a una persona y detenerse ahí.
Modificar los sistemas antes de preservar los registros.
Acciones sin responsables.

Detenerse en «el modelo alucinó» habría dejado sin cambios el proceso de subida, y el siguiente folleto hostil habría producido el mismo resultado. Borrar el folleto antes de copiarlo habría destruido la evidencia de cómo se escribió el texto oculto. Las acciones sin responsables ni fechas tienden a quedar abiertas indefinidamente; cada una de las tres acciones del cierre tenía un responsable designado y un plazo.

28.7b Convertir las causas en correcciones

Cada causa encontrada en una revisión de Ask Lumen se convierte en un cambio concreto con un responsable: una comprobación de salida que falta se convierte en un validador, un paso confuso del manual de actuación se reescribe, una reversión no probada se ensaya. La revisión solo se cierra cuando cada cambio se ha hecho y comprobado, no cuando termina la reunión. En el incidente del cierre, la revisión siguió abierta hasta que la comprobación de fundamentación se probó contra el folleto original. La prueba mostró que Ask Lumen respondía ahora con los horarios de apertura reales del archivo estructurado y señalaba el conflicto para su revisión, tras lo cual se cerró la revisión y la prueba del folleto se añadió al conjunto de regresión.

Ejercicios

EX082 — Causas. Clasifique las causas del incidente del folleto en modelo, datos, integración y proceso. Rúbrica: 3 = clasificación correcta; 2 = la mayoría; 1 = vago; 0 = nada.
EX083 — Lectura del laboratorio. ¿Qué cliente se marca y con qué evidencia? Rúbrica: 3 = client99, 600 consultas, z robusta 30,58, proporción de distintas 0,10; 2 = el nombre; 1 = vago; 0 = incorrecto.
EX084 — Acciones de la revisión. Redacte dos acciones de la revisión del folleto con responsables y fechas. Rúbrica: 3 = concretas, con responsable y fecha; 2 = una; 1 = vago; 0 = nada.

Síntesis

El análisis de fallos convierte los incidentes en aprendizaje: cronologías basadas en evidencia, causas por capas y revisiones sin culpables con acciones que tienen responsable.

Siga estudiando — capítulo 28 de 40

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