Alguien pregunta en la reunión cuánto tiempo hay que guardar los registros del agente, y la respuesta que sale es siempre la misma: «lo que diga la norma». El problema es que son dos normas, y dicen cosas que suenan contrarias. Una te pide conservar. La otra te pide no conservar más de la cuenta. Y quien fija el plazo en la práctica suele ser un administrador de sistemas con una regla de rotación a treinta días que puso por el almacenamiento.
La tesis en una frase: cuánto tiempo guardar los logs de un agente de IA no es una cuestión jurídica sino de diseño. El choque entre el AI Act y el RGPD es menor de lo que parece, porque el propio AI Act cede ante la protección de datos; y es mayor de lo que te conviene, porque un log normal mezcla dos cosas con vidas distintas —la traza de la decisión, que conviene conservar, y el contenido con datos personales, que conviene purgar— y las guarda juntas durante el mismo tiempo.
Cuánto tiempo guardar los logs de un agente de IA: un suelo y un techo que no se miden igual
Empecemos por lo que dice cada texto, porque el debate suele ir sin leerlos. El AI Act obliga a conservar los registros que genera automáticamente un sistema de alto riesgo durante un período adecuado a su finalidad y como mínimo de seis meses, salvo que otra norma de la Unión o nacional disponga otra cosa. Lo dice el artículo 26.6 para quien despliega el sistema y el artículo 19 para quien lo proporciona, y en ambos casos solo en la medida en que esos registros estén bajo su control.
El RGPD no da una cifra, y esa es su gracia. Pide que los datos personales sean adecuados, pertinentes y limitados a lo necesario para su finalidad (artículo 5.1.c) y que se conserven de forma que permita identificar a las personas no más tiempo del necesario para esa finalidad (artículo 5.1.e), según el texto del artículo 5. No hay un número de días. Hay una pregunta —¿para qué lo guardas?— y la obligación de poder contestarla.
| Texto | Qué fija | Para quién | Cuándo aplica |
|---|---|---|---|
| AI Act, art. 26.6 | Conservar los registros automáticos al menos seis meses, o más si lo exige la finalidad u otra norma | Quien despliega un sistema de alto riesgo | Alto riesgo del Anexo III desde el 2 de diciembre de 2027; los integrados en productos regulados, desde agosto de 2028 |
| AI Act, art. 19 | Lo mismo, para los registros que controla el proveedor | Quien proporciona el sistema | Mismas fechas |
| RGPD, art. 5.1.e | No conservar datos identificables más tiempo del necesario para la finalidad | Cualquiera que trate datos personales | Hoy |
| RGPD, art. 5.1.c | Guardar solo lo adecuado, pertinente y limitado a lo necesario | Cualquiera que trate datos personales | Hoy |
Dos aclaraciones que cambian el planteamiento. La primera: el suelo del AI Act solo existe para sistemas de alto riesgo, y la mayoría de los agentes de una pyme —atender consultas, preparar documentos, mover datos entre sistemas— no lo son. Para esos no hay mínimo legal de seis meses: manda tu finalidad y manda el techo. La segunda: las fechas se han movido, y el calendario lo contamos en el AI Act se aplazó, pero tu chatbot sigue teniendo que avisar. Ámbito de todo lo anterior: Unión Europea.
¿Chocan de verdad el AI Act y el RGPD? Menos de lo que parece, y más de lo que te conviene
Menos, porque el artículo 26.6 lleva dentro su propia cláusula de escape: los seis meses valen «salvo que otra norma de la Unión o nacional disponga otra cosa», y el período debe ser el adecuado a la finalidad prevista. Una lectura prudente es que el AI Act no te autoriza a conservar datos personales por encima de lo que el RGPD permite: lo que guardes tiene que seguir teniendo una finalidad que lo justifique. El suelo no es una licencia.
Más, porque en la práctica nadie guarda «una traza»; guarda un volcado. El log típico de un agente contiene el mensaje completo del cliente, la respuesta íntegra, los adjuntos que el agente abrió y el fragmento del CRM que consultó. Eso es dato personal casi siempre. Si lo conservas seis meses «por el AI Act» sin haberte preguntado para qué, has leído el suelo como si fuera un permiso y te has quedado expuesto por arriba. Y si lo purgas a los treinta días porque el disco se llenaba, en un sistema de alto riesgo te has quedado por debajo del suelo. Las dos reglas se incumplen con la misma configuración por defecto.
La traza de la decisión y el contenido tienen vidas distintas
La salida al dilema no es elegir entre seis meses y treinta días: es dejar de tratar el log como una sola cosa. Hay dos objetos con necesidades distintas, y juntarlos es lo que fabrica el falso dilema.
| Qué guardas | Ejemplo | ¿Lleva datos personales? | Cuánto tiempo |
|---|---|---|---|
| Traza de la decisión | Identificador del caso, marca de tiempo, versión del modelo, versión de las instrucciones, herramientas invocadas, decisión tomada, quién la revisó o la anuló | Lo mínimo posible: identificadores internos, nunca el texto | El plazo que fije tu finalidad y, si el sistema es de alto riesgo, nunca menos del suelo |
| Contenido | Mensaje completo del cliente, respuesta íntegra, adjuntos, datos extraídos de los sistemas | Sí, casi siempre | El mínimo que tu finalidad justifique, con purga programada |
| Referencia | Puntero al registro original en el CRM o el ERP, en vez de una copia | No hay copia: el dato vive donde ya está gobernado | Mientras exista el registro de origen |
La traza es lo que hace falta para responder a la pregunta que importa meses después: qué decidió el sistema, con qué versión y quién lo supervisó. No necesita el texto del cliente para eso; necesita que cada decisión pueda reconstruirse y atribuirse. Es el mismo registro que describimos al hablar de trazabilidad de decisiones de IA, y es la parte de la observabilidad de agentes con herramientas abiertas que más tiempo tiene que vivir.
El contenido es lo que caduca. Se guarda el tiempo que haga falta para depurar, revisar una reclamación o cumplir una obligación concreta, y después se purga o se reduce. Y una trampa que conviene tener clara: seudonimizar no es anonimizar. Si sustituyes el nombre por un identificador pero conservas la tabla que lo une, el dato sigue siendo personal a efectos del RGPD. Sirve para reducir riesgo, no para saltarte el techo. Lo que contamos en IA y RGPD: lo que tu proveedor no cuenta sobre dónde acaban los datos vale aquí tal cual.
Cuatro preguntas para fijar el plazo antes de que lo fije el disco
- ¿Tu sistema es de alto riesgo? Si no figura en el Anexo III ni va integrado en un producto regulado, no hay suelo del AI Act: manda la finalidad. Si lo es, el suelo son seis meses y la parte difícil es lo que metas dentro. Para clasificarlo con criterio tienes qué te obliga según seas proveedor o responsable del despliegue.
- ¿Cuánto tarda en aparecer un problema en tu negocio? Una reclamación de cliente, un error de facturación o una discrepancia con un proveedor no salen a los treinta días. El plazo de la traza se calibra contra eso, no contra el tamaño del almacenamiento.
- ¿Qué otra norma te fija plazos? Fiscal, laboral, sectorial. El propio artículo 26.6 prevé que las entidades financieras conserven los registros dentro de la documentación que ya les exige su normativa. Si alguien más ya fijó un plazo, ese plazo cuenta.
- ¿Qué parte del log es traza y cuál es contenido? Si no sabes responder, el primer entregable es separarlos. Todo lo demás depende de eso.
Fíjate en que ninguna de las cuatro se resuelve con una herramienta. Se resuelven con una decisión escrita: qué plazo, para qué y quién puede cambiarlo.
Cuándo NO te sirve esta separación
Cuatro situaciones en las que separar traza y contenido no basta, o directamente estorba:
- Necesitas el texto íntegro para defender una decisión impugnada. Si un cliente reclama por una denegación, quizá haga falta reproducir exactamente lo que el sistema vio. Entonces conservas el contenido de ese caso, con acceso restringido y plazo propio, no el de todo el flujo.
- El proveedor guarda los registros y tú no los controlas. Los dos artículos del AI Act condicionan la obligación a que los registros estén bajo tu control. Si no lo están, el plazo lo fija el contrato, y por eso hay que pedirlo por escrito antes de firmar.
- El agente trata categorías especiales de datos. Salud, afiliación sindical, biometría. El listón de justificación sube y la conversación con tu delegado de protección de datos deja de ser opcional.
- Crees que una regla de ciclo de vida del almacenamiento lo resuelve. Borra por fecha, no por caso. Cuando hay una reclamación abierta necesitas poder congelar justo esos registros, y una purga automática ciega no sabe que existe.
Qué hacer esta semana
- Pregunta, para cada agente, dónde se guardan los registros, quién puede leerlos y cuándo se borran. Si la respuesta es «no lo sé», ya tienes el primer hallazgo. Quién puede leerlos es, además, una decisión de acceso, la que desarrollamos en qué permisos dar a un agente de IA.
- Parte el registro en traza y contenido, aunque sea en dos tablas de la misma base.
- Escribe un plazo para cada una y, al lado, el motivo. Un plazo sin motivo es el que te cuestionarán.
- Programa la purga del contenido y define la excepción para los casos abiertos.
- Apunta quién puede cambiar el plazo, y que sea un nombre, no un equipo.
Ese conjunto es la parte de logs de gobernanza y control de la automatización con IA, la guía donde se cuenta junto a permisos, rollback y auditoría. Y si lo que quieres es llegar a 2027 con el expediente ya construido en lugar de reconstruirlo en pánico, lo que montamos es cumplir el AI Act operando tu IA.
La frase para la próxima reunión
Cuando alguien pregunte cuánto tiempo hay que guardar los logs, la respuesta útil no es un número. Es: ¿hablas de la traza o del contenido? Con la traza, el problema es no perderla; con el contenido, no guardarlo de más. Y la configuración por defecto de casi cualquier sistema falla las dos a la vez.