Del riesgo al requisito en seis preguntas
Qué es
Convertir cada riesgo identificado en un control y cada control en requisitos del sistema de IA que se pueden verificar y validar.
- Quién
- El proveedor del sistema de IA. Lo hace ingeniería, con calidad y con quien gestiona los riesgos.
- Cuándo
- Después de identificar y evaluar los riesgos, en el diseño. Se repite con cada versión del sistema.
- Dónde
- En la especificación de requisitos del sistema, trazada hasta la documentación de riesgos y las pruebas.
- Por qué
- La EN 18286 pide requisitos completos, inequívocos y verificables. Un riesgo sin requisito no se puede probar.
- Cómo
- Riesgo → control, en el orden de la prEN 18228. Control → requisito, escrito con EARS. Requisito → prueba. Detalle abajo.
Lo que pide la EN 18286
En su apartado 8.3.2.1, la EN 18286 pide al proveedor que fije los requisitos del sistema de IA necesarios para cumplir el Reglamento. Pone como ejemplo los que salen del control de riesgos. Tienen que ser completos, inequívocos, verificables y validables. Después pide revisarlos (8.3.2.2), bajarlos a especificaciones (8.3.2.3) y verificarlos y validarlos (8.4).
Para saber qué hace bueno a un requisito, la norma remite a dos normas de ciclo de vida:
- ISO/IEC/IEEE 15288: los procesos del ciclo de vida de un sistema, del concepto a la retirada.
- ISO/IEC/IEEE 29148: la ingeniería de requisitos dentro de ese ciclo.
El modelo de ciclo de vida del sistema de IA lo toma de la ISO/IEC 22989, cláusula 6. La ingeniería de requisitos que estas normas dan por sabida está en el área de requisitos del SWEBOK. Es la guía del IEEE sobre el cuerpo de conocimiento de la ingeniería de software.
Del riesgo al control
El ejemplo sigue el cribado de CV de la sesión de identificación de riesgos. El sistema es ficticio. Ordena los CV de cada oferta y propone a Selección los veinte primeros. La cadena 2 quedó así: quien tiene un hueco de más de un año baja en la lista por ese hueco. La única barrera es una muestra de diez CV al azar que Selección abre a mano, y no hay barrera preventiva.
La prEN 18228, la norma del artículo 9, todavía en borrador, ordena los controles en tres niveles:
| Nivel | Qué es | En el cribado de CV |
|---|---|---|
| 1. Diseño seguro | Quita el peligro del sistema. Es el control preferido. | El modelo no recibe los meses sin empleo ni la fecha de fin del último puesto, que los reintroduce. |
| 2. Protección | Detecta o frena el daño cuando el diseño no basta. | Cada versión se mide por separado con y sin hueco, y no se publica si la diferencia pasa del umbral. La muestra al azar la saca el sistema e incluye CV con huecos. |
| 3. Información | Instrucciones y formación para quien usa el sistema. Nunca va sola. | La lista avisa a Selección de que es una propuesta y no descarta a nadie. |
Dos matices de la norma. Un procedimiento interno no cuenta como control: la muestra que Selección abre a mano pasa a serlo cuando el sistema la saca y la registra. Y cada control se revisa por si crea un peligro nuevo, como la fecha de fin del último puesto, que reintroduce el hueco.
Del control al requisito, con EARS
EARS (Easy Approach to Requirements Syntax) es una forma de escribir requisitos con cinco patrones. La publicaron Alistair Mavin y otros en 2009, en Rolls-Royce. Hay una guía abierta del primer autor. Froga escribe así sus propios requisitos y lo pide a los requisitos que escriben sus usuarios.
| Patrón | Forma |
|---|---|
| Siempre | El <sistema> <respuesta>. |
| De estado | Mientras <estado>, el <sistema> <respuesta>. |
| De evento | Cuando <disparador>, el <sistema> <respuesta>. |
| No deseado | Si <condición no deseada>, entonces el <sistema> <respuesta>. |
| Opcional | Donde <rasgo presente>, el <sistema> <respuesta>. |
Antes, un término. La brecha del hueco compara CV con y sin hueco de más de un año. Es la diferencia en la parte de candidaturas que encajan y quedan fuera de los veinte primeros.
Los controles del cribado, escritos así:
- Siempre. El sistema de cribado excluye de sus entradas los meses sin empleo y la fecha de fin del último puesto.
- De evento. Cuando se entrena una versión nueva, el sistema de cribado calcula la brecha del hueco.
- No deseado. Si la brecha del hueco supera los 2 puntos, entonces el sistema de cribado bloquea la publicación de la versión.
- De evento. Cuando hay CV con hueco de más de un año fuera de la lista, el sistema de cribado incluye al menos tres en la muestra.
- De estado. Mientras Selección no ha abierto los diez CV de la muestra, el sistema de cribado mantiene abierto el proceso.
- Opcional. Donde el sistema de cribado se integra en la herramienta de selección de la empresa, la lista de los veinte primeros muestra el aviso «Propuesta. No descarta a nadie».
El umbral de 2 puntos es inventado para el ejemplo. Lo fija la organización en sus criterios de aceptación del riesgo.
Las reglas de redacción de Froga, que valen para cualquier requisito:
- Un sujeto que no se lee de dos maneras. Aquí, siempre «el sistema de cribado».
- Una exigencia por requisito. Si dos cosas pueden fallar por separado, son dos requisitos.
- Una frase, y sin el porqué: la razón va aparte, trazada al riesgo.
- Sin «puede». El requisito dice qué hace el sistema, no qué se le permite.
- Sin palabras de juicio. «Adecuado», «justo» o «a tiempo» se cambian por un umbral, una condición o un dato.
- Las prohibiciones, como comportamiento no deseado: «Si…, entonces…».
- El umbral y el plazo, dentro de la respuesta.
Del requisito a la prueba
La prEN 18228 pide dos comprobaciones por control (9.2): que está implantado y que reduce el riesgo.
| Requisito | Implantado (verificación) | Reduce el riesgo (validación) |
|---|---|---|
| 1 · Excluye las variables | Inspección: las dos variables no llegan al modelo. | Pares de CV iguales salvo el hueco quedan en el mismo puesto. |
| 2 · Mide la brecha | El informe de la brecha existe para cada versión. | Los datos de validación desglosados, que faltaban en la sesión. |
| 3 · Bloquea la versión | Una versión con 5 puntos de brecha, sembrada a propósito, no se publica. | La brecha se mantiene bajo el umbral en los procesos reales. |
| 4 · Muestra con huecos | En un proceso de prueba con CV con huecos fuera de la lista, la muestra lleva al menos tres. | El registro de la muestra por proceso, que también faltaba. |
| 5 · Muestra abierta | Un proceso con la muestra sin abrir no se cierra. | El mismo registro: cuántas muestras se abren enteras. |
| 6 · Aviso en la lista | El aviso aparece en la herramienta. | Selección abre CV de fuera de la lista. Se comprueba en el registro. |
Cada fila deja una prueba firmada en la documentación técnica: el riesgo, su control, el requisito, la verificación y la validación, enlazados.
Froga hace esa cadena: riesgos, controles, requisitos en EARS, verificación y validación, firmados sobre las herramientas que ya usa el equipo. Froga, del riesgo a la prueba.
