Before You Share: AI Privacy Needs More Than a Promise

Introduction: the conversation is becoming your life

You open an AI assistant to write a difficult reply. You paste the message, explain the relationship, and add a few details you have not shared elsewhere. Another day, you upload a contract, discuss an unfinished idea, or connect your inbox so the assistant can understand what needs your attention.

None of these actions feels like publishing. You are asking for help.

Yet the information can pass through infrastructure, storage systems, review processes, and legal obligations that are largely invisible from the conversation window. An assistant can feel personal long before its handling of your data matches that expectation.

My position is simple: AI privacy should not depend only on what a company promises to do after receiving your information. It should also depend on what its systems prevent from reaching the model in the first place. Policies matter. They need technical protections behind them.

I prepared this article with support from the Dvina team. It examines documented incidents and current practices across ChatGPT, Claude, Cursor, Perplexity, Manus, Meta’s Muse, and Dvina. The purpose is to explain why privacy must become a central engineering priority as AI becomes more involved in our lives—and how Dvina is approaching that responsibility.

What the incidents tell us

The concern is not hypothetical. But different kinds of evidence reveal different problems. A confirmed data exposure, authorized human review, and an allegation about research misuse should not be presented as though they were the same event.

ChatGPT’s 2023 exposure: a failure in the system itself.

On 20 March 2023, a software bug allowed some ChatGPT users to see titles from another active user’s conversation history. OpenAI said the first message of a newly created conversation might also have been visible in certain circumstances. Its investigation identified possible exposure of payment-related information for 1.2% of Plus subscribers active during a particular nine-hour period. Full card numbers were not exposed. OpenAI patched the bug and notified affected users. 1

The lesson is not that the same vulnerability remains open. It is that a privacy commitment cannot, by itself, prevent a system from returning information to the wrong person. Isolation, access checks, and the amount of identifiable information available to expose all matter.

The New York Times litigation: deletion met a legal obligation.

In 2025, OpenAI faced a court order requiring preservation of data that would otherwise have been deleted. Its October update said the broad obligation to preserve new data indefinitely had ended on 26 September 2025, while a limited historical set remained under legal hold. The original preservation requirement excluded certain products and zero-data-retention arrangements. 2

A later development must be read separately: in December 2025, Reuters reported that a judge required OpenAI to produce 20 million anonymized chat logs in the copyright case, rejecting its objections and relying on de-identification and protective safeguards. This was a discovery order, not publication of everyone’s private chats on the internet. 3

Together, these events show why a deletion setting does not settle every question about retained information. Once a copy exists, obligations outside the user’s control can affect what happens to it. Reducing unnecessary retention changes that exposure before a dispute begins.

Human review: access can be permitted without a breach.

OpenAI’s consumer documentation explicitly permits limited access by authorized personnel and service providers for specified purposes, including security investigations, support, legal matters, and eligible model improvement. Anthropic’s consumer guidance permits designated staff to review conversations for usage-policy enforcement, with separate access associated with consented feedback. 4, 8

These are documented access paths, not rumors. They do not establish that employees read every conversation. They do establish that a private-looking chat interface is not necessarily a technical barrier against provider access.

Anthropic’s current documentation adds an important business-side example. Its designated Covered Models require 30-day retention in certain deployments that previously used zero data retention, with controlled human review and exceptions. The rule has model, platform, and eligibility boundaries; it is not a blanket change to every Claude product. Consumer plans are described as unaffected because those surfaces already retain inputs and outputs. 9

Safety monitoring has a legitimate purpose. The engineering challenge is to meet that purpose while minimizing the sensitive information available to monitoring systems and reviewers. A safety justification does not make the privacy question disappear.

The mathematics controversy: an unresolved allegation, a real trust problem

The September 2026 controversy around OpenAI’s Navier–Stokes announcement raised a different concern: what happens when the assistant helping with private research belongs to a company conducting research of its own?

The dispute concerned unpublished mathematical work and credit. Reporting described mathematicians Tristan Buckmaster and Levent Alpöge using AI tools in their work, and Buckmaster questioning whether their private material had contributed to OpenAI’s result. 10

OpenAI disputes that account. Its published response says neither its researchers nor its agents saw the pair’s work before publication. In an update dated 10 September, it further stated that an investigation had excluded any influence from Buckmaster’s Codex prompts during the preceding two months, including through training. That time-bounded statement is more specific than the earlier account in some reporting. 11

The public accounts remain contested. The sources reviewed here do not independently establish that OpenAI used those private conversations to produce its result.

