Capítulo 36 — Seguridad de la IA y del aprendizaje automático: rendimiento y escala
Mapa de la lección
Lección 36 publicada. Mapa, ejemplo, EX106.
flowchart TD
N0["Resultados de aprendizaje"]
N1["36.1 Los controles de seguridad cuestan rendimiento"]
N2["36.2 Consumo ilimitado"]
N3["36.3 Dimensionamiento de las cuotas"]
N4["36.4 Escala y eficacia de los controles"]
N5["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX106"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje"]
N1["36.1 Los controles de seguridad cuestan rendimiento"]
N2["36.2 Consumo ilimitado"]
N3["36.3 Dimensionamiento de las cuotas"]
N4["36.4 Escala y eficacia de los controles"]
N5["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX106"]
[Resultados de aprendizaje]
|
v
[36.1 Los controles de seguridad cuestan rendimiento]
|
v
[36.2 Consumo ilimitado]
|
v
[36.3 Dimensionamiento de las cuotas]
|
v
[36.4 Escala y eficacia de los controles]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX106]
Resultados de aprendizaje
Usted será capaz de (1) relacionar la ingeniería del rendimiento (latencia, capacidad de procesamiento, coste) con los controles de seguridad; (2) defenderse del consumo ilimitado y de la denegación de servicio; (3) dimensionar cuotas y presupuestos; y (4) mantener la eficacia de los controles a escala.
36.1 Los controles de seguridad cuestan rendimiento
Cada barrera de protección, clasificador, segundo modelo y paso de aprobación añade latencia y coste. Bajo carga, los equipos sienten la tentación de desactivar controles. Diseñe los controles con presupuestos de rendimiento desde el principio y mídalos como cualquier otra funcionalidad. Un presupuesto hace explícito el compromiso: por ejemplo, las barreras de protección pueden añadir como máximo 150 ms a una respuesta de Wrench. Si un control supera su presupuesto, el equipo lo optimiza o cambia el lugar donde se ejecuta, en lugar de retirarlo bajo presión. Medir los controles de forma continua también muestra cuándo uno se vuelve poco a poco más caro, como podría ocurrirle a un clasificador cuando los documentos se alargan.
36.2 Consumo ilimitado
OWASP LLM10 abarca los ataques que agotan recursos o presupuestos: entradas extremadamente largas, prompts que provocan salidas muy largas, bucles recursivos de agentes y volúmenes altos de peticiones. Controles: límites de tamaño de las entradas, topes de tokens de salida, tiempos máximos de cómputo por petición, número máximo de pasos del agente, cuotas de tokens por cliente y alertas de coste. El laboratorio del cubo de testigos muestra cómo los ajustes de tasa y de ráfaga equilibran el servicio a los usuarios normales con la protección frente a las avalanchas de peticiones.
"""Lab R: token-bucket limits against unbounded consumption (synthetic).
Simulates 60 seconds of requests from a normal client and a flooding client
against a model endpoint with a per-client token bucket."""
import random
rng = random.Random(4)
def simulate(rate_per_s, burst, reqs):
tokens, last, ok = burst, 0.0, 0
for t in reqs:
tokens = min(burst, tokens + (t - last) * rate_per_s); last = t
if tokens >= 1: tokens -= 1; ok += 1
return ok
normal = sorted(rng.uniform(0, 60) for _ in range(90))
flood = sorted(rng.uniform(0, 60) for _ in range(3000))
for rate, burst in ((5, 20), (2, 10), (1, 5)):
print(f"limit={rate}/s burst={burst:2d} normal_served={simulate(rate, burst, normal):3d}/90 "
f"flood_served={simulate(rate, burst, flood):4d}/3000")
Salida esperada:
limit=5/s burst=20 normal_served= 90/90 flood_served= 319/3000
limit=2/s burst=10 normal_served= 90/90 flood_served= 129/3000
limit=1/s burst= 5 normal_served= 62/90 flood_served= 64/3000
Cada control limita una dimensión distinta, y los atacantes encontrarán la que falte. El bucle desbocado de Wrench mostró que faltaba el límite de pasos.
36.3 Dimensionamiento de las cuotas
Use percentiles del uso observado (por ejemplo, el percentil 99 de tokens por usuario y hora) más un margen, y diferencie niveles. Vuelva a ajustarlas cuando cambie el uso. Combine las cuotas con la detección de anomalías, ya que los atacantes pueden mantenerse justo por debajo de los límites fijos. El tercer ajuste del laboratorio muestra el riesgo de fijar los límites a ojo: un límite de 1 por segundo con una ráfaga de 5 rechaza 28 de 90 peticiones normales. El dimensionamiento basado en percentiles lo evita partiendo de lo que hacen los usuarios reales. Los niveles permiten que una integración intensiva, pero legítima, tenga una cuota mayor sin aumentar la de todos. Un atacante que conoce el límite puede mantenerse justo por debajo, así que la detección de anomalías en los patrones, como la proporción de entradas distintas, cubre lo que los límites fijos no pueden.
36.4 Escala y eficacia de los controles
A escala, los sucesos raros se vuelven comunes: una tasa de éxito de la inyección del 0,1 % sobre 10 millones de documentos al mes son 10.000 éxitos. Los controles que dependen de la revisión humana deben dimensionarse para ese volumen, o diseñarse de modo que cada éxito tenga un impacto acotado. Un equipo pequeño no puede revisar con cuidado diez mil éxitos al mes uno por uno, así que el diseño debe hacer que cada uno sea inofensivo por sí mismo: una propuesta contaminada que necesita confirmación, una herramienta que puede comentar, pero no cerrar. Unas tasas aceptables en un piloto pueden volverse inaceptables en producción solo por el volumen, así que Sam recalcula los recuentos esperados cada vez que crece el uso.
36.5 Ejemplo resuelto (caso sintético de NRS)
Una integración defectuosa hizo que Wrench entrara en un bucle: cada resultado de herramienta desencadenaba otra búsqueda, hasta llegar a 400 pasos en una sola tarea y consumir el presupuesto de un día. Sam fijó un máximo de 12 pasos por tarea, un tope de tokens por tarea y una alerta de coste al 150 % de la mediana diaria. El clasificador de inyecciones pasó a ejecutarse solo sobre el contenido recuperado y no sobre cada mensaje, lo que redujo su coste en un 60 % sin reducir la cobertura de la vía no confiable.
Trasladar el clasificador es seguro porque la vía no confiable es por donde llegan las inyecciones; los mensajes que escriben los técnicos autenticados no son el riesgo para el que se construyó.
36.6 Errores y límites
- Límites por número de peticiones que ignoran el coste en tokens y en cómputo.
- Desactivar controles bajo carga.
- Diseños de revisión humana que no escalan con el volumen.
Contar solo las peticiones permite que un prompt enorme cueste tanto como miles de prompts pequeños. Desactivar controles bajo carga crea exactamente las condiciones que elegiría un atacante, ya que puede provocarlo con avalanchas de peticiones. Los diseños de revisión que suponen un número fijo de casos se rompen cuando crece el volumen. La revisión de operaciones de Sam pregunta, para cada control, cuál es su coste por petición y qué le ocurre con diez veces el tráfico actual.
Ejercicios — capítulo 36
- EX106 — Lectura del laboratorio. ¿Qué ajuste del laboratorio protege frente a la avalancha atendiendo por completo al cliente normal con el límite más estricto? Rúbrica: 3 = 2/s con ráfaga 10: 90/90 normales, 129/3000 de la avalancha; 2 = solo el ajuste; 1 = vago; 0 = incorrecto.
- EX107 — Aritmética de escala. Con un éxito del 0,05 % sobre 4 millones de documentos al mes, ¿cuántos éxitos hay al mes? Rúbrica: 3 = 2.000, con su implicación; 2 = solo la cifra; 1 = desliz; 0 = nada.
- EX108 — Límites de los bucles. Enumere cuatro límites para los bucles de agentes. Rúbrica: 3 = número máximo de pasos, tokens por tarea, tiempo real, alertas de coste/interruptor de corte; 2 = tres; 1 = uno o dos; 0 = ninguno.
Síntesis del capítulo
El rendimiento y la seguridad están acoplados. Los controles con presupuesto, las cuotas que tienen en cuenta el cómputo y los límites de los bucles defienden frente al consumo ilimitado y mantienen la protección asequible a escala.
Siga estudiando — capítulo 36 de 50
← Capítulo 35 (borrador) · Índice de capítulos del curso · Capítulo 37 (borrador) →