A governance committee signs off on the company's "AI memory layer" during a quarterly review. The presentation was clear, the risks were discussed, the motion carried. Six months later, the customer-facing agent is quietly accumulating inferred behavioural profiles in a vector store — no retention policy, no deletion architecture, data lineage nobody can reconstruct. A user submits a GDPR erasure request. The engineering team discovers they have no mechanism to honour it cleanly.

Nobody circumvented the governance process. The governance process simply didn't know what it had approved.

When a CIO tells the board "we need to get on top of AI memory," they are almost certainly talking about a different thing than the CISO nodding next to them. The vendor pitching them next week is talking about a third. This is not a semantic quibble. It is the reason enterprise governance programmes keep failing to account for risks they have already, inadvertently, approved.

There are three architecturally distinct things the industry calls "memory." One of them is exploding in production environments right now. One of them is a slower-moving, unbounded risk heading straight at procurement processes that cannot distinguish between them. Getting this disambiguation right is the difference between a governance programme that protects you and one that performs governance theatre while the real exposure builds elsewhere.

The three memories

There are three types of AI memory. They share a metaphor and almost nothing else.

Type 1: In-Session Memory (Context Window)

Ephemeral. Per-conversation. The model holds the current session in working memory, then forgets. Frontier models have progressively dissolved the "amnesia between chats" problem with million-token contexts. Architecturally, this is solved at the engineering level. Economically, long contexts are painful — but this is not a governance problem. Nothing about your organisation leaves the session when the session ends.

Type 2: External Persistent Memory (Vector Stores, RAG Pipelines, Memory Frameworks)

Information extracted from sessions and stored outside the model — in a vector database, a key-value store, or a managed memory framework like Mem0 or Zep — then retrieved in future sessions. The model doesn't change. Weights are frozen. What changes is that a separate store accumulates summaries, preferences, and inferred context, retrieved at inference time. Technically this is RAG with extra steps. Governable — but only if you've built the infrastructure to audit, edit, and delete from it.

Type 3: In-Weights Memory (Fine-Tuning, Continued Pre-Training)

Knowledge or behaviour baked into the model's parameters through fine-tuning, continued pre-training, or (on some vendor roadmaps) continual learning from live interactions. The model doesn't retrieve this information — it is this information. There is no lookup step, no index to query. The knowledge is expressed through every output the model produces.

Most enterprise procurement teams treat these as a single risk category. They negotiate a DPA, tick a box that says "no training on our data," and consider the question closed. This works for one of the three. It is dangerously imprecise for the other two.

The live bomb: Type 2, right now, in your vector store

Most enterprise governance conversations that do engage with memory focus on external persistent memory, which is correct. But the framing is usually wrong in two ways that matter.

The first wrong framing is treating the tooling as the governance. Teams implement Mem0, LangChain's memory modules, or a custom pgvector setup, and check a box. The framework enables memory governance; it does not constitute it. A vector database has no awareness of your retention policy. It enforces no access controls unless you configure them. It produces no audit trail unless you build one. The framework is plumbing. Governance is the building code. Mistaking one for the other is how organisations end up with well-organised risk rather than managed risk.

The second wrong framing is applying traditional data classification to memory-derived data. Standard classification frameworks — public, internal, confidential, restricted — were designed for documents. Memory-derived data is different in kind. When an AI agent accumulates persistent memory about a customer, it frequently isn't storing raw PII. It's storing inferred PII: summaries like "this user has raised budget concerns three times this month and prefers formal communication in sensitive discussions." That string contains no name, no email, no account number. It will not trigger a traditional DLP rule. But under GDPR's definition of personal data — "any information relating to an identified or identifiable natural person" — it almost certainly qualifies, particularly when combined with session metadata.

Most organisations have no classification tier for this data, which means it defaults to "internal" and gets governed far too loosely.

The closest analogy is not a CRM record. A CRM record is disclosed, expected, and consented to. The closer analogy is an undisclosed employee performance file — a dossier assembled without the subject's knowledge, informing decisions about how they're treated. Most organisations would not permit a manager to maintain undisclosed dossiers on employees or customers. They are permitting the functional equivalent through AI memory infrastructure because the word "memory" sounds innocuous.

The RAG-as-memory anti-pattern

One architectural pattern creates governance exposure faster than any other, and it is common enough to deserve a name: the RAG-as-memory anti-pattern.

A team builds a RAG pipeline for document retrieval — well-understood, reasonably governed. Documents go in, access permissions are configured, version control is applied. It works. Then someone notices that conversation summaries could be fed back into the same vector index to give the AI continuity across sessions. Small change. Index already exists. Infrastructure already works.

