El problema: la preparación para auditorías como proyecto
En la mayoría de las empresas, la preparación para una auditoría (auditoría de cuentas anuales, inspección fiscal, auditoría SOC 2) es un proyecto. Semanas antes de la auditoría se compilan documentos, se toman capturas de pantalla, se exportan evidencias de distintos sistemas y se organizan en carpetas.
Este procedimiento tiene tres problemas: es costoso, es propenso a errores y muestra una instantánea en lugar de un estado. El auditor ve cómo estaba el sistema en el momento de la documentación, no cómo funciona realmente.
Cuando los AI Agents toman decisiones críticas para el negocio, el problema se agrava. Cada decisión individual del agente debe ser trazable. Con miles de decisiones al mes, la documentación manual ya no es viable.
De un vistazo - Cert-Ready by Design
- Cert-Ready by Design significa que la preparación para auditoría es un principio arquitectónico, no un proyecto de documentación retrospectivo.
- Los controles son objetos de datos de primera clase con generación automática de evidencia, versionado de reglas y estado en vivo para auditores.
- ISACA (2023) reporta que las organizaciones con monitorización continua de controles reducen el tiempo de preparación de auditoría hasta un 65%.
- El Framework-Mapping cubre ISA, NIA-ES, SOC 2 e ISAE 3402 - la evidencia habla el lenguaje que los auditores entienden.
- Resultado: la auditoría del procesamiento asistido por IA dura horas en lugar de semanas, con evidencia completa y a prueba de manipulación.
Qué significa Cert-Ready by Design
Cert-Ready by Design invierte el enfoque: la preparación para auditorías no es un proceso posterior, sino un principio arquitectónico. Los controles son objetos de datos técnicos en el sistema. La evidencia se genera automáticamente. Los auditores ven el estado en vivo, no una instantánea.
Controles como objetos de datos de primera clase
En la arquitectura Cert-Ready, cada control es un objeto de datos técnico con atributos definidos:
| Elemento | Función |
|---|---|
| Control_ID | Identificación única del control |
| Technical_Implementation | Implementación técnica concreta (p. ej., política RLS, verificación API, umbral de confianza) |
| Rule_Version | Versión de la lógica de decisión subyacente |
| Evidence_Generator | Mecanismo automático de verificación que genera evidencia |
| Evidence_History | Resultados de verificación historizados con marca temporal |
| Auditor_View | Vista con capacidad de drill-down hasta la implementación |
Los controles no son documentos de Word en una carpeta de SharePoint. Son objetos técnicos que viven en el sistema, se verifican automáticamente y reflejan su estado en tiempo real.
Generación automática de evidencia
La evidencia no se compila a posteriori. Se genera automáticamente, con cada decisión del agente, con cada cambio de regla, con cada evento del sistema.
Un ejemplo: el agente procesa una factura entrante. El Decision Layer aplica la regla PGC-6000 en versión 4.2. Confianza: 97%. Resultado: propuesta de asiento en cuenta 600, centro de coste 1200. Sin escalación (confianza por encima del umbral, importe por debajo del límite de valor).
La evidencia de esta operación se genera automáticamente: datos de entrada, regla aplicada con versión, valor de confianza, decisión de enrutamiento, resultado, marca temporal. Esta evidencia es inmutable y está vinculada al asiento contable.
Portal del Auditor
Los auditores ven en el Portal del Auditor el estado en vivo de todos los controles. Sin exportación PDF, sin instantánea, sino el estado actual del sistema.
El Portal del Auditor ofrece drill-down: desde la vista general de controles (dashboard semáforo: verde/amarillo/rojo) a través del control individual hasta la implementación técnica concreta y el historial de evidencia.
Framework-Mapping
Los controles se mapean a estándares de auditoría establecidos:
ISA / NIA-ES (Normas Internacionales de Auditoría): Para auditorías de cuentas anuales. Los controles representan los controles internos que el auditor de cuentas evalúa en el marco de su auditoría, conforme a la Ley 22/2015 de Auditoría de Cuentas y las normas técnicas del ICAC.
SOC 2 / ISAE 3402: Para auditorías de TI y aseguramiento de terceros. Las implementaciones técnicas de los controles se mapean a los criterios de confianza de SOC 2 e ISAE 3402.
Plan General de Contabilidad (PGC): Para la integridad de la información financiera. El versionado de los conjuntos de reglas, la inmutabilidad del Audit Trail y la trazabilidad de cada decisión de asiento cumplen los requisitos del PGC y la normativa del ICAC.
Este Framework-Mapping asegura que la evidencia generada automáticamente habla el lenguaje que los auditores entienden.
Cert-Ready en la práctica
Una firma de auditoría realiza la auditoría de cuentas anuales de un cliente. El cliente utiliza AI Agents para el procesamiento de facturas.
El auditor abre el Portal del Auditor. Ve: 12 controles para el procesamiento de facturas, todos en verde. Hace clic en el control “BV-003: Completitud de los asientos contables”. Ve: la implementación técnica (verificación API contra la entrada de facturas), la versión actual de la regla, la evidencia de los últimos 12 meses (todas las verificaciones automáticas superadas), la confianza media y la tasa de escalación.
Puede hacer drill-down: verificar asientos individuales por muestreo, trazar la ruta de decisión, consultar la regla aplicada en la versión vigente en el momento de la decisión.
El resultado: la auditoría del procesamiento asistido por TI dura horas en lugar de semanas. La evidencia es completa, generada automáticamente y a prueba de manipulación.
Más sobre este tema: Cert-Ready by Design en detalle
Más sobre gobernanza: Gobernanza de IA
Agendar reunión. Le mostramos el Portal del Auditor en vivo.
Bert Gogolin
Director General, Gosign
AI Governance Briefing
IA empresarial, regulación e infraestructura - una vez al mes, directamente de mi parte.