You do not need to read the whole policy. Search it for four answers: where entries are stored, whether they are used for training, who can access them, and what happens on deletion. Ten minutes and a page search will settle the questions that actually affect your journal, and the wording around those four answers tells you more than the length of the document ever does.
Track journal content separately from account data
Use page search for words such as content, entries, prompts, model, training, retention, deletion, subprocessors, and legal requests. Notice whether the policy treats what you write differently from your email address, device information, or anonymous usage statistics.
This distinction is where most confusion happens. A policy can be entirely accurate when it says data is used to improve the service and still mean something very different depending on whether “data” includes the paragraph you wrote about your marriage or only the fact that you opened the app on a Tuesday.
Pay attention to phrases such as may use, service improvement, and legitimate interests. These are not automatically alarming, but the surrounding explanation should tell you whether personal journal text is included.
Which four answers should you extract from the policy?
If you get nothing else from the document, get these. Write them down in your own words; if you cannot, that is itself the finding.
- Training: is entry text used to train or fine-tune models, and is that on by default?
- Human access: can staff, contractors, or reviewers read entries, and under what conditions?
- Third parties: which model providers or subprocessors receive your text, and what are they permitted to keep?
- Deletion: what does deleting remove, how quickly, and how long do backups hold it?
Which words in a privacy policy deserve a second look?
Certain constructions carry more weight than they appear to. “Aggregated and de-identified” can mean genuinely anonymous statistics, or it can mean your text with the obvious identifiers stripped, which is a much weaker protection for a journal.
“Affiliates” quietly widens the set of companies involved. “We may share as required by law” is standard and unremarkable. “We do not sell your data” is often true and says nothing about sharing, processing, or training, which are the parts that matter here.
Compare the policy with the controls you can actually use
A strong policy is more useful when the product offers matching settings: export, entry deletion, account deletion, memory controls, and a way to contact support. Check the effective date so you know how current the document is.
A promise you can verify inside the app is worth more than a paragraph you cannot. If the policy says memory is optional, the switch should be findable in under a minute; if it says you can export, do it once and open the file.
If an important answer remains ambiguous, ask the company directly and save the response. Clarity is part of the product, especially when the product asks for intimate context. A vague reply to a direct question is a real answer, just not the one they intended to give.
Why the policy is not enough on its own
Read the policy, but do not mistake it for a description of the software. The evidence on this is unusually direct.
When researchers examined twenty-five popular mental health apps in 2026, every one of them contained at least one tracker that its privacy policy did not mention. More than two-thirds failed to disclose half of the trackers present. Runtime testing found apps contacting analytics domains that appeared nowhere in their documents. The policies were not describing the products.
So treat the policy as the company's best-case account of itself. It tells you what they are prepared to commit to in writing, which is genuinely useful information. It is just not the same thing as what the app does.
The controls in the settings screen are better evidence, because they are the part the company had to actually build.
The five words worth searching for
Skip the reading. Use the search function on these five terms and you will extract most of what matters in under ten minutes.
- "train", whether your entries improve a model, and whether that is a default or a choice you made
- "subprocessor" or "third party", which other companies touch your text. A policy that names them is being straight with you; one that says "trusted partners" is not
- "retention", how long things persist after you delete them, and whether backups are mentioned at all
- "aggregate" or "de-identified", the clause that permits use of your material once it has been stripped of obvious identifiers, which is broader than most readers assume
- "acquisition" or "merger", what happens to your journal if the company is bought. This is the most common way privacy terms change, and it is almost never announced loudly
What de-identified actually means
This is the clause that does the most work while attracting the least attention, and it deserves a paragraph of its own.
De-identification removes obvious identifiers: your name, your email, your account number. It does not remove the content. A journal entry stripped of your name is still an account of your divorce, your diagnosis, or your job, written in your voice, containing the names of people around you. Whether that is meaningfully anonymous depends entirely on how distinctive the writing is, and personal writing is distinctive by nature.
The January 2026 order requiring OpenAI to hand over twenty million conversation logs was for de-identified logs. That is what the protection amounted to in practice: the records still moved.
So when a policy reserves the right to use de-identified data broadly, read it as a right to use your writing with the label removed. That may be entirely acceptable to you. It should be a decision rather than a surprise.
Sources
This piece is part of ai journal privacy. A journal only works if you trust it. These reads cover what happens to your entries, the difference between on-device and cloud processing, and the questions worth asking any app.