Herramientas GRC: qué cambia con la IA

Lo esencial

• Las herramientas GRC son el archivo único donde confluyen políticas, riesgos, controles, obligaciones y las pruebas que los enlazan. Su valor reside en el modelo de datos, no en el cuadro de mando.
• Lo que la IA ha modificado es el alcance de ese modelo: los sistemas de IA que una organización desarrolla o adquiere constituyen ya una categoría de activos regulados por derecho propio.
• El artículo 17 del reglamento europeo de IA enumera doce elementos que el sistema de gestión de la calidad de un proveedor debe documentar. Leído como un pliego de compra, ese listado describe lo que una herramienta debe contener.
• El Ómnibus digital aplazó al 2 de diciembre de 2027 el plazo de los sistemas de alto riesgo del anexo III. Se movió el plazo, no el tiempo que exige construir una cadena de pruebas creíble.
• El criterio de elección no es el número de módulos, sino que los resultados resistan el examen de un organismo notificado o de una autoridad de vigilancia del mercado.

Qué hacen realmente las herramientas GRC

Las herramientas GRC constituyen el archivo único donde figuran las políticas de una organización, los riesgos que ha aceptado o rechazado, los controles que tratan esos riesgos, las obligaciones a las que dichos controles responden y las pruebas de que cada control operó efectivamente. Las tres letras designan tres disciplinas nacidas en direcciones distintas. La herramienta es precisamente lo que las obliga a compartir una misma estructura. Esa estructura constituye el producto. Una gobernanza sin datos de riesgo se reduce a documentos que nadie lee. Un riesgo sin vínculo con los controles genera un registro que nunca cambia nada. Un cumplimiento sin pruebas sigue siendo una afirmación. Mientras las tres dimensiones vivan en hojas de cálculo separadas, cada auditoría se convierte en un ejercicio de conciliación y cada pregunta del regulador en un proyecto. Cuando comparten un único modelo de datos, una pregunta del tipo «qué controles tratan este riesgo, quién responde de ellos, cuándo se probaron por última vez y dónde está la prueba» obtiene respuesta en minutos y no en semanas. Es también la razón por la que la categoría se resiste a las definiciones sencillas. Dos productos pueden presentarse ambos como plataforma GRC sin compartir casi nada, porque uno está construido en torno a la distribución de políticas y su aceptación, y el otro en torno a la prueba de controles y al desarrollo de auditorías. La pregunta útil nunca es si se trata de una herramienta GRC, sino qué abarata su modelo de datos y qué encarece.

Por qué el modelo de datos importa más que el cuadro de mando

En las demostraciones comerciales el cuadro de mando ocupa el primer plano, porque se muestra bien. Sin embargo se sitúa aguas abajo. Un mapa de calor se produce sin dificultad cuando riesgos, controles y resultados de pruebas están correctamente enlazados, y resulta imposible de producir con honestidad cuando no lo están. Las preguntas que de verdad sostienen una evaluación se refieren a la estructura. ¿Puede un mismo control satisfacer varios marcos a la vez, o impone la herramienta un control duplicado por cada marco? ¿Puede una obligación rastrearse hasta el artefacto concreto que la cumple? ¿Puede un riesgo asociarse a un activo y no solo a un proceso de negocio? De esas respuestas depende que la herramienta reduzca el trabajo o se limite a desplazarlo. Nuestra guía sobre gobernanza de la IA expone el modelo operativo que esta estructura debe sostener.

El modelo de capacidades OCEG y el lugar real de la herramienta

La mayoría de las presentaciones de esta categoría acaba citando el GRC Capability Model de OCEG, publicado como Red Book. Organiza la disciplina en cuatro componentes: Learn, Align, Perform y Review, bajo el lema de la Principled Performance. Learn consiste en comprender el contexto, la cultura y los grupos de interés. Align conecta objetivos, estrategia y apetito de riesgo. Perform abarca la ejecución de los controles. Review mide qué funcionó realmente. El modelo está disponible en OCEG. La lectura honesta, la que la mayoría de esas presentaciones evita, cabe en una frase: el software instrumenta bien Perform y Review, y no puede fabricar Align en absoluto. Una herramienta sabe registrar una declaración de apetito de riesgo. No dirá si la organización comparte realmente ese apetito, ni si la dirección lo dejaría de lado bajo presión comercial. Adquirir una herramienta antes de haber decidido qué está dispuesta a aceptar la organización produce una versión notablemente bien documentada de un desacuerdo sin resolver. Con la IA esta distinción pesa más de lo que pesaba con los controles financieros, porque las decisiones sobre IA se toman mucho más abajo en la organización. Un responsable de producto puede insertar un modelo en un flujo de cara al cliente en una tarde. Si la fase Align no ha tenido lugar, la herramienta registra las consecuencias en lugar de orientar las decisiones. Ello explica asimismo la borrosidad de las fronteras de la categoría. Las herramientas GRC son una pieza de una cadena de control más amplia, que incluye gestión de identidades, registro de eventos, registros de modelos y supervisión de seguridad, un reparto que exponemos en nuestro análisis sobre la plataforma de cumplimiento frente al resto de la cadena.

