August 18, 20266 min read

AI Assistant Privacy: What Local-First Actually Changes

"Local-first" gets used as a privacy claim far more often than it earns one. Here's what running an assistant on your own machine genuinely protects, what it doesn't, and the questions worth asking.

ByLokesh Kumar· Founder & Builder, Vyra
Share on XShare on LinkedIn

The short answer

Running an AI assistant locally protects one specific thing very well: the content of requests that the local model handles never leaves your machine. It protects almost nothing else automatically. An assistant can be local-first and still send your calendar to a cloud API, still log your voice transcripts to a server, still call a hosted model the moment a request looks hard. "Local-first" describes where the default lives, not a guarantee about where every byte goes.

That distinction matters because a personal assistant is, by construction, the most invasive software you will ever install. It's designed to know your people, your projects, your commitments and your unfinished arguments. The privacy question isn't philosophical — it's about which of those things cross a network boundary, when, and whether you can tell.

What actually leaves the machine, and when

Any assistant that mixes local and cloud models has a routing decision at its centre, and that routing decision is the privacy boundary. In Vyra's case it's a 5-tier model router — Local, Fast, Creative, Thinking, Ultra — choosing per request rather than per session.

When the Local tier handles a request, the prompt and the retrieved memory context stay on your machine. When a cloud tier handles it, they don't: the prompt, and whatever context was assembled for it, are sent to a hosted model. That's inherent to using a hosted model, and no amount of local-first framing changes it.

The useful property isn't that this never happens. It's that it's a visible, per-request decision rather than an invisible default — you can reason about which class of work stays local, instead of hoping.

The four boundaries worth separating

Most privacy confusion comes from collapsing distinct things into one word. It helps to keep them apart:

An assistant can be excellent on one of these and careless on another. Evaluate them separately.

What local-first genuinely buys you

Three things, and they're real:

No third-party retention of local-tier content. Whatever the Local tier handles is not stored, logged or used for training by anyone, because it never arrived anywhere. For the substantial fraction of assistant work that's triage, classification, drafting and retrieval over your own memory, that fraction is larger than people expect.

Function without trust in uptime. Privacy and availability turn out to be the same architectural property viewed from different angles. A system that can run without the network can also run without disclosing to the network.

A smaller blast radius. If a hosted provider has an incident, your exposure is limited to what you actually sent them. Local-first shrinks that set.

What it doesn't buy you

It doesn't make the device secure. Memory stored on your machine is protected by your machine. Full-disk encryption, screen lock and OS-level access controls are doing that work — the assistant is not.

It doesn't cover the actions. Every integration is a disclosure to that integration. An autonomous web agent filling a form is sending data to whoever operates that form.

It doesn't remove the need to read the routing policy. "Falls back to cloud for hard requests" is a reasonable design. It's also a statement that hard requests — often the most sensitive ones — are the ones most likely to leave.

It doesn't imply the vendor collects nothing. Local inference and cloud telemetry coexist comfortably.

Common questions about AI assistant privacy

Is a local AI assistant more private than a cloud one?

For the requests it handles locally, meaningfully yes — that content is never transmitted, so it can't be retained, subpoenaed or used for training. But "local assistant" almost always means "local-first assistant with cloud tiers," so the honest comparison is per-request rather than per-product. Ask which classes of request stay local, not whether the product is local.

Does an AI assistant with persistent memory store my data on a server?

It depends entirely on the implementation, and it's the first thing to check. Vyra keeps episodic memory and the structured world model on the device, which is why memory retrieval continues to work with no connection at all. Assistants that store memory server-side get the same feature with a different trust model — neither is inherently wrong, but they are not interchangeable.

Can I see and delete what my AI assistant remembers?

You should be able to, and if you can't, treat that as the answer to the privacy question. Memory that can't be inspected or corrected is a liability rather than a feature — both because stored mistakes compound silently, and because deletion is the only real remedy once something sensitive has been recorded.

Does using a cloud model mean my data trains it?

Not necessarily — many providers exclude API traffic from training by default — but the guarantee comes from that provider's terms, not from the assistant sitting in front of it. If it matters to you, the policy to read is the model provider's, and the setting to check is whether the assistant lets you restrict which tiers are eligible for which kinds of work.

What's the single most useful question to ask a vendor?

"Which requests leave the device, and can I see the routing decision after the fact?" It's harder to answer vaguely than "are you private," and the quality of the answer tells you most of what you need to know.

Worth knowing before you rely on this

Vyra is in closed alpha, moving to a Founders Beta ahead of a public launch in 2026. The architecture described here — on-device memory, a local Ollama tier as the routing floor, cloud tiers above it — is how the system is built, and the routing behaviour is the thing to scrutinise rather than take on faith. If privacy is the deciding factor for you, the questions in this post are the ones worth putting to us directly, and to anyone else you're evaluating.

Vyra is in closed alpha now, with a Founders Beta ahead of public launch in 2026.

More from the blog