On this page
An assistant preparing a meeting brief may need to read the invitation, the latest project document, and a short exchange about what remains undecided. That is a reasonable request. It may also be able to find an old private note about a colleague, a personal appointment adjacent to the meeting, and a draft that was never sent.
All of this information can be relevant to the person. Very little of it is necessarily relevant to the brief.
Personal AI changes the privacy question because it makes separate records usable together. Earlier software often exposed one object at a time: a search result, a file, an address book entry. An assistant can assemble an explanation from several sources and present the result as one coherent account. The useful part is the connection. The risk is also the connection.
Privacy, in this setting, protects the difference between what a system can know and what it is entitled to use for a particular task. That distinction is harder to preserve than a closed database.
From access to inference
A calendar entry marked "dentist" says something fairly narrow. An assistant with access to years of entries, email and travel history may draw conclusions about someone's routine, relationships, or condition. Those conclusions might be wrong. The mistake may still affect how the assistant speaks or acts.
A record is not harmless because it has no sensitive label. A project title can reveal a pending departure. A pattern of meetings can expose a negotiation. A reply left in drafts can show that someone considered an accusation and decided not to make it. These examples do not depend on secret documents. They depend on ordinary records joined at scale.
The first form of protection is therefore contextual. A meeting brief should not become an unauthorized analysis of a person's private life simply because the assistant can produce one. The user should be able to ask a work question without handing over every signal that could be interpreted about them.
This does not require pretending the assistant never makes inferences. If it is asked whether a deadline is at risk, it may have to connect an unanswered message, a changed calendar entry, and a delayed file update. The system needs to preserve a distinction between records and interpretations, and make it possible to see the basis of the answer.
An inference carries uncertainty and can outlive the source that suggested it. A model that silently stores "this person is unreliable" because three meetings moved would be worse than a search engine that returned three calendar entries. Privacy includes protection from a speculative characterization becoming permanent background knowledge.
The boundary moves when the answer is sent
People often ask whether their data is stored locally or in the cloud. This is a necessary question, but it does not settle what happens next. A local index can retrieve sensitive material and send it to a remote assistant in a single request. Conversely, a carefully configured remote service may receive only a narrow result.
The relevant sequence is collection, storage, retrieval, selection, transfer, use and retention. A promise about one step cannot stand in for a description of the others.
Zortex's current application policy provides a concrete example. Connected Google information is synchronized into a vault and searchable index on the user's device. OAuth authorization and token refresh for the shared Google client pass through a Cloudflare-hosted broker. Its inspected handler processes authorization credentials rather than Gmail message bodies or Drive documents. That is a narrower statement than "Google never sends anything off-device." The broker is off-device, and infrastructure logging and metadata remain separate questions.
OAuth secret cells use AES-256-GCM authenticated encryption. The policy explicitly does not claim application-level encryption for every synchronized record or metadata field. Where the operating system protects storage, the platform and configuration still matter. A single encryption claim cannot describe the entire system.
When an MCP-connected assistant receives selected search results or document content, the assistant host has received that information. If the host uses a cloud model, a provider may process it on remote servers. Disconnecting Zortex does not take back information that provider retained. These are not footnotes to a local-first architecture. They are the places where a person's decision about access has a real consequence.
Our application privacy policy distinguishes these stages. It also documents manual deletion limits, provider authorization, and the difference between a grant and a feature.
One source record moves through local retrieval, a permission decision and selective release.
The question a permission screen cannot answer
Authorization screens describe scopes, often in the language of an API. A user, however, thinks in tasks. They want to summarize a report, check a deadline, or reply to a message. A scope can be broader than any one task.
The Google integration makes that gap visible. The declared Gmail permissions include both read-only and broader mail access; Drive likewise declares wide access. The product's documented mail and file actions are examples of what it supports, not proof that every operation allowed by a declared Google scope is a dedicated feature. Calendar access is declared read-only. It would be misleading to translate those facts into a single label such as "safe access."
The question for the user is more specific. If I connect this source, what information is gathered? For this assistant's current request, what can leave the vault? Can it perform an action or only read? What changes when I revoke access? What has already been delivered elsewhere?
Good permission design should answer in terms a person can use, while the underlying grants and checks remain enforceable in code. A warning shown once during installation cannot excuse a later tool from returning unrelated messages. An integration's actual behavior belongs in implementation checks as well as the privacy policy.
The simplest useful habit for an assistant is to use the smallest set of records that answers the question. If a file title and a passage answer it, do not send an entire folder. If a calendar event supplies the time, do not add attendees' unrelated messages. If confidence is low, show the sources and say what was not resolved rather than gathering more personal history without cause.
Minimization has a cost. A small selection can omit the decisive fact. The answer is to make enlargement deliberate: try the narrower result, identify the missing evidence, then ask for or apply the next permissible search. This gives the user a chance to understand why more context is needed.
What the data is not meant to become
There is another distinction between using context to answer a question and using that context to train a generalized model. Zortex's stated commitment is that it does not use connected Google user data to train or improve generalized AI or machine-learning models. It also states that it does not sell that data or use it for targeted advertising.
Zortex's commitments govern its own handling. A third-party assistant operates under its own terms after receiving selected context, so the context layer controls the recipient, the data released and the grant used for that transfer.
Privacy also protects time. Data submitted for one task should not automatically become available to every future task. A message read to locate a due date is not a standing instruction to remember a family dispute. Durable memory needs more care than a temporary search result because an old interpretation can follow its subject into situations where it no longer belongs.
It protects the ability to revise. A private draft is a place where a person can be wrong, change position, use a clumsy phrase, and reconsider. An assistant that ingests drafts without distinguishing them from published decisions can quietly turn provisional material into asserted history. Source labels, timestamps and correction paths limit that damage; they do not eliminate it.
And it protects other people. An employee's inbox includes correspondents who never installed the software. A team document may contain confidential information belonging to a client. The user holding a copy does not automatically have unlimited authority to send it to every model or make every inference about its authors. Technical access and legitimate use are different questions.
The things a delete button cannot do
Deletion is often described as the final answer to a privacy concern. In practice there are separate places to inspect.
Revoking Google access stops future authorized retrieval through that connection. Disconnecting a source can leave previously synchronized local records. Removing an app may leave local archives, exports or backups. Erasing a local vault cannot undo a previous disclosure to a remote assistant. Each of these requires a different action, and none should be silently represented by the others.
The same discipline applies to websites. Our website privacy policy describes a much smaller set of operations: server request logs, first-party visit counts, waitlist signups and the providers involved in delivering them. It does not claim to be the desktop application policy. Keeping these boundaries separate is more informative than placing every use of the word "privacy" beneath one corporate promise.
Privacy will not mean that a personal AI knows nothing about its user. That would defeat the purpose of asking it to work with personal context. The useful standard is whether knowledge arrives with provenance, stays within a justified purpose, and leaves only through a boundary the person can understand and govern.
When an assistant produces an answer, the crucial question is not simply whether the answer is correct. It is what had to be exposed to produce it, and who can still use that exposure after the answer is over.
