Artículo 9 del AI Act: convertir los riesgos en controles y pruebas verificables

Qué cubre esta guía —y qué queda fuera—

El artículo 9 del Reglamento europeo de inteligencia artificial (AI Act) exige a los proveedores de sistemas de IA de alto riesgo establecer, aplicar, documentar y mantener un sistema de gestión de riesgos. La idea práctica que desarrolla esta guía es sencilla: que cada riesgo identificado quede conectado con una medida y que haya una forma definida de comprobar si esa medida sirve para reducirlo.

Esta guía se limita a ese artículo. No es una explicación completa del Reglamento, una evaluación jurídica de un producto ni un método para decidir por sí solo si un sistema es de alto riesgo. Tampoco convierte cada herramienta de IA en un sistema sujeto al artículo 9. Primero hay que determinar si el sistema y su finalidad de uso entran en el ámbito pertinente del Reglamento; solo entonces tiene sentido aplicar esta plantilla como ayuda de trabajo.

El artículo establece obligaciones para los proveedores de sistemas de IA de alto riesgo. Eso no significa que cualquier persona que use un sistema tenga automáticamente que crear y mantener el sistema de gestión de riesgos exigido a los proveedores. Los deberes de otros actores, como los responsables del despliegue, deben analizarse aparte. Si necesitas orientarte sobre el panorama general, consulta las guías de Inferama sobre seguridad, comparación de sistemas y descubrimiento de herramientas de IA; no sustituyen la comprobación de las obligaciones aplicables a un caso concreto.

A lo largo del artículo distinguimos dos niveles. «Requisito del Reglamento» identifica lo que recoge el artículo 9. «Recomendación operativa» señala una forma práctica de organizar el trabajo que puede ayudar a demostrarlo, pero que no debe confundirse con un formulario o campo obligatorio establecido literalmente por la norma.

Comprobación previa: ¿el sistema está dentro del ámbito?

Antes de registrar riesgos bajo el artículo 9, identifica el sistema concreto y su finalidad prevista. La clasificación no depende únicamente de que el producto use un modelo avanzado, de que la organización lo considere sensible o de que sus resultados tengan consecuencias importantes. El Reglamento determina qué sistemas se consideran de alto riesgo mediante categorías y condiciones, y el encaje puede depender de cómo se usa el sistema y de la función que desempeña.

Como comprobación inicial, describe el uso real y previsto con suficiente precisión: quién opera el sistema, quién recibe o utiliza sus resultados, qué decisión o proceso apoya y en qué contexto se incorpora. Después contrasta esa descripción con las disposiciones aplicables del Reglamento, incluidas las categorías pertinentes y las condiciones o excepciones que puedan afectar a la clasificación. Si hay dudas sobre la categoría, el papel de la organización o la aplicación temporal de una obligación, solicita revisión jurídica antes de tratar una conclusión provisional como un hecho.

No clasifiques un sistema solo por una descripción comercial, por la tecnología que incorpora o por el nombre de una categoría. Un mismo sistema puede tener distintos usos; la evaluación debe centrarse en el uso concreto que se pretende analizar. El ejemplo de selección de candidaturas que aparece más adelante es hipotético y sirve para mostrar cómo documentar un riesgo. No afirma que todo sistema de selección de candidaturas tenga automáticamente la misma clasificación jurídica.

Anota qué información respalda la conclusión inicial: documentación del producto, finalidad declarada, descripción del proceso y condiciones de despliegue. Si la conclusión depende de supuestos aún no confirmados, márcalos como pendientes. Esa precaución evita que la plantilla convierta una hipótesis de clasificación en una premisa aparentemente definitiva.

Del contexto a un riesgo que pueda analizarse

El artículo 9 plantea un proceso continuo e iterativo que debe abarcar el ciclo de vida del sistema. Para empezar de manera útil, describe el contexto de uso antes de enumerar daños posibles. La misma salida del sistema puede tener consecuencias distintas según quién la interprete, qué otras comprobaciones existan y si una persona puede corregir un error antes de que afecte a alguien.

El Reglamento se refiere a riesgos conocidos y razonablemente previsibles para la salud, la seguridad y los derechos fundamentales cuando el sistema se usa según su finalidad prevista. También exige estimar y evaluar riesgos que puedan surgir con esa finalidad y en condiciones de uso indebido razonablemente previsibles. Por tanto, conviene examinar tanto el uso previsto como los desvíos previsibles, sin convertir cualquier posibilidad remota en un riesgo demostrado.

Para cada escenario, separa tres cosas: el hecho que conoces, la hipótesis que quieres comprobar y el posible daño. Por ejemplo, puede ser un hecho que el sistema produce una clasificación; una hipótesis, que ciertos registros incompletos aumentan la probabilidad de una clasificación incorrecta; y un daño plausible, que una persona quede excluida de una fase de evaluación sin una revisión adecuada. La prueba deberá determinar si la hipótesis se sostiene y en qué condiciones.

