Files as Durable Memory vs. Disposable Uploads: What Your AI Actually Keeps

Most AI assistants treat your files like napkin sketches: useful for the moment, gone when you stand up. You upload a contract, a spec, a dataset. The model references it for that conversation. Then the session ends, and the file functionally vanishes. This is the default. The interesting question is whether it should be, and what it means when memory of your documents is either an accident of infrastructure or a deliberate, user-controlled design choice.

Key Takeaways

• Most AI platforms still treat uploaded files as session-scoped by default. "Durable" file storage is arriving unevenly, often limited to paid tiers and specific regions.
• Even when files persist, retrieval-augmented generation (RAG) chunking means only fragments of your document reach the model per turn. The file is "remembered" in name, not in full.
• Deletion is frequently a UI illusion: legal holds, retention policies, and training pipelines can keep data alive long after you click "delete."
• Cross-platform file portability is effectively nonexistent. Your documents live in five vendor silos with five different retention defaults, five different consent models, and five different attack surfaces.
• Durable, user-owned file memory with honest encryption boundaries is an engineering decision, not a marketing feature. We built Selina around that distinction.

What Does "Disposable" Actually Mean for Uploaded Files?

It means the file's usefulness is bounded by the chat session. You upload a 40-page PDF. The model ingests it (or, more precisely, chunks of it). You ask questions. You close the tab. When you open a new conversation, the model has no access to that PDF. It does not know it existed.

This is how most AI chat products still work for single-conversation uploads. Session-scoped uploads in products like Claude are bound to the chat they were dropped into. A new chat starts with no access to them. The file is not deleted from some server necessarily, but it is invisible to the model going forward. From your perspective as a user, it is gone.

The word "disposable" is doing a lot of work here, though. It implies the file is discarded cleanly. In practice, "disposable" often means "no longer useful to you" while still persisting in infrastructure you do not control.

How Are Major Platforms Handling File Persistence Now?

The industry shifted noticeably in early 2026. A File Library feature launched in March 2026 that automatically saves documents, spreadsheets, presentations, PDFs, and images uploaded during chats. Previously, files were tied to individual conversations and lost when a chat was deleted. Under the new system, files persist in user accounts until manually removed.

But this persistence is not universal. The Library is available only to paid subscribers, and the rollout excludes the European Economic Area, Switzerland, and the UK, reflecting ongoing regulatory pressure on AI data handling in those regions. Free users are excluded entirely. And files uploaded during a Temporary Chat mode are not saved to the account or Library at all.

Meanwhile, a structured memory import feature appeared around the same time from another major provider, allowing users to upload personal context in JSON, Markdown, or plain text that persists across conversations. A step forward. But the file handling and the memory system are still separate tracks with separate rules.

The pattern across the industry: persistence is arriving, but it is tiered by plan, gated by region, split across subsystems, and governed by retention policies that most users never read.

Why Does RAG Chunking Undermine the Promise of "Durable" Files?

Because keeping a file is not the same as remembering it.

When a platform stores your file persistently and uses retrieval-augmented generation to reference it, here is what actually happens: a retriever scans the document, scores chunks for relevance to your current query, and injects only those chunks into the model's context window. The rest of the document is not seen. Project-style features load file content via RAG, pulling only the chunks the retriever guesses are relevant per turn. Files can cap at 30MB each in project knowledge, and memory features store summaries rather than document text.

This means a 25-page contract can be "durable" in the system while being effectively unreadable in practice. The retriever might surface clause 4.2 when you ask about indemnification but miss the related definition in the appendix. The model answers confidently. You trust it. The file was "remembered," but the retrieval was partial and unaudited.

We think about this problem constantly at Selina. When we built file handling, the question was not "can we store the file" (trivially yes) but "can we give you provenance for what was actually referenced and when." A durable file without an audit trail of what the model saw is a liability, not a feature.

Is "Deleted" Actually Deleted?

Often, no.

The most concrete example: under a May 2025 court order in NYT v. a frontier provider, the company is required to preserve all user logs, including conversations users have deleted, until litigation concludes. If you are a free or paid user of that product, your "deleted" chats may still exist on their infrastructure right now. Not because of a bug. Because of a legal hold.

This is not unique to one vendor. It is a structural reality of cloud services. Deletion in the UI and deletion on disk are different operations with different timelines, and legal obligations can freeze the latter indefinitely.

Even the product's own documentation separates chat and file management: deleting a chat does not delete files saved to the Library, and users can view and delete saved files from the Library independently. Two systems, two retention tracks, one "delete" button that affects only half of what you think it does.

Retention policies from other providers show a similar split. Default retention can run 30 days for most products, shrinking to 7 days for API logs, while data allowed for model improvement may be retained in de-identified form for up to 5 years in training pipelines.

We designed Selina's file handling around a simpler principle: delete means gone. Actually gone. Files and transfers through SelinaSEND are end-to-end encrypted, and when you remove a file, it is removed. We do not maintain legal-hold infrastructure that quietly overrides your intent. We keep non-content operational metadata for a short retention window, and we are explicit about that. No zero-retention claim, because that would be dishonest.

What Happens When Your Files Live in Five Different Vendor Silos?

