Why We Built Around Privacy-by-Default Before It Was a Legal Requirement

Three things are converging right now — mid-2026 — that make the case for architectural privacy louder than any policy document ever could. A major frontier provider just carved out its newest models from its own data-retention agreements. A federal court compelled production of 20 million user chat logs from another provider. And states keep inventing new categories of "sensitive data" that retroactively change what you're allowed to store. We chose the architecture we chose years ago. Here's why that decision aged well, and what it means if you're evaluating where to put your data next.

Key Takeaways

• Policy-based deletion promises can be overridden by courts, internal safety reviews, or unilateral terms-of-service changes. Architecture that never stores data in the first place cannot be subpoenaed — because there is nothing to produce.
• Frontier providers are already revoking their own data-retention commitments for their newest model tiers, meaning enterprise customers who relied on contractual guarantees now face mandatory retention to access the best models.
• State legislatures keep retroactively classifying new data types as "sensitive" — neural data is the latest, but it won't be the last. If your system retains conversation data, every new classification triggers a compliance project. If it doesn't, it doesn't.
• We built Selina with content encrypted at rest, files and transfers (SelinaSEND) that are zero-knowledge and end-to-end encrypted, and a short retention window for non-content operational metadata. Memory is NOT end-to-end encrypted — a slice of each request reaches a frontier provider at inference. We say what we don't do, because that's the only honest way to describe a privacy architecture.
• The gap between "we promise to delete your data" and "we architecturally cannot retain your data" is the gap between a contract and a fact. Courts, regulators, and adversaries all treat those differently.

What Happened in the Last Twelve Months?

Three independent events made the same point simultaneously. That almost never happens in privacy law. It happened here.

First: In the copyright litigation between a major news publisher and OpenAI, a federal district judge in January 2026 affirmed an order compelling production of 20 million de-identified user logs. Ordinary users' conversations — things they typed assuming they'd be deleted — became potential court evidence. The company's own 30-day deletion policy was judicially overridden by a preservation order back in May 2025, requiring all output log data to be preserved and segregated on a going-forward basis.

But here's the part that matters most: OpenAI itself stated that customers using its Zero Data Retention API were structurally exempt — because the data was never stored, it could not be produced. That's an admission, from a frontier provider, that policy-based deletion promises can be suspended but architectural non-storage cannot.

Second: Anthropic rolled out a significant consumer privacy policy update effective July 8, 2026, adding rules on identity verification, agentic-task data sharing, and law enforcement cooperation. This built on late-2025 changes that introduced an opt-in training toggle — one that extended conversation retention from 30 days to five years for users who opted in. And in a separate move in June 2026, Anthropic revoked zero-data-retention eligibility for its newest "Mythos-class" frontier models — meaning enterprise customers must accept mandatory 30-day retention to use them.

Third: State privacy law in 2026 is shaped by new comprehensive laws, major amendments to existing laws, and the most aggressive enforcement climate in U.S. privacy history. Neural data became "sensitive personal information" under California's CCPA/CPRA effective January 1, 2026, with Connecticut's amendment following on July 1, 2026.

Each of these stories is independent. Together they draw the same line: data that exists can be subpoenaed, reclassified, or re-retained. Data that doesn't exist can't.

Why Does Policy-Based Deletion Fail Under Pressure?

Because a policy is a promise, and a promise can be modified by the promisor, overridden by a court, or reinterpreted under internal review. Architecture is a fact.

Consider the sequence. A frontier provider tells you: "We delete your data after 30 days." You believe them — they probably do, under normal operating conditions. Then a lawsuit arrives. A judge issues a preservation order. The provider's 30-day deletion policy is now legally suspended. Your data — which you assumed was gone — is being segregated into a litigation hold. You had no say. You may not even know.

Or consider the policy-change path. A clause in Anthropic's June 2026 policy update reveals that even users who opted out of training can still have conversations used for model training if Anthropic's systems flag them for safety review — with no disclosed trigger criteria and no user notification. You opted out. Your data is used anyway. Because it existed, and a new internal justification was found to use it.

This isn't a criticism of any one company's ethics. It's a structural property of any system where data exists at rest. Escape hatches get added. Thresholds get redefined. Users never see it happen. The only way to remove the hatch is to remove the room where it could be installed.

What's the Difference Between "We Delete It" and "We Never Stored It"?

The difference is the difference between a contract and a physical constraint. One is enforceable by courts; the other is enforced by the absence of anything to enforce against.

