IA en GRC: citar no es verificar

Un agente de IA lee una política de seguridad, encuentra un párrafo pertinente y marca un requisito como cumplido. Su explicación parece plausible e incluye un enlace a la fuente. Pero ¿qué cambio en el requisito o en las evidencias modificaría ese veredicto?

La investigación reciente sobre gobernanza, riesgo y cumplimiento (GRC) hace ineludible esa pregunta. Un modelo puede dar la respuesta correcta por el motivo equivocado, citar una fuente auténtica vinculada al sistema equivocado o confundir una política escrita con un control eficaz. En Secani lo tomamos como un reto de diseño de producto: la conexión entre requisito, observación y decisión debe poder examinarse.

Compruebe si el veredicto depende de la regla

El preprint Verdict Without the Rule mantiene fijo un caso mientras elimina, sustituye o niega la regla aplicable. En cinco modelos ejecutados localmente y 20 ámbitos, eliminar la regla cambió el veredicto en solo un 5,3 % de los casos de media. Un veredicto que no cambia no es automáticamente erróneo: reglas distintas pueden conducir al mismo resultado. Pero una respuesta correcta por sí sola no puede demostrar que el sistema haya utilizado la regla proporcionada.

Eso exige pares de casos revisados, no solo pruebas comparativas de respuesta única. Si un requisito de revisión de accesos pasa de trimestral a mensual mientras los registros disponibles siguen siendo los mismos, puede que la evaluación deba cambiar. Reformular el mismo requisito sin cambiar su significado debería dejar estable la evaluación. Ambas reacciones importan.

Separe la cobertura de la política de la prueba operativa

PACE separa la recuperación de los pasajes pertinentes de una política de la evaluación de si cubren un requisito de seguridad total, parcialmente o en absoluto. Los resultados que presenta se refieren a la cobertura de la documentación, no a si las medidas descritas funcionan en la práctica. Una política puede exigir autenticación multifactor para los accesos privilegiados sin demostrar qué cuentas están protegidas técnicamente ni qué excepciones existen.

ReCon documenta un fallo aún más simple: en algunos ejemplos, los modelos tratan el texto del requisito incluido en la instrucción como si fuera una evidencia de la empresa. Por tanto, los requisitos y los registros de la empresa necesitan identidades distintas en el modelo de datos. Una cita debe apuntar al pasaje que respalda realmente la afirmación.

Esta distinción hace que los hallazgos sean accionables. «La política existe, pero faltan evidencias técnicas para tres cuentas privilegiadas» indica a un consultor qué investigar. «Cumplimiento parcial» no.

Compruebe la relación, no solo la fuente

El proceso descrito en From Legacy Documentation to OSCAL extrae activos de descripciones de sistemas y utiliza inteligencia de amenazas estructurada para producir artefactos de cumplimiento. Su análisis de errores muestra por qué una fuente real puede respaldar aun así una conclusión equivocada: si un activo se extrae de forma incorrecta, las consultas posteriores pueden devolver vulnerabilidades auténticas de un producto distinto.

La revisión humana aporta más valor en esos vínculos de gran impacto: una versión de producto, un límite de sistema, una ubicación o una asignación de control de la que dependen muchos hallazgos posteriores. Una sugerencia extraída debe seguir siendo distinguible de un elemento de inventario confirmado. Cuando se corrige un vínculo fundamental, las evaluaciones derivadas deben ser trazables.

Dé a las evidencias un alcance y una ventana temporal

Compliance-as-Code for AI-Driven Identity Systems propone «contratos de evidencias» que especifican los tipos de evidencias exigidos, las correspondencias, los campos, las versiones y los periodos de observación. Su prototipo utiliza flujos de identidad sintéticos, por lo que el estudio es un ejemplo de arquitectura y no una validación amplia en entornos empresariales.

Un informe de pruebas de marzo no demuestra automáticamente que un control siga funcionando después de un cambio en el sistema en septiembre. Una exportación de configuración de una filial no acredita el estado de otra. Las evidencias necesitan un objeto, un origen, un periodo y una afirmación que respalden. Si una integración deja de proporcionar datos actuales, el estado presente queda sin demostrar; eso es distinto de un fallo del control demostrado.

Haga repetibles las comprobaciones acordadas

Ontological Knowledge Blocks describe una representación intermedia estructurada de obligaciones definidas por expertos, compilada en reglas de validación ejecutables. La interpretación normativa sigue siendo una responsabilidad humana. Otro preprint sobre evaluación de riesgos asigna artefactos técnicos observables a resultados ordinales mediante reglas versionadas y verifica formalmente algunas propiedades de coherencia. Ninguno de los dos estudios establece un motor universal de cumplimiento ni probabilidades de incidentes calibradas empíricamente.

El principio útil es distinguir la interpretación de la ejecución repetible. Un agente puede proponer criterios a partir de una política. Una vez que los expertos los aprueban, comprobaciones como un campo que falta, un periodo de observación vencido o un umbral superado no deberían necesitar una nueva interpretación del modelo en cada ejecución. Un veredicto debe registrar la versión del requisito, las versiones de las evidencias y la lógica aplicada.

Reabra las decisiones cuando cambien sus premisas

El cumplimiento continuo no exige reabrir todos los controles tras cada modificación de un documento. Exige saber qué conclusiones dependen de la información que ha cambiado. Un encabezado corregido puede no tener ningún efecto. Una nueva excepción para los accesos privilegiados puede afectar a varios marcos.

La decisión histórica debe permanecer intacta: puede que estuviera justificada en su momento. Pero no debe seguir viva indefinidamente como afirmación actual después de que hayan cambiado sus premisas. Las relaciones explícitas y versionadas permiten a los consultores centrarse en las evaluaciones que realmente necesitan una nueva revisión.

Estos artículos no demuestran que la GRC pueda ser totalmente autónoma. Varios son preprints o evaluaciones de prototipos limitados. Sí apuntan, sin embargo, a un estándar útil para Secani: los agentes deben preparar la información, proponer correspondencias, explicar las carencias y ayudar a los consultores a llegar antes a decisiones defendibles.

Un estado en verde es un resultado. El producto es la conexión trazable entre el requisito, la realidad y la decisión.