El expediente de gestión de riesgos más habitual que me encuentro tiene una fecha de creación y una fecha de modificación. Y son la misma: el día antes de la auditoría. Describe un sistema que ya cambió tres veces desde que se escribió. Nació muerto.
Y lo sé porque lo he escrito yo —no para el Reglamento de IA, que todavía no ha auditado a nadie, sino en producto sanitario, bajo el MDR, donde ese expediente de riesgos se inspecciona desde hace décadas—. He reconstruido un análisis de riesgos a destiempo, para que cuadrara con un sistema que ya había cambiado, antes de entender lo que hacía mal. Y un expediente que escribes para que el panel salga verde no demuestra nada. Por eso reconozco el patrón, que no es mala fe: se entendió «gestión de riesgos» como un entregable que hay que tener, no como un trabajo que hay que hacer. Quien lo redacta no miente —rellena lo que cree que le piden—. Pero mira al sitio equivocado, como miraba yo. Y el Reglamento de IA trae esa misma película, otra vez. Ya la he visto.
Y hay una manera de verlo que cualquiera que sepa programar capta al instante. Nadie en su sano juicio escribe todas las pruebas el último día, sobre el código ya terminado, para demostrar que funciona. Las pruebas se escriben mientras construyes, y cada prueba que falla te obliga a cambiar el código. La gestión del riesgo en IA de alto riesgo es eso mismo —o debería serlo—. No un informe que certifica al final. Un bucle que dirige por el camino.
Esta es la tercera de las preguntas que dejé planteadas en el pilar: ¿gestionas esos riesgos como un bucle continuo, o como un informe que se escribe el último día? Voy a por ella.
Qué pide de verdad el artículo 9
Lo primero, leer bien lo que dice. El artículo 9 del Reglamento de IA no habla de un documento de riesgos. Habla de un sistema de gestión de riesgos, y lo define como un proceso continuo e iterativo, planificado y mantenido durante todo el ciclo de vida del sistema. Tres palabras cargan con casi todo: proceso, continuo, ciclo de vida.
Proceso, no artefacto. No es un PDF que existe: es un trabajo que pasa. Continuo, no puntual: no se cierra el día que despliegas. Y de todo el ciclo de vida: la fase en la que el sistema ya está decidiendo sobre personas en producción es parte del bucle, no el final del bucle. El artículo además te pide algo que un informe de casillas casi nunca tiene: pronunciarte sobre el riesgo residual —el que queda después de tus mitigaciones— y decir, con criterio, que es aceptable. Eso no se copia de una plantilla. Se razona sobre tu sistema.
En la pieza anterior vimos cómo identificar los riesgos concretos de tu sistema —los de tu caso de uso, tus datos y las personas a las que afecta—. Esto es el paso siguiente: una vez sabes cuáles son, la pregunta es qué haces con ellos. Y la respuesta del artículo 9 es: los haces girar.
Esto no es nuevo. Es disciplina prestada.
Conviene quitarle el aura de novedad regulatoria. Gestionar el riesgo como un bucle continuo no lo inventó el Reglamento de IA: es práctica madura, importada de la ingeniería que se toma en serio el daño.
La raíz es genérica —la disciplina de gestión del riesgo que se usa en cualquier sector serio—. De ahí baja al producto sanitario, donde tratar el riesgo como un ciclo que no se cierra nunca es obligatorio desde hace décadas: un fabricante de un equipo médico que entregara su análisis de riesgos el día antes de la inspección sería impensable. Y de ahí llega la guía específica para inteligencia artificial, que describe el mismo bucle adaptado a nuestros sistemas. Pasé años construyendo modelos en sitios así —inspección industrial, imagen médica—, donde una predicción equivocada no es un mal trimestre. Esto se aprendía antes de que existiera ningún reglamento: no se trazaba el riesgo para pasar una auditoría, se trazaba para que nadie saliera dañado.
Quien viene de un entorno regulado ya sabe hacer esto. Quien viene del software puro lo reconoce en cuanto ve el paralelismo con las pruebas. El Reglamento no pide una capacidad nueva. Pide una vieja, bien hecha.
El bucle, fase a fase
Esa guía describe el proceso como un ciclo de fases que se realimentan. No reproduzco su texto —son normas con derechos de autor—, pero sí puedo nombrar lo que cubre, en lenguaje de ingeniería y para tu sistema:
- Comunicación y consulta. El riesgo no vive en la cabeza de una persona ni en una carpeta de cumplimiento. Cruza el muro —quien construye, quien opera y quien responde hablan del mismo mapa— y mira hacia fuera: a las partes interesadas afectadas, las personas sobre las que decide el sistema, cuyo punto de vista descubre riesgos que desde dentro no se ven.
- Alcance, contexto y criterios. Antes de medir nada, decides qué cuenta como riesgo aceptable en tu caso de uso. Sin ese criterio, «riesgo alto» es una palabra sin escala.
- Identificación. Qué puede salir mal en tu sistema concreto —la pieza anterior, entera, vive aquí—.
- Análisis. Para cada riesgo, su probabilidad y su gravedad —apoyándote en la cadena causal que ya trazaste al identificarlo—.
- Evaluación. Cuáles toca tratar primero. No todo a la vez: por gravedad y por probabilidad.
- Tratamiento. Y aquí está el corazón: cada medida que metes en el sistema nace de un riesgo concreto. Si no puedes señalar el riesgo del que cuelga un control, sobra el control —o falta el riesgo escrito—.
- Seguimiento y revisión. El sistema ya en producción se vigila, y lo que ves ahí vuelve al principio del bucle.
- Registro e informe. Queda constancia de todo lo anterior. No como tarea aparte: como rastro de haberlo hecho.
Léelo en orden y parece una lista. No lo es. Es un círculo. La última fase —vigilar en producción— realimenta la primera. Aquí entra la vigilancia poscomercialización del artículo 72: cuando el modelo en producción se aleja de lo que validaste, eso no es un incidente que anotas en un parte. Es un disparador que reabre el bucle. Vuelves a identificar, a analizar, a tratar. El sistema que era conforme el día del lanzamiento puede dejar de serlo tres meses después sin que toques una línea, solo porque el mundo cambió. Si tu gestión de riesgos no tiene esa vuelta, no es un bucle. Es una línea recta que termina en el despliegue.
Riesgo a diseño, como prueba a código
Ahora el paralelismo, en serio, porque es la lectura del artículo 9 que aguanta una evaluación de conformidad.
En el desarrollo guiado por pruebas escribes la prueba antes. La ves fallar —rojo—. Escribes el código mínimo para que pase —verde—. Refactorizas. Cada prueba es una especificación ejecutable: dice qué tiene que cumplir el código, y comprueba que lo cumple.
El desarrollo dirigido por el riesgo funciona igual. Identificas el riesgo concreto de tu sistema —rojo—. Diseñas el control que lo mitiga —verde—. Verificas que el riesgo residual es aceptable. Dejas registro. El riesgo es la especificación; la decisión de diseño es la respuesta que tiene que cumplirla.
Aquí está el bisturí. Una prueba que nadie ejecuta no vale nada —da igual lo bien escrita que esté—. Un riesgo que no dirige ninguna decisión de diseño es exactamente lo mismo: teatro. El expediente que nace el día antes de la auditoría está lleno de esos riesgos —enumerados, clasificados, con su color— que jamás cambiaron una línea del sistema. Se parecen a las pruebas que se escriben después, sobre el código ya hecho, para que el panel salga verde. Verde no demuestra nada cuando lo escribiste para que saliera verde.
Llamo a esto desarrollo dirigido por el riesgo: el riesgo dirige el diseño. No es una metáfora bonita para una presentación. Es una disciplina —la única forma de leer el artículo 9 en la que el expediente que sale describe de verdad el sistema que tienes—.
Qué cambia en tu equipo el lunes
Aterrizo, porque dicho así suena a principio y no a práctica. Tratar el riesgo como un bucle cambia cuatro cosas concretas:
- El registro de riesgos vive en el repositorio, versionado junto al código, el modelo y los datos —no en una carpeta compartida que nadie abre entre auditorías—. Se mueve cuando se mueve el sistema.
- Cada control enlaza con el riesgo que lo justifica y con la prueba que lo verifica. Trazabilidad en los dos sentidos: de un control sabes a qué riesgo responde; de un riesgo sabes con qué lo cubriste y cómo lo compruebas.
- La deriva en producción reabre riesgos sola. El seguimiento del que hablábamos no espera a la siguiente auditoría para entrar en el bucle: la realimentación es parte del sistema, no una reunión trimestral.
- El expediente de gestión de riesgos del artículo 9 sale del bucle, no se redacta aparte. Si las tres cosas anteriores están, el documento es una vista de lo que ya hiciste —no un relato que reconstruyes de memoria—.
Esto es lo que vengo llamando GovOps: el mismo movimiento que llevó la operación al desarrollo —DevOps—, luego la seguridad —DevSecOps—, luego los modelos —MLOps—, aplicado ahora a la conformidad. La gestión del riesgo deja de ser un mundo aparte y entra al flujo donde vive el modelo. Y entonces la evidencia de que el bucle giró no se fabrica a mano después. Sale por construcción. Pero cómo se firma y se encadena esa evidencia es harina de otro capítulo.
Una nota de rigor, breve
Para no confundir el estado de las cosas. La guía internacional de gestión del riesgo para IA está vigente y es la que estructura el bucle que acabo de describir, pero hoy es de apoyo: por sí sola no te concede presunción de conformidad. La norma europea armonizada que dará esa presunción para el artículo 9 todavía es un borrador, en consulta pública hasta el 31 de julio de 2026; aún no se puede invocar. Esto es solo el estado de hoy —el porqué de la regla, y el contraste con producto sanitario, lo desbrocé en la pieza anterior—.
El calendario, ahora ya firme: la obligación para la IA de alto riesgo del Anexo III se aplazó al 2 de diciembre de 2027 —fecha que los colegisladores acaban de dejar firme al aprobar la reforma del Reglamento—. Como componente de seguridad del Anexo I, el 2 de agosto de 2028. Tiempo hay. Pero el bucle no empieza en 2027: el sistema que diseñas este trimestre es el que tendrás que defender entonces, y un bucle no se rebobina hacia atrás para llenarlo de decisiones que nunca tomaste.
Tener identificados tus riesgos te dice contra qué diseñas. Hacerlos girar —que cada uno dirija una decisión y que la producción los reabra— es lo que convierte esa lista en ingeniería. La siguiente pregunta es quién mira al sistema cuando ya decide: la supervisión humana, real o decorativa. Esa es la siguiente pieza.
Pruebas, no promesas: el riesgo dirige el diseño, como las pruebas dirigen el código. La evidencia se genera, no se redacta. Si construyes IA que decide sobre personas, suscríbete y seguimos.
— Rodrigo