De la regulación al procedimiento de auditoría

Una regulación puede ocupar cientos de páginas. Un programa de auditoría, en cambio, necesita instrucciones concretas: qué revisar, qué evidencia pedir, cómo probarla y qué resultado justificaría una conclusión.

Ese salto no ocurre copiando artículos en una checklist.

La disciplina central es construir una cadena trazable desde el requisito hasta la conclusión. Si un auditor no puede explicar por qué una obligación aplica, qué riesgo pretende controlar, qué control espera encontrar y qué evidencia demostraría su funcionamiento, todavía no tiene un procedimiento de auditoría. Tiene una referencia normativa.

Esta distinción es especialmente importante en inteligencia artificial. El Reglamento de IA de la Unión Europea ya contiene obligaciones aplicables, pero también mantiene calendarios diferenciados para determinadas disposiciones. La Comisión Europea señala que el Reglamento pasó a ser aplicable con carácter general el 2 de agosto de 2026, mientras que algunas reglas de alto riesgo tienen fechas posteriores. Antes de usar un artículo como criterio, el auditor debe comprobar rol, sistema, jurisdicción, fecha y excepción aplicable.

Un requisito no es todavía una prueba de auditoría

El error más común al auditar regulación es empezar por la pregunta equivocada: “¿Cumple la organización con el artículo X?”. Esa pregunta es demasiado grande para convertirse directamente en evidencia.

Primero hay que separar tres tipos de autoridad. Una regulación como el EU AI Act crea obligaciones jurídicas cuando resulta aplicable. ISO/IEC 42001:2023 es una norma de sistema de gestión con requisitos que pueden utilizarse como criterio de conformidad cuando la organización la ha adoptado, la utiliza en un alcance de certificación o ha decidido evaluarse contra ella; no debe presentarse automáticamente como ley. Las Normas Globales de Auditoría Interna (GIAS), por su parte, gobiernan cómo trabaja la función de auditoría interna; no convierten por sí mismas una práctica de IA del auditado en una obligación regulatoria.

La Norma 13.4 de las GIAS exige identificar los criterios de evaluación más relevantes. Entre los criterios adecuados pueden estar leyes, regulaciones, obligaciones contractuales, políticas internas y marcos profesionales. El punto metodológico es decisivo: el auditor debe determinar primero cuál es el estado esperado y solo después compararlo con la condición observada.

La cadena de seis eslabones

Una traducción robusta puede documentarse en seis pasos conectados. El requisito define el criterio; el riesgo explica por qué importa; el control describe cómo la organización pretende gestionar ese riesgo; la evidencia muestra si el control existe y opera; el procedimiento desafía esa evidencia; y la conclusión resume qué puede sostenerse razonablemente con los resultados.

Eslabón	Pregunta de auditoría	Producto esperado
Requisito / criterio	¿Qué obligación o expectativa aplica exactamente y por qué?	Artículo, cláusula o política, con alcance, rol y fecha de aplicación
Riesgo	¿Qué puede ocurrir si el requisito no se cumple o el objetivo no se logra?	Declaración de riesgo y consecuencia
Control	¿Qué debería prevenir, detectar o corregir ese riesgo?	Objetivo de control y control esperado
Evidencia, prueba y conclusión	¿Qué demostraría operación, cómo se comprobará y qué resultado sería suficiente?	Evidencia solicitada, procedimiento, resultado y conclusión

La trazabilidad evita dos extremos. El primero es la auditoría documental: confirmar que existe una política y declarar cumplimiento. El segundo es la auditoría tecnológicamente sofisticada pero desconectada del criterio: ejecutar pruebas complejas sin poder explicar qué obligación o riesgo están evaluando.

Ejemplo regulatorio: transparencia en el EU AI Act

El artículo 50(1) del EU AI Act establece, para los proveedores de determinados sistemas de IA destinados a interactuar directamente con personas, una obligación de diseño y desarrollo orientada a que esas personas sean informadas de que interactúan con un sistema de IA, salvo cuando resulte evidente en las circunstancias. Las directrices de la Comisión Europea sobre transparencia, publicadas en julio de 2026, ayudan a interpretar estas obligaciones, aplicables desde el 2 de agosto de 2026.

Supongamos que una empresa es proveedor de un asistente de atención al cliente dentro del alcance del artículo. La traducción podría ser la siguiente:

