Capítulo 16 — Ingeniería de sistemas
Mapa de la lección
Lección 16 publicada. Mapa, ejemplo, EX046.
flowchart TD
N0["Resultados de aprendizaje"]
N1["16.1 El modelo en V"]
N2["16.2 Descomposición de requisitos"]
N3["16.3 Interfaces y emergencia"]
N4["16.4 Análisis de peligros"]
N5["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX046"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje"]
N1["16.1 El modelo en V"]
N2["16.2 Descomposición de requisitos"]
N3["16.3 Interfaces y emergencia"]
N4["16.4 Análisis de peligros"]
N5["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX046"]
[Resultados de aprendizaje]
|
v
[16.1 El modelo en V]
|
v
[16.2 Descomposición de requisitos]
|
v
[16.3 Interfaces y emergencia]
|
v
[16.4 Análisis de peligros]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX046]
Resultados de aprendizaje
Usted será capaz de (1) aplicar el modelo en V de la ingeniería de sistemas a los sistemas con IA; (2) descomponer los requisitos del sistema en requisitos de componentes con métodos de verificación; (3) gestionar las interfaces y el comportamiento emergente; y (4) usar análisis de peligros que incluyan los modos de fallo de la IA.
16.1 El modelo en V
La ingeniería de sistemas desciende desde las necesidades de las partes interesadas hasta los requisitos del sistema, la arquitectura, el diseño de componentes y la implementación, y después asciende por la verificación de componentes, las pruebas de integración, la verificación del sistema y la validación frente a las necesidades. Cada requisito de la izquierda tiene una actividad de verificación a la derecha. Los componentes de IA encajan en este esquema, pero necesitan métodos de verificación estadísticos (tasas con intervalos) en lugar de pruebas únicas de superado/no superado. Para TrackEye, superar una prueba significa una tasa declarada con un intervalo, medida sobre un conjunto de prueba identificado, y no una única salida correcta.
16.2 Descomposición de requisitos
Un requisito del sistema como «los defectos del carril mayores de 10 mm se detectan con probabilidad ≥ 0,98 en todas las condiciones de operación» se descompone en requisitos de la cámara, la iluminación, el modelo, el sistema de alertas y la revisión humana. La parte del modelo podría ser «tasa de falsos negativos ≤ 1,5 % en cada estrato de condiciones, con cota superior del 95 %», lo que deja margen para los demás componentes. El reparto es un presupuesto. Si el modelo puede pasar por alto el 1,5 %, el paso de revisión humana y la cadena de alertas deben mantener sus propias pérdidas lo bastante bajas para que la cadena completa siga cumpliendo 0,98. El requisito de cada componente indica su parte y cómo se verificará, de modo que un déficit en un punto es visible y puede compensarse en otro, en lugar de descubrirse al final.
16.3 Interfaces y emergencia
Las interfaces llevan supuestos: el modelo supone imágenes con una resolución y una exposición dadas; el sistema de alertas supone que la confianza del modelo está calibrada. El comportamiento emergente surge cuando los componentes interactúan; por ejemplo, un agente basado en LLM que combina dos herramientas inofensivas para producir un efecto dañino. Los documentos de control de interfaces deben indicar los formatos de datos, los niveles de confianza y el comportamiento ante fallos. Cuando el proveedor de la cámara cambia un sensor, el documento de interfaz dice al equipo qué supuestos del modelo debe volver a probar. En los agentes, el daño emergente se encuentra revisando combinaciones de herramientas, no herramientas aisladas: leer un documento y enviar un correo son inofensivos por separado, pero juntos pueden filtrar el documento.
16.4 Análisis de peligros
Técnicas como el análisis de modos de fallo y sus efectos (FMEA) y el análisis de procesos basado en la teoría de sistemas (STPA) buscan las formas en que el sistema puede llegar a estados peligrosos. Añada los modos de fallo de la IA: desplazamiento de distribución, entradas adversariales, envenenamiento, exceso de confianza, uso inseguro de herramientas. El enfoque de STPA en las acciones de control inseguras encaja de forma natural con los agentes que emiten órdenes. El FMEA trabaja de abajo arriba desde los fallos de los componentes y se adapta a la cadena de percepción de TrackEye. El STPA trabaja de arriba abajo desde los peligros y pregunta qué acciones de control serían inseguras si se dieran, se omitieran, se dieran en el momento equivocado o durante demasiado tiempo. Para Wrench, una acción insegura es una orden de trabajo enviada al activo equivocado, y el STPA pregunta qué haría que el agente la emitiera.
16.5 Ejemplo resuelto (caso sintético de NRS)
Sam elaboró una fila de FMEA para TrackEye: modo de fallo «defecto no detectado con deslumbramiento»; efecto «defecto sin detectar hasta el siguiente recorrido»; causa «desplazamiento de distribución»; detección «monitorización del estrato del amanecer»; gravedad 9, ocurrencia 4, detección 5, número de prioridad de riesgo 180. Una segunda fila, para «marcas adversariales», tenía gravedad 9, ocurrencia 2, detección 7 (difícil de detectar), NPR 126. Ambas superaban el umbral de actuación de 100. La fila de las marcas puntúa menos en conjunto porque la ocurrencia es rara, pero su puntuación de detección es peor, ya que nadie vigila la aparición de patrones deliberados. Superar 100 desencadena una actuación en ambas filas, pero las actuaciones difieren: mejores datos del amanecer en una, un método de detección en la otra. Sam registra en qué se basan las puntuaciones, ya que la ocurrencia de los ataques es una estimación.
16.6 Errores y límites
- Requisitos sobre componentes de IA sin métodos de verificación estadísticos.
- Interfaces que no indican niveles de confianza.
- Análisis de peligros que ignoran los ataques deliberados.
Un requisito como «el modelo detecta defectos» no puede verificarse, porque ninguna prueba finita lo demuestra; una tasa con una cota sí puede. Las interfaces sin niveles de confianza dejan que el texto no confiable fluya sin que nadie lo note hacia componentes privilegiados. Los análisis de peligros que solo consideran fallos aleatorios pasan por alto los casos en que alguien busca a propósito la peor entrada, que suelen ser mucho peores que el caso típico que suponía el análisis.
Ejercicios — capítulo 16
- EX046 — Descomposición. Descomponga «Wrench no debe crear órdenes de trabajo no autorizadas» en tres requisitos de componentes. Rúbrica: 3 = aplicación de la política, confirmación, alcance de la herramienta/registro, cada uno verificable; 2 = dos; 1 = vago; 0 = nada.
- EX047 — NPR. Calcule el NPR para gravedad 8, ocurrencia 3 y detección 6, e indique si supera 100. Rúbrica: 3 = 144, sí; 2 = desliz aritmético; 1 = método; 0 = nada.
- EX048 — Emergencia. Dé un ejemplo de daño emergente a partir de dos herramientas seguras por separado. Rúbrica: 3 = cadena verosímil (p. ej., la búsqueda recupera datos + la herramienta de correo los envía); 2 = cadena vaga; 1 = una sola herramienta; 0 = nada.
Síntesis del capítulo
La ingeniería de sistemas da a la seguridad de la IA una columna vertebral: requisitos descompuestos y verificables, interfaces explícitas y análisis de peligros que incluyen tanto los fallos accidentales como los adversariales.
Siga estudiando — capítulo 16 de 50
← Capítulo 15 (borrador) · Índice de capítulos del curso · Capítulo 17 (borrador) →