Mentavo
People write things in a journal they tell nobody else. Which is why "private" appears so often in app store listings — and why what it means is so rarely spelled out.
The word covers at least three different arrangements. Your entries sit only on your device. Or they sit on a server but are encrypted. Or they sit on a server, are technically readable, and simply aren't sold. All three get marketed as private, and only the first means nobody else can read them.
This piece doesn't recommend an app. It describes which questions you can put to a privacy policy, and how to tell whether they're being answered.
The short version
- "Private" is a claim, not a technical property — what counts is what the policy says.
- The key distinction: local only, encrypted on a server, or readable on a server.
- Once an app has an AI feature, text leaves the device as a rule — that can't be combined with real end-to-end encryption.
- "We don't sell your data" answers none of the relevant questions.
- The informative sections are retention, recipients and international transfers — not the introduction.
- An app that states precisely what gets transmitted is usually more trustworthy than one that only says "secure".
Why "private" means three different things
Local. Entries live on the device only. Nobody but you can read them, the provider included. The price: no device switch without a backup, no view across longer periods, and no AI feature that knows the text.
End-to-end encrypted. Entries sit on a server in a form the provider cannot decrypt. More convenient than local-only, and equally incompatible with features that process the content.
Stored on a server, technically readable. The normal case for anything that does more than store: search across entries, summaries across months, AI replies. Here the technology isn't what decides — what decides is what the provider commits to, logs, and permits access to.
None of the three is inherently better. They're simply different, and many apps leave open which one they're in.
Seven questions to put to a privacy policy
1. Where do my entries live?
The answer should be a place, not an adjective. "Stored securely" is not an answer. "On servers in … operated by …" is.
Worth keeping apart: where the company is incorporated, where the servers are, and who operates them are three separate facts. Servers in Europe operated by a company outside it is a different situation from both being in Europe — and serious policies write that down.
2. Can the provider read them?
Rarely answered head-on, and usually answerable indirectly. Is there full-text search across old entries? An automatic summary? An AI reply that refers to earlier entries? Then the content is readable. Nothing else would be technically possible.
That isn't an accusation — it follows from the feature. It only becomes a problem when "end-to-end encryption" is advertised at the same time.
3. Does my text go to an AI model — and which one?
If an app responds to entries, the text almost always passes through a model run by a specialist provider. The policy should name that provider rather than referring to "our AI partners".
The second half of the question matters more: what exactly is transmitted? The current entry? The last thirty? Mood values, goals, appointments? A good policy lists it. A weak one says "relevant content".
4. Is my text used for training?
Two things are worth separating here: whether the app provider trains on it, and whether the AI provider does. Both need to be stated individually.
It is now common for data submitted through an API not to be used for model training unless explicitly agreed, while being retained for a limited period for abuse detection. If an app says nothing at all about this, that's the gap, not the reassurance.
5. How long is it kept — including after I cancel?
The retention section is the most honest part of any privacy policy, because it's hard to dress up. Concrete periods should be stated, separated by type of data.
If that section is missing, or says only "as long as necessary", you know exactly as much after reading as before.
6. What happens when I delete my account?
Three variants are common and differ considerably: immediate deletion, deletion after a grace period, or deactivation with retention. Good apps have a deletion function inside the app and describe what still exists afterwards — billing records that must be kept, for instance.
7. What else is collected without my noticing?
Many journaling apps collect more than text: crash reports, usage statistics, subscription data, sometimes health or calendar data. What matters is less whether this happens than whether each piece can be switched off individually and is off by default.
The "recipients" section often answers this more clearly than the introduction. A list of five service providers is not a bad sign — it's an honest one.
How to recognise an answer that dodges
Four formulations recur and sound better than they are:
- "We don't sell your data." Answers none of the seven questions. Almost nobody sells journal entries; who can see them is the interesting part.
- "Military-grade encryption." Usually describes transport and storage — the state data is already in with nearly every service.
- "Your data belongs to you." A statement about ownership, not about access.
- "Privacy is our highest priority." A sentence with no checkable content. If it's the most detailed passage on the subject, that itself is the information.
A useful test: after reading, can you say in one sentence where an entry goes once you tap save? If not, the policy is incomplete, however long it is.
The trade-off nobody can remove
There's no way to have both in full: entries that never leave the device, and a feature that shows connections across months or responds to what you've written.
If writing is the point, a local-only app is the better fit. If you want many entries to add up to something readable, you're accepting a server — and should therefore know exactly which one, what sits on it, and for how long.
What it means to entrust personal thoughts to a system at all, independent of the technology, is covered in the piece on telling an AI something personal.
How Mentavo handles it
So that the standard isn't only applied to others, briefly and checkably: entries in Mentavo sit on a server rather than only on the device — which is precisely why they can be viewed across months alongside mood, goals and routines. The service runs in the "EU West" region in Amsterdam; the operator is a US company. Both halves are stated, because the second belongs to the picture.
For AI replies, text is transmitted to OpenAI; which content that is in each case is listed individually. Calendar and Apple Health are separate switches and off by default. Retention periods are given by data type in the privacy policy, together with the list of every service provider used.
None of that says Mentavo is more private than other apps. It's the answer to the same seven questions, in a place where you can read it.
What this article doesn't claim
This is not legal advice and not an assessment of individual providers. Privacy policies change, and what they say today need not hold in a year.
The piece also doesn't claim that server-based apps are unsafe or that local apps are safe. Both depend on implementation and commitments that can only be verified from the outside to a limited degree.
If you record highly sensitive material — connected to treatment, legal proceedings or a situation involving risk — the decision shouldn't rest on a privacy policy alone.
In closing: read the retention section first
If you're short on time, skip the introduction. The three sections that actually say something are named roughly the same in every policy: recipients, international transfers, retention.
If they contain names and periods, the provider has committed to something. If they contain adjectives, the provider has avoided committing.
And if an app responds to what you write, something is reading your text. The question isn't whether — it's what, for how long, and under which commitment.
