Capítulo 38 — Seguridad de la IA y del aprendizaje automático: validación | 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.

Mapa de la lección

Lección 38 publicada. Mapa, ejemplo, EX112.

flowchart TD
  N0["Resultados de aprendizaje"]
  N1["38.1 Verificación frente a validación"]
  N2["38.2 Validación operativa"]
  N3["38.3 El equipo rojo como validación"]
  N4["38.4 Idoneidad para el fin previsto"]
  N5["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Ejemplo resuelto"]
  EX --> Q["Ejercicio EX112"]

Dibujo lógico

flowchart LR
  N0["Resultados de aprendizaje"]
  N1["38.1 Verificación frente a validación"]
  N2["38.2 Validación operativa"]
  N3["38.3 El equipo rojo como validación"]
  N4["38.4 Idoneidad para el fin previsto"]
  N5["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX112"]

[Resultados de aprendizaje]
    |
    v
[38.1 Verificación frente a validación]
    |
    v
[38.2 Validación operativa]
    |
    v
[38.3 El equipo rojo como validación]
    |
    v
[38.4 Idoneidad para el fin previsto]
    |
    v
[Síntesis del capítulo]
    |
    v
[Ejemplo resuelto] --> [Ejercicio EX112]

Resultados de aprendizaje

Usted será capaz de (1) distinguir la verificación (se construyó bien) de la validación (se construyó lo correcto); (2) validar la seguridad de la IA con usuarios y operadores en condiciones realistas; (3) realizar ejercicios de equipo rojo como validación; y (4) decidir la idoneidad para el fin previsto con evidencia documentada.

38.1 Verificación frente a validación

La verificación comprueba que el sistema cumple los requisitos especificados. La validación comprueba que los requisitos y el sistema responden a las necesidades reales de las partes interesadas en el entorno real. Un sistema puede cumplir todos los requisitos y seguir siendo inseguro si los requisitos pasaron por alto una amenaza o si los usuarios se comportan de forma distinta de la supuesta. En el caso de Wrench, la verificación mostró que el punto de aplicación bloquea las llamadas no autorizadas. La validación pregunta si los técnicos pueden hacer su trabajo con él, si leen las pantallas de confirmación y si las amenazas del modelo son las que aparecen realmente. Hacen falta ambas: la verificación sin validación puede aprobar un sistema que nadie usa de forma segura, y la validación sin verificación se basa en impresiones.

38.2 Validación operativa

Realice pilotos en condiciones realistas: cargas de trabajo reales (autorizadas), usuarios reales, contenido adversarial realista. Observe cómo interactúan los usuarios con los controles: ¿leen las pantallas de aprobación?, ¿esquivan las restricciones? Mida juntos el éxito en la tarea y los resultados de seguridad. La observación revela comportamientos que ningún requisito previó, como un técnico que aprueba las propuestas por lotes al final del turno, u otro que copia el texto de los boletines en el chat para ahorrar tiempo. Medir el éxito en la tarea junto con los resultados de seguridad impide que un piloto se declare un éxito cuando el trabajo se aceleró solo porque la gente esquivaba los controles. Las opiniones de los usuarios del piloto se recogen por escrito, con su permiso, y se incorporan a los requisitos.

38.3 El equipo rojo como validación

Un equipo rojo con un alcance y una autorización definidos intenta alcanzar los objetivos de un atacante contra el sistema integrado, usando cualquier técnica dentro de las reglas. A diferencia de un conjunto de pruebas, los equipos rojos encuentran vías no previstas. NIST AI 600-1 incluye los ejercicios de equipo rojo entre las acciones sugeridas para la IA generativa. Informe de los hallazgos con su gravedad y sus correcciones, y convierta las vías que tuvieron éxito en pruebas de regresión. Los equipos rojos funcionan mejor cuando son independientes de los desarrolladores. Los desarrolladores conocen las vías previstas y tienden a probarlas; un equipo externo parte del objetivo del atacante, como un pedido de piezas no autorizado, y retrocede a través de todo lo que expone el sistema. Cada hallazgo se vuelve a probar tras su corrección.

38.4 Idoneidad para el fin previsto

El informe de validación indica: el uso previsto, las condiciones probadas, los resultados frente a las necesidades de las partes interesadas, los hallazgos del equipo rojo y su estado, los riesgos residuales y una recomendación (desplegar, desplegar con condiciones, no desplegar) firmada por los responsables que rinden cuentas. Firman los responsables que rinden cuentas porque el despliegue es una decisión de negocio basada en evidencia de ingeniería, no una decisión exclusivamente de ingeniería. Cada condición asociada a un resultado de «desplegar con condiciones» tiene un responsable y una fecha, y el sistema se comprueba frente a ellas antes de darlas por cumplidas. El informe indica también cuándo debe repetirse la validación, por ejemplo tras un cambio importante del modelo o una integración nueva.

38.5 Ejemplo resuelto (caso sintético de NRS)

Wrench superó la verificación. Durante un piloto de cuatro semanas en dos depósitos, los técnicos pedían a Wrench que «hiciera todo lo del boletín», un patrón de uso no previsto que elevó la proporción de propuestas derivadas de texto no confiable. Después, un equipo rojo interno autorizado consiguió un pedido de piezas no autorizado encadenando un resultado de búsqueda con un correo a un proveedor de la lista de permitidos que llevaba un número de pieza modificado. Resultado de la validación: desplegar con condiciones; los números de pieza de los correos deben coincidir con una orden de trabajo abierta, y se formará a los técnicos sobre las peticiones basadas en boletines.

38.6 Errores y límites

Tratar la verificación como validación.
Equipos rojos sin alcance o en los que los desarrolladores se califican a sí mismos.
Recomendaciones sin la firma de un responsable que rinda cuentas.

Un sistema que cumple su especificación puede fallar a sus usuarios si la especificación pasó por alto cómo trabajan, como mostraron las peticiones basadas en boletines del piloto. Los equipos rojos que informan a los mismos desarrolladores a los que ponen a prueba, o que trabajan sin un alcance por escrito, producen hallazgos fáciles de descartar o peligrosos de obtener. Una recomendación que nadie firma deja sin dueño la decisión de despliegue cuando más tarde algo sale mal.

Ejercicios — capítulo 38

EX112 — V&V. Dé un ejemplo en el que Wrench supere la verificación, pero no la validación. Rúbrica: 3 = ejemplo verosímil (uso no previsto, laguna en los requisitos); 2 = parcial; 1 = vago; 0 = nada.
EX113 — Hallazgo del equipo rojo. Convierta la cadena del equipo rojo en una prueba de regresión. Rúbrica: 3 = escenario, entrada, resultado esperado de la política, criterio de superación; 2 = parcial; 1 = vago; 0 = nada.
EX114 — Recomendación. Redacte la frase de recomendación de la validación de Wrench. Rúbrica: 3 = desplegar con las condiciones enumeradas, responsables, fecha de revisión; 2 = falta uno; 1 = vago; 0 = nada.

Síntesis del capítulo

La validación pregunta si el sistema protegido funciona para personas reales bajo presión real. Los pilotos y los equipos rojos encuentran lo que se les escapó a los requisitos, y los responsables que rinden cuentas deciden la idoneidad para el fin previsto.

Siga estudiando — capítulo 38 de 50

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