Honoring Erasure Requests for AI Agent Memory: A Practical Guide

To delete an AI agent's memory on request, find every place where the person's facts were stored, remove or de-identify each copy, and write down what you removed, where, and how you checked it. The agent's long-term memory is only the first place to look. Summaries, search indexes, conversation logs, handoff notes, backups and vendor-side history often hold the same facts, and an erasure is only complete when each copy is removed or its retention is justified.

Key takeaways

• An erasure request covers every copy of a person's facts, not only the memory table the agent reads from.
• Build an inventory of memory stores before the first request arrives, so you are not discovering them under deadline.
• Delete or de-identify, then re-index and verify. Removing a source row does not remove the fact from embeddings or summaries.
• Keep the erasure record minimal and never copy the deleted personal data into it.
• Have counsel confirm which laws apply and which exceptions, such as legal holds, allow some records to stay.

Why erasure is harder for agent memory than for a database

In a conventional customer database, a deletion request maps to a record with a known key. An agent works differently. It may summarize a conversation into a note, store that note as an embedding for later retrieval, quote the fact in a reply, and keep the transcript in a log. Each step creates a new copy in a different shape. A fact that was never typed into a field can still be retrieved by a similarity search, so searching for a person's name is not enough.

Most business agents do not retrain the underlying model after each conversation, but they do keep external memory that is injected into later prompts. That external layer, along with the logs and indexes around it, is where erasure work actually happens. Treat it as part of your data systems, with owners, retention rules and deletion paths, not as a convenience feature of the chat tool.

Step by step: find every copy of a personal fact

Run the following sequence for each request. Keep the requester's identifiers in a restricted case file, not in a shared chat channel or ticket comment.

• Confirm the identity of the requester and the scope of the request, including whether it covers customers, employees or both.
• List every store the agent can write to: long-term memory, session memory, summaries, vector indexes, knowledge notes, CRM and ticket sync, drafts and logs.
• Search each store by the identifiers you know, then by the facts the agent might have inferred, such as preferences, health details mentioned in passing, or a family situation.
• Check vendor-side features that keep conversation history or memory, and record the retention setting for each one.
• Check backups and exports. If you cannot edit a snapshot, mark it for expiry and document the exception.
• Log each hit with the store name and type, without copying the content into the record.

How do you delete without breaking the agent?

Deleting a memory entry is the easy part. Summaries that quote the fact must be rewritten or removed, and vector entries must be deleted by identifier or the index rebuilt from the cleaned sources. If you remove only the original text, a stale embedding can keep surfacing the fact in answers, and the agent will appear to remember something it was told to forget.

Sync jobs are the most common source of reappearing facts. A nightly process that copies ticket history back into memory can restore a fact you deleted the day before. Pause automatic re-ingestion for the erased identifiers before you delete, then confirm the pause is working. For a fuller procedure, see how to delete AI agent memory on request.

Use de-identification where full deletion would damage records you must keep, such as a transaction that accounting or warranty rules require you to retain. Replace the personal fields with a neutral reference and keep the non-personal business facts. Write the basis for that choice into the erasure record, so anyone reviewing it later can see why the record survived.

Decision guide: delete, de-identify or keep

Use this order for each fact you find. The default is deletion, and every exception needs a stated reason.

• Delete when the fact has no continuing business or legal purpose, such as a stated preference that no longer shapes the service.
• De-identify when the record supports accounting, warranty or safety history that you must keep, and the person's identity is not needed for that purpose.
• Keep only when a specific legal obligation or legal hold applies, and restrict access to that record.
• Refuse only in writing. If a request is excessive, unfounded or conflicts with another legal duty, tell the requester in plain language what you kept and why.
• Escalate to counsel when the data involves health, children, employment disputes or transfers across borders.

For Brazilian companies, LGPD and AI agents sets out the checks that usually matter most before a request arrives.

Illustrative scenario: the handoff note that outlived the chat

Illustrative scenario, not a real case: a customer asks a service agent to erase her data. The team searches the CRM, finds nothing sensitive, and closes the request. A few weeks later the customer receives a reply that refers to a detail from her earlier conversation. The investigation shows that the agent had written a summary into the ticket history, and a nightly job copied that history back into the agent's memory. The fix was not a larger search. The team added ticket history to the store inventory, paused re-ingestion for erased identifiers, and set up a verification query that runs after every deletion and every sync cycle.

Documenting the erasure so you can prove it

The record should answer five questions: what was requested and when, which stores were searched, what was deleted, de-identified or kept, and how the result was verified. Store it in a restricted system, separate from the personal data it describes. A useful minimum includes the following items.

• A request reference and the scope agreed with the requester
• The list of stores checked, with each owner and access method
• The action taken for each store: deleted, de-identified or retained with a stated basis
• The verification method, the date it was run and the result
• The name of the person who approved each exception
• A follow-up check scheduled after the next sync or re-index cycle

Record outcomes and events, not the payload. The [OpenTelemetry observability primer](https://opentelemetry.io/docs/concepts/observability-primer/) describes telemetry as data about how a system behaves, which is the right model for an erasure log. Your vendor contracts should also state how deletion requests reach subprocessors. The data processing agreement checklist lists what to confirm before you sign.

How Be Human handles erasure in managed operations

Be Human designs the memory layer of a company's AI infrastructure with erasure in mind from the start. Each memory store is registered with an owner, a retention rule and a deletion path before any agent writes to it. In managed operations, Be Human runs recurring searches for identifiers across those stores, reviews permission changes that could widen access to memory, and records each erasure request in the format described above. Changes to deletion behavior go through controlled review, and an incident such as a re-ingested fact is handled as an operational event with a written follow-up. Your team sets the scope and the retention decisions, and your legal advisers confirm the legal basis.

If you are not sure which agent in your company holds the most personal memory today, take the free Be Human AI diagnostic to find the first task worth handing to an agent.

Frequently asked questions

Can we refuse an erasure request because the agent needs its memory to work? Usually not in full. The agent can keep working with less personal context, and you can remove the facts that identify the person while keeping the operational data you genuinely need. Any refusal or partial refusal should be written, explained in plain language and reviewed by counsel where the law applies.

Do we have to retrain the AI model to remove someone's data? Typically no, when the personal facts live in your memory stores, logs and indexes rather than in the model's training. Confirm this with your vendor in writing, because some vendors use customer data for training under particular settings. Check the data processing terms and opt-out options before the first request arrives.

How quickly must we act on a request? The deadline depends on the laws that apply to your company and to the people involved, so do not guess it. Set an internal service target your team can meet consistently, and confirm the legal deadline with counsel for each jurisdiction you serve.

What about backups that still contain the data? Backups are usually handled through expiry rather than by editing each snapshot, and your retention policy should say so. Restore procedures must re-apply the erasure log so deleted facts do not return, and the backup should be recorded as a documented exception until it expires.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.