Capítulo 38 — Implementación del proyecto final | Grado 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 Incrementos"]
  N2["38.2 Integración de los controles"]
  N3["38.3 Banco de evaluación"]
  N4["38.4 Defectos y cambios"]
  N5["38.5 Evidencia"]
  N6["38.5b Revisión de código y valores seguros por defec"]
  N7["Síntesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Ejemplo resuelto"]
  EX --> Q["Ejercicio EX112"]

Dibujo lógico

flowchart LR
  N0["Resultados de aprendizaje"]
  N1["38.1 Incrementos"]
  N2["38.2 Integración de los controles"]
  N3["38.3 Banco de evaluación"]
  N4["38.4 Defectos y cambios"]
  N5["38.5 Evidencia"]
  N6["38.5b Revisión de código y valores seguros por defec"]
  N7["Síntesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX112"]

[Resultados de aprendizaje]
    |
    v
[38.1 Incrementos]
    |
    v
[38.2 Integración de los controles]
    |
    v
[38.3 Banco de evaluación]
    |
    v
[38.4 Defectos y cambios]
    |
    v
[38.5 Evidencia]
    |
    v
[38.5b Revisión de código y valores seguros por defec]
    |
    v
[Síntesis]
    |
    v
[Ejemplo resuelto] --> [Ejercicio EX112]

Resultados de aprendizaje

Usted podrá (1) implementar el sistema del proyecto final por incrementos; (2) integrar los controles de seguridad y un banco de evaluación; (3) gestionar los defectos y los cambios de alcance; y (4) mantener al día la evidencia para la evaluación.

38.1 Incrementos

Construya primero una porción fina de extremo a extremo (chat → modelo → políticas → herramienta en un entorno aislado) y añada después las funciones. Cada incremento termina con pruebas, una breve demostración que incluye un caso adversarial y la documentación actualizada. La primera porción de Rina permitía a un paciente sintético pedir una cita y la reservaba en el entorno aislado, con la comprobación de políticas presente desde el principio. Su demostración incluía un caso adversarial, un documento que pedía reservar para otro paciente, que la comprobación rechazó. Los incrementos posteriores añadieron la confirmación, la fundamentación y la monitorización, cada una con sus propias pruebas y su demostración.

38.2 Integración de los controles

Implemente el servicio de políticas como un módulo independiente con sus propias pruebas. Añada los tokens delegados, la confirmación, las comprobaciones de fundamentación y la monitorización. Guarde la configuración en archivos bajo control de versiones; no incruste nunca secretos en el código. Mantener separado el servicio de políticas significaba que sus pruebas se ejecutaban en segundos sin el modelo, así que Rina podía probar cada regla en cada cambio. La clave del proveedor del modelo se leía de una variable de entorno fijada por el sistema de preproducción y nunca apareció en el repositorio. La configuración, como las listas de clínicas y los límites de reservas, estaba en archivos versionados, de modo que cualquier cambio podía rastrearse hasta una confirmación.

38.3 Banco de evaluación

Automatice la evaluación: cargar los conjuntos de pruebas, ejecutar las conversaciones, recoger los registros de las herramientas, calificar los resultados, calcular las tasas con intervalos y redactar un informe fechado. Ejecútelo cada noche. El banco de Rina ejecutaba cada noche 1000 conversaciones contra preproducción, calificaba las reservas a partir del registro del entorno aislado y redactaba un informe con intervalos de Wilson. Cuando un informe matutino mostró que aumentaban las afirmaciones falsas sobre las clínicas, ella lo rastreó hasta un cambio hecho el día anterior en el archivo estructurado de clínicas, que tenía un horario de apertura erróneo; las ejecuciones nocturnas lo detectaron en menos de un día.

38.4 Defectos y cambios

Registre los defectos con su gravedad. Los defectos de seguridad bloquean el siguiente hito hasta que se corrigen o se aceptan formalmente. Los cambios de alcance pasan por el registro de cambios del supervisor. El problema de la pantalla de confirmación que se describe más abajo se registró como defecto de seguridad de gravedad alta y bloqueó el hito hasta que se corrigió. Un problema menor de redacción en los mensajes de negativa se registró como de gravedad baja y se dejó para un incremento posterior. Cuando Rina excluyó el canal de voz, el cambio pasó por el registro de cambios del supervisor en lugar de hacerse en silencio.

