Ley de IA de la UE: Implicaciones para la Tecnología de Auditoría

Contenido

1. El fallo que se repite en los expedientes 2. Marco regulatorio y calendario de aplicación 3. Clasificación del sistema: dónde se equivocan las firmas 4. Proveedor o usuario: la línea que muchos cruzan sin darse cuenta 5. Ejemplo práctico: la herramienta de analítica que clasificamos mal 6. Lista de verificación operativa 7. Errores que aparecen en las inspecciones 8. Contenido relacionado

El fallo que se repite en los expedientes

Vaya por delante que el Reglamento de IA no pide al auditor nada conceptualmente distinto de lo que ya hace con cualquier herramienta del encargo. Pide un análisis, una conclusión documentada y un control sobre cómo se usa. El problema no es el contenido de la obligación. El problema es que el análisis se omite porque la herramienta se arrastra del ejercicio anterior, el proveedor no ha comunicado cambios y el equipo asume que "si lo usamos el año pasado, ya está clasificado".

Eso no es clasificación. Es inercia.

La clasificación que vale para el Reglamento (UE) 2024/1689 exige cuatro decisiones explícitas en el expediente: si la herramienta encaja en la definición del artículo 3.1, en qué categoría de riesgo cae (Título II), cuál es el rol de la firma (artículo 3.2 y 3.4), y qué medidas de supervisión humana se aplican (artículo 14 para sistemas de alto riesgo, práctica recomendada para el resto). Cuatro decisiones. Si alguna falta, la inspección la va a pedir.

Marco regulatorio y calendario de aplicación

El Reglamento (UE) 2024/1689 entró en vigor el 1 de agosto de 2024. La aplicación es escalonada:

- 2 de febrero de 2025: entran en vigor las prohibiciones del artículo 5 y las obligaciones de alfabetización en IA del artículo 4. - 2 de agosto de 2025: entran en vigor las obligaciones para modelos de IA de uso general (capítulo V) y el régimen de gobernanza. - 2 de agosto de 2026: entra en vigor el grueso de obligaciones para sistemas de alto riesgo del Anexo III. - 2 de agosto de 2027: cumplimiento total, incluidos los sistemas de alto riesgo integrados en productos regulados por otras normas de armonización (Anexo I).

En España, la autoridad designada para la supervisión general es la AESIA (Agencia Española de Supervisión de la Inteligencia Artificial), creada por el Real Decreto 729/2023. El ICAC conserva su competencia sobre el control de calidad del auditor. Lo que está por definir es cómo se coordinan ambas autoridades cuando el sistema de IA se usa en un encargo de auditoría de cuentas. La AESIA tiene la competencia sobre el sistema. El ICAC tiene la competencia sobre el expediente. El auditor responde ante los dos.

Clasificación del sistema: dónde se equivocan las firmas

El artículo 6 y el Anexo III definen cuándo un sistema es de alto riesgo. El resto del marco distribuye los sistemas entre prohibidos (artículo 5), riesgo limitado con obligaciones de transparencia (artículo 50) y el conjunto residual sin obligaciones específicas más allá de las buenas prácticas.

Lo que realmente hace que un sistema sea "de alto riesgo"

Dos vías. La primera, que el sistema sea componente de seguridad de un producto cubierto por la legislación de armonización del Anexo I. Esto rara vez afecta al trabajo del auditor.

La segunda vía es la que importa: los ocho dominios del Anexo III. Para el auditor, los relevantes son:

- Anexo III, punto 5, letra b: sistemas usados para evaluar la solvencia o calificar la puntuación crediticia de personas físicas. - Anexo III, punto 4: sistemas usados para el reclutamiento, evaluación del desempeño o toma de decisiones sobre empleo. - Anexo III, punto 1, letra a: sistemas de identificación biométrica remota (si el cliente opera con control de acceso biométrico y la herramienta del auditor lo evalúa directamente).

La herramienta de analítica transaccional estándar no cae en ninguno de estos puntos. La herramienta que puntúa la fiabilidad de empleados del cliente a partir de patrones de pulsaciones, sí. La diferencia parece obvia cuando se lee en frío. En el encargo se diluye porque la herramienta se vende con etiquetas comerciales que no se corresponden con la taxonomía del Reglamento.

La trampa del "riesgo mínimo por defecto"

El enfoque dominante en las firmas medianas españolas es clasificar todo como "riesgo mínimo" salvo prueba en contrario. El Reglamento no funciona así. No existe una categoría llamada "riesgo mínimo" en el texto. Existen sistemas de alto riesgo (capítulo III), sistemas con obligaciones de transparencia (artículo 50), sistemas prohibidos (artículo 5), y el resto.