The dispute nevertheless exposes a question worth answering clearly: when people bring unfinished work to AI, what protects the informational value of that work? Removing an author’s name from a proof does not remove the proof. De-identifying a commercial strategy does not make the strategy public property.

That is why strong privacy needs protections for both identity and content. Users should be able to understand whether their material can enter training, research, evaluation, or review workflows—and what technical controls enforce those boundaries.

Four questions that should never be collapsed into one

Much of the confusion comes from treating “private” as a single property. In practice, four separate questions determine what happens to a conversation.

Training: Can the content help develop or improve a model? An opt-out changes an allowed use of information. It does not necessarily change whether the information was transmitted or stored.

Access: Which systems and people can inspect it? Encryption during transmission and storage is important, but it does not automatically prevent an authorized service from decrypting content for processing or review.

Retention: What remains, where, and for how long? Removing a chat from the interface, deleting production records, expiring backups, and excluding data from future training are different operations.

Actions: What can a connected assistant read, change, or send? Once it can work through your accounts, privacy also depends on permissions and controls over outgoing data.

A useful privacy comparison keeps those questions separate. A paid subscription, a training switch, or a private-task label cannot answer all four.

How the services compare

The table below focuses on individual use unless a different scope is stated. It summarizes the reviewed documentation, not the results of an independent security audit.

Service	Training position	The separate boundary to understand
ChatGPT	Individual content can be used for improvement; controls exclude new conversations and Codex tasks. Temporary Chat is excluded. 4, 5	Authorized access and retention remain separate. Codex also has a distinct full-environment training setting.
Claude	Consumer model improvement depends on user choice; feedback and safety-related uses have separate rules. Incognito is excluded from general improvement. 6	Review and retention exceptions still apply. Certain commercial Covered Models have additional retention requirements. 7–9
Cursor	Privacy Mode excludes customer data from Cursor training and describes provider no-retention arrangements, subject to stated exceptions. 12	Requests still pass through Cursor’s backend. Abuse investigations, caching, and model-specific notices matter.
Perplexity	Consumer AI training collection is enabled by default, including on Pro and Max; users can opt out prospectively. 13	Opting out does not stop processing for service operations or legal compliance. Enterprise terms differ.
Manus	Team documentation lists a training opt-out; this review could not verify the definitive individual-plan training rule. 15	Individual tasks being private by default describes sharing visibility, not a complete restriction on provider use. 14
Meta’s Muse	Launch documentation describes training on sanitized interaction data by default, with an opt-out. 16	Sanitizing before training is not the same as masking before inference. Launch-time operator restrictions differ from the planned Confidential VM.
Dvina	Conversations, files, prompts, and workspace data are not used to train AI models. 17, 18	Automatic masking addresses an earlier boundary: detected personal identifiers are replaced before model processing.

The details below explain where these distinctions become important in everyday use.

ChatGPT and Claude: the action you take changes the rule.

OpenAI lets users disable training without removing ordinary chat history. Temporary Chat changes the handling of a conversation further, but its documentation still allows abuse review and describes a 30-day deletion period. Codex users should also distinguish the account-wide content setting from its separate full-environment setting. 4, 5

With Claude, feedback deserves particular attention. Anthropic says a thumbs-up, thumbs-down, or bug report can involve storing the related conversation for up to five years and using it for purposes including model training. Enabling general model improvement also allows eligible de-identified material to remain in training pipelines for up to five years. Those are not the same rules as ordinary chat deletion. 6, 7

A person can therefore make several privacy decisions inside one product without realizing they are separate decisions. Product design should make those differences clear at the point of use.

Cursor and Perplexity: a product label is not a processing boundary.

Cursor’s Privacy Mode provides meaningful restrictions on training and provider retention. It does not make the editor local-only: Cursor says requests still travel through its backend, even with a user-supplied API key. Its documentation also describes temporary encrypted file caching and exceptions associated with abuse investigations or designated models. 12

Perplexity illustrates a different distinction. Its Free, Pro, and Max accounts fall under consumer training controls, with collection enabled by default. The published opt-out applies to subsequently collected data, not retroactive removal of earlier training data. Buying a personal subscription does not make it an Enterprise account. 13

In both cases, the relevant question is what the selected mode and account change—not what the product name appears to imply.

Manus and Muse: private workspaces still need explicit boundaries.