Elemento	Ejemplo de diseño de auditoría
Riesgo	Una persona puede creer que interactúa con un humano cuando en realidad interactúa con IA, generando una falla de transparencia y exposición regulatoria.
Control	El inventario identifica todos los canales de interacción; el proceso de lanzamiento exige una comunicación de IA en cada interfaz aplicable y una excepción documentada cuando la organización considera que la naturaleza artificial es evidente.
Evidencia	Inventario de sistemas y canales, clasificación regulatoria, especificaciones de interfaz, capturas o configuraciones, casos de prueba, aprobaciones de lanzamiento, historial de cambios y excepciones documentadas.
Prueba y conclusión	Reconciliar el inventario con los canales en producción; ejecutar recorridos en cada canal o una muestra justificada; verificar la comunicación y las excepciones; rastrear cambios posteriores. Una ausencia en un canal activo puede sustentar un hallazgo específico, no una afirmación vaga de “cumplimiento parcial”.

Obsérvese que el control anterior es una forma plausible de operacionalizar el requisito, no texto del Reglamento. La dirección puede diseñar controles distintos y aun así satisfacer el criterio. Auditoría debe evaluar el resultado exigido, no imponer su plantilla preferida.

También importa el rol. Si la organización es únicamente un deployer y no un provider para ese sistema, el artículo 50(1) no debe aplicarse mecánicamente como si fuera su obligación. La determinación jurídica compleja debe coordinarse con Legal o Compliance; auditoría conserva la responsabilidad sobre su juicio profesional y sobre la calidad de la evidencia utilizada.

Ejemplo de sistema de gestión: ISO/IEC 42001

ISO/IEC 42001:2023 ofrece otro tipo de criterio. Su cláusula 8.2 requiere realizar evaluaciones de riesgos de IA en intervalos planificados o cuando se propongan u ocurran cambios significativos, y conservar información documentada de los resultados. El requisito pertenece a un sistema de gestión, no a una regulación general.

La cadena podría traducirse así: el riesgo es que un cambio material llegue a producción con una evaluación desactualizada; el control es un mecanismo de gestión de cambios que activa una reevaluación de riesgos antes de la aprobación, además de revisiones periódicas; la evidencia son registros de cambios, evaluaciones, aprobaciones y fechas; y la prueba consiste en seleccionar cambios significativos, rastrearlos hasta la reevaluación correspondiente y buscar excepciones en la población.

El valor del procedimiento está en la dirección de la prueba. Revisar diez evaluaciones de riesgos y confirmar que “se ven completas” no demuestra que todos los cambios que requerían evaluación la recibieron. Una prueba más fuerte parte de la población de cambios y rastrea hacia la evaluación. Es la diferencia entre comprobar la existencia de documentación y comprobar la integridad del proceso.

GIAS convierte la cadena en trabajo defendible

Las GIAS proporcionan la disciplina para convertir esta lógica en un trabajo reproducible. La Norma 13.6 requiere un programa de trabajo documentado que identifique criterios, tareas, metodologías y herramientas. La Norma 14.1 exige que la información utilizada para análisis y evaluación sea relevante, fiable y suficiente. La Norma 14.2 conecta explícitamente el criterio con la condición observada: la diferencia entre ambos indica un potencial hallazgo. La Norma 14.5 exige una conclusión que resuma los resultados en relación con los objetivos y el alcance del trabajo, y la Norma 14.6 exige documentación suficiente para que una persona informada y competente pueda repetir el trabajo y obtener resultados equivalentes.

En la práctica, un buen papel de trabajo regulatorio debería permitir reconstruir la lógica completa sin depender de la memoria del auditor:

Campo	Lo que debe quedar trazado
Fuente y aplicabilidad	Requisito, versión, fecha, rol, alcance y fundamento de aplicabilidad
Riesgo y control	Riesgo relevante, objetivo de control, control identificado y responsable
Evidencia y procedimiento	Población, fuentes, muestra si aplica, pasos ejecutados y excepciones
Resultado y conclusión	Condición, causa o exposición cuando proceda, importancia y efecto sobre la conclusión

Esta estructura también ayuda a distinguir tres resultados diferentes: un incumplimiento regulatorio, una no conformidad contra una norma adoptada y una debilidad de control o buena práctica. Mezclarlos puede exagerar la gravedad de un hallazgo o, en sentido contrario, minimizar una obligación legal.

La conclusión empieza en el criterio, no al final del trabajo

Una conclusión defendible no nace cuando se redacta el informe. Se construye desde la selección del criterio y la dirección de las pruebas.

Por eso, la mejor pregunta al leer una nueva regulación no es “¿qué documentos deberíamos pedir?”. Es: ¿qué tendría que ser cierto en la organización para que este requisito se cumpla, y qué evidencia suficientemente fiable me permitiría demostrarlo?

Cuando esa pregunta está bien respondida, el resto del trabajo se vuelve más claro. La regulación deja de ser un bloque de texto. Se convierte en una secuencia auditable de riesgo, control, evidencia, prueba y conclusión.