Qué cambia con la IA: el sistema pasa a ser el activo regulado

Hasta hace poco el alcance de un programa GRC comprendía procesos, proveedores, controles e información financiera. La IA añade un objeto para el que el modelo no fue concebido: un activo probabilístico en lugar de determinista, que se degrada en silencio a medida que el mundo se aleja de sus datos de entrenamiento, y que se regula sistema por sistema en lugar de proceso por proceso. De ahí se derivan tres consecuencias. La primera afecta al inventario, que pasa a ser la restricción determinante. No se clasifica, no se controla ni se prueba aquello cuya existencia se desconoce, y la adopción no declarada es la norma antes que la excepción. Todo lo que no se ve queda fuera del conjunto de controles redactados, y ese es el problema concreto que hay detrás de la shadow AI. La segunda consecuencia convierte la clasificación en un acto jurídico y no en una comodidad interna. Según el reglamento europeo, que un sistema quede entre las prácticas prohibidas, entre los de alto riesgo, entre los sujetos solo a obligaciones de transparencia o fuera de todo régimen específico determina las obligaciones que le corresponden. Esa clasificación debe consignarse, motivarse y revisarse cada vez que el sistema evoluciona. La tercera consecuencia pone fin al carácter periódico del registro de riesgos. Un control probado una vez al año es una respuesta razonable para un proceso de compra. Resulta insuficiente para un modelo cuyo comportamiento puede desplazarse tras una actualización del proveedor de la que nadie fue avisado. Nuestra guía de gestión de riesgos de IA precisa qué significa continuo en la práctica.

Del GRC potenciado por IA al GRC sobre la IA

Casi todos los productos del mercado exhiben ya funciones de IA: resumir políticas, redactar descripciones de controles, sugerir valoraciones de riesgo, clasificar cuestionarios. Una parte de ellas elimina trabajo de verdad. Se trata, no obstante, de un asunto enteramente distinto de aquel por el que preguntan los reguladores. El GRC potenciado por IA significa que el proveedor emplea un modelo para acelerar su propio software. El GRC sobre la IA significa que su organización puede demostrar el control de los sistemas de IA que explota. Una herramienta puede sobresalir en lo primero y resultar inútil en lo segundo. Toda la distinción reside en la preposición, y conviene ser directo con los proveedores sobre cuál de las dos se está mostrando. Hay además un punto de segundo orden. Si un modelo contribuye a producir sus pruebas de control, ese modelo entra a su vez en el alcance. Una prueba generada por un sistema no validado no vale más que el sistema que la produjo.

El reglamento europeo redacta el pliego de requisitos

