In just a few months, every major AI assistant maker rolled out its own version of memory: the ability for the assistant to carry context from one conversation into the next. Google's Gemini keeps conversation history active by default for 18 months — a period the person can shorten to 3 months, extend to 36, or turn off entirely. Anthropic's Claude takes a different path: it keeps request and response content for 30 days for safety purposes, then deletes it automatically, unless the law requires otherwise.
There is no single standard among makers, and one detail goes unnoticed. According to Gemini's own privacy hub, a conversation reviewed by a human evaluator stays stored for up to three years even after the person deletes that chat's history. Keeping and deleting are not the same decision — each maker settles that question its own way, for personal use.
That is a configuration detail until the moment it becomes a company problem. When someone on the team pastes a customer's information, a contract, or an internal spreadsheet into a personal assistant, the policy that decides how long that stays stored — and who can access it — does not belong to the company. It belongs to the maker of that assistant, and the company has no say in that decision.
What counts as personal memory versus company knowledge
The most common confusion is treating all memory as one single thing. It is not. There are at least two kinds, and each should have a different owner.
Personal memory is how each person works: a preferred summary format, the tone used in emails, the fact that someone always reviews a contract a specific way. That belongs to whoever uses the assistant day to day, and it should not automatically become information available to the rest of the company.
Company knowledge is a different category: the refund policy in force, the current price table, the approved process for opening a support ticket. That has an owner (the responsible department), a version (the newest one replaces the previous one), and a scope (not every document is meant for the entire company). When that information is treated as loose "memory" from some conversation, it loses exactly the three things that make it trustworthy: owner, version, and scope.
France's data protection authority, the CNIL, sums up the principle in a way that applies to any AI architecture: the data used needs to be selected and organized to serve a clear purpose, not accumulated by chance. That holds both for the material that trains a model and for what a team lets an assistant remember day to day.
Keeping everything or keeping nothing solves neither problem
Faced with the risk, the first instinct tends to be an extreme: turn memory off completely, or let it accumulate indefinitely. Neither one solves anything.
Turning memory off forces the person to re-explain context every single day — who the customer is, what the process is, what format is preferred — which is exactly the kind of repetitive work an assistant should remove, not recreate. A team that re-explains everything every morning has not gained any productivity; it just swapped one manual task for another.
Keeping everything, forever, creates the opposite problem: outdated information stays available as if it still applied, and no one remembers when it was said or by whom. Gemini's own privacy hub shows how that math can slip out of a person's control: a conversation reviewed by a human evaluator stays stored for up to three years even after the user deletes the history — deleting is not the same as disappearing.
In Brazil, the National Data Protection Authority has flagged the same concern. According to Technical Note nº 12/2025, discussed in market analyses, a relevant share of organizations use large volumes of data to personalize AI responses without sufficient clarity about purpose, retention period, and the legal basis for keeping that data. The problem is rarely the AI itself — it is the absence of an explicit rule about what it should remember, and for how long.
What has to be in place
A well-designed corporate AI environment treats memory as a governance decision, not as the maker's default setting. That means a few concrete mechanisms.
Memory layers with a defined owner. Personal memory (how each person works) stays separate from company knowledge (a document with an owner, a version, and a scope by department) and from agent memory (the context a specific automation accumulates about a routine). One does not become the other without going through a process.
Retention configurable by data type, with automatic purging. A single deadline for everything is as wrong as no deadline at all. A personal preference can last as long as the person wants; sensitive customer data should have a short retention window and automatic expiration, without depending on someone remembering to delete it.
Promotion with approval, not automatic. When something that started as a personal note needs to become official team knowledge, it goes through review by whoever is responsible for that subject — the same "four eyes" logic that applies to any document the assistant will use to answer other people.
An audit trail over memory itself. When a piece of information was stored, by whom, for what purpose, and when it expires: that needs to be queryable, the same way any other action recorded in the system is.
This is how Skyller was designed: personal memory stays personal, company knowledge has a defined owner and version, and retention follows a configurable schedule with automatic purging — not a single standard inherited from outside.
From individual recall to memory the whole team uses
The most immediate gain from separating these layers correctly shows up in daily work, not in an audit. A person joining the team today inherits the company's formal knowledge — the documents, the processes — but inherits none of what a colleague learned using the assistant over the past six months. That shortcut for answering a difficult customer, that way of structuring a report that worked well: it stays only in that person's head and personal chat history.
When company knowledge is treated as its own category — with an owner, a version, and reuse permissions — what one person refined can be made available to the whole team, without mixing it with anyone's personal preference. Memory stops being an individual asset scattered across separate accounts and becomes part of what the company actually knows how to do.
That also makes auditing and compliance easier: when someone asks where a piece of information used in an answer came from, there is a verifiable answer — the document, the version, who approved it — instead of "the assistant remembered it from somewhere."
A roadmap for deciding what is worth remembering
Before treating memory as a technical detail, it is worth answering these questions with the IT team and whoever handles sensitive data:
- What is currently treated as "memory" in the assistants the team already uses? If the answer is "we don't know," the first step is simply finding out what is already being stored, and where.
- Is there a clear line between personal preference and official company knowledge? If anything said in a conversation can become a standard answer for someone else, that line does not exist yet.
- Does each type of data have a defined retention period, or does everything stay until someone remembers to delete it? A deadline per data type is what separates a governance policy from unchecked accumulation.
- Who approves when a personal note becomes knowledge available to the team? If the answer is "no one, it just happens," that is the first gap to close.