Incluye a las personas potencialmente afectadas y las condiciones que pueden cambiar el resultado: calidad o ausencia de datos, idioma, entorno de uso, intervención humana, dependencia de otros componentes y cambios en el proceso. No hace falta fingir certeza donde solo hay una hipótesis. Es mejor indicar qué información falta y cómo se investigará que presentar una estimación sin fundamento como si fuera una medición.

De cada riesgo a una medida pertinente

Una vez descrito el escenario, define qué cambio puede prevenir o reducir el riesgo y por qué esperas que funcione. El artículo 9 requiere adoptar medidas de gestión de riesgos apropiadas y dirigidas a los riesgos identificados. También establece que los riesgos deben eliminarse o reducirse todo lo posible desde el punto de vista técnico mediante un diseño y desarrollo adecuados; cuando no puedan eliminarse, deben aplicarse medidas apropiadas de mitigación y control.

En la práctica, una medida puede estar vinculada al diseño del sistema, a su configuración, a instrucciones o a la forma de integrarlo en el proceso. La elección depende del riesgo y del sistema. No des por sentado que una advertencia en la interfaz o una revisión humana genérica bastan: describe qué hará la medida, en qué momento se aplica, quién puede intervenir y qué limitaciones tiene. Si una persona debe recibir información o formación para desplegar el sistema de forma adecuada, especifica qué necesita saber y cómo se le proporciona; el artículo también contempla información y formación para los responsables del despliegue cuando corresponda.

La justificación de una medida debe estar vinculada al mecanismo del riesgo. Si el problema planteado es que datos incompletos producen resultados poco fiables, un control que solo registra la fecha de ejecución puede dejar intacta la causa. En cambio, podrían evaluarse mecanismos que detecten datos incompletos, impidan que un resultado no válido se use sin revisión o avisen a quien opera el sistema. Son opciones para investigar, no una prescripción universal: la prueba debe mostrar si son pertinentes y eficaces en el contexto concreto.

Ten en cuenta que el Reglamento relaciona la gestión con el conocimiento y el estado de la técnica, además de la finalidad prevista y el uso indebido razonablemente previsible. Por eso, el registro debe poder explicar por qué se eligió una medida y qué información sustentó esa elección. Cuando la medida no elimina el riesgo, deja constancia de lo que permanece y de las condiciones bajo las cuales el control podría fallar.

Diseñar pruebas antes de ejecutarlas

El artículo 9 incluye pruebas de los sistemas de alto riesgo para identificar las medidas de gestión de riesgos más apropiadas. También dispone que, cuando corresponda, las pruebas se realicen en distintas fases del desarrollo y, en todo caso, antes de la comercialización o puesta en servicio. La norma indica que deben realizarse conforme a métricas y umbrales probabilísticos definidos previamente y adecuados a la finalidad prevista. No fija en el propio artículo una métrica única que sirva para todos los sistemas.

Para que una prueba permita tomar una decisión, define de antemano qué escenario cubre, qué datos o condiciones intervienen, qué resultado observarás y qué criterio considerarás suficiente. Explica por qué ese criterio es pertinente para el uso previsto. Si lo determinas después de ver los resultados, aumenta el riesgo de adaptar la evaluación a lo que ya ocurrió y de no detectar fallos importantes.

Prueba también las condiciones que importan para el riesgo: por ejemplo, datos ausentes, cambios de idioma, casos limítrofes, entradas fuera de las condiciones habituales o intervención humana prevista. La selección debe tener una razón documentada; no hace falta enumerar escenarios sin relación con el uso. Si se usa una muestra, explica sus límites y qué grupos, situaciones o condiciones no representa. Un resultado favorable en una prueba acotada no demuestra por sí solo que el sistema sea seguro en cualquier entorno.

El resultado puede ser favorable, insuficiente o inconcluso. En los dos últimos casos, describe qué falló o qué impide concluir, ajusta la medida si procede y define una nueva prueba. Conserva los resultados y decisiones relevantes como parte de la evidencia de cómo se gestionó el riesgo. La obligación de probar no debe reducirse a guardar una puntuación: el propósito es evaluar medidas apropiadas y comprobar el comportamiento del sistema en relación con su finalidad.

Plantilla: conectar riesgo, control, prueba y decisión

Una fila de registro útil permite seguir la lógica completa sin confundir una propuesta de control con una medida ya validada. Para el ejemplo hipotético de selección de candidaturas, la cuestión no es afirmar que exista un sesgo o un daño probado. Se trata de mostrar qué información debería reunirse antes de decidir si un control reduce el riesgo planteado.

La medida debe corresponder al escenario y la prueba debe evaluar esa medida, no solo el sistema en abstracto. En el ejemplo, si el escenario es que un dato ausente influya en una clasificación que después no se revisa, una prueba pertinente podría examinar qué ocurre ante la ausencia de ese dato y si se activa el procedimiento de revisión previsto. Los criterios concretos y el resultado no pueden inventarse: deben definirse y medirse para el sistema real.