Lo más útil del reglamento europeo de IA, para quien evalúa herramientas, es su precisión inhabitual respecto a lo que debe existir por escrito. Los artículos 8 a 15 fijan los requisitos aplicables a los sistemas de alto riesgo: sistema de gestión de riesgos (artículo 9), datos y gobernanza de datos (artículo 10), documentación técnica (artículo 11), conservación de registros (artículo 12), transparencia e información a los usuarios (artículo 13), supervisión humana (artículo 14), precisión, solidez y ciberseguridad (artículo 15). El artículo 16 enumera después las obligaciones del proveedor: cumplir esos requisitos, identificarse en el sistema, disponer de un sistema de gestión de la calidad, conservar la documentación, conservar los registros generados automáticamente, someterse a la evaluación de la conformidad, elaborar una declaración UE de conformidad, colocar el marcado CE, registrar el sistema, adoptar las medidas correctoras necesarias, cooperar con las autoridades nacionales competentes y cumplir los requisitos de accesibilidad. El artículo 17 hace aparecer un pliego de compra casi al pie de la letra. El sistema de gestión de la calidad del proveedor debe estar documentado e incluir como mínimo: una estrategia de cumplimiento normativo que abarque los procedimientos de evaluación de la conformidad; las técnicas de diseño, desarrollo y control de la calidad; los procedimientos de examen y ensayo; las especificaciones técnicas; los sistemas de gestión de datos; un sistema de gestión de riesgos; un sistema de vigilancia poscomercialización conforme al artículo 72; los procedimientos de notificación de incidentes graves conforme al artículo 73; un proceso de comunicación con las autoridades; un sistema de conservación de registros; la gestión de recursos; y un marco de rendición de cuentas que fije las responsabilidades de la dirección y del personal. Doce elementos, cada uno de los cuales debe estar en algún sitio y poder presentarse cuando se solicite. Se trata del pliego de un archivo, lo llame así alguien o no. El artículo 9 precisa la forma del trabajo sobre el riesgo. La gestión de riesgos es un proceso iterativo continuo a lo largo de todo el ciclo de vida: identificar y analizar los riesgos para la salud, la seguridad y los derechos fundamentales, evaluar los riesgos que surgen durante el uso, evaluar los riesgos revelados por los datos de vigilancia poscomercialización y adoptar en consecuencia las medidas oportunas. También se fijan las finalidades: eliminar o reducir el riesgo en la medida técnicamente posible, mitigar lo que no pueda eliminarse, facilitar la información de transparencia y formar a los responsables del despliegue cuando proceda. El propio riesgo se define como la combinación de la probabilidad de un daño y su gravedad. Un matiz desactiva la objeción habitual de que todo esto solo afecta a las grandes organizaciones. El artículo 17, apartado 2, exige que la implantación del sistema de gestión de la calidad sea proporcionada al tamaño de la organización del proveedor, y el considerando 146 contempla expresamente una versión simplificada para las microempresas. La proporcionalidad afecta a la cantidad de proceso, no a la existencia de las obligaciones. Nuestros recursos sobre el reglamento europeo de IA abordan en detalle las cuestiones de clasificación.

El plazo se movió, el tiempo de construcción no

El calendario se desplazó en 2026. El Ómnibus digital sobre IA aplazó al 2 de diciembre de 2027 las obligaciones de los sistemas de alto riesgo autónomos del anexo III, y al 2 de agosto de 2028 las relativas a la IA integrada en productos ya cubiertos por la legislación europea de seguridad de los productos. Varias fechas no se movieron: las obligaciones de transparencia y etiquetado de contenidos del artículo 50 se aplican desde el 2 de agosto de 2026, las relativas a los modelos de IA de uso general desde el 2 de agosto de 2025, y las prohibiciones del artículo 5 desde el 2 de febrero de 2025. Los análisis de la Cloud Security Alliance y del despacho Gibson Dunn coinciden en esas fechas. Leer ese aplazamiento como un respiro es un error, por una razón muy concreta. La vigilancia poscomercialización y la conservación de registros son obligaciones retrospectivas. Cuando en 2028 una autoridad pregunte cómo se comportó un sistema, la respuesta se construirá a partir de registros que había que capturar mientras el sistema funcionaba. Una organización que empiece a recopilar a finales de 2027 dispondrá de un sistema de gestión conforme y de ningún histórico que verter en él. El plazo señala el momento en que hay que poder mostrar la cadena, lo que sitúa la decisión de recopilar bastante antes.

ISO 42001 y NIST AI RMF: la capa de controles

El reglamento dice qué debe ser cierto. No entrega un conjunto de controles. Dos referencias cubren esa brecha, y unas herramientas GRC serias deben sostener ambas sin duplicar el trabajo. La norma ISO/IEC 42001 especifica un sistema de gestión de la IA, construido como las demás normas de sistemas de gestión, y es certificable. El punto cuenta tanto en lo comercial como en lo interno, porque un certificado es una prueba transferible en una conversación de compra. Encaja bien con los elementos del artículo 17, y de ahí que tantos proveedores lo conviertan en el esqueleto de su sistema de calidad. Tratamos la norma en ISO 42001 explicada. El NIST AI Risk Management Framework es voluntario y tiene otra forma: cuatro funciones, Govern, Map, Measure y Manage, que dan a los equipos un vocabulario común para hablar de riesgo de IA sin abrir antes una discusión terminológica. Su fuerza está en ordenar el análisis, su debilidad en el valor probatorio ante una auditoría, justo lo contrario que una norma certificable. Nuestra guía del NIST AI RMF recorre las cuatro funciones. La consecuencia para la elección de herramienta es concreta. La mayoría de las organizaciones responde a la vez a un reglamento, a una norma certificable y a un marco voluntario, a menudo además de certificaciones de seguridad ya existentes. Una herramienta que adscriba un control a un solo marco obliga a recopilar varias veces la misma prueba. Una herramienta que modele el control una vez y lo enlace con varias obligaciones convierte una multiplicación en una suma. Esta sola pregunta separa las herramientas que escalan de las que triplican la carga en silencio.

