ISO 23894 — gestión de riesgos de IA
ISO/IEC 23894:2023 es la guía de gestión de riesgos específica para sistemas de IA, derivada del marco genérico ISO 31000. Define un proceso iterativo de seis fases (§6.4–§6.7) que el motor sei implementa directamente. Es el estándar de proceso primario sobre el que se proyectan las obligaciones del EU AI Act Art. 9 y la cobertura de prEN 18228.
§6.4.2 — Identificación de riesgos
Sección titulada «§6.4.2 — Identificación de riesgos»La identificación es el primer paso del proceso: determinar qué eventos de riesgo pueden afectar al sistema, sus consecuencias potenciales y las fuentes de riesgo relevantes.
Implementación en el motor: el AssuranceProgram (la sección risk: de sei.yaml) es el registro vivo de identificación. Los riesgos se declaran con provenance explícita:
| Procedencia | Significado |
|---|---|
declared | Declarado por el equipo en el momento de diseño |
proposed_by_kag | Propuesto por el KAG (Knowledge Assessment Graph) vía sei assess |
derived_from_gap | Derivado de un hueco detectado en la evidencia |
El registro crece durante el desarrollo: sei assess ejecuta el KAG y lista los riesgos propuestos no declarados aún (advisory, no bloqueante). El humano cura el resultado y lo commitea. sei reconstruct puede mostrar cuándo se introdujo cada riesgo en el registro mediante git log -S <risk_id>.
§6.4.3 — Análisis de riesgos (matriz 5×5)
Sección titulada «§6.4.3 — Análisis de riesgos (matriz 5×5)»El análisis determina la naturaleza de cada riesgo y su nivel, combinando la probabilidad de ocurrencia con las consecuencias esperadas.
Implementación en el motor: la función risk_level(likelihood, impact) implementa la matriz 5×5 determinista. La probabilidad se expresa en cinco niveles (Rare, Unlikely, Possible, Likely, AlmostCertain); el impacto sigue la escala RiskLevel ya existente (Negligible, Low, Medium, High, Critical).
El análisis se calcula por dimensión: individual, societaria, y organizativa. Cada dimensión puede tener distintos niveles de probabilidad e impacto, permitiendo que el mismo evento de riesgo tenga perfiles distintos según a quién afecta.
El resultado del análisis se almacena en EvidenceBundle.risk_analysis (campo Vec<RiskAssessment>) en el bundle firmado.
§6.4.4 — Evaluación de riesgos frente al apetito
Sección titulada «§6.4.4 — Evaluación de riesgos frente al apetito»La evaluación compara el nivel de riesgo analizado contra los criterios de aceptabilidad definidos por la organización (apetito de riesgo). El resultado determina si el riesgo requiere tratamiento.
Implementación en el motor: evaluate(level, appetite) → Within | Exceeds. El apetito se declara en sei.yaml (risk.appetite) por dimensión, con niveles calibrados para cada escenario (en el escenario loan: individual/sociedad → MEDIUM, organización → HIGH).
Si el nivel analizado no excede el apetito, el riesgo puede monitorizarse sin tratamiento adicional. Si lo excede, debe tratarse.
§6.5 — Tratamiento de riesgos
Sección titulada «§6.5 — Tratamiento de riesgos»El tratamiento selecciona e implementa opciones para modificar el perfil de riesgo hasta llevarlo dentro del apetito. ISO 23894 reconoce las opciones REDUCE, AVOID, TRANSFER y ACCEPT.
Implementación en el motor: el tipo TreatmentMethod modela las cuatro opciones:
| Opción | Comportamiento en el motor |
|---|---|
REDUCE | El control bloqueante debe pasar; el riesgo se evalúa como cerrado o con discrepancia |
ACCEPT | El riesgo se acepta explícitamente; el gate no falla por este riesgo (ControlResult.accepted) |
AVOID | El riesgo se evita; el ciclo termina en Avoided |
TRANSFER | El riesgo se transfiere a un tercero; el ciclo termina en Transferred |
El motor también modela riesgos positivos (oportunidades) con RiskKind::Opportunity y TreatmentMethod::Pursue. Una oportunidad se persigue, nunca gatea.
Modalidades de tratamiento: el tratamiento es un cambio versionado — a código, a un parámetro operativo, o (en el futuro) a un prompt. El commit del cambio es el acto de tratamiento; git lo fecha, atribuye y ancla a la tripleta (código, modelo, dataset).
Ver Dos gates: frescura y riesgo para el ciclo completo.
Residual híbrido
Sección titulada «Residual híbrido»El residual de un riesgo se calcula de forma híbrida: la medida declara el residual_likelihood esperado tras el tratamiento; el control bloqueante lo confirma empíricamente. Si hay discrepancia entre el residual declarado y el observado, el ciclo termina en estado Discrepancy.
Los estados posibles del ciclo de riesgo (RiskCycle) son:
| Estado | Condición |
|---|---|
Closed | El nivel inherente estaba dentro del apetito, o el tratamiento llevó el residual dentro del apetito |
Monitored | Sin control bloqueante; nivel dentro del apetito; bajo vigilancia |
Open | Nivel excede apetito; tratamiento pendiente o ineficaz |
Accepted | Riesgo aceptado explícitamente con justificación |
Discrepancy | El residual declarado y el observado divergen |
Avoided / Transferred | Riesgo eliminado o transferido |
Realized / Pursuing | Para oportunidades |
§6.6 — Monitorización y revisión
Sección titulada «§6.6 — Monitorización y revisión»El proceso exige monitorizar la eficacia de los tratamientos y el estado del riesgo a lo largo del ciclo de vida. Los cambios en el contexto del sistema o en el entorno pueden hacer que riesgos ya cerrados vuelvan a ser relevantes.
Implementación en el motor: sei status evalúa la frescura de la evidencia firmada sin recomputar. Si el código, el modelo o el dataset han cambiado desde la última ejecución, la evidencia se considera obsoleta y el ciclo se reinicia. El modelo de deriva tipada (clase A, B, C) determina qué partes del ciclo necesitan re-evaluación. Ver Metodología: Deriva tipada.
§6.7 — Registro y reporte
Sección titulada «§6.7 — Registro y reporte»El proceso exige documentar los resultados de cada fase y mantener registros trazables para su revisión posterior.
Implementación en el motor: sei reconstruct reproduce el ciclo completo de tratamiento por riesgo desde el git log del bundle, sin recomputación. El informe muestra las cinco fases: ①identificación ②análisis ③evaluación-vs-apetito ④tratamiento (arco control+evento de tratamiento) ⑤residual (ciclo). El bundle firmado almacena risk_analysis + assessor (identidad del evaluador, §6.7). sei approve --by registra la aprobación de dirección.
Catálogo de cláusulas
Sección titulada «Catálogo de cláusulas»El fichero crates/seigarrena-core/resources/standards/iso-23894-clauses.yaml declara las cláusulas modeladas:
standard: iso/23894@2023clauses: - { id: "6.4.2", title: "Risk identification", cycle_phase: identification } - { id: "6.4.3", title: "Risk analysis", cycle_phase: analysis } - { id: "6.4.4", title: "Risk evaluation", cycle_phase: evaluation } - { id: "6.5", title: "Risk treatment", cycle_phase: treatment } - { id: "6.6", title: "Monitoring and review", cycle_phase: monitor } - { id: "6.7", title: "Recording and reporting", cycle_phase: file }Diferencia con prEN 18228
Sección titulada «Diferencia con prEN 18228»ISO 23894 define el proceso de gestión de riesgos. prEN 18228 define los requisitos de producto para sistemas de IA (paradigma product-safety: hazard→harm, jerarquía de control, riesgo residual global). Venturalítica implementa ISO 23894 como motor y proyecta prEN 18228 por catálogo de cláusulas. Un mismo bundle firmado puede generar informes de conformidad para ambos estándares.
Ver prEN 18228 y Guía: Conformidad dual.