Capítulo 35 — Taller de diseño II
Mapa de la lección
Lección 35 publicada. Mapa, ejemplo, EX103.
flowchart TD
N0["Resultados de aprendizaje"]
N1["35.1 Encargo sintético"]
N2["35.2 Qué es nuevo respecto al taller I"]
N3["35.3 Panel multidisciplinar"]
N4["35.4 Iteración"]
N5["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX103"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje"]
N1["35.1 Encargo sintético"]
N2["35.2 Qué es nuevo respecto al taller I"]
N3["35.3 Panel multidisciplinar"]
N4["35.4 Iteración"]
N5["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX103"]
[Resultados de aprendizaje]
|
v
[35.1 Encargo sintético]
|
v
[35.2 Qué es nuevo respecto al taller I]
|
v
[35.3 Panel multidisciplinar]
|
v
[35.4 Iteración]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX103]
Resultados de aprendizaje
Usted será capaz de (1) diseñar un sistema completo con IA, con requisitos de seguridad, de seguridad funcional y operativos; (2) elaborar un caso de seguridad funcional y ciberseguridad; (3) defender el diseño ante un panel multidisciplinar; y (4) iterar desde la crítica hasta una nueva línea base revisada.
35.1 Encargo (sintético)
Diseñe «Yardmind», un sistema de IA para NRS que usa las detecciones de TrackEye, las alertas de Pulse y Wrench para planificar y despachar las cuadrillas de mantenimiento en una región, lo que incluye proponer limitaciones de velocidad en la vía a un controlador humano. Yardmind combina los tres sistemas anteriores, de modo que sus debilidades pueden sumarse: una etiqueta envenenada de TrackEye, una lectura suplantada de Pulse o un boletín inyectado que llegue a Wrench podrían influir cada uno en el despacho de las cuadrillas. Las limitaciones de velocidad elevan lo que está en juego, ya que una limitación levantada por error puede poner en peligro directamente a los trenes. El encargo pide a los equipos que muestren hasta dónde puede llegar cada debilidad de origen y dónde se detiene.
35.2 Qué es nuevo respecto al taller I
El taller II añade un caso de seguridad funcional y ciberseguridad: un argumento estructurado, respaldado por evidencia, de que el sistema es aceptablemente seguro. Una estructura habitual es afirmación → argumento → evidencia: «Yardmind no puede imponer ni levantar una limitación de velocidad sin la aprobación de un controlador» (afirmación), «todas las acciones de limitación pasan por el punto de aplicación, que exige una decisión firmada del controlador» (argumento), «revisión de código CR-112, informe de pruebas TR-208, prueba de penetración PT-05» (evidencia). Incluya las suposiciones y los refutadores: lo que haría fallar el argumento.
Los refutadores mantienen honesto el caso al nombrar lo que rompería cada afirmación.
35.3 Panel multidisciplinar
El panel incluye a un controlador (realismo operativo), un evaluador de seguridad funcional (cobertura de los peligros), un miembro del equipo rojo (vías de ataque), un delegado de protección de datos (datos personales de las cuadrillas) y un responsable financiero. Cada uno da su conformidad o enumera condiciones. Cada perspectiva ve un riesgo distinto. El controlador sabe que una propuesta que llega durante un turno con mucho trabajo se aprobará rápido; el evaluador de seguridad funcional comprueba si cada peligro tiene un control; el miembro del equipo rojo busca la entrada más débil; el delegado de protección de datos pregunta por qué se almacenan las ubicaciones de las cuadrillas y durante cuánto tiempo; el responsable financiero pregunta si los controles caben en el presupuesto. Las condiciones de un papel a veces chocan con las de otro, y resolverlas forma parte del ejercicio.
35.4 Iteración
Los equipos revisan el diseño en el plazo de una semana y presentan un delta: qué cambió, por qué y qué condiciones del panel se cumplen ahora. Las condiciones no resueltas se convierten en riesgos residuales explícitos con responsables. Presentar un delta mantiene centrada la segunda revisión. El panel no vuelve a leer todo el diseño; comprueba cada condición frente al cambio realizado y la evidencia aportada. Las condiciones que no pueden cumplirse en la semana no se ocultan: se registran con un responsable y una fecha, y el caso de seguridad funcional y ciberseguridad las muestra como refutadores abiertos.
35.5 Ejemplo resuelto (caso sintético de NRS)
El equipo de Sam argumentó que Yardmind podía proponer limitaciones de velocidad, pero nunca aplicarlas ni levantarlas. El miembro del equipo rojo preguntó por el levantamiento: ¿podría una fuente de Pulse manipulada hacer que Yardmind recomendara levantar una limitación antes de tiempo? El equipo añadió una regla: las recomendaciones de levantar limitaciones requieren dos fuentes de evidencia independientes (un paso de TrackEye y un registro de inspección humana), y los controladores ven ambas. El evaluador de seguridad funcional lo aceptó con la condición de que las recomendaciones de levantamiento se registren para una auditoría mensual.
La regla elimina un punto único de fallo: una fuente de Pulse suplantada no puede desencadenar por sí sola una recomendación de levantamiento, porque también se necesitan un paso de TrackEye y un registro humano.
35.6 Errores y límites
- Casos de seguridad sin refutadores.
- Tratar «proponer» como algo sin riesgo cuando las personas aceptan las propuestas de forma rutinaria.
- Ignorar los datos personales de las cuadrillas en el despacho.
Un caso sin refutadores parece completo, pero no puede cuestionarse, así que sus debilidades permanecen ocultas hasta un incidente. «Proponer» solo es seguro si las personas revisan las propuestas con cuidado, y las mediciones de aprobación del capítulo sobre supervisión mostraron con qué rapidez puede fallar eso. El despacho de cuadrillas implica ubicaciones, patrones de turnos y nombres, así que la protección de datos es una entrada del diseño, no una revisión posterior.
Ejercicios — capítulo 35
- EX103 — Afirmación–argumento–evidencia. Redacte una terna de afirmación–argumento–evidencia para Yardmind. Rúbrica: 3 = afirmación específica, argumento sólido, elementos de evidencia concretos; 2 = uno débil; 1 = vago; 0 = nada.
- EX104 — Refutador. Nombre un refutador para la afirmación de 35.2 y cómo abordarlo. Rúbrica: 3 = p. ej., firma del controlador falsificada o punto de aplicación comprometido; protección de las claves/monitor independiente; 2 = solo el refutador; 1 = vago; 0 = nada.
- EX105 — Regla de levantamiento. ¿Por qué las recomendaciones de levantamiento se tratan con más rigor que las de imposición? Rúbrica: 3 = levantar elimina una protección; las consecuencias de un error o un ataque son mayores; riesgo asimétrico; 2 = parcial; 1 = vago; 0 = incorrecto.
Síntesis del capítulo
El taller II hace que el diseño argumente a su favor: un caso de seguridad funcional y ciberseguridad con evidencia y refutadores, puesto a prueba por un panel multidisciplinar y revisado hasta llegar a un riesgo residual explícito.
Siga estudiando — capítulo 35 de 50
← Capítulo 34 (borrador) · Índice de capítulos del curso · Capítulo 36 (borrador) →