Qué son los logs en un sistema de IA
Un log es un registro de eventos producidos durante el funcionamiento de un sistema. Puede recoger fecha, hora, usuario, sistema, versión, operación, input, output, error e intervención humana.
Los logs permiten construir una secuencia: usuario → input → modelo → output → revisión humana → decisión. La trazabilidad aparece cuando esos registros pueden relacionarse de forma coherente para reconstruir qué ocurrió en un sistema de IA de alto riesgo.
Qué exige el artículo 12 del AI Act
El artículo 12 establece que los sistemas de IA de alto riesgo deben permitir técnicamente el registro automático de eventos durante la vida útil del sistema, con un nivel de trazabilidad adecuado a la finalidad prevista.
Las capacidades de logging deben permitir registrar eventos relevantes para:
- identificar situaciones que puedan provocar riesgos
- identificar situaciones relacionadas con una posible modificación sustancial
- facilitar la monitorización posterior a la comercialización
- permitir la supervisión del funcionamiento.
Los logs forman parte del diseño y se conectan con la documentación técnica. No deberían añadirse únicamente después de un incidente.
Para qué sirve la trazabilidad
Permite reconstruir qué ocurrió, cuándo, con qué versión y datos, quién intervino, qué resultado se produjo y qué decisión se tomó. Ayuda a investigar incidentes, revisar errores, analizar sesgos, comprobar controles, auditar, monitorizar rendimiento y construir evidencias.
La trazabilidad convierte eventos aislados en una historia comprensible.
Qué eventos conviene registrar
El AI Act no establece una lista universal idéntica para todos los sistemas. El nivel de logging debe adecuarse a finalidad, riesgo, arquitectura y contexto.
Puede incluir inicio y finalización, usuarios, sesiones, versiones, inputs, outputs, errores, excepciones, controles, decisiones, cambios e intervención humana.
El objetivo no es generar datos sin límite, sino capturar eventos relevantes según la gestión de riesgos.
Identidad, fecha, hora y versión
Un registro puede incluir timestamp, identificador del sistema, versión, modelo, configuración, usuario o rol y entorno. Esto permite saber qué estaba funcionando cuando ocurrió un evento.
Sin información de versión puede ser muy difícil reconstruir un incidente, especialmente cuando el sistema cambia con frecuencia.
Inputs, outputs y decisiones
En determinados sistemas puede ser necesario relacionar datos recibidos → resultado generado. Pero registrar inputs y outputs completos no siempre será necesario ni adecuado.
Según finalidad, riesgo, privacidad, volumen y sensibilidad, pueden utilizarse identificadores, hashes, referencias, metadatos o registros parciales. La estrategia debe equilibrar trazabilidad y minimización.
Supervisión humana y overrides
Puede registrarse revisión humana, aprobación, rechazo, override, escalado, parada y motivo: output → revisión → override → decisión final.
Esto permite demostrar que la supervisión humana funciona en la práctica y analizar patrones, como outputs revertidos con frecuencia.
Errores, excepciones e incidentes
Los logs ayudan a detectar errores, fallos, anomalías, excepciones, interrupciones y degradación. También permiten reconstruir qué ocurrió antes, qué hizo el sistema, qué usuario estaba activo, qué versión se utilizó y qué control falló.
La investigación mejora cuando existe trazabilidad previa.
Logs y monitorización posterior
El artículo 12 conecta expresamente los logs con la monitorización posterior a la comercialización. No sirven solo para investigar el pasado: pueden revelar aumento de errores, degradación, cambios de comportamiento, patrones inesperados y fallos de controles.
La monitorización puede utilizar los logs como fuente de datos.
Cómo diseñar una estrategia de logging
Paso 1. Definir finalidad
Determinar por qué se necesitan logs.
Paso 2. Identificar riesgos
Definir qué debe poder reconstruirse.
Paso 3. Definir eventos
Especificar qué debe registrarse.
Paso 4. Definir metadatos
Incluir tiempo, sistema, versión y usuario cuando corresponda.
Paso 5. Definir acceso
Determinar quién puede consultar los registros.
Paso 6. Definir protección
Evitar alteraciones, pérdida y accesos indebidos.
Paso 7. Definir conservación
Establecer durante cuánto tiempo se mantendrán.
Paso 8. Integrar monitorización
Definir qué indicadores utilizan los logs.
Paso 9. Probar
Seleccionar una operación y comprobar: ¿podemos reconstruirla? Debe repetirse tras cambios relevantes mediante la gestión del cambio.

