# Análisis de modos de fallo y salvaguardas Enumera cómo falla un sistema de IA, qué señal detecta cada fallo y qué ocurre después — incluidos los fallos que no tienen señal alguna. ## Entregable Un documento Markdown, `guardrail-specification.md`, con la estructura fijada en **Salida** más abajo. Toma la salida de **Especificación de agente y prompts** y de **Diseño de conjunto de evaluación y métricas**. ## Entradas obligatorias - **El sistema diseñado** — su alcance, sus herramientas y su salida, en la forma que lleva la especificación de agente. - **Lo que cuesta una respuesta equivocada**, por tipo de salida, y quién lo absorbe. - **La ruta de escalado** — el rol con nombre que recibe un caso que el sistema no debe decidir. Si falta cualquiera de las dos primeras, detente y repórtalo. Una salvaguarda se dimensiona por el coste del fallo que evita; sin ese coste declarado no hay nada contra lo que dimensionarla. ## Entradas opcionales - El plan de evaluación, y la distribución sobre la que se midió el sistema - Registros de fallos reales de este sistema o del proceso al que sustituye - La monitorización y las alertas que ya ofrece el entorno de ejecución - La tolerancia a falsos positivos que aceptará quien opere el sistema - El contenido que el sistema lee y que se origina fuera de la organización - El ritmo al que una persona revisora puede procesar escalados de verdad Cada entrada opcional que falte pasa a **Preguntas abiertas**. Un fallo se registra como no detectado antes que como cubierto por una salvaguarda cercana. ## Ejecución **1 — Enumerar los fallos, no los riesgos.** Recorre las categorías a las que está expuesto este sistema: una respuesta equivocada dada con seguridad, el rechazo de una petición legítima, una instrucción que llega dentro de los datos que el sistema lee, una salida que lleva información que quien la recibe no debe recibir, una degradación que no levanta ningún error, y la conducta ante entradas distintas de todo aquello sobre lo que se evaluó. Cada una pasa a ser una entrada numerada con la forma en que se manifestaría. **2 — Dar a cada fallo una señal de detección.** Declara qué cosa observable cambia cuando ocurre este fallo — en la salida, en las llamadas a herramientas, en los tiempos o en lo que pasa después. Si no existe señal, la entrada se registra como `NO DETECTADO` y se queda así. Un fallo no lo detecta una salvaguarda que vigila otra cosa. **3 — Especificar la salvaguarda.** Qué examina la comprobación, dónde se ejecuta — antes del modelo, después de él o alrededor de la llamada a herramienta — y qué hace cuando salta: bloquear, degradar, anotar o derivar a una persona. Una comprobación que solo escribe una línea en un registro es monitorización, y se etiqueta como monitorización en lugar de contarse como salvaguarda. **4 — Poner precio a la salvaguarda en falsos positivos.** Toda comprobación que detiene un caso malo detiene también algunos buenos. Declara qué tráfico legítimo atrapará esta comprobación, qué ve la persona usuaria cuando ocurre y cómo puede seguir adelante. Una comprobación sin coste declarado es la que desactiva quien esté de guardia la primera noche mala. **5 — Definir el recurso alternativo.** Qué ocurre una vez que la salvaguarda salta y la vía principal queda cerrada: la ruta determinista, una respuesta anterior, un resultado parcial con sus límites declarados, o un rechazo honesto que diga qué hacer a continuación. El silencio y un error genérico no son recursos alternativos y se registran como huecos. **6 — Encaminar el escalado humano.** Por cada fallo que llega a una persona: quién, por qué canal, qué ve cuando llega, qué puede hacer al respecto y qué ocurre si nadie responde. Un escalado sin límite de tiempo y sin nada detrás es una cola. **7 — Marcar la frontera de la distribución evaluada.** Declara sobre qué se midió el sistema y sobre qué no, y la señal de que una entrada ha salido de esa región. Fuera de ella no aplica ninguna medición, y la especificación dice qué hace el sistema allí en lugar de suponer que la conducta se traslada. ## Salida `guardrail-specification.md`, en este orden: - **1. Sistema y fecha** — qué se analiza, contra qué especificación y cuándo - **2. Registro de fallos** — por fallo: qué es, cómo se manifiesta, qué cuesta, quién lo absorbe - **3. Detección** — por fallo: la señal, dónde se observa, o `NO DETECTADO` - **4. Salvaguardas** — la comprobación, dónde se ejecuta y qué hace cuando salta - **5. Coste en falsos positivos** — el tráfico legítimo que atrapa cada comprobación, y la vía para seguir - **6. Recursos alternativos** — por vía cerrada: la conducta, y qué se le dice a la persona usuaria - **7. Escalado** — fallo, rol, canal, qué ve, qué puede hacer, el límite de tiempo - **8. Frontera de la distribución** — qué se evaluó, qué no, y la señal de salida - **9. Fallos no detectados** — los fallos sin señal, y qué haría falta para detectarlos - **10. Preguntas abiertas** — qué no se pudo especificar, y quién puede aportarlo ## Validación La especificación está lista cuando se cumple todo esto: - Cada fallo de la sección 2 aparece en la sección 3 con una señal o como `NO DETECTADO` - Cada salvaguarda de la sección 4 declara dónde se ejecuta y qué hace cuando salta - Cada salvaguarda tiene un coste en falsos positivos en la sección 5, o declara que no bloquea - Cada vía cerrada de la sección 6 tiene un recurso alternativo que no es un error genérico - Cada escalado de la sección 7 nombra un rol y un límite de tiempo - La sección 9 no está vacía, o declara explícitamente que cada fallo tiene señal Falla la ejecución si un fallo aparece como mitigado mientras la sección 3 no registra señal para él, o si aparece alguna cifra que no venga de una entrada. ## Gestión de fallos - **Sin especificación del sistema** — detente. Informa de que el análisis de fallos no tiene nada que analizar, y de que enumerar fallos a partir de una descripción inventa el sistema. - **Sin coste declarado de una respuesta equivocada** — produce las secciones 1 a 3 y 10, y marca las salvaguardas como `SIN DIMENSIONAR`. Nombra a quién debe declarar el coste. - **Un fallo sin señal de detección** — regístralo en la sección 9 como `NO DETECTADO`, declara qué haría falta para detectarlo y no lo traslades a la sección 4 apoyándote en una salvaguarda cercana. - **Sin capacidad de revisión para los escalados** — especifica el escalado, registra la capacidad como `desconocida` en la sección 10 y declara que una ruta de escalado sin capacidad detrás convierte un fallo detectado en uno retrasado. - **Material parcial** — especifica cada sección que el material sostenga, marca el resto como `INCOMPLETO — pendiente de ` y entrega.