Agent Memory and GDPR: Storage, Erasure and Residency

Recognise personal data after extraction

A coding agent records that Marta approves production releases and works mornings because of a medical appointment. Extraction may shorten that sentence, remove her email address or replace her name with an employee identifier. Those changes do not establish anonymity. The European Commission's application guidance says information remains personal data when a person can still be identified, including through combined information or pseudonyms.

Apply that test to profiles, extracted facts, summaries and any embeddings linked to their source records. As an engineering precaution, treat a representation as potentially personal while it remains linkable to someone. A vector is not evidence that the underlying information has become anonymous.

Distinguish the person using the agent from people discussed in its conversation. A developer's private memory can contain customer contacts or another employee's circumstances. Build subject lookup around the people described, rather than assuming the memory owner's account identifies everyone affected. For mixed records, retain enough provenance to review the relevant passage without exporting unrelated colleagues' information.

Approve the memory purpose before enabling capture

Define a bounded use, such as retaining a developer's formatting preferences across sessions. Recording every conversation for unspecified future usefulness gives reviewers no workable boundary. The Commission's principles guidance connects purpose limitation with minimisation, accuracy and storage limits. Use those principles to decide which facts can enter persistent memory.

The EDPB's lawfulness guidance requires an appropriate legal basis and explains that legitimate interests involve necessity and balancing against individuals' rights. It also cautions that employees generally cannot freely consent to employer processing. An administrator enabling capture is therefore an operational decision; establish the legal basis separately for the people whose information may be captured.

For the release example, retain an approved team responsibility if needed, and exclude the medical explanation from general engineering memory. As a design recommendation, favour explicit preferences and reviewed project facts over inferred personality or performance assessments. Record the approved purpose beside the memory category, and route unexpected sensitive content for review.

Explain capture and recall in the relevant privacy information: what is retained, why, who receives it and how long it remains. The Commission identifies these as information individuals should receive. Review the extraction prompt against that explanation before switching on background uploads.

Map recipients as well as database regions

Draw the actual memory route: agent transcript, upload queue, extraction service, memory database, search service, recalled prompt and model provider. Include local session history, diagnostic logs and backups where they exist. For each location, record its operator, region, purpose, retention terms and deletion contact. This is an operational inventory, not an assumption that every deployment has every component.

The Commission distinguishes the controller deciding processing purposes and means from a processor acting on its behalf, and requires their duties to be specified contractually. Assign those roles for each service from its actual processing and terms. Ask whether an extraction or embedding provider retains submitted content and how deletion requests reach its subprocessors.

The EDPB identifies a transfer where a GDPR-subject controller or processor makes personal data available to another organisation outside the EEA, or an international organisation. It explains that transfer conditions apply alongside the ordinary GDPR requirements. An EU database therefore does not settle what happens when recalled memory reaches a separate non-EEA model operator.

Check the applicable adequacy decision or appropriate safeguards for each relevant transfer; the EDPB describes both routes and the assessment associated with standard contractual clauses. For model routing questions, use the companion guide to bringing your own model key for memory and search.

Make erasure follow the memory's lineage

Give extracted records stable identifiers and maintain a restricted subject-to-record mapping. Keep source references and links to derived summaries or index entries. Searching only for a person's current name will miss aliases, merged memories and statements containing no name. These are recommended design choices for finding the records a rights request concerns.

The Commission's requests guidance explains that erasure applies in specified circumstances, including when data is no longer needed, with exceptions such as legal retention obligations and legal claims. Verify the requester and assess the request before issuing deletion commands. Where a particular copy must be retained, document the reason and prevent its routine recall.

For an illustrative PostgreSQL table named agent_memory, assume each row concerns exactly one subject and erasure of the selected rows has been approved. A parameterised statement can identify the rows actually deleted:

DELETE FROM agent_memory
WHERE workspace_id = $1
  AND subject_ref = $2
RETURNING id;

PostgreSQL documents that WHERE selects rows and RETURNING reports deleted rows. Bind both parameters through the database driver. This statement covers that table only; mixed-subject memories need passage-level review or rewriting.

Use the returned identifiers to drive your application's derivative cleanup. Pause pending extraction jobs that could recreate the fact, invalidate recall caches, and propagate requests to relevant processors. Deal explicitly with active agent sessions that already loaded the text. Preventing future retrieval does not remove a copy already present in a conversation.

Account for backups without promising instant disappearance

Build a deletion record that distinguishes active storage, derivatives, processor requests and backup handling. Prefer job identifiers, timestamps and outcomes to retaining the deleted passage as evidence. Limit access and set a retention purpose for that record too; a detailed deletion log can otherwise become another copy of the personal information.

For backups that cannot support selective deletion, define and review how affected data is kept unavailable for ordinary use, when backup copies expire, and how restoration reapplies approved deletions before recall resumes. Test that procedure with a synthetic subject. Do not assume a backup rotation schedule alone resolves an erasure request, or promise that a database command instantly removes every historical copy.

Choose memory review and expiry periods from the documented purpose. A temporary incident contact and a developer's current formatting preference need different review triggers. Put the scheduling mechanics in the retention and deletion policy; keep the request record focused on what happened to this person's information.

How SPYN3 separates memory storage and capture

SPYN3 keeps memory, skills and notes in its EU database in Ireland. Memory is off by default; an admin enables it, while capture requires a second setting and the workspace's own model key. Full-text search uses no model by default. Memory writes, including deletion, require write:memory, and every write is audit-logged. Captured raw turns are deleted after extraction. These controls let teams separate storage from model processing; teams still need to assess their chosen model provider, processing purposes and deletion procedures.

Rehearse a request before retaining real conversations

Create a fictional employee with two aliases, one personal preference, one shared responsibility and one fact merged into a summary. Submit an internal access-and-erasure exercise. Ask the owner to find each record, identify its recipients and explain any retained copies. Include a second person's information in the shared summary to test selective handling.

After approved deletion, test exact lookup and paraphrased recall, restart an agent session, and run a pending extraction job. Restore an isolated backup and verify that the deletion procedure runs before memory becomes available. Capture concrete failures, such as an orphaned embedding or a queued transcript recreating the record, and assign each to its storage owner.

The Commission says rights requests require a response without undue delay, in principle within one month. Use the rehearsal to establish whether your inventory and processor contacts support that response. Keep evidence of completed actions and unresolved copies so the person handling the request can give an accurate account.