The difference between a fact you told it and a fact it inferred: why memory provenance matters

You told it you like Nirvana. It decided you like grunge. These are not the same thing, and the distinction between them is one of the most underexamined problems in how AI memory works today. Most systems that remember you across conversations treat both types of information identically: a flat list of facts, stored the same way, weighted the same way, with no visible marker distinguishing what you actually said from what the model guessed. That conflation has real consequences for accuracy, for privacy, and for your ability to understand why an assistant behaves the way it does.

Key Takeaways

• A peer-reviewed study of 2,050 real memory entries found that 96% were created by the system without the user explicitly asking, meaning almost everything in your AI profile is inferred rather than stated.
• Inferred data occupies a legal gray zone: EU regulators have excluded it from data portability rights, yet courts have ruled that inferences about sensitive categories (health, orientation) trigger the same protections as explicit disclosures.
• Deletion of inferred data is technically incomplete. Research shows that model-editing and unlearning techniques leave recoverable traces, so "delete" does not reliably undo an inference.
• Provenance (tracking whether a fact was told or inferred, and with what confidence) should be a first-class product feature, not a compliance footnote buried in a settings page.
• The meaningful privacy commitment is not just about retention policy. It is about generation policy: deciding what inferences to create in the first place, and how durable to make them.

What does "told" versus "inferred" actually mean?

A told fact is something you explicitly stated in conversation. "I'm vegetarian." "My daughter's name is Elara." "I use TypeScript at work." The system stores it because you said it. The provenance is clean: you are the source.

An inferred fact is something the system derived from your behavior, your phrasing, or the pattern of your requests. You asked for cheap meal suggestions because you were tired. The system stored: "User wants to improve his energy levels by adjusting his diet." That is a conclusion. You did not say you wanted to improve your energy levels. You said you were tired and wanted cheap meals. Researchers at Ruhr-Universität Bochum documented this exact case in their analysis of real memory entries, noting how the system slightly extrapolated intent into a stored belief about the user.

The same study found another telling example: a user asked for bands similar to Nirvana. The system stored "User likes Nirvana." The model itself annotated this inference as only weakly supported, yet it persisted in the memory store with the same weight as explicitly stated facts.

How much of your AI profile did you actually create?

Almost none of it. The "Algorithmic Self-Portrait" study, accepted at the ACM Web Conference 2026, analyzed 2,050 memory entries from 80 real users and found that 96% of stored memories were created unilaterally by the system. The user never asked for them to be saved. The system decided, on its own, that these facts were worth retaining.

The content breakdown is worth sitting with. Twenty-eight percent of stored memories contained personal data as defined under GDPR. Fifty-two percent contained psychological insights about the user. Health-related data appeared in the memory stores of 35% of participants. These are not edge cases. They are the median experience of using a persistent AI assistant.

Why does the distinction matter for privacy?

Because inference creates new data that you never disclosed, and the legal framework treats it differently from data you provided. Legal scholarship distinguishes inferred data as "newly generated" data, as opposed to data obtained indirectly from a person, which is merely a transfer of something that already existed. This distinction is not academic. The EU's Article 29 Working Party has explicitly excluded inferred and derived data from the scope of the GDPR right to data portability. If the system inferred something about you, you cannot necessarily port that inference to another service, because the regulation treats it as the system's creation rather than your data.

And yet: the Court of Justice of the EU ruled in case C-184/20 that data capable of revealing someone's sexual orientation "by means of an intellectual operation involving comparison or deduction" qualifies as special-category data under GDPR Article 9. An inference can trigger the same heightened protections as an explicit disclosure. So the legal system simultaneously says you cannot port inferred data as though it were yours, but that inferred data about sensitive attributes must be protected as though you had disclosed them directly.

This is not a contradiction that has been resolved. It is a live tension that every product with persistent memory has to navigate.

How do inferences compound beyond the original disclosure?

