La cadena del riesgo de IA se rompe entre eslabones, no en ellos

Muchas organizaciones que gobiernan IA tienen ya los siete eslabones de la cadena: una evaluación de riesgos, un registro, unas mitigaciones, unos controles, unos indicadores, alguna forma de monitorización y un procedimiento de incidentes. Y aun así, cuando algo sale mal, la cadena no siempre lo para. Desde mi experiencia, la razón casi nunca está dentro de un eslabón. Está en el paso de uno a otro: un riesgo que no se traduce en ningún control, un control que ningún indicador mide, un indicador sin umbral que dispare nada, una monitorización que no sabe qué es un incidente, un incidente que no vuelve a la evaluación.

Por eso el enfoque que sigo no empieza por los eslabones sino por sus juntas. Cada eslabón se define por lo que entrega al siguiente, y cada junta tiene un dueño. Lo que sigue es la cadena entera, con lo que pide en cada punto el Reglamento (UE) 2024/1689 para los sistemas de alto riesgo y con el marco de incidentes de la OCDE al final. Con una advertencia de papeles por delante: el sistema de gestión de riesgos del artículo 9, la vigilancia poscomercialización del 72 y la notificación de incidentes graves del 73 son obligaciones de quien fabrica el sistema (el proveedor). Quien lo usa bajo su propia autoridad (el responsable del despliegue, deployer) tiene las suyas en el artículo 26 y, en algunos casos, la evaluación de impacto en los derechos fundamentales del 27. La cadena sirve a los dos; lo que cambia es qué eslabones le exige la ley a cada uno, y por dónde se tocan.

Antes del primer eslabón: qué se evalúa y contra qué

La cadena necesita dos cosas que no son eslabones. Un inventario que diga qué sistemas hay, quién los usa y para qué, porque lo que no está en la lista no entra en la cadena: es la razón por la que la IA en la sombra es un fallo de inventario. Y unos criterios de riesgo fijados por la dirección (qué nivel se acepta, quién puede aceptarlo y por encima de qué nivel sube a comité), porque sin ellos cada evaluación decide su propia vara de medir.

Los siete eslabones, por lo que entregan

1. Evaluación de riesgos. Parte del sistema concreto, no de un catálogo: su finalidad prevista, el uso indebido razonablemente previsible y las personas a las que afecta. El artículo 9.2 del reglamento lo pide en esos términos, y ISO/IEC 42001 lo separa en evaluación del riesgo (6.1.2) y evaluación del impacto del sistema (6.1.4). Entrega riesgos con nombre de este sistema. Si los riesgos que salen podrían ser de cualquier otro, la evaluación no ha empezado.

2. Riesgo. Cada riesgo se escribe como causa, hecho y consecuencia, con un dueño y un nivel. «Sesgo» no es un riesgo; «el modelo puntúa peor a candidatos con carreras interrumpidas y eso deja fuera a personas por un motivo protegido» sí lo es. Entrega un enunciado que se puede tratar, y un nivel que alguien ha aceptado.

3. Mitigación. Es la decisión de tratamiento, y el reglamento le da un orden de preferencia que conviene respetar también fuera del alto riesgo. El artículo 9.5 pide primero eliminar o reducir el riesgo con el diseño, después mitigar y controlar lo que no se pueda eliminar, y después informar y formar a quien usa el sistema. Y exige que el residual de cada peligro, y el del sistema en conjunto, se considere aceptable. Entrega el residual aceptado por escrito, con nombre y fecha.

4. Control. Es la mitigación convertida en algo que se puede comprobar: qué se hace, quién lo hace, cada cuánto y qué evidencia deja. Una mitigación sin control es una intención. Entrega un control con prueba de eficacia, no solo de existencia.

5. Indicador. Mide si el control funciona, no si se ejecutó. Es la junta que más falla, y le he dedicado una pieza entera, la del KPI que mentía. Los indicadores rezagados, además, arrancan en verde por falta de historia: cero incidentes no es una métrica. Tres ejemplos de indicador adelantado que sí miden un control: la proporción de resultados que la persona supervisora descarta o corrige (si es cero durante meses, la supervisión humana existe en el papel y no se ejerce), la deriva de los datos de entrada respecto a los de validación, y los cuasi accidentes registrados al mes. Entrega un umbral que dispara una acción concreta, con dueño.

6. Monitorización y observabilidad. No son lo mismo. La monitorización vigila lo que ya se sabe que hay que vigilar: los indicadores con su umbral. La observabilidad es poder investigar lo que nadie previó, con registros y trazas que reconstruyen qué hizo el sistema. El reglamento pide las dos piezas por separado: el registro automático de eventos (artículo 12), la conservación de esos registros por quien despliega el sistema (artículo 26.6), su vigilancia del funcionamiento (artículo 26.5) y la vigilancia poscomercialización de quien lo fabrica (artículo 72). Entrega una definición previa de qué cuenta como incidente y qué como peligro, para que la señal sepa adónde ir.