38.5 Evidencia

Mantenga la evidencia organizada por requisito: pruebas, resultados, informes, versiones. La evaluación final no debería requerir ninguna búsqueda. La carpeta de evidencia de Rina tenía un directorio por requisito, cada uno con la definición de la prueba, el último informe nocturno, los registros en bruto del entorno aislado y el archivo de versiones. En la evaluación final, el examinador pudo abrir el directorio de las reservas para otro paciente y ver cada intento, su resultado y la configuración probada, sin preguntarle dónde estaba nada. Cada directorio contenía además un breve archivo de texto que indicaba lo que mostraba la evidencia y sus límites, escrito en el momento de la ejecución y no al final.

38.5b Revisión de código y valores seguros por defecto

Haga que una segunda persona revise cada cambio que afecte al servicio de políticas, a los tokens o a los adaptadores de herramientas. Use valores seguros por defecto: las herramientas están denegadas salvo que se permitan explícitamente; los registros excluyen los secretos y censuran los datos personales; los nuevos prompts y versiones del modelo no se despliegan hasta que el banco de evaluación los aprueba. Anote cada valor por defecto para que los evaluadores puedan comprobarlo. Un revisor detectó un cambio que registraba los mensajes completos de los pacientes, algo que el valor por defecto de censura debería haber impedido. El cambio se rechazó y se añadió una prueba que falla si cualquier texto de mensaje sin censurar llega al registro, de modo que ahora el valor por defecto lo hace cumplir la canalización y no la memoria.

38.6 Ejemplo resuelto (caso sintético de LCH)

Durante la implementación, Rina descubrió que la pantalla de confirmación mostraba el resumen de la cita generado por el modelo, que podía manipularse para parecer inofensivo. Cambió la pantalla para que mostrara los detalles de la reserva directamente a partir de la propuesta estructurada (clínica, fecha, hora, paciente) en lugar del texto del modelo. La evaluación nocturna mostró después que no había confirmaciones engañosas en 300 casos adaptativos. La corrección aplica el mismo principio que el servicio de políticas: lo que el paciente aprueba debe proceder de datos estructurados, no del texto del modelo, al que un documento inyectado puede dar forma.

38.7 Errores y límites

Construir todas las funciones antes de cualquier prueba de extremo a extremo.
Pantallas de confirmación que muestran texto escrito por el modelo.
Evidencia reunida solo al final.

Construir primero todas las funciones y probar al final habría ocultado el defecto de la pantalla de confirmación hasta la evaluación final, demasiado tarde para corregirlo bien. Una confirmación que muestra texto escrito por el modelo puede hacerse parecer inofensiva, lo que anula su propósito. La evidencia reunida solo al final tiende a estar incompleta, ya que las ejecuciones anteriores y sus versiones se pierden o quedan sobrescritas por ejecuciones posteriores.

Ejercicios

EX112 — Porción fina. Describa la primera porción fina de un proyecto final de monitorización de IA. Rúbrica: 3 = vía mínima de extremo a extremo con prueba y demostración; 2 = parcial; 1 = vago; 0 = nada.
EX113 — Pantalla de confirmación. ¿Por qué mostrar la confirmación a partir de datos estructurados y no del texto del modelo? Rúbrica: 3 = el texto del modelo puede manipularse para engañar; los campos estructurados muestran la acción real; 2 = parcial; 1 = vago; 0 = incorrecto.
EX114 — Salidas del banco. Enumere cinco cosas que debe contener el informe nocturno del banco de evaluación. Rúbrica: 3 = versiones, tamaños de los conjuntos, tasas con intervalos, fallos, comparación con la ejecución anterior; 2 = cuatro; 1 = dos; 0 = nada.

Síntesis

La implementación avanza por incrementos con controles y evaluación desde el principio; pequeños detalles de diseño, como lo que muestra una pantalla de confirmación, pueden decidir si los controles funcionan de verdad.

Siga estudiando — capítulo 38 de 40

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