Una lista de capacidades para las herramientas en la era de la IA

Lo que sigue es lo que conviene poner a prueba al evaluar unas herramientas GRC, con la obligación a la que responde cada capacidad. La lista razona deliberadamente en capacidades y no en módulos, porque los nombres de los módulos varían entre productos mientras que las obligaciones no.

Dos filas concentran en la práctica la mayor parte de la dificultad. El registro automático es el punto de ruptura de las herramientas concebidas para el cumplimiento de procesos, construidas para validaciones humanas periódicas y no para flujos de eventos de máquina. La trazabilidad de la cadena de suministro es donde la mayoría de las organizaciones descubre que no sabe responder a preguntas elementales sobre un modelo que no entrenó, exactamente la brecha tratada en nuestro trabajo sobre auditabilidad.

Pruebas que resisten una auditoría

La mayoría de los problemas de prueba no son ausencias. Son artefactos que existen y aun así no resisten el examen, conforme a cuatro modos de fallo recurrentes. Nuestra guía sobre auditoría de sistemas de IA detalla lo que los evaluadores buscan realmente. La temporalidad viene primero. Una captura de pantalla demuestra que un estado existía en el momento en que alguien la tomó, no que un control operara a lo largo de un periodo. Sigue la atribución: una exportación sin autor, sin versión de sistema y sin marca de tiempo no se ata a nada. La mutabilidad constituye el tercer modo, pues una hoja de cálculo modificable a posteriori demuestra bastante menos de lo que su contenido sugiere. La trazabilidad forma el cuarto y más frecuente: un artefacto que no pueda vincularse a la obligación concreta que cumple deja adivinar al evaluador, y los evaluadores no adivinan a su favor. Los trabajos de COSO sobre control interno aplicado a la IA generativa aportan aquí una distinción que conviene retomar. Cuando la dirección se apoya en una salida de modelo como parte de la prueba de un control, el estándar aplicable a esa prueba se eleva. Rehacer uno mismo una verificación no equivale a aceptar la conclusión de un modelo, y la carga documental difiere en consecuencia: la instrucción, la configuración y la versión del modelo pasan a formar parte del expediente. La misma publicación formula una observación conexa que suele sorprender a los equipos, a saber, que modelos, configuraciones, artefactos de ajuste, incrustaciones e índices de recuperación deberían tratarse como elementos de configuración sujetos a control de acceso y gestión de cambios, y no como contenido. La prueba práctica aplicable a cualquier herramienta se hace en segundos. Tome un control, suba hasta la obligación a la que responde y baje después al artefacto que acredita su funcionamiento en el trimestre anterior. Si ese recorrido exige más de dos clics, o si algún paso descansa en la memoria de alguien, la herramienta es un archivador y no un archivo de referencia.

Comprar, ampliar o ambas cosas

Para dotarse de unas herramientas GRC que cubran la IA se presentan tres opciones honestas, y la elección depende de lo existente. Ampliar una plataforma ya implantada se justifica cuando funciona un programa maduro, cuando el proveedor ofrece un módulo de IA solvente y no un registro de riesgos rebautizado, y cuando la biblioteca de controles existente es realmente reutilizable. La ventaja está en un solo sistema y un solo conjunto de hábitos. El riesgo reside en un módulo que modela los sistemas de IA como activos ordinarios, y que por tanto falla en clasificación, registro y procedencia de los modelos. Un sistema dedicado a la gobernanza de la IA se justifica cuando la IA ocupa un lugar central en el producto, cuando las obligaciones son lo bastante específicas para que las estructuras de control genéricas no sirvan, o cuando no hay nada maduro que ampliar. La ventaja está en un modelo de datos concebido para el problema. El coste es un segundo sistema y un trabajo de integración que nadie disfruta. El enfoque híbrido es el desenlace más frecuente y el menos comentado. La plataforma histórica sigue siendo el archivo de referencia corporativo, mientras un sistema especializado atiende las obligaciones propias de la IA y eleva un estado consolidado. Funciona cuando la frontera se traza deliberadamente, y produce dos registros rivales cuando no es así. Sea cual sea la vía elegida, fije esa frontera antes de la conversación comercial y no durante. Nuestra página de software de cumplimiento para IA expone nuestro planteamiento para la parte especializada.

Preguntas frecuentes

