Capítulo 31 — Seguridad de la IA y del aprendizaje automático: implementación II | Ingeniería 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.

Capítulo 31 — Seguridad de la IA y del aprendizaje automático: implementación II

Mapa de la lección

Lección 31 publicada. Mapa, ejemplo, EX091.

flowchart TD
  N0["Resultados de aprendizaje"]
  N1["31.1 Monitorización y detección de abusos"]
  N2["31.2 Integridad de la canalización de datos"]
  N3["31.3 Carga y actualización seguras de modelos"]
  N4["31.4 Registro y alertas"]
  N5["31.6b Probar las alertas de principio a fin"]
  N6["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Ejemplo resuelto"]
  EX --> Q["Ejercicio EX091"]

Dibujo lógico

flowchart LR
  N0["Resultados de aprendizaje"]
  N1["31.1 Monitorización y detección de abusos"]
  N2["31.2 Integridad de la canalización de datos"]
  N3["31.3 Carga y actualización seguras de modelos"]
  N4["31.4 Registro y alertas"]
  N5["31.6b Probar las alertas de principio a fin"]
  N6["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX091"]

[Resultados de aprendizaje]
    |
    v
[31.1 Monitorización y detección de abusos]
    |
    v
[31.2 Integridad de la canalización de datos]
    |
    v
[31.3 Carga y actualización seguras de modelos]
    |
    v
[31.4 Registro y alertas]
    |
    v
[31.6b Probar las alertas de principio a fin]
    |
    v
[Síntesis del capítulo]
    |
    v
[Ejemplo resuelto] --> [Ejercicio EX091]

Resultados de aprendizaje

Usted será capaz de (1) implementar la monitorización y la detección de abusos en los servicios de modelos; (2) implementar controles de integridad en la canalización de datos; (3) implementar la carga y la actualización seguras de modelos; y (4) integrar los controles con el registro y las alertas.

31.1 Monitorización y detección de abusos

Registre por cliente los volúmenes de consultas, la diversidad de las entradas, el número de tokens, los rechazos y las propuestas de llamadas a herramientas. Los estadísticos robustos (mediana y desviación absoluta mediana) encuentran los valores atípicos sin que estos los distorsionen. El laboratorio señala un extractor sintético (scraper) que envía un barrido de entradas en forma de cuadrícula, típico de los intentos de extracción.

