Keep the logs, says the EU AI Act; delete personal data once it is no longer needed, says GDPR. For AI agents, the two meet in the action record. Separate the event from the content: keep a lean record of what the agent did and why, and keep personal detail only as long as each purpose needs.
What do the two rules require?
EU AI Act. Article 12 requires high-risk systems to record events automatically over their lifetime. Article 26 requires deployers to keep the logs under their control for a period appropriate to the system's intended purpose, with a minimum set in the Act, unless other EU or national law, in particular data protection law, provides otherwise. Financial institutions can keep them within the records they already maintain under financial services law.
GDPR. Article 5 sets the storage limitation principle: personal data must be kept in a form that permits identification of people for no longer than necessary for the purposes it is processed for. Data minimisation, in the same article, says it must be adequate, relevant and limited to what is necessary. Article 6 requires a lawful basis for keeping it; a legal obligation to retain is one.
Read together, the Act supplies a reason to keep logs, and GDPR requires that reason to justify each item kept and for how long. They do not conflict head-on. The Act's own wording defers to data protection law.
Who has to reconcile them?
The deployer, as controller of the personal data in its logs. If you are also the provider, you design the logs as well. Our explainer on who is the provider and who is the deployer of an AI agent helps settle which hat you wear.
The tension also reaches non-EU firms whose agents serve EU customers. Both the Act and GDPR have extraterritorial reach, as noted in whether the EU AI Act applies to companies outside the EU.
Why is the tension sharper for agents?
A scoring model's log is small: input features, score, timestamp. An agent's log, if kept naively, is the whole working session: every message, every document it read, every tool call with full parameters, and every draft. That can include bank statements, medical notes, identity documents and the content of other people's emails.
Three features of agents make it worse:
- Breadth. An agent reads widely to do its job. Logging everything it read copies that breadth into the log.
- Duplication. The same document is logged on every run that reads it, multiplying copies of personal data.
- Memory. Some agents keep summaries across sessions. Those summaries are personal data with their own retention problem, covered in GDPR storage limitation and AI agent memory.
The audit value of an agent log sits in the events: what was attempted, what was decided, by which rule, approved by whom. Very little of it sits in raw content.
How do you design logs that serve both?
| Requirement | Control | Evidence it leaves |
|---|---|---|
| Automatic recording of events (Act) | Event record per action: agent, capability, verdict, deciding bound, approver, time | Complete event stream |
| Reconstruct what was relied on (Act) | Event record holds references and hashes of sources, not copies | Source references resolvable while the source exists |
| Keep logs for the required period (Act) | Event record retained for the Act's period or longer where sector law requires | Retention schedule with legal basis per record type |
| Storage limitation (GDPR) | Raw content, such as message text and document copies, kept on a shorter schedule | Deletion jobs and their run history |
| Data minimisation (GDPR) | Personal identifiers in the event record replaced by pseudonymous keys | Key management records; access controls on the key store |
| Lawful basis (GDPR) | Retention basis recorded per record type: legal obligation, legitimate interests | Entry in the record of processing |
| Integrity (both) | Append-only event store; deletion of content does not break the event chain | Tamper-evidence checks |
The pattern is tiered retention. The event record is small, pseudonymised and long-lived. The content tier is large, identifiable and short-lived. Deleting content leaves the event chain intact, so you can still show that an action was held and approved by a named person long after the customer's message text is gone.
This design also eases subject access and erasure requests, because personal content sits in one known place. For the logging side in more detail, see EU AI Act Article 12 record-keeping.
What will a supervisor or auditor ask?
- How long do you keep agent logs, and what is the basis for each period?
- What personal data is in the long-lived record, and why is each item needed?
- If a customer asks for erasure, what happens to the logs?
- Can you still reconstruct a decision after content has been deleted?
- Who can re-identify a pseudonymised record, and how is that controlled?
Data protection authorities and AI supervisors may ask these from opposite directions. The same design should answer both.
What do the rules not settle?
The Act does not say what an agent's log must contain beyond its purposes, so the content choice is yours. GDPR does not fix retention periods; you set them and justify them. Neither settles conflicts with sector record-keeping rules, which may require longer retention for financial records. And neither decides where logs may be stored, which raises transfer questions. The full map is in AI agent regulation, mapped to controls.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
Where Pryme fits
Pryme files every verdict in an append-only record that names the agent, the capability, the bound that decided and the person who approved. Facts arrive through the Pryme Context Protocol with their origin attached, so the record can reference a sealed ledger entry rather than copying it. That keeps the long-lived record lean.
Questions people ask
Does the AI Act override GDPR on retention?
No. The Act's log retention duty expressly gives way where data protection law provides otherwise. Treat the Act as a reason to keep certain records, which GDPR then requires you to justify and limit.
Can we anonymise agent logs instead of deleting them?
Truly anonymised data falls outside GDPR. But agent logs are hard to anonymise fully, because context can re-identify people. Pseudonymisation is more realistic, and pseudonymised data is still personal data.
Should failed or refused actions be kept as long as allowed ones?
Yes, in the event tier. Refusals show controls working and are often what an auditor asks for. Their content can follow the same shorter schedule as any other.