Análisis jurídico completo para empresas y administraciones públicas. La guía oficial de la AESIA más el criterio de iusia para el asesoramiento práctico.
El artículo 12 del AI Act establece la obligación de que los sistemas de alto riesgo generen registros automáticos de su funcionamiento — los denominados logs. El artículo 26.6 establece la obligación del desplegador de conservar esos logs durante un período mínimo de seis meses. Estas dos disposiciones conforman el sistema de trazabilidad jurídica del AI Act: la capacidad de reconstruir a posteriori qué hizo el sistema, cuándo, con qué datos y con qué resultado.
La Guía 12, con 33 páginas, analiza en detalle el contenido mínimo de los logs que el art. 12 exige, las obligaciones de conservación del art. 26.6, el acceso de las autoridades supervisoras a los logs, y la intersección con las obligaciones de protección de datos del RGPD cuando los logs contienen datos personales.
El propósito de los logs del AI Act es múltiple. En primer lugar, permiten a las autoridades supervisoras verificar a posteriori si el sistema ha funcionado conforme a sus especificaciones y a los requisitos del Reglamento. En segundo lugar, permiten al desplegador demostrar que ha cumplido con su obligación de supervisión humana del art. 14 — si hay registros de cada revisión humana, la supervisión puede probarse. En tercer lugar, los logs son evidencia crucial en caso de reclamaciones de personas afectadas por las decisiones del sistema — permiten reconstruir exactamente qué información usó el sistema para tomar o influir en una decisión específica.
El artículo 12.2 establece que los logs deben registrar, como mínimo, ciertos elementos que permitan la trazabilidad completa de cada uso del sistema. La guía organiza estos elementos en cuatro categorías.
La primera categoría es la información temporal: el período de activación del sistema en cada uso, con la fecha y hora exactas de inicio y fin de cada sesión de uso o de cada consulta individual, según la naturaleza del sistema. Esta información permite verificar cuándo se ha usado el sistema y con qué frecuencia.
La segunda categoría es la información sobre los datos de entrada: la identificación o la referencia a los datos de entrada que el sistema ha procesado en cada uso. Para sistemas que procesan documentos o imágenes, el log debe incluir la referencia al documento o imagen procesada. Para sistemas que procesan datos estructurados, el log debe incluir los valores de los campos relevantes o una referencia al registro de la base de datos procesado.
La tercera categoría es la información sobre los outputs: el resultado generado por el sistema, incluyendo el nivel de confianza o la puntuación asociada al output cuando el sistema produce este tipo de información. Para sistemas de clasificación, el log debe incluir la categoría asignada y la puntuación de confianza. Para sistemas de puntuación, debe incluir el valor de la puntuación y el umbral que determina la acción a tomar.
La cuarta categoría es la información sobre la supervisión humana: la identidad de las personas físicas que han verificado los resultados del sistema, cuándo realizaron la verificación, y si confirmaron o modificaron el output del sistema. Esta información es la que permite demostrar que la supervisión humana del art. 14 se ha ejercido efectivamente.
El artículo 26.6 establece que el desplegador conservará los logs generados automáticamente por los sistemas de alto riesgo, en la medida en que dichos registros estén bajo su control, durante un período apropiado de seis meses como mínimo, salvo que se disponga algo diferente en el derecho de la Unión o nacional aplicable, o en los acuerdos contractuales celebrados con el proveedor.
La guía destaca que el período de seis meses es un mínimo legal que puede ampliarse por tres vías. La primera es la normativa sectorial: en sectores como la banca, los seguros, la sanidad o los recursos humanos, la normativa sectorial puede imponer períodos de conservación de documentos y registros más largos que el mínimo del AI Act. Por ejemplo, la normativa bancaria española exige conservar determinados registros de operaciones durante diez años. Si los logs del sistema de scoring crediticio contienen información sobre operaciones, el período de conservación aplicable es el más largo.
La segunda vía es el derecho nacional: la futura ley española de buen uso y gobernanza de la IA o normas sectoriales posteriores pueden establecer períodos de conservación más largos para determinados tipos de sistemas o sectores. La guía recomienda revisar la normativa sectorial aplicable en cada caso antes de definir la política de conservación de logs.
La tercera vía son los acuerdos contractuales con el proveedor: el contrato entre proveedor y desplegador puede establecer períodos de conservación más largos que el mínimo legal, por ejemplo si el proveedor necesita acceder a los logs para la vigilancia poscomercialización del sistema.
La obligación de conservación del art. 26.6 recae expresamente sobre el desplegador, no sobre el proveedor. Sin embargo, en muchos modelos de despliegue — especialmente los sistemas de software como servicio (SaaS) — los logs se generan en la infraestructura del proveedor y el desplegador no tiene acceso directo a ellos. La guía analiza esta situación práctica y ofrece orientación sobre cómo resolverla.
La solución recomendada es que el contrato entre proveedor y desplegador incluya cláusulas específicas sobre los logs: el proveedor se compromete a conservar los logs durante el período mínimo exigido por el art. 26.6 (o el período más largo que aplique), a proporcionar al desplegador acceso a esos logs cuando lo solicite, y a notificar al desplegador con suficiente antelación antes de eliminar logs que el desplegador tenga obligación legal de conservar.
Cuando el proveedor es quien conserva los logs, la guía recomienda que el contrato establezca también el mecanismo para que el desplegador pueda cumplir con sus obligaciones de proporcionar logs a las autoridades supervisoras si estas los solicitan: el desplegador debe poder obtener los logs del proveedor en el plazo en que las autoridades los soliciten.
Los logs son el principal instrumento de verificación que las autoridades supervisoras — la AESIA y, en su caso, la AEPD — utilizarán en los procedimientos de inspección e investigación. El art. 74 del AI Act establece que las autoridades de vigilancia del mercado tienen poderes para acceder a los datos generados y almacenados por los sistemas de IA de alto riesgo, incluyendo los logs.
La guía orienta sobre cómo prepararse para una eventual solicitud de logs por parte de las autoridades supervisoras. El sistema de logs debe estar diseñado desde el inicio para que los registros sean exportables en formatos estándar y comprensibles sin necesidad de conocimiento técnico avanzado. La estructura del log debe ser autodocumentada — cada campo debe tener un nombre y una descripción que permitan entender su significado sin necesidad de acceder a documentación técnica adicional.
El desplegador tiene el derecho de ser informado de la solicitud de logs por parte de las autoridades antes de su transmisión, salvo en situaciones de urgencia, y puede solicitar la confidencialidad de cierta información comercialmente sensible contenida en los logs, siempre que esa confidencialidad sea compatible con los objetivos de la inspección. La guía recomienda consultar con el departamento jurídico antes de responder a cualquier solicitud de logs de las autoridades supervisoras.
Cuando los logs contienen datos personales — lo que es prácticamente inevitable cuando el sistema procesa datos de personas físicas — el RGPD se aplica simultáneamente al AI Act. Esta superposición genera una tensión entre dos obligaciones: la obligación de conservar los logs durante al menos seis meses conforme al AI Act, y el principio de limitación del plazo de conservación del art. 5.1.e RGPD, que exige que los datos personales no se conserven más tiempo del necesario para los fines para los que se tratan.
La guía proporciona un marco para resolver esta tensión. El tratamiento de datos personales en los logs para la finalidad de cumplimiento del art. 12 AI Act y de facilitar la vigilancia supervisora puede justificarse bajo el art. 6.1.c RGPD (cumplimiento de una obligación legal) durante el período mínimo que establece el AI Act. La clave es que los logs deben contener solo los datos personales mínimos necesarios para los fines de trazabilidad del sistema — no deben ser registros exhaustivos de toda la información disponible sobre cada persona procesada.
La guía recomienda revisar el diseño de los logs con el DPO antes de su implementación para garantizar que el contenido de los logs cumple con el principio de minimización del RGPD mientras satisface los requisitos de trazabilidad del AI Act. En algunos casos, puede ser posible implementar técnicas de seudonimización o de separación de los logs que preserven la trazabilidad del comportamiento del sistema sin conservar los datos personales identificativos durante todo el período de retención.
Los sistemas de logs para el cumplimiento del art. 12 del AI Act deben diseñarse con características técnicas específicas que van más allá de los sistemas de logging convencionales. La guía describe las características técnicas que los logs del AI Act deben tener para ser válidos como evidencia ante las autoridades supervisoras.
La inmutabilidad de los registros es la primera característica fundamental: una vez generado un log, no debe ser posible modificarlo sin dejar un rastro detectable de la modificación. Los sistemas de logs con inmutabilidad garantizada pueden implementarse usando técnicas de timestamping criptográfico, blockchain privado para el sellado de logs, o sistemas de storage con Write Once Read Many (WORM). La inmutabilidad es especialmente importante para que los logs sean válidos como prueba en procedimientos sancionadores o judiciales.
La integridad del log es la segunda característica: el sistema debe garantizar que todos los eventos que deben registrarse se registran efectivamente, sin omisiones. Un sistema de logging que ocasionalmente pierde eventos — por problemas de rendimiento, de conectividad o de configuración — no proporciona una trazabilidad completa y puede dar lugar a gaps en la evidencia. La guía recomienda implementar mecanismos de verificación periódica de la completitud de los logs — por ejemplo, comparando el número de transacciones registradas por el sistema de IA con el número de entries en el sistema de logs.
La estructura estandarizada de los logs es la tercera característica: los campos y el formato de los logs deben estar definidos y documentados de forma que sean interpretables sin necesidad de acceso al código fuente del sistema. La guía recomienda usar estándares abiertos de logging — como el formato W3C Extended Log File Format o el formato CEF (Common Event Format) — y documentar el significado de cada campo en el Manual del SGC.
Cuando el sistema de IA afecta a trabajadores — sistemas de evaluación del rendimiento, de asignación de tareas, de control de presencia — los logs generan datos personales de los trabajadores que están sujetos tanto al art. 12 del AI Act como al artículo 22 de la LOPDGDD sobre los derechos digitales en el ámbito laboral. El art. 22 LOPDGDD exige que los empleadores informen a los trabajadores de los sistemas de control implementados con anterioridad a su implantación.
La guía recomienda que el protocolo de información a los trabajadores sobre el sistema de IA incluya información específica sobre los logs que el sistema genera: qué datos de los trabajadores se registran, con qué frecuencia, durante cuánto tiempo se conservan, quién tiene acceso a ellos, y para qué finalidades pueden usarse. Esta información debe proporcionarse en un lenguaje comprensible para los trabajadores, no en términos técnicos.
La AEPD ha establecido en resoluciones anteriores que el uso de datos de los trabajadores registrados en sistemas de control para finalidades disciplinarias requiere que los trabajadores hayan sido informados de esta posibilidad con carácter previo. El mismo principio aplica a los logs de sistemas de IA: los logs sobre el rendimiento o el comportamiento de los trabajadores no pueden usarse en procedimientos disciplinarios si los trabajadores no fueron informados de que esos datos se registraban y podían tener esa finalidad.
Los sistemas de IA de alto riesgo complejos frecuentemente operan sobre arquitecturas distribuidas — múltiples microservicios, múltiples proveedores cloud, sistemas en la nube y on-premise combinados. En estas arquitecturas, los logs se generan en múltiples puntos y deben consolidarse en un sistema centralizado de gestión de logs (SIEM) para poder ofrecer la trazabilidad completa que el art. 12 exige.
La guía establece que la responsabilidad de consolidar los logs en un sistema único y coherente recae sobre el desplegador, con independencia de la complejidad de la arquitectura técnica del sistema. Si el sistema usa múltiples proveedores y los logs están fragmentados entre distintos sistemas, el desplegador debe implementar los mecanismos técnicos necesarios para consolidarlos y garantizar que la trazabilidad completa de cada transacción del sistema de IA pueda reconstruirse a partir de los logs consolidados.
Los sistemas de logs para el cumplimiento del art. 12 del AI Act deben diseñarse con características técnicas específicas que van más allá de los sistemas de logging convencionales. La guía describe las características técnicas que los logs del AI Act deben tener para ser válidos como evidencia ante las autoridades supervisoras.
La inmutabilidad de los registros es la primera característica fundamental: una vez generado un log, no debe ser posible modificarlo sin dejar un rastro detectable de la modificación. Los sistemas de logs con inmutabilidad garantizada pueden implementarse usando técnicas de timestamping criptográfico, blockchain privado para el sellado de logs, o sistemas de storage con Write Once Read Many (WORM). La inmutabilidad es especialmente importante para que los logs sean válidos como prueba en procedimientos sancionadores o judiciales.
La integridad del log es la segunda característica: el sistema debe garantizar que todos los eventos que deben registrarse se registran efectivamente, sin omisiones. Un sistema de logging que ocasionalmente pierde eventos — por problemas de rendimiento, de conectividad o de configuración — no proporciona una trazabilidad completa y puede dar lugar a gaps en la evidencia. La guía recomienda implementar mecanismos de verificación periódica de la completitud de los logs — por ejemplo, comparando el número de transacciones registradas por el sistema de IA con el número de entries en el sistema de logs.
La estructura estandarizada de los logs es la tercera característica: los campos y el formato de los logs deben estar definidos y documentados de forma que sean interpretables sin necesidad de acceso al código fuente del sistema. La guía recomienda usar estándares abiertos de logging — como el formato W3C Extended Log File Format o el formato CEF (Common Event Format) — y documentar el significado de cada campo en el Manual del SGC.
Cuando el sistema de IA afecta a trabajadores — sistemas de evaluación del rendimiento, de asignación de tareas, de control de presencia — los logs generan datos personales de los trabajadores que están sujetos tanto al art. 12 del AI Act como al artículo 22 de la LOPDGDD sobre los derechos digitales en el ámbito laboral. El art. 22 LOPDGDD exige que los empleadores informen a los trabajadores de los sistemas de control implementados con anterioridad a su implantación.
La guía recomienda que el protocolo de información a los trabajadores sobre el sistema de IA incluya información específica sobre los logs que el sistema genera: qué datos de los trabajadores se registran, con qué frecuencia, durante cuánto tiempo se conservan, quién tiene acceso a ellos, y para qué finalidades pueden usarse. Esta información debe proporcionarse en un lenguaje comprensible para los trabajadores, no en términos técnicos.
La AEPD ha establecido en resoluciones anteriores que el uso de datos de los trabajadores registrados en sistemas de control para finalidades disciplinarias requiere que los trabajadores hayan sido informados de esta posibilidad con carácter previo. El mismo principio aplica a los logs de sistemas de IA: los logs sobre el rendimiento o el comportamiento de los trabajadores no pueden usarse en procedimientos disciplinarios si los trabajadores no fueron informados de que esos datos se registraban y podían tener esa finalidad.
Los sistemas de IA de alto riesgo complejos frecuentemente operan sobre arquitecturas distribuidas — múltiples microservicios, múltiples proveedores cloud, sistemas en la nube y on-premise combinados. En estas arquitecturas, los logs se generan en múltiples puntos y deben consolidarse en un sistema centralizado de gestión de logs (SIEM) para poder ofrecer la trazabilidad completa que el art. 12 exige.
La guía establece que la responsabilidad de consolidar los logs en un sistema único y coherente recae sobre el desplegador, con independencia de la complejidad de la arquitectura técnica del sistema. Si el sistema usa múltiples proveedores y los logs están fragmentados entre distintos sistemas, el desplegador debe implementar los mecanismos técnicos necesarios para consolidarlos y garantizar que la trazabilidad completa de cada transacción del sistema de IA pueda reconstruirse a partir de los logs consolidados.
Más recursos: calendario del AI Act tras el Ómnibus Digital · análisis del AI Act en 2026 · servicios para administraciones públicas (LexQuark).
Newsletter gratuita · Empresas y administraciones públicas · En español