Manus says individual tasks are private unless shared. Its Team documentation also explains that owners can access team session content. These are useful visibility rules, but they do not establish the individual training policy. The full Manus privacy page could not be retrieved for this review, so that question remains unverified rather than being filled in from another plan. 14, 15

Muse’s launch documentation is unusually explicit about the difference between operational restrictions and technical prevention. Meta says the launch-time Secure VM limits staff access through policies but does not prevent access when needed to operate, support, or secure the service. A Confidential VM intended to cryptographically prevent operator access was described as forthcoming and in limited testing. A planned protection should not be counted as already available to everyone. 16

Muse also keeps real connector credentials away from its main agent and places action approvals under a separate permission authority. That illustrates a valuable principle: an agent should not receive a secret or a permission merely because it might be convenient. 16

Move protection to the point before exposure

A training exclusion governs a use of data. Masking changes the data available for processing. Restricted retention reduces the copies that remain. Permission controls limit what an agent can do. These protections are complementary, and the stage at which each operates matters.

Consider an illustrative request: write a follow-up to a client at a particular email address. The model may need the purpose, tone, and relevant commitments. It may not need the client’s real name or address to draft the message. Replacing those detected identifiers with placeholders before inference reduces what the model receives while preserving the useful structure of the task.

That is different from sending the original text and promising to remove identifiers before some later use.

The same principle extends beyond personal identifiers. Confidential research needs controls over the research content itself; connected accounts need narrowly scoped permissions; retained records need defined lifetimes and enforceable access restrictions. Identity masking is one component of that design, not a substitute for protecting the substance of an invention or document.

There is relevant work across the industry. OpenAI released a locally runnable Privacy Filter in April 2026, and Meta’s Muse documentation describes technical isolation and a stronger confidential-computing design in development. These efforts support the case for engineering privacy into the system. A tool release or roadmap, however, is not by itself evidence that every consumer conversation already receives the corresponding protection. 16, 19

The standard should be the protection a person receives in the product they are using today.

Dvina: make privacy part of the normal interaction

Dvina’s approach brings this earlier protection into the assistant experience. Its documented design detects sensitive personal information locally as people type or upload content, encrypts detected personal data, and substitutes placeholders before model processing. The model works with those placeholders rather than the original detected identifiers. 17, 18

The difference is practical. A user should not need to interrupt every task to manually remove names and contact details, or rely only on a promise about what will happen after the model receives them. Protection should accompany the interaction.

Dvina also excludes user conversations, files, prompts, and workspace data from model training. The combination matters: a no-training commitment restricts reuse, while pre-processing protection limits the personal information exposed to the model in the first place. 17, 18

Other layers support that approach. Dvina describes encrypted conversation storage, separation between stored messages and user identity, and EU-hosted data with GDPR-level protections. Each addresses a different part of the handling process rather than asking one training preference to carry the whole burden. 17, 18

The technical distinction is precise: detected personal identifiers are replaced in the model input while the surrounding task remains available for processing. Privacy becomes part of the data flow, rather than only a preference users must remember to manage.

For me, this is the more useful direction for AI: let people bring meaningful context to their work while designing the system to disclose less of their identity than the task requires.

Conclusion: privacy will determine how far people let AI into their lives

AI assistants become more useful as they understand more of our circumstances. That creates a responsibility to protect the information behind that understanding. Asking people for greater access while offering only another settings page is not a sufficient answer.

The evidence points to several distinct risks. Software can expose data across accounts. Stored conversations can become subject to legal demands. Authorized review can exist without a security breach. Disputes over private research can undermine trust even when the allegation has not been independently established.

Those risks require engineering work, not just better wording. Sensitive-data detection, pre-processing protection, separation of identity, limited retention, and enforceable permissions should receive sustained attention as foundational AI safety capabilities. The usefulness of an assistant and the protection of its user must advance together.

With Dvina, we are helping lead that shift by making protection before model processing part of the product’s foundation. The ambition is not to ask for more trust through stronger claims. It is to reduce how much trust must rest on a promise alone.

People should be able to seek help, develop an idea, and share the context needed to move forward without treating every conversation as a potential surrender of their privacy. Building that confidence is one of the most important tasks ahead for AI.

Sources and scope

Sources reviewed on 22 September 2026. This article draws on provider documentation and attributed reporting; it is not an independent security audit. Individual plans are the main comparison scope. Commercial, API, and model-specific exceptions are identified separately. The mathematics section distinguishes reported concerns from OpenAI’s updated response; neither is presented as an independent finding. Manus’s individual-plan training rule remains unverified because its full privacy policy could not be retrieved.