When a provider says "we delete your data after 30 days," they're making a contractual commitment. That commitment is subject to: terms-of-service amendments (unilateral, often with 30-day notice-or-less), judicial preservation orders (no notice to you), regulatory demands, internal safety reviews, and acquisition by a new entity with different policies.

When a system architecturally doesn't store your data, none of those mechanisms have purchase. A judge can order production of records. If there are no records, the order is satisfied — there's nothing to produce. A terms change can expand what's done with stored data. If there's no stored data, the change is vacuous.

This is not a hypothetical distinction. It was tested, in federal court, in 2025-2026. And the provider itself confirmed that its zero-data-retention API customers were structurally exempt from exposure that affected every other tier.

How Did We Think About This When We Built Selina?

We started from a simple premise: if we don't have it, we can't lose it, leak it, be compelled to produce it, or be tempted to use it.

That premise drove several architectural decisions. Content is encrypted at rest. Files and transfers via SelinaSEND are zero-knowledge and end-to-end encrypted — we can't read them, by design. Non-content operational metadata is kept for a short retention window, not indefinitely. Your account is protected. Delete means gone. Actually gone.

But we need to be precise about what we don't claim. Memory is NOT end-to-end encrypted. It is NOT zero-knowledge encrypted. A slice of each request reaches a frontier provider at inference — that's how inference works. We use a stack of frontier models, routed per task, and those models see what they need to see to produce a response. We can't pretend otherwise, and we don't.

The honest framing is: we minimize what's stored, encrypt what must be stored, and make deletion irreversible. That's meaningfully different from a system that stores everything and promises to delete it later. But it's also meaningfully different from a claim of total secrecy — which would be a lie, given how inference against frontier models works.

What Does Debugging Look Like in an Encrypted-at-Rest System?

It looks different from anything you're used to — and that's a cost we accepted deliberately.

In a conventional system, when a user reports a bug, an engineer queries the database, reads the relevant rows, and reproduces the issue. In an encrypted-at-rest system, the database is not the source of truth for debugging. A content column can read as empty in a raw query and still decrypt to perfect data through the application's own decrypt path. The raw column tells you nothing.

So the method that works — the only method that works — is to debug through the application's decrypt path on the specific rows under investigation. You don't browse the database. You don't grep logs for plaintext content. You run the decryption code against the exact rows the user is referencing, and you see what the application sees. Everything else is ciphertext.

This is slower. It requires more careful tooling. It means you can't just hand a database dump to a new engineer and say "figure out what happened." That's the point. The same constraint that makes debugging harder is the constraint that makes data exposure harder. You trade convenience for a structural guarantee. We think that's the right trade.

Why Does the Neural Data Expansion Matter for AI Products?

Because it previews the next decade of regulatory whack-a-mole — and shows why architecture beats patchwork compliance.

Four states have now enacted specific neural data protections, with California's CCPA/CPRA including neural data within its definition of sensitive personal information. Connecticut's amendment adding neural data as sensitive data takes effect July 1, 2026. Multiple additional states — Virginia, Massachusetts, Illinois, Minnesota, Vermont — have pending bills.

Neural data is the current frontier, but the pattern is general. The regulatory reflex goes like this: AI systems get better at inferring something from ordinary inputs (mood, health status, cognitive state, behavioral patterns). Legislators notice. A new category of "sensitive data" is created. Retroactively. With opt-in consent requirements, deletion rights, and heightened protections.

If your system retains conversation data, every one of these new classifications triggers a compliance project. You need to audit what you stored, determine whether any of it falls under the new category, implement new consent flows, and potentially delete historical data you thought was fine to keep. Multiply that by forty-plus states with divergent definitions and timelines.

If your system doesn't retain conversation data, none of that applies. There is no historical data to reclassify. There is no audit to perform. There is no deletion to execute. The new law takes effect and — nothing changes. Because there was nothing to change.

This isn't about predicting which specific data type regulators will classify next. It's about recognizing the pattern and building for it once, structurally, rather than re-architecting every time a state legislature meets.

Why Are Frontier Providers Revoking Their Own Retention Commitments?

Because the economics of frontier model training create an inherent tension with data minimization. Newer, more capable models require more training data. Providers who committed to not retaining data now face a choice: honor the commitment and withhold their best models from those customers, or change the terms.

Anthropic chose the former, explicitly: zero-data-retention agreements do not extend to Mythos-class models. Enterprise customers who built their compliance posture around those agreements must now choose between accessing the newest models and maintaining their data-retention stance. The agreement they signed covers the old models. The new models come with new terms.

This is instructive. A vendor's commitment to not retain your data is only as durable as the vendor's incentive to honor it. When the vendor's most advanced product requires retention, the commitment bends. Not because the vendor is dishonest — but because business incentives and privacy commitments eventually collide, and the business usually wins.

