Capítulo 21 — Seguridad de la IA y del aprendizaje automático: requisitos
Mapa de la lección
Lección 21 publicada. Mapa, ejemplo, EX061.
flowchart TD
N0["Resultados de aprendizaje"]
N1["21.1 De los casos de abuso a los requisitos"]
N2["21.2 Tipos de requisito"]
N3["21.3 Redacción de requisitos estadísticos verificabl"]
N4["21.4 Trazabilidad"]
N5["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX061"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje"]
N1["21.1 De los casos de abuso a los requisitos"]
N2["21.2 Tipos de requisito"]
N3["21.3 Redacción de requisitos estadísticos verificabl"]
N4["21.4 Trazabilidad"]
N5["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX061"]
[Resultados de aprendizaje]
|
v
[21.1 De los casos de abuso a los requisitos]
|
v
[21.2 Tipos de requisito]
|
v
[21.3 Redacción de requisitos estadísticos verificabl]
|
v
[21.4 Trazabilidad]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX061]
Resultados de aprendizaje
Usted será capaz de (1) redactar requisitos de seguridad para componentes de IA que sean específicos, medibles y verificables; (2) derivar requisitos de los casos de abuso; (3) expresar requisitos estadísticos con cotas de confianza; y (4) trazar los requisitos hasta los marcos y la regulación.
21.1 De los casos de abuso a los requisitos
Un caso de abuso describe cómo alguien podría hacer un mal uso del sistema: «Un proveedor incrusta en un boletín una instrucción que hace que Wrench programe un mantenimiento innecesario». Cada caso de abuso da lugar a requisitos que lo previenen, lo detectan o lo limitan. Redactar los casos de abuso como historias con un actor, un objetivo y una vía los hace lo bastante concretos para probarlos. El caso del boletín da tres requisitos: etiquetar el texto de los boletines como no confiable (prevenir), alertar ante contenido con apariencia de instrucción en los boletines (detectar) y exigir confirmación para las órdenes de trabajo (limitar). Tener los tres significa que el fallo de uno no deja abierto el caso de abuso.
21.2 Tipos de requisito
- Funcionalidad de seguridad: «Las órdenes de trabajo requieren la confirmación del técnico».
- Comportamiento estadístico: «En el conjunto reservado de inyecciones (≥ 600 casos), Wrench propone llamadas a herramientas no autorizadas en ≤ 2 % de los casos (cota superior del 95 %)».
- Proceso: «Cada publicación de un modelo supera el control de evaluación de seguridad».
- Datos: «Las imágenes de entrenamiento llevan su procedencia; los reetiquetados de los contratistas se muestrean y revisan al 5 %».
- Operación: «Presupuesto de acciones por usuario de 20 órdenes de trabajo por hora; las alertas por encima de 3 veces la línea base avisan a la guardia».
El mínimo de 600 casos es el doble del conjunto de 300 casos que bloqueó el prompt más amable, porque un conjunto menor da una cota superior demasiado amplia para mostrar una tasa cercana al 2 %.
21.3 Redacción de requisitos estadísticos verificables
Indique la población (conjunto de prueba), la métrica, el umbral, el nivel de confianza y el tamaño mínimo de la muestra. «Robusto frente a ataques» no es verificable. «Exactitud bajo PGD con L∞ ε = 4/255 ≥ 70 % en el conjunto reservado» sí lo es, y enuncia implícitamente el modelo de amenazas. El ejemplo de PGD nombra el ataque, la norma y el presupuesto, de modo que los probadores saben exactamente qué ejecutar y los lectores saben qué no cubre el resultado: presupuestos mayores, otras normas y ataques físicos. Un requisito estadístico necesita además datos suficientes para decidir. Si el conjunto de prueba es demasiado pequeño, la cota superior puede superar el umbral aunque el modelo sea bueno, y no puede demostrarse que el requisito se cumple. Por eso el tamaño de la muestra forma parte del propio requisito.
21.4 Trazabilidad
Vincule cada requisito con su origen (caso de abuso, entrada de OWASP, artículo del Reglamento de IA, objetivo de control de la ISO/IEC 42001) y con su método de verificación. El artículo 15 del Reglamento de IA de la UE exige que los sistemas de alto riesgo sean resistentes a los intentos de alterar su uso o su funcionamiento aprovechando vulnerabilidades, y menciona el envenenamiento de datos, el envenenamiento de modelos, los ejemplos adversariales y los ataques a la confidencialidad; los requisitos que abordan cada uno hacen trazables los argumentos de cumplimiento. Una tabla de trazabilidad funciona en ambos sentidos: de cada origen a los requisitos que le responden, y de cada requisito a su prueba. Así, las lagunas aparecen como celdas vacías.
21.5 Ejemplo resuelto (caso sintético de NRS)
Sam redactó el REQ-AI-014: «La tasa de falsos negativos de TrackEye para defectos ≥ 10 mm será ≤ 1,5 % con cota superior del 95 %, por estrato de condiciones (día, amanecer/anochecer, noche, lluvia), en un conjunto reservado de ≥ 1.000 defectos por estrato; se verificará mediante un informe de pruebas en cada publicación». Origen: peligro H-03 y artículo 15 del Reglamento de IA (precisión). El REQ-AI-015 abordaba las marcas adversariales: «Ninguna marca individual de ≤ 20 × 20 cm colocada a ≥ 0,5 m del carril reducirá por debajo del 95 % la detección de un defecto adyacente en la campaña de pruebas físicas». La regla de los estratos cierra la laguna del amanecer: una buena tasa global ya no puede ocultar una condición débil.
21.6 Errores y límites
- Requisitos sin umbrales ni conjuntos de prueba.
- Umbrales sin cotas de confianza.
- Requisitos que no pueden verificarse con los datos disponibles.
Sin un umbral y un conjunto de prueba, nadie puede decir si un requisito se ha cumplido. Un umbral sin cota de confianza puede superarse por suerte con una muestra pequeña. Un requisito que necesita datos que no existen, como mil defectos nocturnos por estrato cuando solo se han registrado doscientos, debe reescribirse o ir acompañado de un plan para recoger los datos antes de la publicación que depende de él.
Ejercicios — capítulo 21
- EX061 — Reescritura. Reescriba «Wrench no debe filtrar secretos» como un requisito verificable. Rúbrica: 3 = población, métrica, umbral, confianza, verificación; 2 = cuatro; 1 = vago; 0 = sin cambios.
- EX062 — Caso de abuso. Redacte un caso de abuso para Pulse y un requisito derivado. Rúbrica: 3 = caso verosímil y requisito verificable; 2 = uno débil; 1 = vago; 0 = nada.
- EX063 — Tamaño de la muestra. ¿Cuántos casos de prueba se necesitan para mostrar una tasa ≤ 2 % con una cota superior unilateral del 95 % si se observan cero fallos? Rúbrica: 3 = unos 150 (regla del tres: 3/n ≤ 0,02); 2 = solo el método; 1 = incorrecto pero razonado; 0 = nada.
Síntesis del capítulo
Los buenos requisitos de seguridad de la IA son enunciados medibles sobre el comportamiento ante ataques declarados, con tamaños de muestra y confianza, trazados hasta su origen y hasta su verificación.
Siga estudiando — capítulo 21 de 50
← Capítulo 20 (borrador) · Índice de capítulos del curso · Capítulo 22 (borrador) →