Where your data goes

Pia can run without sending anything you write to us, sync to our server, or sync to one you run yourself. Which of those you are in depends on two independent choices: whether you sign in to Pia Cloud, and which AI model you pick. This page walks the combinations and says, for each, what leaves your device — and at the end, what the app fetches whichever combination you are in.

The short version

Your setup	Where synced data lives	Where prompts go
Not signed in, own AI provider	Nowhere — it stays on your device	Straight to your provider
Signed in to Pia Cloud, Pia Cloud model	Our server	Through our server to the AI provider
Signed in to Pia Cloud, own AI provider	Our server	Straight to your provider
Signed in to your own server, its AI proxy	Your server	Through your server to the AI provider
Signed in to your own server, own AI provider	Your server	Straight to your provider

Two things are worth reading twice. The AI choice is per provider, not per account — you can use a Pia Cloud model in Optimize and your own provider in the Assistant at the same time. And syncing and prompting are separate exits: turning off one does not turn off the other.

Not signed in

Without a Pia Cloud account there is no sync, and nothing about your conversations reaches us. You add your own provider key, and requests go from your machine to that provider. What they do with the request is governed by their terms, not ours. The app still checks for updates and downloads the models it runs locally — see what the app fetches.

Signed in to Pia Cloud

Signing in enables Cloud Sync. Your sessions, todos, templates, personas, provider configurations and settings are stored on our server so they reach your other devices. Your memory vault is not synchronised: its memory, notes and topic pages stay on this device.

With a Pia Cloud model

You need no provider key: the request goes to our server, which forwards it to the AI provider and returns the answer. Our server does not store your prompt — the conversation that results is stored as synced data, under the same encryption choice as everything else. One of the AI providers behind Pia Cloud keeps prompt and answer for 30 days to detect abuse of its service, then deletes them; for that it is a controller in its own right, under its own privacy notice. Which provider that is, the list of sub-processors (in German) says.

With your own provider

The request goes from your machine straight to the provider you configured. It does not pass through our server at all. Your sync data still does.

One detail worth knowing: without end-to-end encryption, your provider configuration syncs in readable form — the provider name, its type, its endpoint and the model. Your API key does not; it stays on the device. With encryption on, the configuration syncs encrypted, and your API key goes with it, also encrypted, so your other devices can use it.

Signed in to a server you run

Everything above applies, except the server is yours. We operate nothing and see nothing — there is no activation call and no licence check over the network. See Community Edition for what running it involves.

What end-to-end encryption covers

This is the part most worth being precise about.

End-to-end encryption applies to what you sync. Your device encrypts each record before uploading it, and the server stores something it cannot read. Turn it on in Cloud Sync settings, keep the recovery code, and the content is unreadable to whoever runs the server.

It does not apply to a request to a Pia Cloud model, and it cannot: the server has to read the prompt in order to pass it to the AI provider. Encryption protects what is kept, not what is relayed. If you want prompts never to reach our server either, use your own provider — then they never do.

Some data is created on the server rather than on your device — managed personas, device and plugin metadata, trusted certificates. That data is not end-to-end encrypted, because your device was never the place it existed.

What the app fetches, in every setup

None of the combinations above covers the app’s own housekeeping. It happens whichever one you are in:

Update checks. On start, and then every few hours, the app asks our update host whether a newer version exists. You can turn this off in the settings.
Local models and voices. Speech recognition, speaker separation, the spoken voices and the local index each need a model file. The app downloads one from our host the first time you use the feature — the index model already at startup — and keeps it on your device afterwards. If our host can’t be reached, the download fails; the app never falls back to Hugging Face or GitHub instead.
The browser for the meeting assistant. Unless your release bundles it, the app fetches Chromium from Microsoft’s download network the first time it joins a meeting. This is the one fetch that does not come from us: the library in use sets that address itself.

What these send is your IP address and which program is asking. They send nothing you wrote.

What never leaves, in any setup

Speech runs entirely on your machine. Dictation uses a local recognition model and spoken replies use a local voice — neither sends audio anywhere, with or without an account. Only the model files themselves are downloaded, once. See Speech.

A dictation is recorded to %LOCALAPPDATA%\Pia\Recordings while Pia turns it into text. If a recording is interrupted — Pia closes or crashes mid-dictation — the leftover file is deleted the next time Pia starts.

Your history on this device

Whether you sync or not, your chats, prompts, memories and to-dos are kept on your computer in %LOCALAPPDATA%\Pia\history.db. That file is encrypted. Its key is bound to your Windows account and sits next to it as history.db.key, so another Windows account on the same computer can’t open your history.

The first time you start a version of Pia that encrypts it, Pia converts the database:

It saves the unencrypted original as %LOCALAPPDATA%\Pia\Backups\history-before-encryption-<date and time>.zip.
Only then does it encrypt the database. If the backup can’t be written, nothing is converted, and Pia tries again at the next start.

The zip stays until you delete it. It holds your history unencrypted, so delete it once you are sure you won’t need it.

If the key can no longer open the database — after your Windows profile was reset, for example — Pia moves the file aside as history.db.unreadable-<date and time> and starts with an empty history.

Next steps

Cloud Sync — turning sync and encryption on
AI Providers — choosing between Pia Cloud and your own
Privacy — keeping personal details out of what you send