Ley de Inteligencia Artificial de la UE (AI Act)

Estructura escalonada y dos líneas de responsabilidad

El AI Act funciona por niveles de riesgo. Un sistema de alto riesgo (decisiones de crédito, selección de personal, evaluación de proveedores, control de acceso a servicios públicos) arrastra requisitos detallados de documentación técnica, evaluación de impacto en derechos fundamentales, registro de actividades y, en algunos casos, evaluación de conformidad por tercero independiente. Riesgo limitado se queda en obligaciones de transparencia. Riesgo mínimo no genera obligaciones específicas.

Para el auditor financiero la norma abre dos frentes:

1. El cumplimiento normativo del cliente. Si la entidad auditada usa sistemas de alto riesgo (lo más común en mi cartera: scoring de proveedores, automatización de altas de empleados, motores de fraude en facturación), el auditor verifica documentación de conformidad, evaluaciones de impacto sobre derechos fundamentales, designación de responsable y registros de funcionamiento. El anclaje normativo es la NIA-ES 250. 2. La fiabilidad de las herramientas que usa el propio equipo de auditoría. Si el equipo aplica IA para análisis de datos, scoring de muestras o procedimientos analíticos sustantivos, la NIA-ES 520.A1 exige evaluar la fiabilidad de los datos subyacentes. Un modelo entrenado con datos sesgados produce conclusiones no fiables, y la responsabilidad de detectarlo es del auditor, no del proveedor del software.

El AI Act no es un estándar de auditoría. No sustituye a la NIA-ES. La forma en que se cruza con el trabajo del auditor es lateral: a través de la 250 para cumplimiento, la 240 cuando el sistema puede haber sido manipulado de forma intencionada, la 315 para evaluación de riesgos y la 520 para fiabilidad de procedimientos analíticos. Esta es la primera idea que se confunde en revisiones de calidad del ICAC.

Lo que realmente ocurre en los papeles de trabajo

Vaya por delante que no he revisado todavía un encargo donde el equipo haya hecho bien las dos líneas. La pauta que veo es siempre la misma: el equipo identifica que el cliente tiene un sistema de alto riesgo, pide al cliente la documentación de conformidad, archiva el PDF de la evaluación de impacto y marca la casilla. Fue un trámite. Nadie ha probado si el sistema funciona como dice la documentación, ni si la dirección puede anular sus decisiones sin dejar rastro.

En mi caso esto me preocupa más que el cumplimiento formal del Reglamento, porque el riesgo de fraude vive precisamente en las anulaciones no documentadas. Y aquí entra la opinión incómoda: la mayoría de las firmas medianas van a acabar autoclasificando sus propias herramientas internas de IA como "riesgo limitado" porque la presión presupuestaria de la tecnología de auditoría no permite sostener la documentación técnica y la evaluación de conformidad de un sistema de alto riesgo. Eso ocurrirá porque el AEPD no inspecciona firmas de auditoría, el ICAC no tiene mandato para inspeccionar herramientas de IA y nadie controla la frontera entre las dos categorías.

Ejemplo práctico: Constructora Hispana S.L.

Constructora Hispana S.L., con sede en Madrid y facturación de 18,7 millones de euros, ha puesto en producción un sistema de IA de alto riesgo para evaluar ofertas de subcontratistas y asignar proyectos. El modelo combina datos históricos de desempeño, disponibilidad y proximidad geográfica para automatizar decisiones de contratación.

Paso 1. Durante la evaluación de riesgos (NIA-ES 315), el auditor identifica el sistema. Pide la documentación de conformidad: ¿hay evaluación de impacto en derechos fundamentales? ¿Hay responsable designado? ¿Existen registros de actividad?

Nota de documentación: en la carpeta permanente se abre la subplantilla "Sistemas de IA. Evaluación de cumplimiento con el AI Act" donde se registra la existencia del sistema, su clasificación de riesgo y el estado de la documentación regulatoria.

Paso 2. El auditor solicita los registros de transparencia: datos de entrada, lógica de entrenamiento, sesgos documentados en la selección. La pregunta operativa es si el patrón de contrataciones del último ejercicio es coherente con los criterios programados o si hay una desviación que apunte a manipulación. Aquí la 240 aparece de costado: un sistema técnicamente conforme con el AI Act sigue pudiendo ser instrumento de fraude si la dirección lo configura para favorecer a un subcontratista vinculado.

Nota de documentación: se registra la solicitud, la respuesta de la dirección y el análisis de coherencia entre las decisiones ejecutadas y los criterios documentados del modelo.

Paso 3. El auditor selecciona una muestra de decisiones de contratación y comprueba si el sistema funcionó como se documenta. La complicación que requiere juicio aparece aquí: dos contratos del último trimestre se adjudican a un subcontratista cuya puntuación no era la más alta. La dirección lo justifica con un correo informal que habla de "disponibilidad inmediata" y "experiencia previa con la obra", pero la anulación no está registrada en el sistema. ¿Es debilidad de control, riesgo de fraude bajo la NIA-ES 240 o ambas? Mi lectura es ambas, porque la ausencia del registro hace imposible distinguir un caso de otro.