¿Cuál es un ejemplo de herramientas GRC? La categoría abarca varias formas de producto. Las plataformas GRC corporativas centralizan registros de riesgos, prueba de controles y desarrollo de auditorías para grandes organizaciones reguladas. Las herramientas de automatización del cumplimiento se centran en la recogida continua de pruebas frente a certificaciones de seguridad. Los sistemas de gestión de políticas cubren redacción, distribución y aceptación. Los sistemas dedicados a la gobernanza de la IA modelan los sistemas de IA, su clasificación y sus obligaciones. La mayoría de las organizaciones utiliza más de uno, de modo que la comparación útil es cuál sostiene el archivo de referencia y cuáles lo alimentan. ¿Son lo mismo el GRC y la auditoría informática? No, aunque se confundan con frecuencia porque ambos miran los mismos controles. El GRC es la disciplina operativa continua: fijar la política, mantener el registro de riesgos, ejecutar controles y recoger pruebas sin interrupción. La auditoría informática es una evaluación independiente y periódica de si esa disciplina funciona. Un programa GRC bien llevado abarata las auditorías, puesto que las pruebas ya existen de forma estructurada. Los hallazgos de auditoría vuelven después al registro de riesgos. La relación es cíclica, pero los papeles siguen deliberadamente separados, y la independencia es la razón. ¿Es Jira una herramienta GRC? Por sí solo no. Jira sigue tareas, y buena parte del trabajo GRC consiste en tareas: acciones de remediación, pruebas de controles, peticiones de evidencia. Muchos equipos empiezan haciendo pasar por ahí su actividad de cumplimiento. Lo que falta es el modelo de datos subyacente, es decir, objetos de primer nivel para riesgos, controles, obligaciones y pruebas, con las relaciones entre ellos. Las incidencias con etiquetas lo aproximan hasta el día en que un evaluador pregunta qué controles tratan un riesgo dado y dónde está la prueba. Jira funciona bien junto a un archivo de referencia, y mal como tal. ¿El GRC exige saber programar? Por lo general no para el trabajo diario. Las herramientas actuales se configuran por interfaz, y las partes exigentes del oficio son analíticas antes que técnicas: clasificar bien los sistemas, redactar controles realmente comprobables, decidir qué constituye prueba suficiente. La programación cobra relevancia en los extremos, sobre todo en las integraciones que recuperan pruebas automáticamente desde plataformas en la nube, registros de modelos o sistemas de logging. Esa automatización es lo que hace viable la vigilancia continua a escala, de modo que cierta capacidad técnica en el equipo sigue siendo una ventaja concreta incluso donde no se exija. ¿Qué es mejor, un SOC o un GRC? Responden a preguntas distintas y no son alternativas. Un centro de operaciones de seguridad detecta y atiende amenazas casi en tiempo real. El GRC establece qué debe controlarse, por qué, y si los controles funcionaron a lo largo de un periodo. Un SOC produce pruebas e incidentes que un programa GRC consume, y un programa GRC fija las políticas y el apetito de riesgo dentro de los cuales opera un SOC. Las organizaciones que los tratan como partidas presupuestarias rivales acaban con una detección que nadie ha vinculado a una obligación, o con obligaciones que nada vigila. ¿Cubren las herramientas GRC el reglamento europeo de IA? Cada vez lo afirman más, y esas afirmaciones merecen comprobarse. Pida ver un inventario de sistemas de IA con clasificación por sistema y motivación consignada, pruebas enlazadas a artículos concretos y no a una familia genérica de controles, registros de máquina conservados en lugar de atestaciones humanas, y una gestión de incidentes graves acompasada a los plazos normativos. Muchos productos satisfacen lo primero y tropiezan con el resto. Un proveedor que reivindique esa cobertura debería poder recorrer un sistema desde su registro hasta un expediente legible por un evaluador.

Conclusión

La categoría no ha cambiado de nombre. Ha cambiado de alcance. Las herramientas GRC se juzgaban por cómo trataban procesos, proveedores y controles financieros; ahora se juzgan por su capacidad de tratar además un sistema de IA como objeto gobernado de primer nivel, con una clasificación, un conjunto de controles, una cadena de registros y un responsable. El reglamento ha hecho los requisitos inusualmente legibles. El artículo 17 enumera lo que debe documentarse, el artículo 12 exige que existan los registros, el artículo 72 prolonga la vigilancia tras el despliegue, y el aplazamiento de los plazos significa que la cadena de pruebas debe arrancar mucho antes de la fecha con la que se medirá. Evalúe en consecuencia: no por el número de módulos, sino por la solidez del recorrido que enlaza la obligación con el control y después con el artefacto fechado, cuando alguien con autoridad lo recorre. Si está llevando esa evaluación específicamente para sistemas de IA, nuestra plataforma de cumplimiento para IA está construida en torno a las obligaciones artículo por artículo descritas más arriba.