---
title: "Data retention policies for AI memory"
description: "A data retention policy states how long an AI system keeps each class of stored information and what happens at expiry. How to classify, enforce, and verify."
canonical: https://past.dev/guides/ai-data-retention
last-updated: 2026-09-02
---
# Data retention policies for AI memory

Source: https://past.dev/guides/ai-data-retention

A data retention policy for AI memory states how long each class of stored information is kept and what happens when the period ends. Retention differs from supersession: supersession keeps old values with closed validity windows so history stays queryable, while retention removes data entirely on a schedule. A workable policy classifies what the agent stores, sets a horizon per class, and is enforced by scheduled deletion rather than by intention.

## Retention, supersession, and erasure are different controls

| Control | Trigger | What remains afterwards |
| --- | --- | --- |
| Supersession | A fact changes | Both values, with dated validity windows |
| Retention expiry | A class's time horizon passes | Nothing from the expired sources |
| Erasure | A person or obligation demands it | Nothing that only those sources supported |
| Eviction or decay | Relevance ranking demotes it | The data, ranked lower at recall |

Confusing these controls produces real failures. Supersession used where retention is required keeps data that should be gone. Retention used where supersession is wanted deletes history the [audit trail](/guides/ai-audit-trail) depends on. The four are defined side by side in [designing a forgetting policy](/guides/forgetting-policy).

## Classifying what an agent stores

A single horizon for everything is either too short for operational facts or too long for personal data. Classification comes first.

- **Raw source records.** Transcripts, emails, tickets. Often the largest class and the one with the clearest legal constraints.
- **Extracted facts about the business.** Budgets, owners, deadlines. Usually kept long, with supersession carrying the history.
- **Personal data and preferences.** Subject to privacy law and to [erasure requests](/guides/gdpr-memory-deletion) regardless of the schedule.
- **Operational records.** Recall logs kept as audit evidence; for some deployments a legal minimum applies, see [EU AI Act record-keeping](/guides/eu-ai-act-record-keeping).

## Enforcement mechanics

Enforcement reuses the erasure machinery. Each source record carries its class and its ingestion date; a scheduled job enumerates sources past their horizon and deletes them by identifier. Deletion by source then guarantees the derived layer follows: facts supported only by expired sources are erased with them, and facts with living support remain. The verification loop is the same one used for [erasure](/guides/gdpr-memory-deletion): recall before, delete, recall after, expect `NoKnownSupport` where support is gone.

In a self-hosted deployment the memory sits in the customer's own Postgres, so retention jobs run under the customer's scheduler and the data never leaves their infrastructure; see [self-hosting](/docs/memory-api/self-hosting). Export before expiry is available either way: customers can export their data.

## Writing the policy

1. Inventory the classes above and map each thing the agent ingests to one class.
2. Set a horizon per class, with the reasons written down: legal minimums, legal maximums, and operational need.
3. Decide per class whether history is kept by supersession or removed at expiry.
4. Name who may trigger out-of-schedule erasure and how requests are validated.
5. Automate enforcement and alert on failures; a retention job that silently stops is a liability.
6. Test quarterly with the recall-delete-recall loop, and record the runs as audit evidence.

## Where past.dev fits

past.dev gives retention its enforcement primitive: `DELETE /api/v1/ingest/{ingestionId}` removes a source and erases what only it supported. Stable source identifiers assigned at ingestion make the expiry job a loop over known ids; the [quickstart](/docs/memory-api/quickstart) shows where they are set. Recall behavior on questions whose support has been removed is part of what the [benchmarks](/benchmarks) evaluate.

## Frequently asked questions

### How long should an AI agent keep conversation history?

As long as the class it belongs to justifies, and no longer. Transcripts holding personal data usually get a short horizon; durable business facts extracted from them can be kept with supersession carrying the history.

### Does retention apply to facts derived from expired sources?

Yes. Deletion by source erases the facts that only the expired sources supported. A fact that other, unexpired sources also support remains with its surviving evidence.

### Is a retention policy legally required?

Some regimes set minimums for specific records and others effectively set maximums for personal data. The operator of the agent owns the analysis; the memory layer's job is to make whatever policy they choose enforceable and verifiable.

## Related

- [Designing a forgetting policy](https://past.dev/guides/forgetting-policy)
- [The right to be forgotten in agent memory](https://past.dev/guides/gdpr-memory-deletion)
- [Audit trail for AI agent decisions](https://past.dev/guides/ai-audit-trail)
- [EU AI Act record-keeping](https://past.dev/guides/eu-ai-act-record-keeping)
- [Self-hosting](https://past.dev/docs/memory-api/self-hosting)