Nota de documentación: en el programa de pruebas sustantivas de transacciones de contratación se añade la línea "Verificar que las decisiones de contratación ejecutadas son consistentes con los resultados del sistema de IA, o que las anulaciones están justificadas y registradas en el propio sistema".

Conclusión. Constructora Hispana cumple formalmente el AI Act. Tiene registros, documentación de conformidad y responsable designado. Sin embargo, el control sobre el sistema es débil porque la dirección puede anular decisiones sin trazabilidad. La conformidad regulatoria no es lo mismo que un control interno efectivo.

Disenso legítimo entre socios

El socio A diría que el hallazgo es exclusivamente debilidad de control interno bajo la NIA-ES 315 porque no hay evidencia directa de manipulación intencionada y la justificación de la dirección es plausible. El socio B diría que la ausencia sistemática de registros de anulación constituye un indicio de fraude bajo la NIA-ES 240 porque crea precisamente el espacio en el que el fraude puede ocurrir sin dejar huella, y eso ya es relevante con independencia de la intención probada. Yo cierro con el socio B, porque la NIA-ES 240 trata de riesgos, no de fraudes confirmados, y porque el patrón de anulaciones sin registro no es una excepción operativa: es una característica del sistema.

Errores frecuentes en revisiones de calidad

- Confundir "auditoría del modelo de IA" con "evaluación del cumplimiento del cliente con el AI Act". El revisor del ICAC a veces reformula el hallazgo como "no se auditó el modelo correctamente". El AI Act no impone un estándar de auditoría sobre el modelo. El auditor financiero evalúa cómo la existencia y el control del sistema afectan al riesgo de fraude, al cumplimiento normativo y a la fiabilidad de los datos financieros. La auditoría técnica del modelo, cuando aplica, es un encargo separado de un especialista en IA o del organismo notificado correspondiente.

- No evaluar la fiabilidad de los datos de entrada cuando el sistema está conectado a la contabilidad. Si el sistema de alto riesgo del cliente consume datos contables (típicamente un motor de scoring de fraude en facturación que se alimenta del ERP), la NIA-ES 520.A1 obliga a evaluar la fiabilidad de esos datos. Lo que veo en la práctica es documentación que se limita a "el sistema existe y está clasificado". Eso no es prueba de fiabilidad de los datos, son los papeles flojos.

- Asumir que la conformidad con el AI Act equivale a control interno sólido. No es así. Una entidad puede tener registros, documentación y responsable designado, y aun así permitir que la dirección anule decisiones sin justificación registrada. La conformidad regulatoria es condición previa, nunca conclusión sobre el control efectivo del sistema.

Relacionado con

- NIA-ES 250: cumplimiento del cliente con leyes y regulaciones aplicables, incluido el AI Act. - NIA-ES 240: fraude relacionado con sistemas de IA. Diseño o manipulación intencional del modelo como mecanismo de fraude. - NIA-ES 520: procedimientos analíticos. Fiabilidad de los datos que alimentan sistemas automatizados, internos del auditor o del cliente. - NIA-ES 315: evaluación del riesgo de incorrección material. La identificación de sistemas de alto riesgo en la entidad afecta directamente a la valoración del riesgo combinado. - ISAE 3402: si la entidad auditada presta servicios y el sistema de IA está integrado en controles que afectan a usuarios finales, puede requerirse un informe de tipo II sobre controles en una organización de servicios.

Términos relacionados

- Evaluación de impacto en derechos fundamentales (FRIA): requisito del AI Act para sistemas de alto riesgo. Identifica cómo el sistema puede afectar a derechos humanos. El auditor verifica su existencia y completitud. - Responsable de cumplimiento de IA: persona designada por la entidad para garantizar la conformidad. El auditor confirma su existencia operativa, no solo nominal. - Sistema de alto riesgo: clasificación del AI Act para sistemas que toman decisiones que afectan a seguridad o derechos fundamentales (decisiones de crédito, empleo, acceso a servicios públicos, evaluación de proveedores con impacto contractual significativo). - Transparencia del sistema de IA: documentación de cómo funciona el sistema, qué datos consume y quién es responsable. El auditor lo verifica como parte de la evaluación de control interno. - Evaluación de conformidad por tercero: algunos sistemas de alto riesgo requieren certificación por organismo notificado. Esto no es responsabilidad del auditor financiero, pero su ausencia sí es relevante para la NIA-ES 250. - Sesgo del modelo: riesgo de decisiones discriminatorias por parte del sistema. El auditor lo evalúa bajo la NIA-ES 240 cuando el patrón resultante puede indicar fraude intencional.

---