1:1 mentoring with Big Tech AI engineers
LLM & Agentic

Memory Compliance & Interview Prep

GDPR and privacy compliance for agent memory, plus FDE interview scenarios and deep-dive questions.

Last updated

After this section you can

  • Translate GDPR data-subject rights into operations a memory store must support
  • Design an erasure that reaches rows, embeddings, derived data, backups and processors, and prove it with a test
  • Set retention and write-time controls, and take a memory system through a pre-ship checklist
19

Memory Compliance & Interview Prep

Once an agent remembers people, its memory is a store of personal data. Each right a user has becomes an operation you must be able to run, across every copy, and prove you ran.

Key idea

Design memory so that, for any person, you can find everything held about them, export it, correct it, stop using it and delete it from every copy, including embeddings, summaries and backups. Those five operations must exist before launch; retrofitting them onto a running store is where teams fail.

One erasure request, six places to delete from. It is done when every store has confirmed.
1 · Erasure request “delete what you hold” identity verified 2 · Erasure job looks up every store in the data map by subject_id idempotent, retried until each store confirms 3 · Audit record who, when, which stores no personal content Memory rows every row for the subject, including superseded ones Vector index delete the vectors, then confirm the index purged them Derived data summaries, profiles and caches that mention them Sessions + logs transcripts, traces, eval and test sets Backups put beyond use, expire on rotation or crypto-shred Processors LLM API, vendors: their retention and deletion terms Dashed: outside your system, governed by contract. Deleting the main table is one step of six.

Related

More in LLM & Agentic

Get full access to all 74+ sections with code examples, diagrams, and interactive animations.

Unlock Premium