No fixed period applies. GDPR storage limitation says an AI agent may keep conversation history and working memory in identifiable form only as long as the purpose needs it. In practice that means a short life for working memory, a defined period for conversation history tied to the case, and deletion that reaches every store the agent writes to.
What does storage limitation require?
Article 5 requires personal data to be kept in a form that permits identification for no longer than necessary for the purposes it is processed for. Longer storage is allowed only for archiving in the public interest, research or statistics, with safeguards.
In substance, that creates three duties. Decide a retention period, or the criteria for one, for each category of data. Tell people what it is in your privacy information. Delete or anonymise the data when the period ends. Your Article 30 records of processing should show the periods, where possible.
The principle is a controller's duty. Your agent platform must be able to carry out your retention decisions, but the decisions are yours.
Who does it apply to?
Every controller under GDPR and UK GDPR whose agents store personal data. That includes data stored implicitly, such as an agent's notes, summaries and cached documents, not only the records the agent writes to your systems of record.
What counts as memory for an agent, and how long can each kind last?
Agent memory is not one thing. Our explainer on what agent memory is sets out the types; for retention they behave differently.
| Memory type | What it holds | Typical retention logic |
|---|---|---|
| Working memory within a task | Facts retrieved and intermediate notes for the job in hand | Ends when the task ends; no reason to keep it |
| Conversation history | The exchange with a customer or colleague | Tied to the case or complaint it belongs to, then deleted |
| Long-term memory about a person | Preferences, prior issues, notes carried between conversations | Only while the relationship exists and the purpose needs it; reviewed periodically |
| Retrieved copies of documents | Files pulled from a document store or system of record | Should not persist; the agent should re-read the source |
| Decision and action logs | What the agent did, when, under which limits | Justified by accountability and other legal duties; minimised and access-restricted |
Two agent-specific problems follow from this table.
Copies outlive their source. If an agent caches a customer's file, and the source system deletes it on schedule, the agent's copy survives. Storage limitation is then breached by a store nobody thought to include.
Long-term memory drifts. Memory that persists across conversations tends to accumulate. An agent that records "customer prefers email" is fine. An agent that over months records stress, family events and inferred financial trouble is building a profile with no retention boundary.
How do you enforce deletion?
| Requirement | Control | Evidence it leaves |
|---|---|---|
| A period for each category | Retention schedule lists each agent memory type with a period or trigger | Approved schedule; Article 30 records |
| Working memory not kept | Task memory cleared on completion | Configuration; sample checks |
| History tied to the case | Conversation history deleted when the linked case closes plus its period | Deletion jobs with counts |
| Long-term memory bounded | Allowed fields defined; free-text notes reviewed or expired | Field definitions; expiry logs |
| No unmanaged copies | Agent reads systems of record at the time of use instead of keeping copies | Architecture records; cache settings |
| Deletion reaches the platform | Contract and configuration require deletion in the vendor's stores and backups within a set time | Contract clause; deletion confirmations |
| Logs justified separately | Log retention set by legal and accountability needs, with personal data minimised | Log retention policy; field review |
The last row is where firms struggle. Logs that evidence an agent's behaviour are needed for audits, complaints and, for high-risk systems, under the EU AI Act. They also contain personal data. Our piece on EU AI Act record-keeping vs GDPR storage limitation explains how to keep both: retain the log, minimise what it contains, and restrict who can read it.
Can scheduled deletion and erasure requests work together?
They need to. Scheduled deletion handles data that has reached the end of its life. Erasure requests remove a specific person's data early. Both must reach the same stores: memory, conversation history, summaries, logs where legally possible, and the vendor's systems.
If you build retention correctly, erasure becomes a targeted run of the same machinery. If you do not, each request becomes a manual search. Our guide to GDPR erasure requests and AI agent memory covers that process.
What will a supervisor or auditor ask?
- What types of memory do your agents keep, and what is the retention period for each?
- Does any agent keep copies of documents from systems of record?
- Show us the deletion runs for last quarter: what was deleted, from where, and how many records?
- How do you stop long-term memory accumulating detail no one approved?
- How long does the vendor keep prompts, outputs and logs, and can you prove deletion?
What does storage limitation not cover?
It does not require deleting data you must keep by law, for example records required by financial regulation. It does not apply to properly anonymised data. It does not decide what the agent may use data for; that is purpose limitation. For the wider set of obligations, see AI agent regulation, mapped to controls.
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
Questions people ask
Should an agent remember customers between conversations at all?
Only where it serves the customer and you can say why. Remembering an open complaint is useful. Remembering everything said in every call is rarely necessary. Start with no long-term memory and add specific fields that earn their place.
Do summaries count as personal data that needs a retention period?
Yes. A summary of a conversation about a person is personal data about that person. Treat summaries like the conversation they came from, with the same or a shorter period.
What if the model provider keeps prompts for abuse monitoring?
That is retention by a sub-processor and must be covered in your contract and privacy information. Ask for the period, whether it can be reduced or switched off for your account, and how deletion is confirmed.