Lo esencial
- La gestión de riesgos de cumplimiento es la práctica de conducir la gestión de riesgos corporativa de manera que la reconozca toda autoridad supervisora, transformando los resultados en evidencia auditable.
- En 2026 la disciplina se redibuja por tres movimientos: la IA como nuevo vector de riesgo de cumplimiento, la IA como capa operativa de herramientas y una ola regulatoria que coloca la gestión de riesgos en el centro de cada obligación sobre sistemas de IA de alto riesgo.
- El stack coherente de 2026 combina ISO 31000 como tronco del riesgo corporativo, ISO/IEC 42001 como rama del sistema de gestión de la IA, el NIST AI RMF como funciones operativas y el artículo 9 del Reglamento IA como obligación jurídica vinculante.
- Los papeles de proveedor y responsable del despliegue del Reglamento IA reparten la titularidad del riesgo de cumplimiento: la IA desarrollada en casa concentra todo en la organización, la IA de terceros desplaza parte hacia el riesgo de proveedor.
- La nueva generación de herramientas pasa del GRC en hoja de cálculo o flujo de trabajo a la supervisión continua aumentada por IA, que convierte el dato de riesgo en señal en tiempo real.
¿Qué es la gestión de riesgos de cumplimiento?
La gestión de riesgos de cumplimiento es la disciplina operativa que garantiza que cada actividad de tratamiento del riesgo dentro de la organización cumple la normativa, los estándares y las obligaciones contractuales aplicables. Se sitúa en el cruce de dos prácticas GRC que los buscadores suelen confundir. La gestión de riesgos en sentido estricto consiste en identificar, evaluar y tratar el riesgo frente al apetito definido. La gestión del cumplimiento consiste en satisfacer obligaciones externas. La gestión de riesgos de cumplimiento es el cruce: conducir la gestión de riesgos en sí misma de un modo que el supervisor acepte y producir la documentación que lo prueba. El National Institute of Standards and Technology define la función Govern de su AI Risk Management Framework como el cultivo de una cultura de gestión de riesgos en toda organización que diseña, desarrolla, despliega o utiliza sistemas de IA. La formulación pesa: la gobernanza ya no es un frente paralelo a las operaciones, es la precondición para que cualquier otra actividad de riesgo cuente como evidencia de cumplimiento. En 2026 tres fuerzas empujan la disciplina hacia el plano de control de la IA. Primero, cada texto que aterriza este año sobre la mesa de un Chief Risk Officer, del Reglamento IA a DORA pasando por NIS2, contiene una cláusula expresa de gestión de riesgos que exige un tratamiento continuo, documentado y durante todo el ciclo de vida. Segundo, el perímetro auditable se ensancha: donde hace dos años el registro de riesgos contenía ciber, fraude y ESG, hoy debe contener también riesgo de modelo, riesgo de IA de terceros y responsabilidad sobre decisiones automatizadas. Tercero, la capa de herramientas evoluciona: las plataformas GRC aumentadas por IA comprimen la distancia entre dato de riesgo y decisión de riesgo, del trimestre al tiempo real. La consecuencia práctica para los equipos que llevan este nombre es nítida. La gestión de riesgos de cumplimiento ya no es una atestación trimestral basada en muestreo. Es un régimen de control continuo que debe aguantar una inspección un martes cualquiera.
Gestión de riesgos de cumplimiento frente a gestión del riesgo de cumplimiento (y por qué importan ambas)
Los buscadores tratan las dos formulaciones como sinónimas. No lo son. Una disciplina que las confunde acaba sobrecontrolando un lado y exponiendo el otro. La gestión de riesgos de cumplimiento pregunta: ¿mis actividades de gestión de riesgos cumplen las normas que las enmarcan? El ejemplo clásico es un banco que opera un programa interno de validación de modelos. La validación misma es gestión de riesgos; si el programa satisface las expectativas del supervisor según SR 11-7 o la TRIM del BCE es gestión de riesgos de cumplimiento. La gestión del riesgo de cumplimiento plantea la pregunta inversa: ¿qué riesgo tengo de que mi organización incumpla la normativa que le aplica, y cómo lo piloto? Aquí el objeto de análisis es la postura de cumplimiento de la organización. La entrada en el registro de riesgos suena así: « incumplimiento de la entrega de informes de post-market monitoring para sistemas de IA de alto riesgo en plazos legales, probabilidad residual media, impacto potencial 35 millones de euros en sanciones más daño reputacional ». El Reglamento IA expone las dos dimensiones a la vez. El artículo 9 obliga a los proveedores de sistemas de IA de alto riesgo a operar un sistema de gestión de riesgos, que es en sí una actividad de gestión de riesgos (y por tanto debe ejecutarse de manera conforme: gestión de riesgos de cumplimiento). En paralelo el artículo crea una nueva obligación de cumplimiento; no respetarla es a su vez un riesgo de cumplimiento que la segunda línea debe registrar y tratar (gestión del riesgo de cumplimiento). Un modelo operativo bien diseñado trata los dos movimientos como distintos pero entrelazados, con taxonomía, registro y biblioteca de controles compartidos. La razón mecánica por la que importan ambas: un supervisor que encuentre uno de los dos lados roto tratará el otro como comprometido por inferencia.
El stack 2026: ISO 31000, ISO 42001, NIST AI RMF y artículo 9 del Reglamento IA
Bajo presión regulatoria el reflejo es montar un programa por sigla nueva. Ese reflejo produce silos: un equipo ISO 31000 para riesgo corporativo, un equipo ISO 42001 para IA, un grupo NIST RMF y un grupo de trabajo Reglamento IA que llevan cuatro registros paralelos. La cura es una arquitectura única en estrella en la que cada marco ocupa una posición definida. ISO 31000 es el tronco. El marco internacional de gestión del riesgo empresarial, publicado por primera vez en 2009, fija principios, marco y proceso para gestionar el riesgo a nivel corporativo. No es específico de IA. Aporta el vocabulario (riesgo, control, riesgo residual, apetito) y el ciclo (establecer contexto, identificar, analizar, evaluar, tratar, monitorizar, comunicar) que cada programa derivado hereda. ISO/IEC 42001 es la rama IA. Publicada en diciembre de 2023, es la primera norma auditable del mundo para un sistema de gestión de la IA. Se ensambla sobre el tronco ISO 31000 mediante la estructura común de los sistemas de gestión (la High-Level Structure del Anexo SL) y añade controles específicos para IA: calidad de datos, transparencia, supervisión humana, gestión del ciclo de vida. Una organización ya certificada ISO 27001 o ISO 9001 reconocerá la forma y podrá extender la gobernanza a la IA sin reconstruir su sistema de gestión. El NIST AI RMF es el protocolo operativo. Sus cuatro funciones núcleo (Govern, Map, Measure, Manage) describen lo que los equipos hacen a diario. Govern fija las precondiciones culturales y de política. Map recoge los casos de uso de IA y su contexto. Measure cuantifica el riesgo frente a las características de IA fiable (válida, fiable, segura, protegida, responsable, transparente, explicable, respetuosa con la privacidad, justa). Manage asigna recursos al tratamiento. El RMF se mapea con limpieza sobre los controles de ISO/IEC 42001, razón por la que se invocan juntos cada vez más. El artículo 9 del Reglamento IA es la obligación vinculante. El artículo 9, apartado 1 dice textualmente: « Se establecerá, aplicará, documentará y mantendrá un sistema de gestión de riesgos en relación con los sistemas de IA de alto riesgo ». El artículo 9, apartado 2 define el proceso iterativo continuo a lo largo del ciclo de vida del sistema de IA: identificar y analizar los riesgos conocidos y razonablemente previsibles, estimarlos bajo uso previsto y mal uso razonablemente previsible, evaluarlos con los datos de post-market monitoring y adoptar medidas selectivas. El artículo 9, apartado 10 invita expresamente a la integración: los proveedores ya sometidos a otros requisitos de gestión de riesgos de la Unión pueden fundir estas disposiciones en los procedimientos existentes. Esa cláusula es la autorización jurídica para mantener un stack y no cuatro. A partir de ahí el mapeo es directo. Una actividad de identificación del riesgo ISO 31000, ejecutada sobre un caso de uso de IA capturado por la función Map del NIST AI RMF, documentada según el control A.5.4 del Anexo A de ISO/IEC 42001, satisface el artículo 9, apartado 2, letra a. Una actividad, un registro, cuatro casillas marcadas.
Proceso en cuatro pasos para la gestión de riesgos de cumplimiento en la era de la IA
El ciclo del artículo 9 marca la columna vertebral: identificar, estimar, evaluar, gestionar. Cada paso debe conservar su sustancia tradicional y añadir la dimensión que hace defendible el registro en 2026. Paso 1: identificar. El movimiento tradicional recoge entradas de propietarios de procesos, hallazgos de auditoría, barridos de horizonte normativo y registros de incidentes en un registro de riesgos. La adición IA enumera cada caso de uso de IA en producción o desarrollo y le asigna una clasificación de riesgo (prohibido, alto riesgo, riesgo limitado, riesgo mínimo) según los artículos 5 y 6 del Reglamento IA. El resultado es un registro unificado donde los riesgos de IA conviven con las entradas de ciber, fraude y ESG, en lugar de en una hoja paralela. Paso 2: estimar. La estimación tradicional ejecuta un análisis de probabilidad e impacto, a menudo en una escala 1 a 5, calibrado con datos históricos de pérdida. La adición IA es doble: estimar bajo uso previsto Y bajo mal uso razonablemente previsible (formulación tomada textualmente del artículo 9, apartado 2, letra b) y añadir al eje de impacto las dimensiones de IA fiable (sesgo, alucinación, deriva, seguridad, explicabilidad). Un sistema de IA de apoyo a la decisión clínica no se puede estimar sólo por exposición a sanciones; el vector daño al paciente debe entrar también en la cuenta. Paso 3: evaluar. La evaluación tradicional compara el riesgo estimado con el apetito de la organización y ordena los tratamientos. La adición IA es la incorporación explícita de los datos de post-market monitoring, impuesta por el artículo 9, apartado 2, letra c. Una vez en producción, un sistema de IA no puede evaluarse únicamente con la estimación de diseño. Deriva real, frecuencia de incidentes, métricas de equidad obtenidas del tráfico en vivo y quejas de usuarios alimentan el bucle de evaluación. La función Measure del NIST AI RMF aporta una batería de métricas operativas lista para levantarse a este paso. Paso 4: gestionar. El tratamiento tradicional elige entre aceptar, evitar, transferir, mitigar. La adición IA es la eliminación por diseño: según el artículo 9, apartado 3, los riesgos deben tratarse mediante el desarrollo o el diseño del propio sistema de IA, no sólo mediante controles posteriores. Donde un riesgo de proveedor se habría mitigado históricamente con una cláusula de indemnización, un riesgo de sistema de IA debe examinarse primero para su eliminación a nivel de datos de entrenamiento, arquitectura del modelo o diseño del despliegue. Sólo el residuo se transfiere o acepta. Un registro que recorre estos cuatro pasos por cada caso de uso de IA, con trazabilidad a los registros de medición NIST AI RMF y a las atestaciones de control ISO/IEC 42001, sirve a la vez a la gestión de riesgos corporativa y a la obligación del artículo 9. Dos movimientos, un solo flujo.
Proveedor o responsable del despliegue: ¿quién posee qué riesgo de cumplimiento?
El Reglamento IA introduce una distinción que los equipos de cumplimiento entrenados en la lógica responsable-encargado del RGPD reconocerán, pero no deberían dar por idéntica. Un proveedor es la entidad que desarrolla un sistema de IA o lo manda desarrollar y lo introduce en el mercado bajo su nombre. Un responsable del despliegue es cualquier persona física o jurídica que utiliza un sistema de IA bajo su propia autoridad. La misma organización puede ser proveedora del sistema A y responsable del despliegue del sistema B en la misma semana. Las obligaciones del proveedor son densas. Los artículos 16 a 25 del Reglamento IA asignan al proveedor la documentación técnica, el sistema de gestión de la calidad, la gestión de riesgos (artículo 9), la gobernanza de datos, la transparencia, la supervisión humana, el post-market monitoring, el registro y la notificación de incidentes graves. El registro de riesgos de cumplimiento del lado proveedor debe llevar una línea por cada una de estas obligaciones, con titular del control, referencia de evidencia y puntuación de riesgo residual. Las obligaciones del responsable del despliegue están en el artículo 26. Incluyen el uso de los sistemas de alto riesgo conforme a las instrucciones del proveedor, la asignación de la supervisión humana a personal competente, la monitorización del funcionamiento y la información al proveedor sobre riesgos o incidentes graves, el mantenimiento de la calidad de los datos de entrada y la conservación de los registros generados automáticamente. El riesgo de cumplimiento del lado del despliegue es estructuralmente distinto: menos diseño, más disciplina operativa y gestión de proveedores. La implicación para la gestión de riesgos de cumplimiento es que el registro mismo debe llevar un atributo de rol en cada línea de IA. Un banco que opera un sistema de IA antifraude desarrollado en casa carga con las obligaciones de proveedor y debe registrar el sistema de gestión de riesgos del artículo 9 como actividad propia. El mismo banco que utiliza un modelo generativo de un tercero para el triaje de servicio al cliente carga con las obligaciones de responsable del despliegue y debe registrar en su lugar controles de vigilancia del proveedor, fidelidad a las instrucciones y notificación de incidentes. La biblioteca de controles que sostiene ambos lados es en parte común (gobernanza de datos, supervisión humana) y en parte divergente (el post-market monitoring es del proveedor, la due diligence de proveedor es del responsable del despliegue). Un programa que no trace esta línea sobrecontrolará el lado del despliegue o subcontrolará el lado del proveedor. El control práctico consiste en ejecutar, cada vez que un nuevo sistema de IA entra en el inventario, una breve clasificación interna: ¿quién lo ha desarrollado, bajo qué nombre se introduce en el mercado, quién controla el contexto operativo? La respuesta dicta qué controles del artículo 26 o de los artículos 16 a 25 se adhieren.
Más allá del Reglamento IA: convergencia con DORA, NIS2 y CSRD
El Reglamento IA no llega en el vacío. Otros tres textos han introducido en los últimos dos años sus propios requisitos de gestión de riesgos, y un programa que los trate como cuatro movimientos separados se pasará el tiempo copiando entradas entre hojas en lugar de tratar el riesgo. El Reglamento de Resiliencia Operativa Digital (DORA), en vigor desde enero de 2025 para entidades financieras, exige un marco completo de gestión del riesgo TIC que cubra identificación, protección, detección, respuesta, recuperación y aprendizaje. Su perímetro se solapa con el artículo 9 del Reglamento IA allí donde un sistema de IA es también un activo TIC: un modelo antifraude es las dos cosas. La Directiva sobre Seguridad de las Redes y la Información 2 (NIS2) impone medidas de gestión de riesgos a entidades esenciales e importantes de sectores críticos, con énfasis en ciberseguridad. Los sistemas de IA que sostienen servicios cubiertos por NIS2 heredan esas medidas. La Directiva sobre Informes de Sostenibilidad Corporativa (CSRD) obliga a las empresas a informar sobre riesgos y oportunidades materiales en sostenibilidad, incluida la gobernanza de impactos derivados de elecciones tecnológicas. Las decisiones impulsadas por IA que afectan a trabajadores, consumidores y socios de cadena de valor entran en el ámbito. El patrón de convergencia es el mismo en los cuatro casos: identificar, evaluar, tratar, monitorizar, informar. Una biblioteca de controles unificada, donde cada control apunta a todas las normas que satisface, convierte cuatro programas en un registro con cuatro vistas de salida. El Committee of Sponsoring Organizations of the Treadway Commission (COSO) actualizó su guía en 2024 para cubrir conjuntamente gobernanza de IA, riesgo en la nube, ciberriesgo y gestión del riesgo de cumplimiento, señal de la misma dirección a nivel de estándar. El coste de no converger es mecánico: un caso de uso de IA que dispara artículo 9, riesgo TIC DORA y obligación ciber NIS2 producirá tres entradas de registro, tres carpetas de evidencia, tres pistas de auditoría. Un programa convergido produce una entrada con tres etiquetas.
Taxonomía del riesgo de cumplimiento en 2026
Las cinco familias clásicas del riesgo de cumplimiento permanecen. La taxonomía necesita tres adiciones para seguir siendo creíble en 2026. Riesgo regulatorio: riesgo de sanción, restricción o requerimiento de una autoridad estatutaria. Ejemplo: una sanción del Reglamento IA de hasta el 7 por ciento de la facturación mundial anual por introducir en el mercado un sistema de IA prohibido. Riesgo operativo: riesgo de interrupción de las operaciones a consecuencia del incumplimiento o de su remediación. Ejemplo: la retirada forzosa de un modelo de suscripción que falla un test de equidad, con retrasos en cascada en el equipo de precios. Riesgo reputacional: riesgo de daño a la marca. Ejemplo: una investigación mediática sobre discriminación algorítmica que dispara un abandono de clientes muy por encima de la multa. Riesgo financiero: exposición monetaria directa más allá de las multas: coste de remediación, compensación a clientes, gastos jurídicos, impacto bursatil. Riesgo penal: riesgo de procedimiento penal individual contra administradores o directivos. Ejemplo: vulneración consciente del RGPD o, en ciertas jurisdicciones, negligencia grave en obligaciones de seguridad sobre IA. Tres adiciones IA se apilan sobre las cinco clásicas. Riesgo de modelo: riesgo de que un modelo de IA produzca salidas incorrectas, sesgadas o inestables en producción. Engloba sesgo, alucinación, deriva distribucional y vulnerabilidad adversarial. Ejemplo: un modelo de credit scoring cuyo ratio de impacto dispar superara el umbral de fair lending tres meses después del despliegue. Riesgo de IA de terceros: riesgo heredado de proveedores de modelos aguas arriba, API de modelos de base y herramientas de proveedores aumentadas por IA. Ejemplo: un chatbot de servicio al cliente construido sobre un modelo de base cuyo proveedor cambia silenciosamente el prompt del sistema, alterando el comportamiento de salida sin previo aviso. Responsabilidad por decisión automatizada: riesgo derivado de decisiones tomadas únicamente sobre tratamiento automatizado, en particular cuando producen efectos jurídicos o similares. Combina el artículo 22 del RGPD con el derecho a explicación del artículo 86 del Reglamento IA. Ejemplo: un rechazo de préstamo automatizado del que el cliente exige explicación al amparo de ambos textos en el mismo gesto. Una taxonomía que sostenga estas ocho categorías, con ejemplos y propiedad clara en primera, segunda y tercera línea, hace el registro defendible frente a una inspección que puede llegar sin avisar.
Herramientas: del GRC en hoja de cálculo a la supervisión continua aumentada por IA
La capa de herramientas de la gestión de riesgos de cumplimiento ha atravesado tres generaciones. La primera fue el registro en hoja de cálculo: un libro, varias pestañas, columna propietario, columna estado, ciclo de actualización medido en trimestres. Escala a unas decenas de riesgos antes de colapsar bajo su propia metadata. La segunda fue el GRC en flujo de trabajo: un sistema apoyado en base de datos, con bibliotecas de controles, depósito de evidencias, enrutamiento de atestaciones y cuadros de mando. Escala a miles de controles y hace soportable la recuperación de evidencias en auditoría, pero sigue siendo un sistema del escrito: alguien tiene que actualizar cada fila, y la frescura de un campo depende de que alguien se acuerde de refrescarlo. La tercera, que toma forma en 2026, es la capa de supervisión continua aumentada por IA. Lee directamente la telemetría operativa (registros de rendimiento de modelos, detectores de deriva, tickets de incidente, flujos de seguridad de proveedores, barridos de horizonte normativo) y entrega los cambios al equipo de cumplimiento como señales en lugar de tickets. El registro de riesgos se convierte en una vista viva sobre un flujo subyacente de evidencias, en lugar de un documento estático actualizado por cadencia. AI Sigil está construida para esta tercera generación. La plataforma conecta la obligación del artículo 9 del Reglamento IA, los registros de medición del NIST AI RMF y las atestaciones de control ISO/IEC 42001 en una sola capa GRC, para que un equipo de cumplimiento pueda pilotar la disciplina a la velocidad a la que los sistemas bajo gestión cambian realmente.
Preguntas frecuentes
¿Qué es el cumplimiento en la gestión de riesgos? El cumplimiento en la gestión de riesgos es el requisito por el que toda actividad de tratamiento del riesgo (identificación, evaluación, tratamiento, monitorización) se conduzca de manera que satisfaga leyes, reglamentos, normas y obligaciones contractuales aplicables, conservando la evidencia para la auditoría. Es la sutura entre dos disciplinas GRC: hacer el trabajo de gestión de riesgos Y hacerlo auditable. ¿Cuáles son los cuatro tipos de gestión de riesgos? Los cuatro tipos más citados son enterprise risk management (ERM), gestión del riesgo operativo, gestión del riesgo financiero y gestión del riesgo de cumplimiento. En 2026 la gestión del riesgo de IA se nombra cada vez más como quinta familia, apoyada sobre las cuatro y que hereda de cada una. El Reglamento IA formaliza esta capa con el artículo 9, que constituye un marco sectorial de gestión de riesgos para sistemas de IA de alto riesgo. ¿Qué es un marco de gestión de riesgos de cumplimiento? Un marco de gestión de riesgos de cumplimiento es el conjunto de principios, procesos y controles que una organización usa para conducir la gestión de riesgos de un modo que los supervisores reconozcan. Los puntos de anclaje más comunes en 2026 son ISO 31000 para la capa corporativa, ISO/IEC 42001 para el sistema de gestión de la IA, el NIST AI RMF para las funciones operativas y el artículo 9 del Reglamento IA para la obligación jurídica cuando la IA entra en el perímetro. La mayoría de las organizaciones maduras adopta un modelo en estrella en el que un marco ancla y los otros se mapean encima. ¿Qué ejemplos hay de riesgo de cumplimiento? Los ejemplos clásicos incluyen fallos AML, vulneraciones del RGPD, brechas anticorrupción, lagunas en filtros de sanciones e infracciones del derecho laboral. Los ejemplos de la era IA incluyen la introducción en el mercado de un sistema de IA prohibido, el incumplimiento del registro de un sistema de IA de alto riesgo en la base de datos de la UE, obligaciones de post-market monitoring incumplidas, despliegue de un modelo cuyas métricas de sesgo superan los umbrales de fair lending y dependencia de un proveedor de modelo de base que no mantiene la documentación técnica que el responsable del despliegue necesita para cumplir sus propias obligaciones. ¿Hace falta una certificación para trabajar en gestión de riesgos de cumplimiento? Ninguna certificación es legalmente obligatoria, pero los empleadores esperan cada vez más al menos una de las siguientes: Certified in Risk and Information Systems Control (CRISC), Certified Compliance and Ethics Professional (CCEP), certificaciones de cumplimiento del Chartered Insurance Institute o equivalentes sectoriales (FRM y PRM en servicios financieros). Sobre la dimensión IA, las formaciones en NIST AI RMF y los itinerarios lead-auditor o lead-implementer ISO/IEC 42001 se están convirtiendo en la nueva base. ¿En qué cambia la gestión de riesgos de cumplimiento en la banca? En la banca la disciplina soporta la carga regulatoria más pesada, apilada sobre los marcos de capital Basilea III/IV, las guías supervisoras sobre riesgo de modelo (SR 11-7 en Estados Unidos, TRIM en la zona euro), la resiliencia operativa DORA, AML, sanciones, protección al consumidor y ahora el artículo 9 del Reglamento IA para credit scoring y otros usos de IA de alto riesgo. La biblioteca de controles es más densa, la cadencia más próxima al tiempo real y la segunda línea es típicamente más grande y más independiente que en otros sectores. ¿La gestión del riesgo de cumplimiento es lo mismo que ISO 31000? No. ISO 31000 es el marco de gestión del riesgo corporativo que aporta principios, marco y proceso para todas las categorías de riesgo. La gestión del riesgo de cumplimiento es un subconjunto que se centra en el riesgo de incumplimiento regulatorio. ISO 31000 aporta el vocabulario y el ciclo de vida que la gestión del riesgo de cumplimiento toma prestados; por sí misma no satisface ninguna obligación de cumplimiento específica.
Conclusión
La gestión de riesgos de cumplimiento en 2026 ya no es la disciplina que era en 2020. La llegada del Reglamento IA, ISO/IEC 42001, NIST AI RMF y la ola paralela DORA, NIS2, CSRD ha redibujado qué significa « conducir la gestión de riesgos de modo conforme ». Los equipos que hacen converger sus marcos en una sola arquitectura en estrella, que registran los riesgos de IA junto a las ocho familias clásicas, que clasifican cada sistema de IA como proveedor o responsable del despliegue para asignar el juego adecuado de controles y que pasan de la hoja estática a la supervisión continua aumentada por IA, dedicarán menos tiempo a copiar entradas entre hojas y más tiempo a pilotar el riesgo de verdad. AI Sigil existe para ofrecer a los equipos de cumplimiento esa capa operativa, con el artículo 9 del Reglamento IA, el NIST AI RMF e ISO/IEC 42001 cableados como un solo movimiento.