We hear the same question in almost every serious sales conversation, usually from someone doing a security review: "okay, but what does local-first actually mean?"

It's a fair question. Every meeting tool on the market now calls itself private. Most of them mean something narrow: your recording is encrypted while it travels to a server, and maybe encrypted while it sits there.

That's real security. It is not the same thing as local-first, and the gap between the two is exactly where GDPR gets complicated for most vendors.

What "local-first" literally means

When you record a meeting in Weeve, here is what happens. The audio is captured on your Mac. The transcript is generated on your Mac, using Apple's on-device MLX framework.

Speaker detection runs on your Mac. The summary is written on your Mac. At no point does the recording, the transcript, or the summary get sent to a server, ours or anyone else's.

No cloud AI provider is ever in the loop. No bot joins your call to capture it in the first place.

That wasn't always the case. Weeve used to offer an optional setting that let you connect your own Anthropic, Google, or OpenAI account and route summarization through the cloud. It was off by default, and almost nobody turned it on, which told us people were choosing Weeve specifically because they didn't want a cloud model touching their meetings.

We removed the option in April 2026. [1] There is no cloud path for your meeting content today, on or off, and no setting that brings one back. Once the models are downloaded, Weeve works with no internet connection at all.

That's the part worth being precise about, because "local-first" gets used loosely across this category. For us that's simply how the system is built. There's no setting to flip and no policy that could quietly change in a future update. It's the only path the data has.

The question underneath the question

The people asking about local-first are usually asking something more specific, even if they don't phrase it that way. A pattern we hear often, from IT leads and privacy-conscious operators alike: they already trust one system of record, often a coding or AI assistant they've vetted internally. They're wary of adding a second tool into the loop that touches the same sensitive conversations without the same scrutiny.

They want to know if it trains on the audio, where the files actually sit, whether they're anonymized before anyone else's model sees them. And if the content is going to end up back in a tool they already trust anyway, why it needed to pass through a third party's servers first.

That reaction makes sense in a category where "private" has been used to mean a dozen different things, most of which still involve your meeting leaving the building.

The GDPR questions this architecture removes

GDPR compliance for a cloud meeting tool is a real, substantial piece of work, and the vendors doing it properly deserve credit. It usually means data processing agreements with every sub-processor in the chain under Article 28 [2], a documented legal basis for each cross-border transfer under Chapter V [3], a retention and deletion policy someone has to actually enforce, and a clear answer to who could be compelled to hand your data over and under which country's law.

Done well, that's a thick binder of documentation, mapped article by article, often broken out country by country because the details shift depending on where your team sits.

Weeve mostly sidesteps that binder. There's nothing on the other side of it to solve.

If your meeting audio and transcript never leave your laptop, there's no sub-processor to sign a DPA with for that data, because there's no processor. There's no cross-border transfer question, because nothing crossed a border. There's no retention policy to write for content sitting on a server we don't have.

The compliance argument is a consequence of an architecture decision we made before compliance ever entered the conversation — we thought your meetings shouldn't leave your machine to begin with.

What still leaves the device, and why

Running a software business means some data has to leave the device, and it's worth being precise about what that is so the claim doesn't fall apart the moment someone checks.

Your account email and sign-in code, so we know it's you.

Your subscription status, so we know which plan you're on.

A monthly usage counter, so we can enforce plan limits.

Anonymous version checks, so the app knows when to update.

None of that is your meeting content. All of it is the ordinary account and billing data any subscription software needs, handled under the same rules as any other SaaS vendor's account layer, DPA included where one is needed.

That's the boundary of the claim. The part of GDPR that gets genuinely hard is sensitive conversation content moving through third-party infrastructure, and your meetings never enter that infrastructure in the first place.

What this means if you're the one doing the review

If you're evaluating Weeve for your team, the practical upshot is this: for the meeting content itself, there's no subprocessor to list, no cross-border transfer mechanism to review, no "where does the audio actually live" question to chase down with a vendor's support team.

That part of your due diligence gets short, because the architecture leaves less to verify in the first place.

That's the whole case: where the data goes, and where it doesn't.

Sources

[1] Weeve, "How Weeve stays private by default."
https://getweeve.io/blog/how-weeve-stays-private-by-default

[2] Regulation (EU) 2016/679 (GDPR), Article 28 — Processor.
https://gdpr-info.eu/art-28-gdpr/

[3] Regulation (EU) 2016/679 (GDPR), Chapter V — Transfers of personal data to third countries or international organisations (Articles 44–49).
https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:02016R0679-20160504