7. Incidente. Aquí entra el marco de la OCDE, y conviene adoptarlo tal cual porque resuelve dos problemas a la vez. El primero es de definición. La OCDE llama incidente de IA al hecho en el que el desarrollo, el uso o el fallo de un sistema provoca un daño (a la salud, a la gestión de infraestructuras críticas, a derechos humanos u obligaciones legales que los protegen, o a bienes, comunidades o el medio ambiente), y peligro de IA al que podría provocarlo. Los cuasi accidentes son peligros. Su incidente grave está alineado con el incidente grave del reglamento. El segundo problema es de forma: su marco común de notificación, de febrero de 2025, propone 29 criterios para describir un incidente, de los que siete son obligatorios (título, descripción, cómo se relaciona el sistema con el incidente, quién informa, material de soporte, gravedad y tipo de daño). Adoptar esos siete como plantilla interna hace comparable cualquier incidente propio con los del monitor público de la OCDE, y deja preparada la parte que el reglamento exige notificar.

Esa parte es estrecha. El artículo 73 obliga al proveedor de un sistema de alto riesgo a notificar los incidentes graves a la autoridad de vigilancia del mercado, en quince días como máximo desde que establece el vínculo causal, en dos si la infracción es generalizada o afecta a infraestructuras críticas, y en diez si hay un fallecimiento, con la posibilidad de una primera notificación incompleta. El plazo corre desde que se establece el vínculo causal entre el sistema y el incidente, o su probabilidad razonable, y eso convierte una pregunta técnica en una de gobierno: quién decide que hay vínculo y en cuánto tiempo. Si no está escrito antes del primer incidente, la tentación de no mirar para no saber es real. Quien despliega el sistema vigila y avisa al proveedor y, si ve un riesgo, también a la autoridad, y suspende el uso (artículo 26.5). Entrega la lección de vuelta al eslabón 1.

La junta que cruza de una organización a otra

La junta más difícil no está dentro de una organización, sino entre quien usa el sistema y quien lo fabrica. Quien lo usa ve el incidente; quien lo fabrica tiene que reevaluar el sistema. El reglamento traza el camino (las instrucciones de uso del artículo 13 bajan del proveedor a quien despliega, la vigilancia y el aviso del artículo 26.5 suben de vuelta, y el artículo 25.4 pide acuerdo escrito con quien suministra componentes y modelos), pero el camino solo funciona si el contrato dice qué se avisa, en qué plazo y con qué registros. Es una de las cosas que tiene que decir una cláusula de IA con un proveedor.

La junta que cierra el círculo

El artículo 9.2 describe la gestión de riesgos como un proceso iterativo durante todo el ciclo de vida, y su letra c es la junta que cierra la cadena: evaluar otros riesgos a partir de los datos de la vigilancia poscomercialización. Dicho en operativo, un incidente, o un peligro bien registrado, tiene que reabrir la evaluación del sistema y, si hace falta, la de los sistemas parecidos. Si se cierra en el equipo que lo resolvió, la cadena vuelve a ser una línea.

El incidente no es el único que reabre la evaluación. El mismo artículo pide revisiones sistemáticas periódicas, y en la práctica la reabren también los cambios: de modelo, de datos de entrenamiento, de finalidad o de proveedor. Un cambio que no estaba previsto en la evaluación de la conformidad y que afecta al cumplimiento es, además, una modificación sustancial en el sentido del reglamento, con consecuencias propias.

Esa es también la diferencia entre gestionar riesgos y acumular deuda de gobierno: la deuda no es que falte un eslabón, es que nadie paga la junta.

Lo que decide la organización

Quién es dueño de cada junta, no solo de cada eslabón. El equipo de riesgos tiene la evaluación, el de control interno los controles, el de datos los indicadores, el de operaciones la monitorización. Las juntas (del riesgo al control, del control al indicador, del indicador a la acción, del incidente a la evaluación) necesitan un nombre cada una. Es la misma lógica de las ruedas de quién responde: que algo exista no dice quién responde de que funcione.

Qué umbral dispara qué. Un indicador sin umbral es decoración, y un umbral sin acción asociada es una alarma que nadie atiende. Cada indicador de la cadena tiene que decir qué pasa cuando cruza la línea y quién lo hace.

Quién establece el vínculo causal. Es la decisión que pone en marcha el reloj del artículo 73, y por eso tiene que tener nombre y plazo antes de que haga falta.

Que el registro de peligros se use. Si solo se registra lo que hay que notificar, la organización aprende de la punta del iceberg. El registro de cuasi accidentes, con los siete criterios de la OCDE, es la pieza que menos cuesta y más informa, siempre que informar de un peligro no tenga coste para quien lo cuenta.

Una cadena de riesgo no se juzga por sus eslabones, sino por lo que pasa entre ellos el día que algo sale mal.