Decir "riesgo mínimo" en el expediente es tentador porque cierra la discusión sin documentar. Es exactamente el tipo de atajo que el ICAC va a señalar cuando empiece a revisar cómo las firmas aplican el Reglamento en los encargos. El expediente necesita la cadena analítica: definición del artículo 3.1 cumplida o no, Anexo III revisado punto por punto, artículo 5 descartado, artículo 50 evaluado para obligaciones de transparencia. Conclusión motivada al final, no al principio.

Proveedor o usuario: la línea que muchos cruzan sin darse cuenta

El artículo 3.3 define al proveedor como quien desarrolla el sistema o lo hace desarrollar y lo pone en el mercado bajo su nombre. El artículo 3.4 define al responsable del despliegue (el "usuario" en lenguaje corriente) como quien utiliza el sistema bajo su propia autoridad.

Parece limpio. No lo es.

El artículo 25 convierte al responsable del despliegue en proveedor cuando se da cualquiera de estas tres condiciones: pone su nombre o marca en el sistema, introduce una modificación sustancial, o cambia la finalidad prevista. Las firmas medianas de auditoría cruzan esta línea más a menudo de lo que creen.

El caso más común. La firma contrata una herramienta de analítica a un proveedor externo. El motor del proveedor viene entrenado con datos genéricos. La firma reentrena el modelo con los datos históricos de sus propios encargos para "ajustar la sensibilidad a los patrones del cliente". Ese reentrenamiento es modificación sustancial en el sentido del artículo 3.23. La firma acaba de convertirse en proveedor, con todas las obligaciones del capítulo III si el sistema es de alto riesgo, o del artículo 50 si activa obligaciones de transparencia.

El desacuerdo que va a aparecer en tu firma. Dos posturas razonables:

- Postura A (el socio técnico): "Ajustar parámetros del modelo a través de la interfaz del proveedor no es modificación sustancial. El artículo 3.23 habla de cambios en el uso previsto o en las prestaciones. Un reajuste de umbrales es configuración, no modificación." - Postura B (el socio responsable de calidad): "El considerando 128 y el artículo 25.1.c son claros: cambiar la finalidad prevista convierte al responsable del despliegue en proveedor. Si usamos la herramienta para algo distinto de lo que el proveedor declara en las instrucciones de uso, somos proveedores. Y el reentrenamiento con nuestros datos roza ese umbral."

La postura correcta depende de qué dice exactamente la documentación del proveedor sobre el uso previsto y de qué tan profundo sea el reentrenamiento. Lo que no es opinable es que la decisión tiene que quedar documentada antes del uso, no después de la inspección.

Ejemplo práctico: la herramienta de analítica que clasificamos mal

Contexto del cliente: Inmobiliaria Levante S.L., Valencia. Ingresos 28 millones de euros, 150 empleados, 12.000 clientes activos en base de datos. Promoción residencial en la Comunidad Valenciana. Auditoría del ejercicio 2025, primera auditoría obligatoria tras superar umbrales del artículo 263 de la Ley de Sociedades de Capital.

Sistema evaluado: Herramienta de analítica transaccional del proveedor "AuditIQ" (nombre ficticio) que identifica patrones atípicos en asientos del libro diario y emite una puntuación de riesgo por asiento.

Complicación que cambia la clasificación

A mitad del encargo, el equipo descubre que Inmobiliaria Levante usa un módulo adicional de AuditIQ, "HR Insights", que el cliente activó en enero 2025 para evaluar el desempeño de los 45 comerciales que gestionan las preventas. Este módulo no es parte del encargo de auditoría en sentido estricto, pero el auditor debe considerarlo al evaluar el entorno de control del cliente bajo NIA-ES 315.

Aquí la clasificación cambia. "HR Insights" cae en el Anexo III, punto 4, letra b: sistemas usados para evaluar el desempeño en el trabajo. Es sistema de alto riesgo. El cliente, como responsable del despliegue, tiene obligaciones del artículo 26 y posiblemente del artículo 27 (evaluación de impacto en los derechos fundamentales).

