Audit trail en IA: qué registros exige el AI Act y cómo implementarlos

Uno de los requisitos técnicos más concretos que el AI Act impone a los sistemas de IA de alto riesgo es la capacidad de registro automático: el sistema tiene que ser capaz de generar logs que permitan reconstruir su comportamiento después de que haya tomado o asistido una decisión.

No es un requisito abstracto: el AI Act especifica el tipo de información que debe registrarse. La fecha en la que se puede exigir es el 2 de diciembre de 2027 para los sistemas de alto riesgo del anexo III y el 2 de agosto de 2028 para la IA integrada en productos ya regulados, después del aplazamiento que introdujo el Reglamento (UE) 2026/1744 en julio de 2026. Esta guía explica qué hay que registrar, cómo y por cuánto tiempo.

Qué es el audit trail en sistemas de IA

Un audit trail es una secuencia cronológica de registros que documenta las entradas, el procesamiento y las salidas de un sistema a lo largo del tiempo. En sistemas convencionales existe desde hace décadas para fines de seguridad y cumplimiento. En sistemas de IA de alto riesgo, el AI Act lo convierte en obligatorio y especifica el contenido mínimo de esos registros.

El objetivo regulatorio es concreto: si un sistema de IA asiste en una decisión que afecta a una persona —por ejemplo, evalúa a un candidato, rechaza un crédito o recomienda un diagnóstico— debe ser posible reconstruir exactamente qué inputs recibió el sistema y qué outputs generó, de forma que pueda auditarse la decisión a posteriori.

Qué información exige registrar el AI Act

El reglamento no da una lista cerrada de campos, pero establece que los logs deben permitir:

• Identificar el período de operación del sistema
• Registrar los inputs (datos de entrada) que el sistema procesó para cada decisión o asistencia
• Registrar los outputs (salidas) del sistema para cada decisión
• Identificar las personas responsables de supervisar el sistema en cada operación
• Detectar y registrar situaciones de riesgo o anomalías operativas

En términos prácticos, esto implica registrar para cada inferencia relevante:

Campo	Descripción
timestamp	Fecha y hora exacta de cada operación
input_hash o input_id	Referencia a los datos de entrada (sin necesariamente guardar los datos crudos, por privacidad)
output	La decisión o recomendación generada
model_version	Versión del modelo que generó el output
confidence_score	Puntuación de confianza o probabilidad si aplica
human_override	Si hubo intervención humana para modificar o rechazar la salida
operator_id	Identificador del operador o supervisor humano
context_flags	Cualquier flag de anomalía o situación de riesgo detectada

Cuánto tiempo hay que conservar los registros

El AI Act establece que los registros deben conservarse durante un período mínimo de seis meses salvo disposición contraria de la legislación de la Unión o nacional aplicable (por ejemplo, si hay normativa sectorial —financiera, sanitaria, de protección de datos— que exija plazos distintos, prevalece la más restrictiva).

En la práctica, para muchos sistemas en sectores regulados como finanzas o salud, los plazos de conservación pueden ser significativamente mayores —2, 5 o incluso 10 años— por superposición con otras normativas.

Quién tiene acceso a los registros

Los logs del AI Act no son necesariamente públicos. El reglamento distingue entre:

• Las autoridades nacionales de supervisión: tienen derecho de acceso completo a los logs para auditorías e investigaciones
• El desplegador del sistema: debe poder acceder a los logs para gestionar el sistema y documentar el uso
• Las personas afectadas: tienen derecho a obtener información sobre la decisión que les afectó, pero no necesariamente acceso directo al log completo

Cómo implementar el audit trail en la práctica

Opción 1: Logging integrado en la inferencia

La opción más limpia arquitectónicamente es instrumentar el sistema de IA directamente en la capa de inferencia: cada llamada al modelo genera automáticamente una entrada en el log antes de devolver el output a la aplicación. Esto garantiza que el registro es completo y no puede omitirse por error.

Opción 2: Middleware de auditoría

Para sistemas donde modificar el código del modelo no es viable —por ejemplo, si usas modelos de terceros via API— se puede implementar un middleware que intercepta las llamadas al modelo, registra inputs y outputs, y los envía a un almacén de logs antes de devolver la respuesta al cliente.

Opción 3: Logging a nivel de aplicación

Si el sistema ya tiene una capa de aplicación que orquesta las llamadas al modelo, el logging puede implementarse allí. El riesgo de esta opción es que si la capa de aplicación cambia o hay errores, el logging puede ser incompleto.

Privacidad y logs: el conflicto con el RGPD

El mayor desafío técnico del audit trail en IA es la intersección con el RGPD. Los datos de entrada pueden contener datos personales —y el RGPD obliga a minimizarlos y a no retenerlos más de lo necesario.

Las soluciones más comunes para resolver este conflicto son:

• Pseudonimización: los inputs se guardan con un ID de referencia, no con los datos personales crudos. El dato personal queda en otro sistema separado que solo se cruza en caso de auditoría
• Hashing de inputs: se guarda el hash del input, no el input en sí, lo que permite verificar si un input específico fue procesado sin exponer el dato
• Separación de logs: el log de auditoría del AI Act y el log de datos personales son sistemas separados con accesos diferenciados

Qué pasa si el audit trail es incompleto o inexistente

La ausencia de registros adecuados en un sistema de alto riesgo constituye incumplimiento del AI Act, sancionable con multas de hasta 15 millones de euros o el 3% de la facturación global. Pero más allá de la multa, la imposibilidad de auditar una decisión puede generar responsabilidad civil adicional si esa decisión causó daño a una persona.

Diseñar para el audit trail desde el principio

La conclusión práctica es que el audit trail es significativamente más barato de implementar cuando se diseña desde el principio que cuando se intenta añadir a un sistema ya en producción. Retroadaptar logging a sistemas heredados puede ser complejo y costoso, especialmente si el modelo no fue instrumentado para ello.

Si estás desarrollando un sistema de IA que puede caer en la categoría de alto riesgo, el momento de diseñar el audit trail es durante el diseño de la arquitectura, no antes del go-live.

El aplazamiento a diciembre de 2027 es margen para hacerlo así, no para no hacerlo. Un sistema que entre en producción en 2026 sin trazabilidad llegará a la fecha con el problema más caro de resolver, no menos.

Cómo puede ayudarte Yeeply

En Yeeply trabajamos con empresas certificadas especializadas en arquitecturas de IA que ya incorporan los requisitos de logging y trazabilidad del AI Act en sus patrones de diseño. Si necesitas auditar un sistema existente o diseñar uno nuevo desde cero con cumplimiento integrado, podemos conectarte con el equipo técnico adecuado.

El audit trail es una pieza del expediente completo. Si quieres verlo entero, aquí explicamos cómo te ayudamos a cumplir el AI Act de principio a fin.

Usa el botón Pedir presupuesto en yeeply.com o escribe a sales@yeeply.com.