If you journal in a cloud app, your entries are stored on a server you do not control. That was always true. What has changed is what happens next.
AI features are now built directly into cloud productivity tools — summarizing, suggesting, indexing, and in some cases training on what users write. The line between "private note" and "data the model has seen" has become less clear, and the terms of service that govern it can change faster than most people read them.
This is not a hypothetical. It is an architecture question: what does your journaling app actually do with the text after you type it?
The cloud storage problem, restated
Cloud journaling apps store your entries on remote servers. To do that, they need to decrypt your writing at some point — to index it, display it across devices, or run features against it. Even apps that use client-side encryption often process plaintext on the server for features like full-text search or AI assistance.
The result is that your entries exist, in plaintext, on infrastructure you do not own. The app's privacy policy describes what the company promises to do with that data. It does not describe what is technically possible.
That gap matters more now than it did five years ago. The same writing that trained a personal summary feature this year could inform a model update next year. Whether that happens depends on corporate policy choices, not on anything you control.
What privacy settings actually protect you from
Most cloud apps give you some version of a privacy toggle — opt out of data sharing, opt out of training, disable AI features. Those settings are real and meaningful. They also have limits.
A setting is a policy choice made by the company today. It can change. Terms of service updates, acquisitions, new product directions, and regulatory pressure can all shift what a setting means or remove the option entirely. If the data exists on a server, the range of what can happen to it depends on what the company decides, not what you set.
This is different from a structural guarantee. A structural guarantee is not a policy — it is a property of how the software works. An app that never sends your entries off your device cannot expose them to server-side AI processing, regardless of what features ship next year.
What local-first actually means for AI exposure
A local-first journal stores entries on your machine, encrypted, and does not send them to a server. There is no server-side AI pipeline that can process your entries because the entries are never there. The protection is not a setting — it is a consequence of the architecture.
That distinction is worth being precise about. "Offline mode" in a cloud app usually means the app queues your changes and syncs them when connectivity returns. The data still travels to the server; the delay is just longer. Offline mode is not the same as offline storage.
A genuinely local-first app has no sync destination. The data stays on the device because there is no remote database to write to. When there is no server, there is no server-side policy to worry about.
For journaling specifically — which involves long-term, personal, often sensitive writing — that architectural boundary is more durable than any privacy setting.
The encryption question
Encryption is often cited as the solution to cloud privacy concerns. In some contexts it is. But the details matter.
Client-side encryption, where entries are encrypted before they leave your device, does prevent the server from reading raw entry text. If implemented correctly, it is a meaningful protection.
The weaker version — encryption at rest on the server, or encryption in transit — does not protect entries from the server itself. The app still decrypts on the server to run features, and the entry content is visible to the infrastructure at that point.
Even strong client-side encryption does not change the ownership question. The company still controls the server, the encryption key management, and the terms under which your data is kept or deleted. A future key escrow requirement or a forced upgrade to a new key management scheme can change the picture without you doing anything wrong.
The most direct answer to the AI exposure question is not "good encryption on a cloud server." It is "entries that never reach a server in the first place."
Where Mini Diarium fits
Mini Diarium is a private offline desktop journal. Entries are stored in an encrypted SQLite database on your machine. Each entry is encrypted with AES-256-GCM before it is written to disk — the plaintext of your writing is never stored anywhere unencrypted.
The app has no HTTP client. It cannot send entries to a server because it contains no code to do so. There is no sync service, no account requirement, no telemetry, and no cloud dependency of any kind. The protection is not a setting you configure — it is a property of how the software was built.
That means an AI policy change at a cloud company, a new terms of service update, or a new AI feature rollout does not affect entries stored in Mini Diarium. There is no server for those changes to reach.
If you want to understand the encryption model in more detail, the encrypted journal guide covers AES-256-GCM, how key management works, and what "encrypted at rest" means in practice. For a direct comparison of cloud and local architectures, the post on encrypted journal apps vs cloud notes apps covers the structural differences.
The practical takeaway
AI access to your writing is not mainly a question of intent. It is a question of architecture. If entries are stored on a server, the range of what can happen to them is determined by the company that controls the server, now and in the future.
A local-first encrypted journal removes that variable. Not by offering better settings, but by removing the server from the equation entirely.
If that structural guarantee matters to you, the encrypted journal guide is the clearest starting point. Mini Diarium is available for Windows, macOS, and Linux and requires no account to use.