This is where the real harm vectors emerge. Stanford researchers documented a concrete scenario: a user asks a chatbot for low-sugar recipes. The system classifies them as health-vulnerable. That determination can ripple through the developer's ecosystem, eventually surfacing as medication advertisements or health-insurance-relevant profiling. The user disclosed a recipe preference. The system generated a health classification. Those are categorically different things, but downstream consumers of the profile cannot tell them apart.

The compounding problem gets worse with scale. State Attorneys General in the US have begun examining whether AI companies' consent mechanisms for memory collection are clear and fair under consumer-protection law, pushing for explicit informed consent rather than default-on settings. The concern is straightforward: if 96% of memory entries are system-generated, "consent to memory" is not meaningfully consent to the profile that actually gets built.

Can you even see what was inferred about you?

Poorly, if at all. Contrary Research documented the opacity problem in detail: a user may see a high-level summary like "prefers X over Y" but cannot trace which past interactions produced that conclusion, how strongly it influences retrieval, or whether other behavioral signals contributed. You cannot verify or contest a model of yourself that you cannot inspect at the level of its inputs.

One example of provider-side ambiguity is particularly stark. MIT Technology Review reported that one model's system prompt instructs it to never confirm to a user that it has modified, forgotten, or declined to save a memory. The publication noted this is likely because the company itself cannot guarantee those instructions will be followed. The system is uncertain about its own memory behavior, and the user is kept uninformed about that uncertainty.

Does deleting an inference actually remove it?

Not reliably. Research published by TechPolicy.Press shows that even state-of-the-art model-editing and unlearning techniques often leave recoverable traces of "deleted" information inside a model's internal representations. The inferential capability, the pattern that led to the conclusion, is not reliably undone through deletion alone. You can remove the label from the profile. You often cannot remove the model's tendency to re-derive it.

This is one of the reasons we think the industry's framing is wrong. The conversation has centered on retention policy: how long data is kept, when it is deleted, what the user can remove. Those are necessary questions. But they are insufficient. The more important question is generation policy: what inferences should the system create in the first place? How confident must the system be before it commits an inference to durable storage? And should that inference decay over time if it is never reinforced?

What would a better system look like?

It would treat provenance as a visible, first-class attribute of every stored fact. Not metadata buried in a database column. A thing the user can see: this fact was stated by you on this date, versus this fact was inferred from these interactions with this confidence level.

Mem0's 2026 architecture update moves in this direction. Their group-chat system uses message-name fields to attribute memories to either the user or the agent, letting retrieval separate user-stated facts from agent-generated inferences. Agent confirmations and recommendations are stored as first-class objects with their own provenance. This is the right structural instinct: treat told and inferred as different types, not interchangeable entries in a flat list.

But attribution alone is not enough. The system also needs confidence scoring and temporal decay. A stray comment should not become a permanent character trait. If someone mentions a stressful day at work, the system should not store "user has workplace anxiety" with the same durability as "user's primary language is Portuguese." The first is a low-confidence inference from a single data point. The second is a high-confidence fact reinforced across hundreds of interactions. They should age differently, surface differently, and be deletable differently.

How does this affect what we build at Selina?

We think about this daily. Selina uses a stack of frontier models, routed per task, with memory that persists across conversations. That memory is encrypted at rest. It is not end-to-end encrypted, because a slice of each request reaches a frontier provider at inference time. We state that limit plainly because it shapes the design constraints we work under.

Given those constraints, the told-versus-inferred distinction becomes a load-bearing architectural decision. When the system stores something about you, it matters whether that fact came from your explicit statement or from the model's interpretation of your behavior. We treat these differently. We are not perfect at it. Adaptive memory is not a transcript, and the line between "stated" and "derived" is genuinely blurry in natural conversation. But the alternative, treating everything the model concludes about you as equivalent to what you said, is worse. It produces profiles that users cannot recognize as their own.

One thing we learned from running this in production: the hardest cases are not the obvious ones. "User is vegetarian" derived from "I don't eat meat" is a reasonable inference that virtually every user would endorse. The dangerous inferences are the ones that cross category boundaries. A request for calming music before a meeting becomes "user experiences performance anxiety." A question about custody law becomes "user is going through a divorce." These are plausible readings. They might even be correct. But they are the system writing a story about you, and that story should be marked as authored by the system, not by you.

