Andy Yen, Proton’s co-founder and CEO, says AI and privacy can coexist—but only if we stop treating “privacy” as one giant switch. Proton’s Lumo makes that distinction concrete: a no-log policy, encrypted saved chats, protection during GPU inference and limits on an AI agent’s access are separate layers, with separate risks.
That is the useful answer for anyone wondering whether Lumo is completely private. Proton has published a privacy-focused design for the assistant, but those policy commitments are not the same thing as cryptographic protection at every stage of processing. Yen said the stronger GPU interface was still the missing piece during the interview in which he discussed it.
The promise—and the qualification
Yen’s position is straightforward: AI is too useful to simply reject, so Proton should offer an alternative built around privacy rather than treating personal data as an advertising asset. Lumo, launched on July 23, 2025, is Proton’s answer to that challenge.
The interesting part is not whether Proton uses privacy-friendly language. It does. The interesting part is what each promise actually covers.
A service can avoid retaining a conversation and still need to process a prompt on a server. It can encrypt a saved chat and still face a different technical problem while a model is reading the prompt. And even the strongest encryption cannot stop an agent from exposing information after a user gives it broad access to a device or account.
That layered view is the difference between a privacy policy and a privacy architecture.
What Lumo publicly promises
Proton says Lumo does not keep server-side conversation logs and does not use user conversations or inputs to train its language models. Proton also says saved chats use zero-access encryption, meaning the company says it cannot read those stored conversations.
The product description adds several other privacy controls:
- Lumo can be used without an account.
- Logged-in users can use ghost mode, in which the current chat disappears after closing.
- Web search is optional and user-enabled.
- Proton says uploaded files are not retained after analysis.
- Proton says Lumo runs on open-source models in Proton’s European data centers.
Those features answer important questions about retention, storage and product operation. They do not automatically answer what happens to a prompt while the model is processing it.
The distinction matters because “zero-access encryption” for saved chats is not the same claim as end-to-end cryptographic protection during inference. In plain English: protecting a conversation in storage and protecting it while a GPU is actively working on it are different engineering problems.
Why GPU processing changes the privacy question
A large language model usually needs access to a prompt to generate a response. That makes the processing boundary—where the prompt reaches the model and its hardware—a crucial part of any privacy design.
Yen said Lumo’s infrastructure for stronger cryptographic protection was largely built, but that the final interface to the GPUs was still missing at the time of the interview. That statement does not establish what the implementation status is now. It does establish why Proton’s published storage and retention policies should not be casually described as complete end-to-end protection for every moment of inference.
This is the point where many AI privacy discussions become mushy. “No logs” describes what a provider says it retains. “No training” describes how it says conversations are used. Zero-access encryption describes saved data. None of those phrases, by themselves, explains whether the provider can access a prompt while the model is generating an answer.
A useful privacy review therefore asks four questions:
- Is the prompt retained?
- Can the provider read saved conversations?
- Can user data be used for model training?
- What protection exists while the model processes the prompt?
Lumo’s published design addresses the first three in Proton’s stated terms. Yen’s comments show that the fourth question is its own technical frontier.
The keynote is a corporate presentation, so it is best understood as Yen’s explanation of Proton’s position—not as an independent audit of Lumo’s security model.
The limit no encryption can solve
There is another boundary that has little to do with Proton’s servers: what the user allows an AI agent to do.
Yen has pointed out that encryption cannot protect information after a user gives an agent broad access to a device or account and the agent then discloses that information. That is not a narrow Lumo feature claim; it is a general limitation of permissioned software.
Imagine putting a valuable document in a locked cabinet, then handing the key to an automated assistant and telling it to “handle everything.” The lock may be excellent. The instruction is the problem.
For AI agents, the practical risks include access to mail, files, credentials and connected tools. An encrypted storage system can protect data at rest, but it cannot decide whether an authorized agent should copy a secret into a message, upload it to another service or publish it somewhere. That decision happens after access has been granted.
Cloud AI, local AI and the trust boundary
Local AI can reduce exposure to an external provider because prompts can remain on the user’s hardware. That makes local inference attractive for highly sensitive work—but it is not a magic privacy shield.
A local setup still depends on the security of the device, its operating system, downloaded models, network configuration and connected applications. Malware can undermine a private model. An agent with excessive permissions can undermine it too. Keeping a prompt off a provider’s servers is valuable, but it does not make the surrounding computer trustworthy by default.
The practical choice is less dramatic than “cloud bad, local good”:
- Use local processing when the material is highly sensitive and the device is properly secured.
- When cloud AI is necessary, minimize the information sent to it.
- Never paste passwords, API keys or other credentials into a prompt.
- Prefer services with clear retention and training policies.
- Give agents the narrowest permissions they need, and isolate credentials from the model’s direct context.
This is also why ordinary users cannot reduce the entire question to a single privacy badge. Provider policies, technical documentation, contractual controls and audits can improve trust, but users still need to decide what information they are willing to send outside their own devices.
Why privacy demand crosses political lines
Yen also presents privacy as a broadly shared concern rather than a partisan one. He said Proton saw increased demand during both the Trump and Biden administrations, using those two periods as examples of how political changes can drive interest in privacy services.
The broader point is practical: privacy is not only about hiding wrongdoing or choosing a political camp. It is about limiting how much control any institution—company, government or automated agent—has over personal information when circumstances change.
That argument fits Proton’s history. The company’s origin story places its founding in 2014 among scientists working at CERN, and Yen has long framed encryption as something that should be usable by ordinary people rather than reserved for specialists. Lumo extends that philosophy into AI, where usability and confidentiality are now forced to share the same room.
What privacy layer are you actually evaluating?
| Privacy layer | What Proton says about Lumo | What the reader should understand | Practical consequence |
| Conversation retention | Proton says Lumo keeps no server-side conversation logs. | This is a retention policy claim about server-side records. | Avoid assuming that “no logs” answers every question about live processing. |
| Saved chats | Proton says saved chats use zero-access encryption. | Stored-chat protection is different from protection during inference. | Saved history may have stronger protection than a prompt being actively processed. |
| Model training | Proton says user conversations and inputs are not used to train its models. | This describes stated data-use policy, not every technical step in processing. | Check the policy before sending sensitive material, and do not treat “no training” as “no access.” |
| GPU inference | Yen said the final interface for stronger cryptographic protection was still missing during the interview. | The processing layer is a separate technical question, and that reported status was time-specific. | Do not describe stored-chat encryption as proof of complete protection during inference. |
| Agent permissions | Yen says encryption cannot prevent an agent with broad device or account access from disclosing information. | Authorized access can defeat protections that work well for storage. | Restrict tools, accounts and credentials instead of giving an agent blanket control. |
What readers should conclude
Can AI and privacy coexist? Yes, in principle—but only when retention, training use, inference access and agent permissions are evaluated separately. Lumo is a useful example because Proton’s public design makes several of those layers explicit while Yen’s own explanation highlights the difficult boundary around GPU processing.
That does not make Lumo private or non-private in one sweeping verdict. It makes the right question more precise: which data is protected, from whom, at what moment, and under whose control?
For everyday, low-sensitivity tasks, Proton’s stated policies may offer a privacy posture that is more deliberate than services built around broad data collection. For secrets, credentials or highly personal material, the safer rule is simpler: do not send what you cannot afford to expose, use local processing where it genuinely fits, and keep AI agents on a very short leash.
Privacy is not a mascot, a slogan or a single checkbox. It is a chain. The chain is only as strong as its least-protected link.
