Capítulo 46 — Proyecto final de ingeniería 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.

Mapa de la lección

Lección 46 publicada. Mapa, ejemplo, EX136.

flowchart TD
  N0["Resultados de aprendizaje"]
  N1["46.1 Construir conforme a la línea base"]
  N2["46.2 Implementación de los controles"]
  N3["46.3 Entorno de evaluación"]
  N4["46.4 Defectos y cambios"]
  N5["46.4b Demostraciones y evidencia"]
  N6["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Ejemplo resuelto"]
  EX --> Q["Ejercicio EX136"]

Dibujo lógico

flowchart LR
  N0["Resultados de aprendizaje"]
  N1["46.1 Construir conforme a la línea base"]
  N2["46.2 Implementación de los controles"]
  N3["46.3 Entorno de evaluación"]
  N4["46.4 Defectos y cambios"]
  N5["46.4b Demostraciones y evidencia"]
  N6["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX136"]

[Resultados de aprendizaje]
    |
    v
[46.1 Construir conforme a la línea base]
    |
    v
[46.2 Implementación de los controles]
    |
    v
[46.3 Entorno de evaluación]
    |
    v
[46.4 Defectos y cambios]
    |
    v
[46.4b Demostraciones y evidencia]
    |
    v
[Síntesis del capítulo]
    |
    v
[Ejemplo resuelto] --> [Ejercicio EX136]

Resultados de aprendizaje

Usted será capaz de (1) construir e integrar el sistema del proyecto final conforme a su línea base aprobada; (2) implementar los controles de seguridad y los entornos de evaluación; (3) gestionar los cambios y los defectos; y (4) prepararse para la verificación y para el ensayo de recuperación.

46.1 Construir conforme a la línea base

Implemente por incrementos, cada uno de los cuales termina con pruebas y una demostración breve. Mantenga al día la trazabilidad de los requisitos: cada requisito apunta al código, la configuración y las pruebas. Use el control de seguridad de la CI del capítulo 14 desde el primer incremento. Los incrementos mantienen pequeña la distancia entre el diseño y el código, de modo que los problemas afloran mientras corregirlos es barato. Una demostración al final de cada incremento muestra al cliente un avance real y propicia una retroalimentación temprana. Ejecutar el control de seguridad desde el principio significa que la primera versión ya tiene una referencia con la que compararse, en lugar de descubrir muchos fallos a la vez al final.

46.2 Implementación de los controles

Implemente el punto de aplicación, el tratamiento de la procedencia, la validación de salidas, la monitorización y las comprobaciones de la cadena de suministro como módulos separados y comprobables. Evite los desvíos «temporales»; si alguno es necesario para el desarrollo, condiciónelo a una configuración que no pueda activarse en la compilación de publicación. Los módulos separados permiten probar y revisar cada control por sí solo, y sustituirlo sin alterar los demás. Los desvíos temporales son una fuente clásica de incidentes: una opción que desactiva el punto de aplicación para las pruebas locales es inofensiva hasta que llega a producción. Hacer que la compilación de publicación no pueda activarla convierte una promesa en una comprobación que la canalización hace cumplir.

46.3 Entorno de evaluación

Construya el entorno que ejecuta los conjuntos reservados benignos y adversariales, calcula las métricas con intervalos y guarda las salidas en bruto. Incluya el conjunto independiente de ataques adaptativos proporcionado por otro equipo. Ejecútelo cada noche y en cada versión candidata. El conjunto adaptativo de otro equipo es la parte más valiosa, porque sus autores no sabían qué ataques preveía el diseño. Las ejecuciones nocturnas detectan las regresiones en el día siguiente al cambio que las causó. Las salidas en bruto guardadas permiten al equipo investigar un fallo sin volver a ejecutar el modelo y responder a preguntas posteriores del panel.

46.4 Defectos y cambios

