Lo esencial
- La gestión de riesgos de IA es un programa operativo con un responsable único, no un glosario de marcos: un mismo ciclo (identificar, evaluar, mitigar, supervisar) que absorbe
NIST AI RMF,ISO/IEC 42001conISO/IEC 23894y el artículo 9 de la EU AI Act en un solo conjunto de controles, propietarios y evidencias. - Se diferencia del riesgo empresarial o de ciberseguridad clásico porque el modelo cambia con los datos, se degrada con el tiempo y produce resultados probabilísticos difíciles de explicar.
- El artículo 9 de la EU AI Act lo convierte en obligación legal para los sistemas de alto riesgo: un proceso continuo e iterativo a lo largo del ciclo de vida, con revisión sistemática.
- Las categorías de riesgo se agrupan en cuatro familias: datos, modelo, operación y seguridad, y derechos fundamentales y cuestiones jurídicas.
- Un programa creíble deja artefactos que un auditor u organismo notificado pueda inspeccionar: inventario de IA, registro de riesgos, mapa de controles, evidencias y firma de aceptación del riesgo residual, dentro de un cumplimiento de la gestión de riesgos más amplio.
¿Qué es la gestión de riesgos de IA?
La gestión de riesgos de IA es la práctica de identificar, evaluar, tratar y supervisar los peligros específicos que introduce un sistema de inteligencia artificial a lo largo de toda su vida útil, desde el entrenamiento hasta el despliegue, el uso real y la retirada. No es un ejercicio documental que se archiva tras una auditoría, sino un circuito vivo que produce decisiones: qué se despliega, con qué salvaguardas, quién responde y bajo qué condiciones se acepta el riesgo que queda. Conviene distinguirla de dos disciplinas con las que se confunde. La gestión de riesgos empresariales trata amenazas relativamente estables (financieras, reputacionales, de continuidad) con causas conocidas. La ciberseguridad protege la confidencialidad, la integridad y la disponibilidad de los sistemas frente a atacantes. La gestión de riesgos de IA hereda elementos de ambas, pero añade una dificultad que ninguna resuelve: el sistema aprende de datos, su comportamiento se desplaza cuando el entorno cambia y sus salidas son probabilísticas, no deterministas. Un modelo puede pasar la validación en el laboratorio y, meses después, discriminar a un colectivo porque los datos de producción han derivado. Esa naturaleza cambiante obliga a tratar el riesgo de forma continua y contextual. El mismo modelo de puntuación puede ser inofensivo en una recomendación de contenidos y de alto riesgo en la concesión de un crédito o en la selección de personal. Por eso el propósito previsto, las personas afectadas y el contexto de uso forman parte inseparable del análisis. En la práctica, la gestión de riesgos de IA se apoya en un programa de gobernanza de la IA que fija los roles, las políticas y los mecanismos de decisión. Un programa maduro no pregunta «¿tenemos una política de IA?», sino «¿qué riesgo concreto plantea este sistema, quién es su propietario, qué control lo mitiga y qué evidencia lo demuestra?».
Por qué la gestión de riesgos de IA importa ahora
La presión regulatoria ha dejado de ser una hipótesis. El artículo 9 de la EU AI Act exige que todo proveedor de un sistema de alto riesgo establezca, implemente, documente y mantenga un sistema de gestión de riesgos concebido como un proceso continuo e iterativo a lo largo de todo el ciclo de vida, con revisión sistemática. La guía práctica de la EU AI Act para operadores desglosa cómo se traduce esa obligación en tareas concretas. No basta con una evaluación inicial: la norma pide identificar los riesgos para la salud, la seguridad y los derechos fundamentales, estimarlos, evaluarlos y adoptar medidas específicas hasta que el riesgo residual pueda considerarse aceptable. A la presión legal se suma la operativa. Los sistemas de IA fallan de maneras que los tradicionales no conocen: alucinan hechos, amplifican sesgos presentes en los datos, se degradan en silencio cuando el mundo cambia y pueden ser manipulados mediante entradas diseñadas para engañarlos. Cada fallo tiene consecuencias tangibles, desde decisiones erróneas que afectan a personas hasta sanciones, litigios y pérdida de confianza de clientes y reguladores. Existe además un problema de visibilidad que precede a cualquier control. Muchas organizaciones no saben cuántos sistemas de IA operan realmente dentro de sus procesos, porque los equipos adoptan herramientas por su cuenta sin pasar por ningún registro. Ese fenómeno, conocido como shadow AI, significa que el riesgo existe aunque nadie lo esté gestionando. Un programa que no empieza por inventariar lo que se usa parte de una ficción. Por último, el marco normativo se multiplica más allá de Europa. Iniciativas como la ley de IA de Colorado extienden las obligaciones de evaluación y documentación a otras jurisdicciones. Para las empresas reguladas, disponer de un único programa capaz de responder ante varios marcos a la vez deja de ser una ventaja y se convierte en una condición para operar. En España, la AEPD y la AESIA refuerzan esa expectativa de rendición de cuentas.
Las principales categorías de riesgo de IA
Ordenar los riesgos por familias evita el error habitual de tratar cada incidente como un caso aislado. Cuatro categorías cubren la mayor parte de lo que un programa debe vigilar, y cada una exige controles distintos.
Riesgos de datos
Los datos son el origen de buena parte de los problemas. La mala calidad (etiquetas erróneas, valores ausentes, muestras poco representativas) se traslada directamente al comportamiento del modelo. La procedencia también cuenta: si no se sabe de dónde vienen los datos ni con qué base legal se recogieron, cualquier despliegue arrastra un riesgo de privacidad y de cumplimiento. A ello se suma el envenenamiento de datos, en el que un actor introduce ejemplos manipulados durante el entrenamiento para inducir un comportamiento. Antes de tratar datos personales con un sistema de IA conviene documentar el análisis mediante una evaluación de impacto sobre la protección de datos, que fija qué se procesa, con qué finalidad y con qué salvaguardas.
Riesgos de modelo
El propio modelo introduce riesgos que no dependen de un atacante. El sesgo algorítmico produce resultados sistemáticamente desfavorables para determinados grupos, muchas veces heredado de datos históricos. La deriva, o degradación del rendimiento cuando la realidad se aparta de la distribución de entrenamiento, erosiona la fiabilidad de forma silenciosa. En los modelos generativos aparece además la alucinación, es decir, la producción de afirmaciones plausibles pero falsas; se trata de uno de los riesgos más señalados de la IA generativa. Medir estos comportamientos exige pruebas repetibles, y aquí los benchmarks de modelos de lenguaje aportan una referencia comparable entre versiones.
Riesgos operativos y de seguridad
Cuando el sistema pasa a producción surgen amenazas de explotación deliberada. Los ataques adversarios manipulan las entradas para forzar respuestas incorrectas; la inyección de instrucciones subvierte el comportamiento de un modelo de lenguaje; el uso indebido convierte una herramienta legítima en un vector de daño. El catálogo MITRE ATLAS documenta estas técnicas contra sistemas de aprendizaje automático y sirve de referencia para diseñar defensas. A ello se suman los riesgos clásicos de disponibilidad e integridad de la infraestructura que sostiene el modelo.
Riesgos éticos, jurídicos y para los derechos fundamentales
La última familia toca el terreno donde la regulación es más exigente. Una decisión automatizada puede discriminar, vulnerar la privacidad o afectar al acceso a servicios esenciales sin que la persona afectada comprenda por qué. La falta de transparencia agrava el problema: si nadie puede explicar cómo se llegó a un resultado, no hay forma de impugnarlo ni de corregirlo. Por eso la explicabilidad de la IA y la supervisión humana efectiva dejan de ser aspiraciones y se convierten en controles verificables.
El ciclo de vida de la gestión de riesgos de IA
Un programa serio no es una lista de amenazas, sino un ciclo que se recorre una y otra vez, y cada una de sus cuatro fases produce un artefacto que la siguiente reutiliza.
Identificar y mapear
Todo empieza por saber qué se tiene. El primer paso es construir un inventario de IA: qué sistemas existen, para qué sirven, qué datos consumen, quién los opera y a qué personas afectan. Para cada uno se documenta el propósito previsto y el contexto de uso, que determinan el nivel de riesgo. Esta fase se corresponde con la función Map de NIST AI RMF y con la identificación de riesgos de ISO/IEC 23894. Sin un mapa completo, las fases siguientes trabajan sobre una imagen parcial y el shadow AI queda fuera del radar.
Evaluar y medir
Con el mapa en la mano, cada riesgo se estima en probabilidad e impacto, considerando la gravedad para la salud, la seguridad y los derechos de las personas afectadas. La evaluación no puede ser un juicio de despacho: exige pruebas concretas, métricas de rendimiento por subgrupos, ensayos de robustez frente a entradas adversas y comprobación de la calidad de los datos. El artículo 9 de la EU AI Act es explícito al señalar que las pruebas sirven para identificar las medidas de gestión más adecuadas. Esta fase equivale a la función Measure de NIST AI RMF y al análisis y evaluación de ISO/IEC 23894.
Mitigar y gestionar
Aquí el riesgo se traduce en controles. Para cada riesgo relevante se asigna un control (técnico, organizativo o procedimental), un propietario responsable y una evidencia que demuestre su aplicación. No todo riesgo se elimina: el objetivo es reducirlo hasta un nivel de riesgo residual que la organización pueda aceptar de forma justificada. Ese punto exige una decisión formal, una firma de aceptación por parte de quien tiene autoridad para asumirla. Documentar quién aceptó qué, con qué fundamento y en qué fecha es lo que distingue un programa auditable de una buena intención. Esta fase corresponde a la función Manage de NIST AI RMF y al tratamiento del riesgo de ISO/IEC 23894, apoyado en los controles del Anexo A de ISO/IEC 42001.
Supervisar y revisar
El riesgo aceptado hoy puede dejar de serlo mañana. La supervisión continua vigila la deriva del modelo, la aparición de nuevos casos de uso y los cambios en el entorno regulatorio. Cuando algo falla, un proceso de respuesta a incidentes debe activarse, y en el marco europeo la notificación de incidentes graves conforme al artículo 73 impone plazos y obligaciones concretas. Mantener esta vigilancia de forma estructurada es lo que la supervisión del cumplimiento de los sistemas de IA permite sostener en el tiempo. Todo ello deja un rastro que sustenta la auditabilidad del sistema, es decir, la capacidad de reconstruir qué se decidió y por qué.
Marcos y normas
Los tres marcos de referencia describen la misma disciplina con vocabularios distintos. La utilidad práctica no está en elegir uno y descartar los demás, sino en reconocer que apuntan a los mismos pasos y alimentarlos con un único conjunto de controles y evidencias. Un mapeo entre NIST AI RMF, ISO/IEC 42001 y la EU AI Act evita duplicar el trabajo cada vez que aparece una nueva obligación.
NIST AI RMF
El NIST AI RMF 1.0, publicado en 2023, organiza la gestión de riesgos en cuatro funciones básicas: Govern, Map, Measure y Manage, aplicadas de forma iterativa a lo largo del ciclo de vida. Puede consultar el documento fundacional en NIST AI 100-1 y el desglose de las funciones en el recurso oficial de NIST. Govern es transversal: define la cultura, las estructuras y las responsabilidades que sostienen a las demás. En la práctica, los equipos empiezan por Map (contexto e impactos), continúan con Measure (evaluar) y cierran con Manage (tratar y asignar recursos). Es un marco voluntario, y nuestra guía del NIST AI RMF para operadores lo traduce en pasos aplicables.
ISO/IEC 42001 e ISO/IEC 23894
Estas dos normas se complementan. ISO/IEC 42001 es un sistema de gestión de la IA certificable (un AIMS): define el «qué» y el «dónde», los requisitos que una organización debe cumplir para gestionar la IA de forma responsable. ISO/IEC 23894 aporta el «cómo»: la guía del proceso de gestión de riesgos (identificación, análisis, evaluación y tratamiento a lo largo del ciclo de vida). ISO/IEC 42001 importa ISO/IEC 23894 como método de referencia para sus cláusulas de riesgo, de modo que ambas encajan sin fricción. La explicación de ISO/IEC 42001 detalla qué implica la certificación y puede ampliarse en la ficha oficial de ISO.
EU AI Act, artículo 9
A diferencia de los dos anteriores, la EU AI Act es obligatoria. El artículo 9 impone a los proveedores de sistemas de alto riesgo un sistema de gestión de riesgos documentado y mantenido como proceso continuo, con identificación de riesgos para la salud, la seguridad y los derechos fundamentales, evaluación, adopción de medidas específicas y aceptación de un riesgo residual justificado. Se puede combinar con los procesos de riesgo exigidos por otras normas de la Unión, lo que refuerza el argumento de un programa único. Las obligaciones se extienden también a la IA de propósito general, con requisitos propios.
| Etapa del programa | NIST AI RMF | ISO/IEC 42001 + 23894 | EU AI Act Article 9 |
|---|---|---|---|
| Gobernanza y responsabilidad | Govern | Cláusulas de liderazgo y planificación | Sistema de riesgo documentado y mantenido |
| Identificar y contextualizar | Map | Identificación de riesgos (23894) | Identificar riesgos para salud, seguridad y derechos |
| Evaluar y medir | Measure | Análisis y evaluación (23894) | Estimar y evaluar los riesgos, pruebas |
| Tratar y aceptar | Manage | Tratamiento (23894); controles del Anexo A | Adoptar medidas; riesgo residual aceptable |
| Supervisar y revisar | Govern y Manage | Cláusulas de evaluación y mejora | Proceso continuo, revisión sistemática |
Construir un programa de gestión de riesgos de IA: roles, artefactos y controles
Un marco sobre el papel no reduce ningún riesgo. Lo que lo reduce es un programa con responsables nombrados, artefactos vivos y controles que alguien mantiene. El punto de partida es un marco de gobernanza de la IA que fije quién decide y quién responde antes de entrar en el detalle técnico. Los roles son la primera pieza. Cada sistema necesita un propietario de negocio que responda de su uso, un propietario técnico que responda de su comportamiento y una función de riesgo o cumplimiento que valide de forma independiente. Un comité de gobernanza resuelve los casos límite y aprueba las aceptaciones de riesgo que superan un umbral. Sin nombres concretos, la responsabilidad se diluye y las decisiones se posponen hasta que ocurre el incidente. Los artefactos son la memoria del programa. Cuatro resultan imprescindibles. El inventario de IA recoge todos los sistemas en uso, incluidos los que llegaron por vías informales. El registro de riesgos asocia a cada sistema sus riesgos, su valoración, su propietario y su estado. El mapa de controles conecta cada riesgo con el control que lo mitiga y con la cláusula del marco que lo exige, de modo que una sola evidencia responda a varias obligaciones. El repositorio de evidencias guarda las pruebas (ensayos, aprobaciones, registros) que un auditor o un organismo notificado podrá inspeccionar. A ellos se suma la firma de aceptación del riesgo residual, que cierra el circuito de cada sistema. Los controles son la parte que actúa. Conviene distinguir entre controles fundacionales, que aplican a toda la organización con independencia del sistema (una política de uso de la IA, un procedimiento de aprobación, un plan de formación), y controles específicos de cada sistema (pruebas de sesgo, límites de uso, mecanismos de supervisión humana). Mapear ambos contra los requisitos convierte el cumplimiento en una consecuencia del trabajo y no en un esfuerzo separado, en línea con el cumplimiento de la gestión de riesgos entendido como proceso repetible.
Errores comunes en la gestión de riesgos de IA
El primer error es tratar la gestión de riesgos como un ejercicio único. Una evaluación al lanzar un sistema, guardada en un documento que nadie vuelve a abrir, contradice la exigencia de proceso continuo y deja el riesgo sin vigilancia justo cuando el modelo empieza a derivar. El segundo es gestionar solo lo que se conoce. Si el inventario ignora las herramientas adoptadas por los equipos sin autorización, el programa protege una fracción de la exposición real. Ignorar el shadow AI no lo elimina; solo lo oculta. El tercero es confundir tener una política con tener controles. Un documento de principios sin propietarios, evidencias ni verificación no mitiga nada; produce la ilusión de control sin su sustancia. El cuarto es mantener marcos en paralelo. Llevar NIST AI RMF, ISO/IEC 42001 y la EU AI Act en hojas de cálculo separadas multiplica el trabajo y genera contradicciones. El error opuesto, igual de frecuente, es no revisar nunca el riesgo residual aceptado: lo que fue aceptable con un modelo y un contexto deja de serlo cuando cualquiera de los dos cambia.
Cómo AI Sigil operacionaliza la gestión de riesgos de IA
AI Sigil está pensado para las industrias reguladas que necesitan sostener un único programa de riesgo frente a varios marcos a la vez. La plataforma reúne el inventario de IA, el registro de riesgos, el mapa de controles, las evidencias y la firma de aceptación del riesgo residual en un mismo lugar, de modo que una evidencia responda a la vez a NIST AI RMF, a ISO/IEC 42001 y al artículo 9 de la EU AI Act. Si duda entre montar su propio conjunto de herramientas o adoptar una solución integrada, esta comparación entre plataforma de gobernanza y pila de herramientas expone las diferencias. El objetivo es sencillo: que el trabajo diario deje, sin esfuerzo añadido, el rastro que un auditor o un organismo notificado espera encontrar.
Preguntas frecuentes
¿Cuáles son los cuatro tipos de riesgo de IA? Los riesgos de IA suelen agruparse en cuatro familias. Los riesgos de datos abarcan la calidad, la procedencia, la privacidad y el envenenamiento de los datos de entrenamiento. Los riesgos de modelo incluyen el sesgo, la deriva, la alucinación y la falta de robustez. Los riesgos operativos y de seguridad cubren los ataques adversarios, el uso indebido y la disponibilidad del sistema. Por último, los riesgos éticos, jurídicos y para los derechos fundamentales tratan la discriminación, la falta de transparencia y la ausencia de supervisión humana efectiva. Cada familia exige controles distintos y ninguna se gestiona sola.
¿Cómo se utiliza la IA en la gestión de riesgos? Conviene separar dos sentidos. Gestionar el riesgo de la IA significa aplicar el ciclo de identificar, evaluar, mitigar y supervisar a los propios sistemas de inteligencia artificial. Usar la IA para gestionar riesgos significa emplear modelos como herramienta dentro de un proceso más amplio, por ejemplo para detectar fraude, clasificar alertas o priorizar controles. Ambos usos son legítimos, pero no deben confundirse: cuando una organización usa IA como herramienta de riesgo, esa herramienta se convierte a su vez en un sistema que también hay que gobernar y someter al ciclo.
¿Existe una «regla del 30 %» en la gestión de riesgos de IA? No. La supuesta «regla del 30 %» circula por internet en contextos muy diversos (productividad, automatización, límites de uso), pero no es un principio reconocido en ningún marco de gestión de riesgos de IA. Ni NIST AI RMF, ni ISO/IEC 42001, ni el artículo 9 de la EU AI Act mencionan umbral porcentual alguno. La gestión de riesgos no consiste en alcanzar una cifra fija, sino en reducir cada riesgo hasta un nivel residual justificable según su probabilidad, su impacto y su contexto de uso. Conviene tratar con escepticismo cualquier cifra redonda presentada como norma universal.
¿En qué se diferencia del riesgo de ciberseguridad? La ciberseguridad protege los sistemas frente a atacantes, velando por la confidencialidad, la integridad y la disponibilidad. La gestión de riesgos de IA incluye la seguridad, pero va más allá: se ocupa de fallos que surgen sin ningún adversario, como el sesgo heredado de los datos, la deriva del modelo o las alucinaciones. Además, el comportamiento de un sistema de IA es probabilístico y cambia con los datos, mientras que un fallo de seguridad clásico suele tener causa determinista. Por eso un programa de IA añade controles de calidad de datos, pruebas de equidad y supervisión humana que la ciberseguridad, por sí sola, no contempla.
¿Qué marco conviene utilizar? Depende del objetivo, pero no son excluyentes. Para una estructura práctica y voluntaria, NIST AI RMF ofrece un lenguaje claro. Para una certificación reconocible, ISO/IEC 42001 (apoyada en ISO/IEC 23894 para el método de riesgo) es el camino. Si opera sistemas de alto riesgo en la Unión Europea, el artículo 9 de la EU AI Act es obligatorio. Lo recomendable es adoptar los tres como una sola disciplina, alimentando un mismo conjunto de controles y evidencias, de modo que satisfacer una obligación contribuya a las demás en lugar de duplicar el esfuerzo.
¿Quién es responsable de la gestión de riesgos de IA? La responsabilidad es compartida, pero debe estar nombrada. Cada sistema necesita un propietario de negocio que responda de su uso y un propietario técnico que responda de su comportamiento, con una función independiente de riesgo o cumplimiento que valide el proceso y un comité de gobernanza que resuelva los casos límite y apruebe las aceptaciones de riesgo relevantes. En términos regulatorios, la EU AI Act atribuye obligaciones concretas al proveedor y al responsable del despliegue. La rendición de cuentas se sostiene sobre nombres y firmas, no sobre departamentos genéricos.
Conclusión
La gestión de riesgos de IA rinde cuando se trata como un único programa operativo y no como una colección de marcos que compiten por atención. Un mismo ciclo puede absorber NIST AI RMF, ISO/IEC 42001 con ISO/IEC 23894 y el artículo 9 de la EU AI Act en un solo conjunto de controles, propietarios y evidencias, siempre que exista un responsable claro y cada decisión deje rastro. Lo que convierte la buena intención en un programa auditable son los artefactos duraderos: inventario de IA, registro de riesgos, mapa de controles, evidencias y firma de aceptación del riesgo residual. Con esa base, una organización deja de reaccionar ante cada incidente y demuestra, ante un auditor o un regulador, que sabe qué IA utiliza, qué riesgo asume y por qué. El punto de partida es una gobernanza de la IA que ordene el conjunto desde el principio.