You get five copies of your data, governed by five different retention policies, five different consent models, and five different attack surfaces. None of them talk to each other.

As of mid-2026, every major AI platform scores yes on cross-session memory and no on working across other AI platforms, because each vendor's memory is designed to keep users on its own product. A user might upload a spec to one assistant, drop it into another for a second perspective, then summarize it in a third, but each tool runs its own retriever over a fresh copy. A fact one tool surfaced is not available to the others later.

Coverage tends to frame this as a UX annoyance. You repeat yourself. You re-upload. You re-explain context. That is real, but it is not the deeper problem.

The deeper problem is diffuse, ungoverned risk. Every copy is a potential training input under different consent defaults. Every silo is an attack surface. Microsoft researchers spent February 2026 tracing more than 50 hidden prompts back to 31 companies that were quietly training AI assistants' memory to recommend their products. Durable memory stores are not just a convenience feature; they are an injection target.

When your documents are scattered across five vendors, you have five places where memory hijacking can happen, five retention policies to audit, five "delete" buttons that may or may not do what they claim. Fragmentation is not just inconvenient. It is a privacy risk multiplied by the number of vendors you touch.

How Should Durable File Memory Actually Work?

It should be singular, user-owned, and auditable. That is the short answer.

The longer answer involves several specific engineering decisions that most platforms have not made:

• Full-document fidelity. The file should be available to the model in its entirety when you reference it, not just as retriever-selected chunks. RAG is useful for search over large corpora. It is not a substitute for reading a document.
• Provenance tracking. You should know which parts of a file were referenced in a given response, and when. If the model cites clause 7.3 of your contract, you should be able to verify that clause 7.3 was actually in the context window.
• Encryption with honest boundaries. Files and transfers should be end-to-end encrypted. Memory (the model's learned context about you) is a different problem, because a slice of each request reaches a frontier provider at inference. Memory is NOT end-to-end encrypted. We say that plainly because the alternative is to let you assume something that is not true. Memory in Selina is encrypted at rest and protected in transit, but it is NOT zero-knowledge encrypted. Files and SelinaSEND transfers are.
• User-controlled durability. You decide what persists and what does not. Not a retention policy buried in a terms-of-service update. Not a legal hold you were never told about. You.
• Cross-session continuity without cross-vendor leakage. Your file context should carry across conversations with the same assistant. It should not silently replicate into five vendor silos because you wanted a second opinion.

These are not aspirational design goals. They are the decisions we made when building Selina's file and memory systems. We route inference through a stack of frontier models, routed per task. We do not name them (that is a deliberate policy). Your account is protected. Your content is encrypted. Your files are yours.

What Does the Memory Benchmarking Landscape Look Like?

It is maturing from marketing claims to measurable engineering, which is overdue.

Standardized benchmarks like LoCoMo now test 1,540 questions across four categories of memory recall, letting researchers compare memory architectures on the same evaluation set. This matters because "memory" has been a vague marketing term for two years. One vendor's "memory" is a summary. Another's is a vector store. Another's is a fine-tuned preference layer. Without benchmarks, you cannot compare them. With benchmarks, you can at least see which architectures actually recall what they claim to recall.

We are watching this space closely. Selina's memory is adaptive, not a transcript. We do not claim perfect or complete recall. What we do claim is that your files, when stored, are stored as files, not as lossy summaries in a vector database that may or may not surface the right chunk when you need it.

Why Does the Regulatory Patchwork Matter for Your Files?

Because whether your files are durable or disposable can depend on where you live, not what you chose.

File Library features are unavailable in the EEA, Switzerland, and the UK for at least one major provider. Memory features from another provider are similarly unavailable in the EU and UK under GDPR. If you are a user in those regions, your files revert to session-scoped by default regardless of your preferences.

This creates a strange situation. The same product offers durable file memory in the US and disposable file handling in Europe. The user's intent is the same. The product's behavior is different. And in neither case does the user have real control over the retention mechanics happening behind the UI.

We built Selina to behave consistently regardless of region. Your encryption model does not change because you crossed a border. Your file retention rules are the ones you set, not the ones a regulatory patchwork imposed on your vendor.

What Does This Mean for How You Work with AI?

If you use AI assistants seriously, for contracts, for code, for research, for anything with context that matters beyond a single conversation, the durability of your files is not a feature. It is a prerequisite.

The current state of the industry is roughly this: files are becoming persistent, but the persistence is partial (RAG chunks, not full documents), conditional (paid tiers, specific regions), and opaque (retention policies that conflict with deletion UI). Memory systems are proliferating, but they are siloed, unchunked, and increasingly targeted by adversarial prompt injection.

The question is not whether your AI should remember your files. It should. The question is who controls that memory, what encryption boundaries actually apply, and whether "delete" is a real operation or a cosmetic one.

We do not claim Selina solves every problem here. We do claim we are honest about the boundaries. Memory is NOT end-to-end encrypted. Files and transfers are. Delete means gone. Your account is protected. We keep operational metadata for a short retention window, not forever. And we built the system so that durable file memory is a user-controlled decision, not an infrastructure accident.

If that distinction matters to you: 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