Haga un seguimiento de los defectos con su gravedad; los defectos de seguridad bloquean la publicación hasta que se corrigen o se aceptan formalmente con un responsable del riesgo. Los cambios de alcance o de requisitos pasan por el control de cambios acordado en el proyecto final I. Un defecto de seguridad aceptado formalmente nombra quién lo aceptó, por qué y hasta cuándo, para que no se vuelva permanente por omisión. Bloquear la publicación por defectos de seguridad sin corregir puede parecer lento, pero evita el patrón habitual de debilidades conocidas que se publican porque llegó una fecha límite. Los cambios de alcance durante la construcción siguen el mismo proceso que antes, lo que mantiene el sentido de la línea base.

46.4b Demostraciones y evidencia

Termine cada incremento con una demostración breve al cliente que incluya al menos un caso adversarial, no solo el camino feliz. Guarde el guion de la demostración, las entradas y las salidas como evidencia; pasarán a formar parte del expediente del capítulo 48. Mostrar un fallo con honestidad, con la corrección planificada, genera más confianza que una demostración pulida que lo oculta. La demostración de Bulletin Gate tras el cambio de esquema incluyó uno de los boletines adaptativos del otro equipo: una instrucción oculta en una nota de mantenimiento, ahora asignada a una categoría enumerada sin texto libre en la salida. Mostrar en la misma demostración la caída de la exactitud al 95,3 % formó parte de la honestidad que buscaba el panel.

46.5 Ejemplo resuelto (caso sintético de NRS)

Durante la construcción, el modelo en cuarentena de Bulletin Gate copiaba a veces frases con apariencia de instrucción en un campo de texto libre «notes» de su esquema de salida. El esquema se endureció: las notas pasaron a ser una enumeración de categorías de mantenimiento predefinidas más campos numéricos. El conjunto adaptativo del otro equipo produjo entonces cero cadenas de instrucción en las salidas en 300 casos (cota superior del 95 % ≈ 1 %), mientras que la exactitud de la extracción bajó del 96,4 % al 95,3 %, y seguía cumpliendo el requisito.

La corrección fue estructural y no un filtro mejor: eliminar el texto libre suprimió el lugar donde podían esconderse las instrucciones.

46.6 Errores y límites

Campos de texto libre que reabren vías de inyección.
Desvíos de desarrollo que llegan a producción.
Entornos de evaluación que solo se ejecutan al final.

Un campo de texto libre en una salida supuestamente estructurada da a las instrucciones inyectadas una vía a través de la cuarentena, como mostró el campo de notas. Los desvíos de desarrollo que se publican convierten una comodidad en una puerta abierta. Un entorno de evaluación que solo se ejecuta al final encuentra todos los problemas a la vez, demasiado tarde para corregirlos bien. El equipo de Sam mantuvo el entorno de evaluación, la comprobación de la compilación de publicación y la revisión del esquema en la definición de terminado de cada incremento.

Ejercicios — capítulo 46

EX136 — Trazabilidad. Muestre cómo se traza un requisito hasta el código, la configuración y las pruebas. Rúbrica: 3 = ID del requisito con enlaces concretos a los tres; 2 = dos; 1 = vago; 0 = nada.
EX137 — Texto libre. ¿Por qué importaba el campo de notas y qué regla general se deriva? Rúbrica: 3 = el texto libre transporta instrucciones inyectadas; restringir las salidas a enumeraciones/estructuras; 2 = parcial; 1 = vago; 0 = incorrecto.
EX138 — Cota. Con 0 fallos en 300 casos, ¿cuál es la cota superior aproximada del 95 %? Rúbrica: 3 = ≈ 3/300 = 1 %; 2 = solo el método; 1 = incorrecto pero razonado; 0 = nada.

Síntesis del capítulo

El proyecto final II construye el sistema tal como se diseñó: por incrementos, con trazabilidad, con la evaluación como control y con los defectos de seguridad tratados como bloqueantes de la publicación.

Siga estudiando — capítulo 46 de 50

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