What are the legal boundaries right now?

They are shifting and inconsistent, which is part of the problem. The European Data Protection Board ran a coordinated enforcement action on the right to erasure in February 2026, calling it one of the most frequently exercised and most complained-about GDPR rights. The board specifically flagged the difficulty of applying erasure when data has been inferred, summarized, or embedded. If the data was never provided by the user, what does "erasure" mean? If the model can re-derive the conclusion from other retained data, has erasure actually occurred?

Meanwhile, the practical surface area is growing fast. Federal Reserve survey data released in April 2026 found that approximately 18% of US companies have adopted an AI tool or LLM, a 68% year-over-year increase. The told-versus-inferred question is no longer confined to individual consumer chatbots. It is scaling into enterprise contexts where the inferences might involve employee performance patterns, client legal strategies, or patient health trajectories.

Non-content operational metadata adds another layer. Most providers retain some operational data for a window after requests. At Selina, that window is short, but it is not zero. We say "short retention window" because saying "zero retention" would be inaccurate, and inaccuracy on this point is the kind of thing that erodes trust in ways you cannot repair.

Why should provenance be a product feature?

Because the alternative is a settings page that nobody reads, attached to a privacy policy that describes the system's behavior in terms so general they could apply to any product built in the last decade. Provenance as a visible feature means the user can open their memory, see what the system believes about them, and distinguish between "I said this" and "the system concluded this." That distinction is the minimum viable transparency for a system that builds a persistent model of its user.

We are not claiming this is easy. Natural language is ambiguous. "I've been feeling really run down lately" could be a health disclosure, a weather complaint, or a figure of speech. The system has to make a judgment call about whether to store it and how to categorize it. The question is whether that judgment call is visible to the user or hidden behind a clean, friendly summary that obscures its origins.

The Algorithmic Self-Portrait researchers proposed an "Attribution Shield" concept: a framework where each memory entry carries metadata about its source, confidence level, and the interaction that generated it. The industry is converging toward something like this, slowly. We think the convergence should be faster, and that products competing on memory quality will eventually compete on memory legibility.

What we do not claim

We do not claim perfect memory. Selina's memory is adaptive, not comprehensive. It forgets things. It sometimes stores things you would rather it did not. The system is better than it was six months ago and worse than it will be six months from now.

We do not claim that our told-versus-inferred separation is complete or that confidence scoring eliminates bad inferences. It reduces them. The reduction is meaningful. It is not total.

We do not claim that memory encryption solves the provenance problem. Encryption protects the content of what is stored. It says nothing about whether what is stored is accurate, fair, or endorsed by the user. These are separate concerns, and treating encryption as a substitute for provenance is a category error we see frequently in competitor messaging.

Files and transfers through SelinaSEND are end-to-end encrypted. Memory is not. The account is protected. The content within it is encrypted at rest. These are precise statements, and the precision matters.

Where this is going

The told-versus-inferred distinction will become a regulatory requirement before it becomes an industry standard. The EDPB's enforcement actions, the CJEU's rulings on inferred sensitive data, and the attention from US state Attorneys General all point in the same direction: systems that build persistent profiles will need to demonstrate what was stated versus what was derived, and users will need meaningful mechanisms to contest the derived portion.

Products that treat this as a compliance burden will bolt on a settings page. Products that treat it as a design constraint will build memory systems where provenance is structural. We are trying to be in the second category. We are not there yet. But the destination is clear enough to build toward.

A stray comment should not become a permanent character trait. That is not a privacy slogan. It is an engineering specification.

If this matches how you think about the problem, start a free 7-day trial, no card required.

Michael C.

Founder & Principal Engineer, Selina Labs

Michael builds Selina, a privacy-first AI that remembers you across conversations. He ships security-sensitive AI in production — real attacks, real fixes, measured in minutes and dollars — and writes about privacy, security, and LLMs from that seat. Top Rated Plus and expert-verified on Upwork.

• www.upwork.com
• x.com
• medium.com
• selinalabs.io