¿El auditor tiene que documentar esto? Sí, en dos sentidos: 1. Como factor de entorno de control (NIA-ES 315.25): el cumplimiento por parte del cliente del Reglamento (UE) 2024/1689 respecto a "HR Insights" es un control sobre el que el auditor puede necesitar obtener una comprensión, especialmente si las comisiones variables basadas en el sistema afectan al reconocimiento de ingresos. 2. Como riesgo de cumplimiento regulatorio (NIA-ES 250): si la dirección no ha realizado la evaluación de impacto del artículo 27, existe un riesgo de incumplimiento de disposiciones legales que puede afectar a los estados financieros vía sanciones potenciales.

Resultado del encargo: herramienta del auditor clasificada correctamente como no de alto riesgo, firma como responsable del despliegue, supervisión documentada. Sistema del cliente "HR Insights" identificado como punto de atención bajo NIA-ES 315 y NIA-ES 250, con procedimientos adicionales de indagación a la dirección.

Lo que pasa cuando no se hace esto: el expediente del año siguiente arrastra la herramienta como "ya clasificada", el nuevo equipo asume que el año anterior se hizo el análisis completo, y el módulo de alto riesgo del cliente pasa desapercibido hasta que AESIA lo detecta. Entonces el auditor tiene que explicar por qué, habiendo usado IA en el encargo, no identificó el sistema de alto riesgo del cliente que estaba delante de sus papeles de trabajo.

Lista de verificación operativa

Al inicio del encargo

1. Inventariar los sistemas de IA que el equipo va a usar, con versión, proveedor y finalidad declarada por el proveedor. 2. Aplicar la cadena analítica del Reglamento a cada sistema: artículo 3.1, artículo 5, Anexo III, artículo 50, rol de la firma según artículos 3.3 y 3.4 (más artículo 25). 3. Solicitar al proveedor la declaración UE de conformidad, las instrucciones de uso del artículo 13 y la documentación técnica del artículo 11 si procede. 4. Documentar las medidas de supervisión humana proporcionales al nivel de riesgo del sistema.

Durante el encargo

5. Identificar los sistemas de IA del cliente que puedan ser de alto riesgo bajo el Anexo III, como parte del entendimiento del entorno de control (NIA-ES 315). 6. Evaluar si el incumplimiento del cliente respecto al Reglamento genera riesgos de incumplimiento de disposiciones legales (NIA-ES 250) con efecto en los estados financieros. 7. Conservar los registros operativos generados por los sistemas usados en el encargo, durante el plazo del artículo 30 de la Ley 22/2015.

Al cerrar el expediente

8. Revisar que la cadena analítica quedó documentada para cada sistema, con conclusión motivada. 9. Verificar que la posición proveedor/responsable del despliegue quedó justificada frente al artículo 25. 10. Dejar constancia de la supervisión humana ejercida, con trazabilidad a los papeles de trabajo donde se aplicó.

Errores que aparecen en las inspecciones

• Clasificación por defecto sin cadena analítica. El expediente dice "sistema de riesgo mínimo" sin revisar el Anexo III punto por punto ni descartar expresamente el artículo 5 y el artículo 50. El ICAC va a pedir el análisis, no la conclusión.

• Asumir que el proveedor ya cumple. La responsabilidad del artículo 26 recae en el responsable del despliegue, no en el proveedor. Tener la declaración UE de conformidad del proveedor no exime al auditor de documentar su propia supervisión humana, el monitoreo del funcionamiento, ni la conservación de registros.

• Ignorar la frontera del artículo 25. Reentrenar el modelo con datos propios, cambiar la finalidad prevista declarada por el proveedor, o rebrandear la herramienta con la marca de la firma convierte al responsable del despliegue en proveedor. Si la firma no lo detecta, asume obligaciones del capítulo III sin tener los procesos para cumplirlas.

• No identificar sistemas de IA del cliente. El entendimiento del entorno de control bajo NIA-ES 315 incluye, desde 2025, los sistemas de IA de alto riesgo que el cliente opera. Saltar esta consideración es un defecto en la identificación del riesgo, no solo un tema regulatorio.

• Documentar al final del encargo. La clasificación, el análisis del rol y la evaluación de impacto del artículo 27 (cuando aplique) deben hacerse antes del uso, no al cerrar el expediente. Un análisis fechado el día de la entrega del informe es una reconstrucción, no un análisis.

Contenido relacionado

- Glosario: Sistema de Inteligencia Artificial - Definición técnica y criterios de clasificación según la Ley de IA de la UE - Herramienta: Evaluador de cumplimiento de IA - Determine el nivel de riesgo y los requisitos aplicables para sistemas de IA en auditoría - Artículo: Tecnología en auditoría y NIA-ES 315 - Cómo integrar herramientas automatizadas con los requisitos de identificación y evaluación de riesgos