Registro de peligros

Un peligro es algo que puede salir mal en su sistema, escrito con quién es responsable y qué lo mide. El registro vive junto a la política de publicación, en hazards.yaml, así que se revisa en pull requests como el resto del proyecto, y cada ejecución registra la versión con la que se leyó.

Escribir el registro

version: 1
hazards:
  - id: rag-leak
    title: A poisoned document makes the assistant disclose a customer's data
    systems: [support-bot]
    triggers: [a retrieved document carries an instruction]
    exposed: customers whose tickets the assistant reads
    severity: {level: 5, narrative: customer data leaves the company}
    occurrence: {level: 2}
    detectability: {level: 3}
    controls: [retrieved text is quoted, never obeyed]
    residual: Low while the leak ceiling holds; reviewed after every model change.
    owner: [email protected]
    review_by: 2026-12-01
    state: open
    measured_by: [no-leak]
    tested_by: [safety]

Cada peligro nombra en measured_by las reglas que lo miden. Deben ser techos de release.yaml: una regla max: o una regla max_failures: (Techos de riesgo). Un suelo mide con qué frecuencia algo sale bien, así que un peligro medido por un suelo se rechaza. systems y tested_by acotan de qué sistemas y suites se lee la evidencia; si faltan, cuentan todos.

La gravedad, la ocurrencia y la detectabilidad son las calificaciones ordinales de un análisis de modos de fallo y efectos, de 1 a 5, dadas por personas. Oloproof las muestra tal como se dieron y nunca las combina: no hay número de prioridad de riesgo ni puntuación de riesgo residual, porque el producto de calificaciones ordinales es una precisión que nadie midió. El riesgo residual es la frase del responsable. El state de un peligro (open, mitigated, accepted o closed) es del equipo, nunca una decisión.

Comprobarlo

oloproof hazards check

La comprobación rechaza un registro cuyos peligros nombran una regla que la política no tiene, o un suelo, y termina con 2. Si no, lista cada peligro con sus calificaciones, su responsable y su estado, avisa de una revisión vencida y lee cada regla de medición en la última ejecución de cada sistema en cada suite, tal como la decidió el motor. Un peligro sin regla de medición aparece como no medido, y se nombra una regla que ninguna última ejecución decidió. --json escribe el mismo informe para un pipeline.

Dónde aparece

oloproof run registra el registro con la ejecución, oloproof push lo lleva a su espacio de trabajo y oloproof export lo escribe junto a los bundles que lee un banco de trabajo local. La página Safety and risk muestra cada peligro encima de los techos, con sus calificaciones, sus controles y el estado de los techos que lo miden, cada uno enlazado a su evidencia. Cuando un registro de peligros cambió y volvió a cambiar, el actual es el que registró la ejecución más reciente, no el último que se escribió. Un registro de decisión nombra el registro de peligros que registró su ejecución; record verify lo presenta como la palabra del equipo.

Siguientes pasos

• Techos de riesgo cubre las reglas que miden un peligro.
• Gating cubre cómo un techo bloquea una publicación.