An AI assistant can make a journal more useful, but only if its input boundary is explicit. “Private” cannot mean that protected writing is excluded from staff view while a background job quietly sends it into embeddings, summaries, or an AI provider.
Why history leakage changes the question
In March 2023, a bug allowed some ChatGPT users to see titles from another active user's chat history. OpenAI's incident write-up illustrates a broader point: even a small derived field can be private, and systems that process sensitive text need strict tenant, cache, and input boundaries.
AI starts with an input inventory
Before choosing a model, a product should name every source that can reach the feature: a Memory body, title, link, attachment, tag, summary, embedding, event log, cache entry, or support export. “The model is private” is not an answer to where those values came from or where they travel afterward.
Protected Memories are excluded
Inpages' embedding service returns without scheduling protected Memories, and the journal-insight corpus selects only records whose encrypted state is false. When a Memory becomes encrypted, the service removes the server-derived journal insight. This preserves the rule that Rails should not need protected plaintext to create a useful server-side derivative.
Derived data can create another leak
Encrypting the source but keeping a readable summary, vector, preview, or generated title can recreate the disclosure risk in a second database column. Derived data needs its own lifecycle: exclusion on creation, clearing on the protection transition, access control, export handling, and deletion behavior.
A future feature needs an explicit choice
If a future client-side or server-side assistant can inspect protected writing, it needs a separate product decision and plain consent language. The choice should name what will be read, where it will be processed, whether an external provider receives it, and how the result can be removed. Convenience is not a reason to weaken a protected boundary invisibly.
What encryption does not prove
This exclusion does not prove that cache isolation, authorization, or every future integration is flawless. It narrows one important input path. The wider encryption threat model and analytics boundary remain necessary when evaluating private AI features.