What just happened is that two architecturally distinct functions have merged into one: knowledge retrieval (pulling from a governed document corpus) and memory persistence (accumulating from live interactions). The governance controls appropriate for the former — document access permissions, content review before ingestion — are wholly inadequate for the latter. A user's concern about their company's M&A process, a customer's disclosed health condition, an employee's performance issue mentioned in passing — all of this now lives in the same index as the product documentation, governed identically, with no mechanism to identify or isolate it.

This is not a hypothetical failure mode. It is the natural evolution of RAG implementations when teams are moving fast and treating memory as a simple extension of retrieval rather than a distinct problem requiring distinct controls.

The slower bomb: Type 3, and the procurement gap heading toward it

In-weights memory deserves more attention than it currently receives, for one specific reason: fine-tuning is becoming accessible at the exact moment that governance functions at smaller companies are least equipped to handle it. Consumer-friendly APIs, low friction, minimal review, a few clicks to a domain-adapted model. Accessibility is a feature for adoption and a risk amplifier for governance.

The governance implication of Type 3 is severe and almost entirely absent from enterprise conversations: once something is in the weights, it cannot be surgically removed. There is no DELETE statement. There is no retention policy you can enforce after the fact. If a model is fine-tuned on data that later becomes legally problematic — a dismissed employee's communications, superseded regulatory guidance, a dataset containing sensitive client context — the only remediation is retraining from a clean dataset. The knowledge cannot be patched out.

The right question to ask before any fine-tuning run is not "what do we want the model to know?" It is "what is in this dataset that we may later need to un-know?" Most organisations are not asking it.

The commercial dimension is where Type 3 becomes acute. Right now, almost no frontier-model vendor ships weight updates from live customer interactions to enterprise tenants. But continual learning is an explicit roadmap item at multiple providers. The vendors who get there first will have a performance advantage; the ones who preserve frozen-weight isolation will have a compliance advantage. The procurement frameworks your organisation has today were built without a clear line between these.

Here is the specific way this bites enterprises over the next 18–24 months. A vendor ships an upgraded "memory" feature. Your product team loves it. Procurement asks the standard "do you train on our data?" question. The answer is technically no — or technically qualified, or technically per a toggle whose default is unclear. What your team does not ask, because the distinction is not in their framework, is: which of the three memories does this implement? Are model weights updated, directly or indirectly, from our interactions? If so, how is cross-tenant isolation enforced architecturally rather than contractually? Can you produce reproducible behaviour against a named model version we are entitled to remain on?

A contract that says "we do not train on your data" is architecturally meaningful when the vendor runs frozen weights with per-user retrieval. It is architecturally meaningless if the vendor has drifted into weight updates and your procurement team did not know to ask.

What to do before the end of the month

Three specific actions. Each is high-leverage relative to effort.

1. Rewrite the "AI memory" section of your AI use policy to explicitly distinguish the three types. This is an afternoon of work and is the single highest-leverage governance intervention available to you. Once the policy separates them, every vendor conversation, every DPA review, and every internal risk register entry is forced to name which memory it is describing. The conflation stops.

2. Map what you actually have against the taxonomy — and verify your deletion architecture works. Not what you approved. What you have. Walk the codebase and identify every place where data from AI interactions is written to persistent storage. Classify each: Type 2 external persistent memory, or an inadvertent Type 3 precursor? For every persistent store, answer one question: if a user submits an erasure request today, what is the exact sequence of steps to honour it — and have you tested it end to end? If the answer is "we'd have to figure that out," that is a compliance liability that grows with every day of production traffic.

3. Add four questions to every AI vendor assessment, and audit fine-tuning datasets for temporal decay. Ask: which memory types does this product implement? Are model weights updated — directly or indirectly — from our interactions, at any frequency? If yes, what is the architectural mechanism for cross-tenant isolation? Can you produce reproducible outputs against a named model version? And before any fine-tuning run on internal data, review the dataset for information with an implicit expiry: former employees, resolved disputes, superseded policies, deprecated products. The time to make those calls is before training. There is no equivalent opportunity after.

Governance programmes fail on AI memory not because they lack rigour, but because they lack vocabulary. Give the committee the wrong word and they will approve the wrong risk. Give them the taxonomy above and the right questions follow almost automatically: What type is this? Where does it persist? Can we delete it? What is in the training data?

That is not a compliance exercise. That is the difference between a governance process that knows what it approved and one that finds out six months later.