Proton Scribe Launch: Privacy-First AI Writing Assistant

Proton released a writing assistant for its business plans last Thursday. It drafts and rewrites email, it costs around three dollars per user per month as an add-on, and it can run either in the browser on the user's own machine or on Proton's servers with an undertaking that nothing is logged or used for training. As a product launch it is modest. As a procurement test case it is one of the more useful things to appear this year, because a company whose entire proposition is end-to-end encryption cannot add an assistant without answering the question everyone else has been allowed to leave vague.

An end-to-end encrypted mailbox cannot have a server-side assistant without deciding, explicitly, where the encryption ends

That is not a criticism of the vendor. It is the reason this launch is worth reading closely.

What the two modes actually mean

Composition happens on the client, before anything is encrypted and sent. So an assistant that runs locally in the browser sits inside the existing guarantee: the text never leaves the device, and the provider's inability to read your mail is unchanged. The server-side mode is a different kind of promise. The text of your draft is transmitted to the provider's infrastructure, processed, and returned. The commitment that it is not logged, retained or used for training is a policy and contractual assurance, which is what every other vendor offers. It may well be honoured. It is not the same category of claim as cryptography, and the substitution should be conscious rather than absorbed. Both modes are defensible. Presenting them as equivalent is the only mistake available here.

The hardware caveat that decides which mode you actually get

Local inference requires a machine with a dedicated graphics processor and several gigabytes of video memory. That describes a developer workstation, a design machine and almost nothing else in a normal corporate fleet. The typical business laptop — integrated graphics, sixteen gigabytes of system memory — will fall back to the server mode. So the honest reading is that the privacy-preserving option exists, is real, and will be used by a small minority of your users. Do not write a policy that depends on a mode your hardware cannot run, and do not let a vendor answer a compliance question with a capability that only a tenth of your estate can reach.

The generalisable test

Strip away the specific vendor and you get five questions that should now attach to every artificial intelligence feature appearing in software you already own. Where does the inference run. What is retained, in what form, and for how long. Is any of it used to improve the model. Is the feature on by default. And who in your organisation can switch it off. The last two matter more than they look. Features of this kind rarely arrive through procurement. They arrive through a release note, enabled for everyone, in a product that cleared review three years ago under a description that no longer fits.

Governance arrives at renewal, not at purchase

The practical consequence is that your vendor inventory is now out of date in a way that a vendor list cannot express. You need a feature inventory: which of your existing tools have added generative capabilities in the last year, which are enabled, what data they touch, and whether the contract you signed covers the new processing. That exercise usually takes a day and usually produces at least one surprise. The three-dollar price point is part of the problem — it is small enough to be approved by anyone with a card and far too small to trigger a review, while the data question it raises is identical to the one you would spend six weeks on for a six-figure platform.

Practical Guidance for Privacy-First AI Tooling Strategy

• Build a feature inventory, not just a vendor list.
• Ask where inference runs for every assistant in your stack.
• Get retention and training terms in the contract, not the marketing page.
• Check what is enabled by default after each vendor release.
• Confirm your hardware can run any local mode you rely on.
• Decide which content classes may leave the device and say so plainly.
• Name an owner for approving new assistant features.
• Keep administrative access to business records whatever tooling you adopt.

The Regional Angle

There is a complication with privacy-first tooling in this market that rarely appears in the vendor's own materials. Products built so that the provider cannot read your content also make it difficult for your own organisation to read it, and regional businesses operate under conditions where that matters: regulator information requests, disputes where the company must produce correspondence, internal investigations into procurement or payments, and government or semi-government contracts carrying record-production undertakings. A mailbox the employer cannot access is a strong privacy position and a weak evidentiary one. Before adopting any encryption-first platform, confirm what administrative access, legal hold and export capability you retain over business records, and get it in writing. The correct outcome is usually a tool that protects content from the provider while preserving the employer's access to its own records — those are separable, and vendors do not always separate them for you. The second is confidentiality, which in regional professional services, family offices and advisory firms is contractual rather than merely ethical. Engagement letters, non-disclosure agreements and government contracting terms were written before generative assistants existed, and they typically restrict disclosure to third parties without defining processing. The conservative reading — and the one a client's counsel will take — is that transmitting the substance of a client matter to a vendor's inference service is a disclosure requiring consent. Review the standard engagement terms now, add a short processing schedule that names the categories of tooling used, and give staff a clear rule about which client content may be pasted into an assistant of any kind. One paragraph in the engagement letter costs nothing; the alternative is discovering the gap during a dispute. The third is the fleet, and it is a budget question disguised as a technical one. Regional device estates skew towards inexpensive hardware with integrated graphics, refreshed on long cycles, frequently shared in operational roles. Any strategy premised on local inference is therefore premised on a hardware refresh nobody has budgeted. Two sensible responses: either accept server-side processing for most users and control it contractually, reserving local-only tooling for the small set of roles handling the most sensitive material, or specify graphics capability in the next refresh cycle for those roles specifically. What does not work is a policy that assumes on-device processing across a fleet that cannot perform it, which is how a compliance answer quietly becomes fiction.

The objection worth taking seriously

The strongest objection is that privacy-first assistants are a positioning exercise. The models small enough to run in a browser are markedly weaker than the frontier systems people are comparing them to, users will notice within a week, and the ones who care about output quality will simply paste the same text into a better tool on their phone. Meanwhile the server-side mode — which is what almost everyone will actually use — offers precisely the contractual assurance that every mainstream vendor already offers, dressed in stronger language. On that reading you pay a quality penalty for a difference that exists mainly in the marketing. The quality gap is real and the shadow-usage risk is the sharper half of the argument. What the objection misses is that the value here is not the product, it is the disclosure. A vendor forced by its own architecture to state where inference runs sets a standard the rest of the market can be held to, and the five questions above are far easier to ask once one supplier has answered them in public. The organisations that will handle this well are not the ones that standardised on the most private tool. They are the ones that can say, for each assistant in their estate, where the text goes and what happens to it — and that capability is worth building on a three-dollar add-on rather than on the platform that will matter next year.

Common Questions

Is server-side processing acceptable for confidential material?

Often, provided the contract addresses retention and training and your own confidentiality undertakings permit it. The point is to decide deliberately rather than by default.

Should we block assistants until we have a policy?

Blocking without providing an approved alternative reliably moves the activity to personal devices, where you have no visibility at all. Supply something sanctioned while the policy is written.

How do we find features that were switched on without us noticing?

Read release notes for your top ten tools, check administrative consoles for newly enabled settings, and ask each vendor directly what generative features shipped in the last twelve months.

What should we expect over the next twelve months?

Expect assistants to appear in essentially every collaboration product you own, mostly enabled by default and mostly without a contract amendment. Expect on-device inference to improve as smaller models get better and as hardware with dedicated inference capability reaches mainstream laptops, though not fast enough to change your fleet this year. Expect enterprise buyers to start demanding processing location as a contractual term rather than a support-page statement. And expect the first uncomfortable disclosure dispute involving an assistant and a client matter, which will do more for adoption of these controls than any policy document.

---

Privacy-First AI Tooling Strategy — we inventory the assistants already switched on in your stack and tell you where your text is actually going.