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
Section titled “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
Section titled “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
Section titled “Signed in to Pia Cloud”Signing in enables Cloud Sync. Your sessions, memories, todos, templates, personas, provider configurations and settings are stored on our server so they reach your other devices.
With a Pia Cloud model
Section titled “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. Your prompt is processed there, not stored — the conversation that results is stored as synced data, under the same encryption choice as everything else.
With your own provider
Section titled “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 is unreadable to us too.
Signed in to a server you run
Section titled “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
Section titled “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
Section titled “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.
- 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
Section titled “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.
Next steps
Section titled “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