Cómo utilizar los logs para demostrar trazabilidad
Los logs generan valor cuando conectan sistema → versión → input → output → control → supervisión → decisión → evidencia.
No todos los procesos necesitarán el mismo detalle, pero esta lógica conecta comportamiento técnico con gobierno y permite comprender qué ocurrió, qué control actuó y quién tomó la decisión final. Un registro e inventario práctico facilita esa conexión.
Cuánto tiempo deben conservarse
El artículo 19 establece obligaciones de conservación para proveedores de sistemas de IA de alto riesgo respecto de los logs automáticamente generados bajo su control.
El periodo debe ser adecuado a la finalidad prevista y, como regla general, de al menos seis meses. Los responsables del despliegue también deben conservar los logs automáticamente generados bajo su control durante un periodo adecuado y, como regla general, de al menos seis meses.
Otra legislación de la Unión o nacional puede establecer una duración diferente, especialmente en protección de datos. Seis meses es un mínimo general, no una regla absoluta aislada del resto de la legislación.
Logs, privacidad y minimización de datos
Más logging no siempre significa mejor gobierno. Los registros pueden contener datos personales, información sensible o confidencial.
La estrategia debe considerar minimización, finalidad, acceso, seguridad, conservación y eliminación. No debería registrarse información innecesaria solo porque sea técnicamente posible.
La trazabilidad debe ser suficiente, no ilimitada.
Cómo integrar logs con evidencias y auditoría
Los logs pueden demostrar uso real, revisión, intervención, versión, ejecución de controles, incidencias y escalados. Apoyan auditorías, investigaciones, revisiones internas y monitorización.
Pero no sustituyen políticas, evaluaciones, decisiones, contratos, documentación técnica o formación. Funcionan mejor cuando esas fuentes son coherentes dentro de un framework de gobierno de IA.
Errores habituales
Registrar demasiado
Genera volumen sin utilidad.
Registrar demasiado poco
Impide reconstruir decisiones.
No registrar versiones
Dificulta investigar cambios.
No proteger los logs
Los registros necesitan controles de integridad y acceso.
No relacionarlos con supervisión humana
Se pierde trazabilidad de decisiones.
Conservarlos indefinidamente
Puede crear riesgos innecesarios.
No revisar los registros
Tener logs que nadie utiliza aporta poco valor.
Confundir logs con documentación técnica
Están relacionados, pero son piezas distintas.
La trazabilidad permite convertir una decisión en una historia verificable
Cuando un sistema produce un resultado importante, la organización debería poder responder qué ocurrió, cuándo, con qué versión y datos, qué resultado produjo, quién intervino y qué decisión se tomó.
Los logs conectan evento → sistema → decisión → evidencia → responsabilidad. El objetivo no es registrar todo, sino reconstruir lo importante.
Referencias
- Regulation (EU) 2024/1689 — Artificial Intelligence Act.
- Article 12 — Record-keeping.
- Article 19 — Automatically generated logs.
- Article 26 — Obligations of deployers of high-risk AI systems.
- Article 72 — Post-market monitoring by providers and post-market monitoring plan.
- Annex IV — Technical documentation.
¿Podrías reconstruir hoy una decisión tomada por tu sistema de IA?
La trazabilidad depende de que logs, versiones, controles, supervisión y evidencias estén conectados.
Realizar diagnóstico →
El diagnóstico de Céntrika puede ayudarte a identificar qué elementos ya existen y dónde siguen existiendo brechas.