"""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

El extractor destaca en ambas medidas: 600 consultas dan una z robusta superior a 30, y una proporción de entradas distintas cercana a una de cada diez muestra que repite una cuadrícula fija de 61 valores. Los clientes ordinarios se sitúan entre 40 y 89 consultas, con proporciones en torno a la mitad. Usar la mediana y la MAD evita que el propio volumen del extractor eleve el umbral con el que se le juzga.

31.2 Integridad de la canalización de datos

Calcule hashes de los datos en la ingesta; mantenga versiones inmutables; exija fusiones revisadas para los cambios de etiquetas; ejecute comprobaciones automáticas de duplicados, cambios en el equilibrio de clases y correlaciones sospechosas entre características y etiquetas (posibles disparadores); ponga en cuarentena las fuentes nuevas hasta que se revisen. Cada comprobación apunta a una vía de envenenamiento. Los hashes y las versiones inmutables impiden las ediciones silenciosas. Las fusiones de etiquetas revisadas detectan a un contratista que invierte etiquetas. Las comprobaciones de equilibrio y de correlación buscan la firma de una puerta trasera, como una característica que predice casi a la perfección una clase en los datos nuevos, pero no en los antiguos. La cuarentena da tiempo a los revisores para muestrear una fuente nueva antes de que ningún modelo aprenda de ella, lo que resulta mucho más barato que volver a entrenar después.

31.3 Carga y actualización seguras de modelos

Cargue solo artefactos firmados cuyos resúmenes del manifiesto coincidan; use formatos que solo contengan tensores; verifique en el dispositivo de destino; conserve la versión anterior para poder revertir; registre qué versión atendió cada petición. La secuencia se comprueba por orden en el dispositivo: firma, después resúmenes, después formato. La carga falla de forma cerrada si falla cualquier paso, y el dispositivo sigue ejecutando la versión verificada anterior. Registrar la versión de cada petición permite a los investigadores relacionar una salida extraña con el modelo exacto que la produjo, lo que importa cuando un proveedor informa más tarde de una versión defectuosa y NRS necesita saber a qué inspecciones afectó.

31.4 Registro y alertas

Correlacione los ID de petición entre los servicios del modelo, de políticas y de herramientas. Las alertas deben ser específicas («client99 z robusta = 30,6; proporción de entradas distintas 0,10») y dirigirse a un responsable con un manual de operación. Evite registrar íntegramente el contenido sensible de los prompts; registre hashes o formas censuradas cuando sea posible, de acuerdo con las obligaciones de protección de datos. Una alerta específica permite al ingeniero de guardia juzgar la gravedad de inmediato; «actividad inusual» le obliga a repetir el análisis. Los manuales de operación indican las primeras comprobaciones, como confirmar si el cliente es un socio conocido, y cuándo escalar.

31.5 Ejemplo resuelto (caso sintético de NRS)

NRS abrió una API limitada de TrackEye a un socio. Sam desplegó las reglas de monitorización: una z robusta superior a 3,5 en el volumen diario, o una proporción de entradas distintas inferior a 0,2 con un volumen alto, desencadena una revisión. En el primer mes se señaló un script del socio; era un bucle de reintentos mal configurado, no un ataque, y el socio lo corrigió. Sam mantuvo la regla y documentó el falso positivo. Un bucle de reintentos y un barrido de extracción producen ambos un volumen alto, así que la segunda regla, una proporción baja de entradas distintas, ayuda a distinguirlos: un bucle de reintentos reenvía las mismas pocas entradas, mientras que la extracción reparte las consultas de forma sistemática. Documentar el falso positivo da al siguiente revisor un patrón conocido que comprobar primero.

31.6 Errores y límites

Umbrales de media y desviación típica que el propio valor atípico infla.
Registrar indefinidamente prompts completos con datos personales.
Actualizaciones cargadas sin comprobar la firma.

Un umbral basado en la media sube con cada usuario intensivo, de modo que un extractor grande puede elevar el listón por encima de su propio volumen y librarse de la alerta. Los prompts completos conservados indefinidamente se convierten en un almacén de datos personales que es en sí mismo un objetivo y puede incumplir las normas de conservación. Las actualizaciones sin firmar permiten a cualquiera que llegue al dispositivo sustituir el modelo. Cada uno de estos puntos figura en la revisión de monitorización de Sam como una pregunta de sí o no con la evidencia adjunta.

31.6b Probar las alertas de principio a fin

Cada regla de monitorización de Wrench y TrackEye se prueba inyectando un suceso sintético en preproducción y comprobando que la alerta llega al ingeniero de guardia con contexto suficiente para actuar. Las reglas que nunca se han disparado en una prueba se tratan como no verificadas. Las dos reglas de la API de TrackEye de Sam se probaron así antes de que el socio empezara a operar: un cliente sintético que enviaba 600 consultas en forma de cuadrícula en preproducción tenía que disparar la regla de la proporción de entradas distintas y avisar al ingeniero de guardia. La primera alerta real del mes, el bucle de reintentos mal configurado del socio, llegó entonces por una vía que ya se sabía que funcionaba, con el volumen del cliente y su z robusta en el mensaje.

Ejercicios — capítulo 31

EX091 — Lectura del laboratorio. ¿Qué z robusta y qué proporción de entradas distintas tenía client99, y por qué usar la mediana y la MAD? Rúbrica: 3 = 30,58 y 0,10; robustas frente a la influencia de los valores atípicos; 2 = solo las cifras; 1 = vago; 0 = incorrecto.
EX092 — Comprobación de disparadores. Describa una comprobación automática de posibles disparadores de puertas traseras en datos de entrenamiento nuevos. Rúbrica: 3 = buscar características poco frecuentes fuertemente correlacionadas con una etiqueta, comparar con versiones anteriores, señalar para revisión; 2 = parcial; 1 = vago; 0 = nada.
EX093 — Privacidad en los registros. ¿Cómo se mantienen registros útiles que preserven la privacidad? Rúbrica: 3 = censurar o aplicar hashes al contenido, límites de conservación, control de acceso, conservar los metadatos; 2 = dos; 1 = uno; 0 = ninguno.

Síntesis del capítulo

La implementación II añade los controles detectivos y de integridad: monitorización robusta, comprobaciones de integridad de datos y modelos, y un registro correlacionado y respetuoso con la privacidad.

Siga estudiando — capítulo 31 de 50

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