Capítulo 25 — Taller de diseño I
Mapa de la lección
Lección 25 publicada. Mapa, ejemplo, EX073.
flowchart TD
N0["Resultados de aprendizaje"]
N1["25.1 Formato del taller"]
N2["25.2 El encargo sintético"]
N3["25.3 El paquete de diseño"]
N4["25.4 Crítica"]
N5["25.4b Tablas de compromisos"]
N6["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX073"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje"]
N1["25.1 Formato del taller"]
N2["25.2 El encargo sintético"]
N3["25.3 El paquete de diseño"]
N4["25.4 Crítica"]
N5["25.4b Tablas de compromisos"]
N6["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX073"]
[Resultados de aprendizaje]
|
v
[25.1 Formato del taller]
|
v
[25.2 El encargo sintético]
|
v
[25.3 El paquete de diseño]
|
v
[25.4 Crítica]
|
v
[25.4b Tablas de compromisos]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX073]
Resultados de aprendizaje
Usted será capaz de (1) trabajar en equipo para diseñar un subsistema con IA y requisitos de seguridad; (2) presentar alternativas de diseño y sus compromisos; (3) recibir la crítica de un diseño y responder a ella; y (4) elaborar un paquete de diseño (requisitos, arquitectura, modelo de amenazas, plan de verificación).
25.1 Formato del taller
Equipos de tres a cinco personas reciben un encargo, elaboran un diseño en dos semanas, lo presentan ante un panel y lo revisan. El panel interpreta papeles: operador, atacante, evaluador de seguridad funcional y responsable del presupuesto. El objetivo es practicar cómo tomar y defender compromisos, no encontrar un diseño perfecto. Los papeles tiran en direcciones distintas a propósito. Un operador quiere rapidez y pocos clics, un atacante quiere cualquier vía hacia el impacto, un evaluador de seguridad funcional quiere que los fallos sean seguros y un responsable del presupuesto quiere que el coste esté justificado. Un diseño que satisface por completo a un papel suele fallarle a otro, y las preguntas del panel lo ponen de manifiesto antes de escribir una sola línea de código.
25.2 El encargo (sintético)
Diseñe un asistente basado en LLM que ayude a los planificadores de los depósitos de NRS a programar inspecciones usando el historial de mantenimiento, las previsiones meteorológicas y los boletines de proveedores. Puede proponer cambios en el calendario; un planificador debe aprobarlos. El encargo es pequeño, pero contiene la tensión central del curso. El historial de mantenimiento es interno, las previsiones meteorológicas proceden de una fuente externa y los boletines de proveedores los redactan terceros, de modo que en un solo asistente confluyen tres niveles de confianza. El asistente solo puede proponer, pero las propuestas de aplazar inspecciones afectan a la seguridad ferroviaria. Los equipos deben decidir hasta qué punto puede influir cada fuente en una propuesta y qué necesita ver un planificador antes de aprobarla.
25.3 El paquete de diseño
- Contexto y partes interesadas. 2. Requisitos (funcionales, de seguridad, estadísticos, operativos) con métodos de verificación. 3. Arquitectura con fronteras de confianza y un punto de política externo. 4. Modelo de amenazas jerarquizado y en correspondencia con OWASP/ATLAS. 5. Plan de verificación: conjuntos de evaluación, tamaños de muestra, controles. 6. Riesgos residuales y cuestiones abiertas.
El orden refleja cómo lee un revisor: para quién es el sistema, qué debe hacer, cómo está construido, qué podría salir mal, cómo se comprobará y qué queda pendiente. Cada elemento remite a los anteriores, de modo que una amenaza apunta al requisito que pone en peligro y a la prueba que verificará el control. Un paquete sin plan de verificación se devuelve sin leer, porque sin él no puede comprobarse nada más.
25.4 Crítica
Cada papel del panel formula preguntas desde su perspectiva. El papel de atacante es especialmente valioso: «Controlo un espejo de la fuente meteorológica. ¿Qué puedo hacer?». Los equipos deben responder con su arquitectura, no con promesas sobre el modelo. Una respuesta como «el modelo ignorará las instrucciones maliciosas» no sirve, porque depende de un comportamiento que nadie puede garantizar. Una respuesta aceptable señala la arquitectura: los valores de la fuente meteorológica pasan por un validador que solo acepta números dentro de los límites físicos, y cualquier cambio en el calendario sigue necesitando la aprobación de un planificador con la fuente a la vista. Los equipos aprenden a agradecer las preguntas difíciles, ya que cada problema encontrado en el taller es uno menos que se encuentra en servicio.
25.4b Tablas de compromisos
Presente las alternativas en una tabla con columnas para el efecto en la seguridad, el efecto en la seguridad funcional, la fricción para el usuario, el coste y el riesgo residual. Así, un panel puede ver por qué se rechazó una opción en lugar de adivinarlo. Por ejemplo, «sin acceso a herramientas» tiene el menor riesgo, pero pierde la mayor parte del beneficio; «acceso libre a herramientas» tiene el mayor beneficio y un riesgo inaceptable; «propuesta más aprobación» queda en medio. Ser explícito sobre lo que sacrifica cada opción convence más que afirmar que alguna opción no cuesta nada.
La revisión del asistente para planificadores de Sam cabe en una tabla así: «boletines leídos directamente en el prompt» se rechazó por su riesgo residual, mientras que «resumidos por un modelo de bajo privilegio más dos aprobaciones para los cambios críticos para la seguridad» aceptó algo más de fricción para los planificadores a cambio de un peor caso acotado.
25.5 Ejemplo resuelto (caso sintético de NRS)
El equipo de Sam propuso leer los boletines de proveedores directamente en el prompt del planificador. El panelista atacante mostró (en términos de diseño) que un boletín podía pedir al modelo que aplazara las inspecciones de una ruta. El equipo revisó el diseño: los boletines los resume un modelo independiente de bajo privilegio cuya salida se etiqueta como no confiable; los cambios en el calendario que afectan a inspecciones críticas para la seguridad requieren dos aprobaciones; y cada cambio propuesto muestra los documentos de origen que influyeron en él.
La revisión muestra el patrón que el taller pretende enseñar: al ataque se respondió cambiando la estructura, no mejorando el prompt.
25.6 Errores y límites
- Diseños que confían en que el modelo «ignore» el texto malicioso.
- Paquetes sin planes de verificación.
- Respuestas defensivas a la crítica.
Confiar en que el modelo ignore el texto malicioso es una promesa, no un control. Un paquete sin plan de verificación no puede demostrar que se cumpla ningún requisito. Las respuestas defensivas, como argumentar que un atacante nunca intentaría algo, desperdician la retroalimentación más útil del panel. El equipo de Sam adoptó una regla para el taller: cada crítica recibe una respuesta escrita que dice aceptada, rechazada con motivo o aplazada con un responsable y una fecha.
Ejercicios — capítulo 25
- EX073 — Paquete. Enumere las seis partes del paquete de diseño. Rúbrica: 3 = las seis; 2 = cuatro; 1 = dos; 0 = ninguna.
- EX074 — Pregunta del atacante. Responda a la pregunta del espejo de la fuente meteorológica para su diseño. Rúbrica: 3 = identifica la vía de influencia y el límite arquitectónico; 2 = parcial; 1 = confía en el modelo; 0 = nada.
- EX075 — Dos aprobaciones. ¿Por qué exigir dos aprobaciones solo para los cambios críticos para la seguridad? Rúbrica: 3 = control proporcional, limita la fricción y acota el riesgo de alto impacto; 2 = parcial; 1 = vago; 0 = incorrecto.
Síntesis del capítulo
El taller practica la competencia central de la ingeniería: tomar compromisos explícitos y defenderlos ante operadores, atacantes, evaluadores de seguridad funcional y responsables del presupuesto.
Siga estudiando — capítulo 25 de 50
← Capítulo 24 (borrador) · Índice de capítulos del curso · Capítulo 26 (borrador) →