¿Qué es un registro de riesgos de IA?
Gobernanza, riesgo y aseguramiento
Un registro de riesgos de IA es un documento vivo que recoge los riesgos materiales de IA de una organización, los controles utilizados para abordarlos, quién es responsable de cada riesgo, qué evidencia respalda la valoración y cuándo debe revisarse el riesgo. Ayuda a los equipos a gestionar el riesgo de IA a lo largo del tiempo, en lugar de tratar la gobernanza como un ejercicio puntual. En la práctica, conecta la evaluación, la aprobación, el seguimiento, la gestión de incidentes, la auditoría y la documentación regulatoria.
Revisado por Jackie, Head of Learning & Development, Levellers - Última revisión: 8 de junio de 2026
Qué significa esto
Un registro de riesgos de IA no es lo mismo que un riesgo de IA, un inventario de IA ni un marco completo de gobernanza de la IA. Es el registro continuo que muestra qué riesgos se han identificado para un sistema o caso de uso de IA concreto, cuál es su gravedad, qué controles están en vigor, qué queda pendiente y quién debe actuar.
Un buen registro se actualiza a lo largo del ciclo de vida de la IA. Normalmente comienza cuando se propone o adquiere un caso de uso, incorpora los hallazgos de las evaluaciones de impacto, las pruebas y la diligencia debida con proveedores, y permanece activo tras el despliegue a medida que los registros, los incidentes, las auditorías, los comentarios de los usuarios y los cambios en el sistema revelan nuevos problemas.
Pocas leyes exigen un documento con el título exacto de "registro de riesgos de IA". Aun así, múltiples leyes, normas y guías de reguladores requieren una gestión de riesgos documentada, revisión, trazabilidad y responsabilidad a nivel directivo. Por eso el registro de riesgos de IA se ha convertido en un artefacto de gobernanza práctico en distintos sectores y jurisdicciones.
Por qué es importante
La gobernanza de la IA suele fallar en los espacios entre equipos y a lo largo del tiempo. Un equipo de privacidad puede señalar una preocupación, un equipo de producto puede añadir un control, el área de compras puede confiar en las promesas del proveedor y un grupo de aprobación puede dar luz verde al lanzamiento, pero sin un registro compartido esas acciones no permanecen conectadas. El registro crea continuidad. Muestra qué se identificó, qué se hizo, qué sigue pendiente y quién es responsable si el riesgo sigue siendo demasiado elevado.
Esto importa en el ámbito regulatorio porque muchas obligaciones en materia de IA no son verificaciones puntuales. Son obligaciones continuas de documentar, supervisar, actualizar, registrar, reevaluar y escalar. Un registro ayuda a una organización a convertir los principios generales de gobernanza en evidencia que puede ser revisada por la dirección, compradores, auditores, reguladores y, cuando proceda, autoridades públicas. También ayuda a los responsables a decidir si un uso de IA debe continuar, continuar con condiciones, pausarse o retirarse.
Cómo funciona
Registra el riesgo en contexto
Un registro de riesgos de IA útil no se limita a enumerar etiquetas genéricas como "sesgo", "privacidad" o "seguridad". Cada entrada debe estar vinculada a un sistema o caso de uso de IA concreto, su finalidad prevista, las personas o procesos afectados y el escenario que genera la preocupación. El contexto importa porque el mismo componente técnico puede generar problemas de gobernanza muy distintos según se utilice para redacción interna, clasificación de clientes, detección de fraude, selección de personal, apoyo médico o prestación de servicios públicos.
En el caso de IA adquirida o integrada, el contexto también debe incluir la relación con el proveedor, la versión o modelo utilizado, las dependencias de datos relevantes y los supuestos incorporados en los contratos o la documentación. Esto es especialmente importante cuando el desplegador no ha construido el modelo, pero sigue siendo responsable de utilizarlo de forma controlada.
Vincula las valoraciones de riesgo a los controles y la evidencia
Una vez identificado un riesgo, el registro debe mostrar cómo se evalúa y qué se está haciendo al respecto. La mayoría de las organizaciones utilizan algún tipo de escala de gravedad y probabilidad, que a menudo se traduce en bandas de prioridad o niveles de tolerancia. El método de puntuación exacto importa menos que la coherencia y la posibilidad de revisión.
Cada entrada también debe apuntar al conjunto de controles asociados a ese riesgo. Según el sistema, los controles pueden incluir pruebas, restricciones de acceso, revisión humana, reglas de supervisión, cláusulas de contratación, verificaciones de calidad de datos, registros, escalado de incidentes, condiciones de reentrenamiento o activadores de desmantelamiento. El registro es más sólido cuando vincula estos controles a evidencia, como una EIPD, una evaluación de impacto de IA, informes de pruebas, documentos de proveedores, aprobaciones internas, registros de incidentes o logs. También debe mostrar el riesgo residual, es decir, el nivel que permanece tras aplicar esos controles.
Asigna responsabilidad y derechos de decisión
Un registro solo funciona si cada riesgo material tiene un responsable designado con autoridad para actuar. Eso suele significar un responsable de negocio, producto u operaciones para el riesgo en sí, más responsables de control para las mitigaciones asociadas. La autoridad de revisión suele recaer en las funciones de privacidad, seguridad, legal, riesgo de modelos, compras o gobernanza de la IA, según el problema.
Esto importa porque la gobernanza de la IA suele fallar cuando el equipo que detecta el riesgo no es el que puede modificar el sistema o detener el despliegue. El registro debe mostrar, por tanto, quién puede remediar, quién puede aceptar el riesgo residual dentro de la tolerancia, quién debe escalar cuando se supera esa tolerancia y quién aprueba los lanzamientos o los cambios importantes. La aprobación a nivel directivo es especialmente importante cuando los riesgos no pueden eliminarse por completo y requieren una decisión informada de la dirección.
Se sitúa entre el inventario, los controles y la aprobación
Un inventario de casos de uso de IA, un flujo de aprobación, una biblioteca de controles y un sistema de gestión de IA cumplen funciones distintas. El inventario indica qué IA existe y dónde se utiliza. La biblioteca de controles enumera las salvaguardas estándar que la organización puede aplicar. El flujo de aprobación registra si un uso o cambio puede continuar. El sistema de gestión de IA es el conjunto más amplio de políticas, responsabilidades, ciclos de revisión y procesos de mejora continua.
El registro de riesgos conecta estos artefactos. Muestra qué controles están realmente asociados a qué riesgo, si las condiciones de aprobación siguen abiertas, si un uso concreto sigue dentro del apetito de riesgo de la organización y si nueva evidencia ha cambiado el panorama. En ese sentido, es el puente operativo entre la política y la práctica.
Permanece activo a lo largo del ciclo de vida de la IA
Un registro de riesgos de IA debe iniciarse pronto y sobrevivir al despliegue. Los momentos clave que deben activarlo incluyen la incorporación, la adquisición, las pruebas previas al despliegue, la aprobación del lanzamiento, el reentrenamiento importante, el ajuste fino, nuevas fuentes de datos, nuevos grupos de usuarios, actualizaciones de proveedores, incidentes, hallazgos de auditoría, reclamaciones y la retirada del sistema. Los riesgos cerrados deben marcarse con fecha y motivo, no eliminarse silenciosamente.
Este punto del ciclo de vida es central en la gobernanza moderna de la IA. El EU AI Act trata la gestión de riesgos para la IA de alto riesgo como un proceso documentado, continuo e iterativo vinculado a la documentación técnica, los registros y el seguimiento poscomercialización. En la práctica de protección de datos del Reino Unido, la ICO espera que los riesgos identificados para los sistemas de IA que utilizan datos personales estén documentados, aprobados y rastreados a través de un registro de riesgos corporativo adecuado. En el contexto federal de EE. UU., la OMB exige inventarios, evaluaciones de impacto de IA y revisión continua para la IA que afecta a derechos y a la seguridad. Un registro activo es una forma práctica de mantener conectadas estas piezas en movimiento.
Ayuda a traducir la ley y las normas en gobernanza cotidiana
El registro es útil en parte porque los documentos legales y normativos suelen describir las obligaciones en piezas separadas. Un instrumento puede exigir una gestión de riesgos documentada. Otro puede requerir documentación técnica, registros, seguimiento poscomercialización, pruebas, supervisión humana o responsabilidad directiva. Las normas pueden hacer hincapié en la gobernanza, la claridad de roles, los ciclos de revisión, la tolerancia al riesgo y la mejora continua. Un registro ofrece a los equipos un único lugar donde reunir esos hilos para un sistema o caso de uso concreto.
Por eso el mecanismo funciona bien en distintas jurisdicciones. El AI RMF de NIST es voluntario, pero fomenta la gestión de riesgos documentada, la definición de roles, los inventarios, la tolerancia al riesgo, el seguimiento y la revisión. ISO/IEC 42001 es también una norma voluntaria de sistemas de gestión, pero orienta a las organizaciones hacia una forma estructurada y continuamente mejorada de gobernar los riesgos relacionados con la IA. Incluso cuando un regulador no prescribe un registro por su nombre, la lógica de gobernanza subyacente lo respalda con fuerza.
Crea evidencia para el aseguramiento y la auditoría
Un registro de riesgos de IA bien gestionado no es solo una herramienta de gestión. Es también un artefacto de aseguramiento. Permite que un equipo de auditoría interna, un regulador, un comité del consejo, un organismo público o un cliente importante comprueben si la organización conocía un riesgo concreto, lo vinculó a controles, asignó responsabilidad, revisó nueva evidencia y reconsideró la decisión tras un cambio.
Esto no significa que el registro sustituya a la prueba subyacente. Los informes de pruebas, las evaluaciones de impacto, los logs, los contratos, los análisis de incidentes y los documentos técnicos siguen siendo los que hacen el trabajo pesado. Pero el registro actúa como el índice que muestra dónde se encuentra la prueba y cómo la organización convirtió esa prueba en una decisión gestionada.
Ejemplos
Ejemplo actual, despliegue interno en el Gobierno del Reino Unido: el "Hidden AI Risks Toolkit" de la Cabinet Office describe cómo el equipo detrás de la herramienta de IA generativa Assist identificó más de 100 riesgos hipotéticos durante el despliegue y, a continuación, utilizó una plantilla de registro de riesgos publicada para catalogarlos, clasificarlos y reducirlos a 33 riesgos prioritarios en seis categorías. Es una ilustración clara de un registro utilizado como herramienta de gobernanza operativa para la priorización y la revisión continua, no como un apéndice final elaborado al término del proceso.
Ejemplo regulatorio actual, IA de alto riesgo en la UE: el EU AI Act exige a los proveedores de sistemas de IA de alto riesgo que gestionen un sistema de gestión de riesgos documentado a lo largo de todo el ciclo de vida, mantengan actualizada la documentación técnica, habiliten el registro de logs, mantengan documentación de gestión de calidad y establezcan un seguimiento poscomercialización documentado. En la práctica, un registro de riesgos de IA es una forma razonable de mantener coherentes esas obligaciones vinculadas para un sistema concreto, especialmente cuando las modificaciones, los comentarios de los desplegadores o los incidentes cambian el panorama de riesgos.
Ejemplo regulatorio actual, uso por agencias federales de EE. UU.: la OMB M-24-10 exige a las agencias que hagan un inventario de los casos de uso de IA y, para la IA que afecta a derechos o a la seguridad, que completen una evaluación de impacto de IA, la actualicen a lo largo del ciclo de vida y dejen de utilizar la IA si no se cumplen las prácticas mínimas de gestión de riesgos. Para un equipo de gobernanza de una agencia, el registro es el documento operativo que puede conectar la entrada del inventario, la evaluación de impacto, el responsable designado, las mitigaciones previstas, el ciclo de revisión y cualquier decisión de cese de uso.
Malentendidos frecuentes
Un error habitual es confundir el registro con un inventario de IA. No son lo mismo. El inventario indica qué IA existe y dónde se utiliza. El registro indica qué podría salir mal en ese uso, qué controles están en vigor y si la dirección sigue dispuesta a continuar.
Otro error es pensar que una EIPD o una evaluación de impacto de IA cumple la misma función. Esas evaluaciones son análisis en profundidad en un momento determinado. El registro es el documento vivo que traslada los problemas identificados al seguimiento, las aprobaciones, los cambios de versión y la auditoría.
También es incorrecto asumir que solo los constructores de modelos necesitan uno. Los compradores, los desplegadores y las organizaciones que dependen de IA de terceros siguen teniendo obligaciones de gobernanza, privacidad, seguridad, operativas y sectoriales. Si se utiliza el sistema, se depende de su resultado o se integra en un proceso, sigue siendo necesario un método controlado para registrar y revisar el riesgo.
Algunos equipos creen que el aseguramiento del proveedor significa que el riesgo puede quedar fuera del registro. Es un planteamiento arriesgado. La documentación del proveedor es evidencia, no un sustituto del propio registro del uso previsto, los controles locales, los activadores de revisión y la decisión de aceptación.
Un último malentendido es que el registro queda terminado una vez aprobado el sistema. Los sistemas de IA cambian, su contexto cambia y la evidencia que los rodea cambia. Un registro estático suele ser señal de una gobernanza estática.
Riesgos y límites
Un registro de riesgos de IA tiene límites claros. No prueba que un control funcione. Una entrada con estado verde tiene poco valor si el registro de pruebas subyacente, la evidencia de auditoría o el aseguramiento del proveedor son deficientes. Tampoco debe convertirse en un depósito de todos los temores imaginables. Si las entradas son demasiado genéricas, no tienen responsable o están desconectadas de decisiones reales, el registro pierde valor rápidamente.
Tampoco sustituye a los artefactos más amplios que exige la gobernanza. Puede que sigan siendo necesarios documentación técnica, logs, registros de incidentes, evaluaciones de impacto, diligencia debida con proveedores, registros de protección de datos, condiciones contractuales, aprobaciones sectoriales específicas y evidencia de auditoría interna. El registro debe apuntar a esos documentos, no reemplazarlos.
El estatus legal también varía. El AI RMF de NIST y la ISO/IEC 42001 son normas voluntarias, no leyes. La guía de la ICO explica cómo se aplica la ley de protección de datos del Reino Unido cuando los sistemas de IA tratan datos personales. La OMB M-24-10 vincula a las agencias federales de EE. UU., no a las empresas privadas. El EU AI Act crea obligaciones vinculantes de gestión de riesgos documentada para determinados sistemas, pero no impone una obligación global universal para que todas las organizaciones mantengan un documento con la etiqueta exacta de "registro de riesgos de IA". La lección práctica es sencilla: la etiqueta puede variar, pero la necesidad de un registro de riesgos de IA estructurado y revisable es hoy difícil de evitar.
Qué hacer a continuación
Identificar los sistemas, usos y cambios de IA que deben activar una entrada en el registro, y conectar esa regla con la incorporación, la adquisición y la gestión del cambio.
Utilizar un esquema claro y único para las entradas: sistema o caso de uso, descripción del riesgo, personas o procesos afectados, valoración, controles, responsable, evidencia, riesgo residual, estado y fecha de próxima revisión.
Otorgar a un órgano directivo designado la autoridad para aceptar, escalar, pausar o retirar usos de IA que superen la tolerancia, en lugar de dejar las decisiones difíciles únicamente en manos de los equipos técnicos.
Exigir que cada entrada material esté vinculada a artefactos de respaldo, especialmente evaluaciones de impacto, EIPDs, registros de pruebas, documentos de proveedores, logs, informes de incidentes y decisiones de aprobación.
Revisar el registro cuando los sistemas sean reentrenados, ajustados, reutilizados, expuestos a nuevos datos, conectados a nuevos proveedores o utilizados en nuevos contextos, no solo según un calendario anual.
Mantenerlo proporcionado. Una herramienta de redacción interna de bajo riesgo no necesita el mismo nivel de detalle que la IA utilizada en empleo, crédito, sanidad, aplicación de la ley o prestación de servicios públicos.
¿Tiene alguna pregunta o sugerencia, o desea saber cómo investigamos y revisamos estas guías? Lea sobre nuestros estándares editoriales y cómo contactarnos.
Preguntas frecuentes
¿Es el registro de riesgos de IA un requisito legal?
Por lo general, no con ese nombre exacto. Pocos regímenes prescriben la etiqueta en sí, pero muchos exigen la disciplina subyacente, como la gestión de riesgos documentada, la evaluación de impacto, la responsabilidad a nivel directivo, los registros de logs, el seguimiento o la documentación técnica.
¿Qué debe contener cada entrada del registro de riesgos de IA?
Como mínimo, un sistema o caso de uso concreto, una descripción clara del riesgo en contexto, un método de valoración, los controles asociados, un responsable designado, evidencia de respaldo, el riesgo residual, el estado actual y una fecha de revisión.
¿Quién debe ser responsable del registro?
La administración diaria puede recaer en una función de gobernanza, riesgo o cumplimiento, pero cada riesgo material sigue necesitando un responsable operativo o de negocio con autoridad para actuar. La revisión a nivel directivo debe corresponder al órgano con capacidad para aprobar, condicionar, pausar o detener el uso.
¿Es lo mismo que una EIPD o una evaluación de impacto de IA?
No. Una EIPD o una evaluación de impacto de IA es un análisis estructurado en un momento determinado. El registro es el documento continuo que hace seguimiento de los riesgos identificados una vez completada la evaluación.
¿Necesitamos uno para herramientas de IA de terceros?
Sí. La IA de proveedores puede generar riesgos locales aunque no se haya construido el modelo. El registro debe recoger el uso previsto, los supuestos del proveedor, los controles contractuales, los activadores de revisión y la evidencia en la que se basó la decisión.
¿Con qué frecuencia debe revisarse un registro de riesgos de IA?
En la incorporación, antes del despliegue, tras cambios significativos, tras incidentes o reclamaciones, tras actualizaciones importantes de proveedores y en un ciclo periódico regular. La cadencia adecuada depende de los riesgos en juego y de la rapidez con que cambia el sistema.
¿Puede un equipo pequeño empezar con una hoja de cálculo?
Sí. Una hoja de cálculo puede ser suficiente al principio si los campos son claros, la responsabilidad es real, la evidencia está vinculada y se mantiene la disciplina de revisión. A medida que crece el número de sistemas, reguladores y revisores, muchos equipos migran a una plataforma de gobernanza o gestión de riesgos más estructurada.