For us, the calculus is different. We route requests to a stack of frontier models per task. We don't train models ourselves. We don't have a training-data incentive that would conflict with our retention architecture. Our incentive is aligned with yours: keep less, not more.

What Does "Privacy by Default" Actually Mean in Practice?

It means the default state of the system — with no configuration, no toggle, no opt-out form — is the most private state. You don't have to do anything to protect yourself. You have to actively opt in to share more, not actively opt out to share less.

This sounds obvious. In practice, almost no one builds this way, because it's expensive. Every feature that would benefit from retained data — personalization, analytics, debugging, model improvement — has to be redesigned to work without it or to work with encrypted-at-rest data that the operator can't casually access.

Selina's adaptive memory, for instance, is encrypted at rest. It is NOT end-to-end encrypted — to be clear again — because inference requires passing data to frontier models. But the memory store itself is not a plaintext database that an engineer can browse. The same data that makes Selina useful to you is the data we made hardest for ourselves to access.

That's not a perfect system. We don't claim perfect memory — it's adaptive, not a transcript. We don't claim complete protection — a request in transit to a frontier model is, by definition, visible to that model's provider for the duration of inference. What we claim is that the architecture minimizes what's stored, encrypts what's stored, and makes deletion irreversible. That's a set of facts about how the system works, not a promise about what we'll choose to do later.

Is This the Year Data Retention Becomes a Board-Level Risk?

Yes. One analysis frames 2026 as the year that once AI becomes part of core business operations, retention is no longer a privacy footnote — it becomes a board-level risk decision. That framing matches what we're seeing in conversations with prospective users.

The risk surface has three dimensions now, not one:

1. Legal discovery risk. If your AI provider retains your data, that data is discoverable in litigation — potentially litigation you're not even a party to. The 20-million-log production order demonstrated this concretely: users' conversations became evidence in someone else's lawsuit.
2. Regulatory reclassification risk. Data you stored legally yesterday can become "sensitive" today when a state amends its privacy law. Neural data is the current example, but the mechanism applies to any new category a legislature creates.
3. Vendor policy-change risk. Your provider's retention commitment can change when their newest model requires it, when their terms of service are updated, or when an internal safety-review process overrides user preferences. You find out after the fact, if at all.

These three risks compound. A vendor changes its retention terms; your data is now retained longer. A state reclassifies a data type; the data you're now retaining longer is now "sensitive." A lawsuit arrives; the sensitive data you're retaining is now discoverable. Each risk is manageable in isolation. Together they create a surface area that grows faster than any compliance team can patch.

What Should You Actually Look For When Evaluating AI Privacy?

Look at architecture, not marketing pages. Specifically:

• What is stored? Not "what do they promise to delete" — what physically exists on disk after you close the tab? Is it plaintext? Encrypted at rest? Encrypted end-to-end? Each of those is a different fact with different implications.
• What reaches the inference provider? Any system using frontier models sends something to a model provider. The question is what, for how long, and under what retention terms the provider imposes. Ask whether the provider offers actual zero-data-retention inference, and whether that applies to the specific models being used — not just the older ones.
• What survives deletion? When you press "delete," what actually happens? Is it a soft delete (flag in a database) or a hard delete (data destroyed, keys rotated)? Can the vendor recover it? Can a court order require them to?
• What changes without your consent? Read the terms-of-service amendment clause. If the vendor can change retention terms with 30 days' notice and your continued use constitutes acceptance, your "privacy guarantee" is really a 30-day option.

These are factual questions with factual answers. They're more useful than trust badges, certifications, or marketing copy — including ours.

Where Does This Go Next?

More states will add more sensitive-data categories. More courts will issue more preservation orders against AI providers. More providers will face the tension between training-data needs and retention commitments — and more of them will resolve that tension by changing the commitment rather than limiting the model.

Privacy is becoming the foundation of responsible AI governance, not an afterthought. The companies that built for it architecturally — not just in their privacy policy — won't need to re-architect. Everyone else will.

We built Selina to remember you and to protect you. Those two goals are in tension, and we're honest about the tradeoffs. Memory is not end-to-end encrypted. A short retention window exists for operational metadata. We don't claim zero retention. We don't claim perfection. We claim that the architecture minimizes what's stored, encrypts what must be stored, and ensures that delete means gone — actually gone — and that files and transfers via SelinaSEND are zero-knowledge, end-to-end encrypted.

That's the bet we made before any of this was legally required. It's looking like a reasonable bet.

If you want to see how it works: 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