Somebody in the meeting asks how long the agent's records have to be kept, and the answer is always the same: “whatever the rules say”. The catch is that there are two sets of rules, and they sound like opposites. One tells you to keep. The other tells you not to keep more than you need. And whoever actually sets the period is usually a sysadmin with a thirty-day rotation rule they put in for storage reasons.
The thesis in one line: how long to keep AI agent logs is not a legal question, it is a design one. The clash between the AI Act and the GDPR is smaller than it looks, because the AI Act itself yields to data protection; and it is bigger than you would like, because a normal log mixes two things with different lifespans — the decision trail, which you want to keep, and the content with personal data, which you want to purge — and stores them together for the same length of time.
How long to keep AI agent logs: a floor and a ceiling that are not measured the same way
Start with what each text actually says, because the debate usually runs without reading them. The AI Act requires logs automatically generated by a high-risk system to be kept for a period appropriate to its purpose and for at least six months, unless other Union or national law provides otherwise. Article 26(6) says it for whoever deploys the system and Article 19 for whoever provides it, and in both cases only to the extent the logs are under their control.
The GDPR gives no number, which is its whole point. It asks that personal data be adequate, relevant and limited to what is necessary for the purpose (Article 5(1)(c)) and kept in a form that identifies people for no longer than necessary for that purpose (Article 5(1)(e)), per the text of Article 5. There is no day count. There is a question — what are you keeping it for? — and the duty to be able to answer it.
| Text | What it sets | Who it applies to | When it applies |
|---|---|---|---|
| AI Act, Art. 26(6) | Keep automatically generated logs at least six months, or longer if the purpose or other law requires it | Whoever deploys a high-risk system | Annex III high-risk from 2 December 2027; systems embedded in regulated products from August 2028 |
| AI Act, Art. 19 | The same, for the logs the provider controls | Whoever provides the system | Same dates |
| GDPR, Art. 5(1)(e) | Do not keep identifiable data longer than necessary for the purpose | Anyone processing personal data | Today |
| GDPR, Art. 5(1)(c) | Keep only what is adequate, relevant and limited to what is necessary | Anyone processing personal data | Today |
Two clarifications that change the picture. First: the AI Act floor only exists for high-risk systems, and most of a small company's agents — answering queries, preparing documents, moving data between systems — are not. For those there is no six-month legal minimum: your purpose rules, and so does the ceiling. Second: the dates have moved, and we cover the calendar in the AI Act was postponed, but your chatbot still has to disclose. Scope of everything above: European Union. If you operate in the EU or have EU customers, it applies to you wherever you are based.
Do the AI Act and the GDPR really clash? Less than it seems, and more than you would like
Less, because Article 26(6) carries its own escape clause: the six months apply “unless provided otherwise in applicable Union or national law”, and the period must be appropriate to the intended purpose. A prudent reading is that the AI Act does not authorise you to keep personal data beyond what the GDPR allows: whatever you keep still needs a purpose that justifies it. The floor is not a licence.
More, because in practice nobody keeps “a trail”; they keep a dump. The typical agent log holds the customer's full message, the complete reply, the attachments the agent opened and the CRM snippet it queried. That is personal data almost every time. If you keep it six months “because of the AI Act” without asking what for, you have read the floor as a permit and left yourself exposed from above. And if you purge it at thirty days because the disk was filling up, on a high-risk system you have dropped below the floor. Both rules get broken by the same default setting.
The decision trail and the content have different lifespans
The way out is not choosing between six months and thirty days: it is to stop treating the log as one thing. There are two objects with different needs, and bolting them together is what manufactures the false dilemma.
| What you keep | Example | Personal data? | How long |
|---|---|---|---|
| Decision trail | Case identifier, timestamp, model version, instructions version, tools invoked, decision taken, who reviewed or overrode it | As little as possible: internal identifiers, never the text | The period your purpose sets and, if the system is high-risk, never less than the floor |
| Content | The customer's full message, the complete reply, attachments, data pulled from systems | Yes, almost always | The minimum your purpose justifies, with scheduled purging |
| Reference | A pointer to the original record in the CRM or ERP instead of a copy | No copy: the data lives where it is already governed | As long as the source record exists |
The trail is what you need to answer the question that matters months later: what the system decided, with which version, and who supervised it. It does not need the customer's text for that; it needs every decision to be reconstructable and attributable. It is the same record we describe in traceability of AI decisions, and it is the part of agent observability with open tools that has to live the longest.
The content is what expires. You keep it as long as you need to debug, review a complaint or meet a specific obligation, and then you purge or reduce it. And one trap worth having clear: pseudonymising is not anonymising. If you swap the name for an identifier but keep the table that links them, the data is still personal under the GDPR. It reduces risk; it does not get you past the ceiling. What we cover in AI and the GDPR: what your vendor does not tell you about where data ends up applies here as is.
Four questions to set the period before the disk sets it for you
- Is your system high-risk? If it is not in Annex III and not embedded in a regulated product, there is no AI Act floor: purpose rules. If it is, the floor is six months and the hard part is what you put inside. To classify it properly, see what binds you depending on whether you are provider or deployer.
- How long does a problem take to surface in your business? A customer complaint, a billing error or a supplier dispute does not show up at thirty days. The trail's period is calibrated against that, not against storage size.
- What other rule sets deadlines for you? Tax, employment, sector-specific. Article 26(6) itself provides that financial institutions keep the logs within the documentation their own rules already require. If someone else has already set a period, that period counts.
- Which part of the log is trail and which is content? If you cannot answer, the first deliverable is splitting them. Everything else depends on it.
Notice that none of the four is solved by a tool. They are solved by a written decision: what period, what for, and who can change it.
When this split does NOT work for you
Four situations where separating trail from content is not enough, or just gets in the way:
- You need the full text to defend a contested decision. If a customer complains about a denial, you may need to reproduce exactly what the system saw. Then you keep that case's content, with restricted access and its own period, not the whole flow's.
- The vendor holds the logs and you do not control them. Both AI Act articles tie the obligation to the logs being under your control. If they are not, the contract sets the period, which is why you ask for it in writing before you sign.
- The agent handles special categories of data. Health, trade-union membership, biometrics. The bar for justification goes up and the conversation with your data protection officer stops being optional.
- You think a storage lifecycle rule solves it. It deletes by date, not by case. When a complaint is open you need to freeze exactly those records, and a blind automatic purge does not know it exists.
What to do this week
- For each agent, ask where the records are kept, who can read them and when they are deleted. If the answer is “I don't know”, you have your first finding. Who can read them is also an access decision, the one we cover in what permissions to give an AI agent.
- Split the record into trail and content, even if it is just two tables in the same database.
- Write a period for each and, next to it, the reason. A period without a reason is the one that will be challenged.
- Schedule the purge of the content and define the exception for open cases.
- Write down who can change the period, and make it a name, not a team.
That set is the logs part of governance and control of AI automation, the guide where it sits alongside permissions, rollback and audit. And if you want to reach 2027 with the file already built instead of rebuilding it in a panic, what we put in place is complying with the AI Act by operating your AI.
The line for the next meeting
When somebody asks how long logs have to be kept, the useful answer is not a number. It is: are you talking about the trail or the content? With the trail, the problem is losing it; with the content, keeping too much of it. And the default setting of almost any system fails both at once.