Registra por separado quién preparó la evaluación, quién aprobó una decisión interna y quién debe revisar cuestiones legales. La asignación de estas funciones puede ser una buena práctica de gobernanza, pero no atribuyas al artículo 9 un cargo universal que el texto no especifica. La persona o entidad obligada depende del papel que desempeñe conforme al Reglamento y del caso concreto.

Qué hacer con resultados insuficientes y riesgos residuales

Un resultado que no alcanza el criterio previsto no se arregla cambiando retrospectivamente el umbral para que parezca aceptable. Registra el resultado tal como se obtuvo, explica qué condición no se cumplió y analiza si la causa requiere modificar el diseño, añadir o cambiar una medida de mitigación, alterar el proceso de despliegue o restringir el uso evaluado. Después, planifica una nueva evaluación cuando sea pertinente.

Si la prueba no permite llegar a una conclusión, identifica la razón: falta de datos adecuados, un escenario no reproducible, una muestra limitada o una condición de uso no observada. Esa incertidumbre también es información relevante. Indica qué sería necesario para resolverla y quién debe tomar la decisión de seguir investigando, limitar el uso o escalar el asunto.

No describas un riesgo como eliminado si lo único que se ha hecho es reducir su probabilidad o limitar su impacto. La documentación debe dejar visible la diferencia entre el riesgo inicial, el efecto de las medidas y lo que todavía no se ha probado. Esta separación ayuda a que quienes revisen el expediente no interpreten una acción prevista como una eficacia demostrada.

El artículo 9 exige documentar el sistema de gestión de riesgos y las decisiones pertinentes. Como recomendación operativa, conserva junto al registro las versiones de las pruebas, las condiciones de ejecución, los resultados y el razonamiento de las decisiones. Antes de fijar plazos de conservación, confirma las disposiciones aplicables al sistema y a la organización: esta guía no establece un periodo universal.

Revisión durante el ciclo de vida y relación con otros procesos

La gestión de riesgos del artículo 9 no se plantea como una evaluación única que termina cuando se completa una prueba. El sistema debe funcionar como un proceso continuo e iterativo a lo largo del ciclo de vida, con revisión y actualización regulares y sistemáticas. La información obtenida después del despliegue puede ser relevante para evaluar riesgos; el artículo contempla también los datos reunidos mediante el seguimiento poscomercialización al que remite el Reglamento.

Como propuesta de organización, define qué cambios pueden activar una revisión: modificaciones relevantes del sistema, cambios en la finalidad o el contexto de uso, problemas detectados, nueva información sobre riesgos o resultados de seguimiento. Establece quién recibe esa información y cómo se decide si corresponde actualizar el análisis, las medidas o las pruebas. Esos disparadores concretos son una recomendación para hacer operativa la revisión, no una lista literal del artículo 9.

Si el sistema ya está sujeto a requisitos de gestión de riesgos de otra legislación de la Unión, el artículo 9 prevé que el sistema de gestión correspondiente pueda formar parte de los procesos exigidos por esa legislación o contribuir a ellos, en las condiciones indicadas en el Reglamento. No des por hecho que un procedimiento previo satisface automáticamente todas las obligaciones del AI Act: comprueba qué riesgos, evidencias y requisitos cubre realmente cada proceso.

La fecha en que una obligación resulta aplicable depende de las disposiciones temporales pertinentes y puede requerir revisar las modificaciones y medidas transitorias vigentes. El calendario no se deduce solo del artículo 9. Antes de planificar una fecha de cumplimiento, comprueba el texto oficial vigente y las disposiciones aplicables al tipo de sistema y al papel de la organización. Si la fecha afecta a una decisión inmediata, solicita asesoramiento jurídico actualizado.

Criterios prácticos antes de cerrar la evaluación

Antes de considerar completo el trabajo, revisa si cada riesgo tiene una descripción comprensible y si se distingue lo observado de lo hipotético. Comprueba que cada medida responda a un riesgo específico, que su justificación pueda reconstruirse y que la prueba incluya criterios definidos antes de ejecutarse. Si una medida no se ha probado, identifícala como pendiente; si una prueba solo cubre ciertas condiciones, no extiendas su resultado a otras.

Verifica también que el análisis se refiera a la finalidad y al contexto realmente evaluados, que considere los usos indebidos razonablemente previsibles que correspondan y que no omita a personas potencialmente afectadas. Documenta los límites del trabajo y las cuestiones que exigen revisión legal o técnica. Cuando intervengan procesos ya existentes, comprueba qué cubren, qué evidencia aportan y qué lagunas permanecen.

El artículo 9 no es una certificación automática de que un sistema sea seguro ni una garantía de que no habrá daños. Es el fundamento de un proceso de gestión de riesgos que debe mantenerse y documentarse. La utilidad de una matriz no se mide por el número de filas, sino por si permite entender por qué se seleccionó una medida, qué prueba la respalda, qué resultado se observó y qué sigue sin resolverse.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.