Proton’s Lumo puts privacy first in AI chat, and that actually changes the product

Proton has launched Lumo, an AI assistant for web, Android, and iOS built around a privacy stance most consumer AI products still avoid: your prompts aren't supposed to become a durable company asset.

The pitch is simple. Lumo encrypts chats end to end, keeps no readable conversation logs on Proton’s servers, supports anonymous use without an account, and runs on open-source language models instead of a closed stack from OpenAI, Google, Anthropic, or a Chinese provider. Proton is also running inference in European data centers and connecting the product to Proton Drive for document Q&A.

That changes the trust model.

Most AI chat products still ask users to tolerate a blurry line between assistance and retention. Vendors may say they don't train on your data, then keep prompts anyway for safety, debugging, abuse detection, analytics, or legal reasons. Proton is trying to cut that down hard.

What Proton is shipping

Lumo is available through a web client at lumo.proton.me and native mobile apps. You can use it without creating an account. You can also upload files directly or pull documents from Proton Drive and ask questions about them.

The privacy case rests on three choices:

• Zero-access encryption for chat data
• No-log handling for conversations
• Open-source LLMs underneath

Proton says conversation content is encrypted client-side and only decrypted on the user’s device. That matters because it keeps Proton out of plaintext access. If the implementation holds up, Proton can store ciphertext but can't casually inspect chats, mine them for telemetry, or hand over readable transcripts it never had.

There’s also a ghost mode that drops session state when you leave. No saved history. No retrievable server logs. No quiet pileup of metadata because someone set the default retention policy to "just in case."

For a company built on encrypted email and storage, this tracks. In AI, it's still unusual.

The technical part that matters

The source material says Lumo uses a crypto stack close to Proton’s existing security architecture: ed25519 for signing, x25519 for key exchange, and ChaCha20-Poly1305 for symmetric encryption of chat content. That's standard, battle-tested stuff. No homemade crypto.

The basic flow looks like this:

1. The client generates keys.
2. Conversation data is encrypted locally with a symmetric session key.
3. That session key is wrapped with the user’s public key.
4. Proton stores encrypted payloads.
5. Decryption happens on the client.

The obvious upside is breach resistance. If someone gets into Proton’s servers, they should find encrypted blobs instead of readable chats.

There’s a second upside, and it matters just as much. This kind of design limits what the company can do later. A lot of vendors talk about privacy while keeping full internal access in reserve for policy changes, legal pressure, or a product team that wants more data. Zero-access systems narrow those options by design.

That’s the right move.

The caveat: inference still runs server-side

There’s one line engineers should focus on. Lumo appears to run model inference on Proton’s EU GPU infrastructure, using open-source models including Meta’s Llama 3 and Mistral 7B.

So this is not a fully on-device assistant. It still needs server-side compute to answer questions. The privacy model depends on how Proton handles the line between encrypted storage and live inference.

That line matters.

If the model is generating a response on Proton’s servers, some form of prompt content has to be usable during inference. The source material describes encrypted conversations stored server-side, with decryption only on the client. It also says inference runs in Proton’s data centers. Those claims can both be true, but only with careful session handling and a narrow window where plaintext is available to the inference system in memory and not written to logs or durable storage.

That’s a meaningful distinction. It’s still better than standard SaaS AI retention. But it isn't magic. If you were evaluating this for legal, medical, or internal corporate use, you'd want a lot more detail on:

• whether prompt plaintext ever exists outside transient memory during inference
• whether application logs, traces, or crash dumps can capture prompt fragments
• how uploaded files are chunked, indexed, and deleted
• what metadata remains even when content is erased
• how abuse prevention works without creating shadow logs elsewhere

Privacy claims in AI stand or fall on operational details.

RAG under encryption gets messy fast

Lumo supports document uploads and Proton Drive integration, which means retrieval-augmented generation. According to the source material, it builds an encrypted vector index on the server with something like FAISS or hnswlib, then uses that index to retrieve context for the model.

This is usually where the clean story around private AI starts to fray.

Semantic retrieval needs embeddings, indexing, ranking, and context assembly. Those systems work best when the server can operate on useful data representations. Fully private retrieval is much harder than encrypting stored chat history. Private information retrieval exists, but it's expensive and awkward at interactive latency. Homomorphic encryption is even less practical for general-purpose chat today.

So Proton seems to be taking the pragmatic route. Encrypt data at rest, keep retention tight, confine processing to controlled EU infrastructure, and use open models it operates itself. For real deployments, that's a sane compromise.

Still, teams should keep the categories straight. Stored data protection and private computation are not the same thing. Lumo appears strong on the first. The second is still limited by how current AI systems work.

Open-source models are a real strategic choice

Proton says Lumo uses only open-source LLMs and avoids dependence on US or Chinese AI giants. Some of that is positioning. Some of it is architecture and geopolitics.

Open weights give Proton a few concrete advantages:

• It can host the models itself.
• It doesn't have to send prompts to a third-party API.
• It can audit model provenance and update schedules more directly.
• It avoids a lot of cross-border data transfer and vendor lock-in problems.

That matters for European enterprises. So does data residency. If your compliance team already hates the idea of corporate prompts moving through a US cloud vendor with opaque retention rules, Lumo is a much easier sell.

There are trade-offs. Open models still lag the strongest proprietary systems on some reasoning tasks, coding depth, and multimodal polish. Mistral 7B is efficient and lightweight, but it isn't in the same class as the top frontier models. Depending on the exact Llama 3 configuration Proton is using, users will probably feel that gap on harder tasks.

That’s the trade. Better privacy posture, tighter infrastructure control, lower ceiling on raw model capability.

Plenty of teams will accept that.

Performance matters, and so does restraint

The source material claims sub-2-second responses for typical queries, with GPU caching and batch scheduling helping reduce latency. That sounds plausible, especially if the system is tuned around relatively compact open models and constrained context windows.

The pressure comes later, if usage grows and document chat takes off. RAG pipelines cost more than basic chat. Parsing files, generating embeddings, indexing documents, retrieving context, then generating across multi-turn conversations all add latency and expense.

That creates a familiar temptation: keep more data around, centralize more context, optimize harder around user history. A lot of AI products drift that way because it improves UX and reduces repeated compute.

Lumo’s credibility depends on not drifting.

Why technical teams should care

Even if you never touch Lumo, Proton is testing an approach most AI vendors have sidestepped: privacy as a hard product constraint.

A few points stand out.

First, client-side encryption changes system design early. Key management, session recovery, mobile secure storage, sync behavior, and support flows all get harder. You don't bolt this on later.

Second, open models plus self-hosted inference are still the cleanest path for privacy-sensitive AI. If you want real control over retention, residency, and auditability, sending core prompt flow to someone else’s API is a bad foundation.

Third, RAG is the weak seam in nearly every private-AI pitch. That’s where the hard questions belong. How are embeddings stored? Are indexes encrypted? What metadata survives deletion? Can admins inspect retrieved chunks? A lot of products turn back into ordinary SaaS at that layer.

And fourth, zero-log claims need proof. Security teams should ask for architecture docs, open-source client code, external audits, and clear retention semantics. "We don't log" is easy to print. Enforcing it across observability stacks, reverse proxies, queues, and GPU-serving infrastructure is harder.

Proton has more credibility here than a random startup, mainly because encrypted products are already its business. Even so, AI trust should require more than good branding and vague promises.

Lumo matters because it takes a position the rest of the market has mostly avoided: an AI assistant doesn't need to become a permanent record. That should've been standard much sooner.