What Does Private AI Mean? A Glossary of the Claims

"Private AI" is not one claim. It is a label sitting on top of at least twenty separate technical statements, and two products can both use it while offering guarantees that have almost nothing in common. One might mean the model runs on the phone in your hand. Another might mean a company promises not to train on what you type, while still receiving every word of it. Both sentences are true uses of the phrase, and only one of them survives the company changing its policy.

This page is a glossary rather than a recommendation. Each term below gets a plain definition, and then the part that usually goes unsaid: what the term does not guarantee. Jump to the full glossary table if you want the summary, or to what you can verify yourself if you want the short list of claims that do not require trusting anyone. For the product-level view, see our guide to on-device AI versus cloud AI.

Group 1: where the computation happens

This is the first question to settle, because it decides whether every later term is architecture or paperwork. If your text never leaves the device, there is no server-side retention policy to read.

On-device AI (also: local AI, local inference)

The model file is stored on your own phone, tablet or computer, and the text is generated by that device's own processor. No prompt or response is sent anywhere in order to produce the answer. This is the strictest common form of private AI, because the property comes from the architecture rather than from a commitment. What it does not guarantee: that the app sends nothing. Generation can be local while analytics, crash reports or a model download run over the network as separate traffic. On-device is a claim about generation, not automatically about everything the software does.

Edge AI

Computation performed near where the data is created, rather than in a central data centre. In consumer contexts "the edge" often means your own device, which makes it a near-synonym for on-device. In industrial and enterprise contexts it frequently means an on-premises server or a gateway appliance. What it does not guarantee: that the edge in question is yours. Edge is a statement about network topology, not ownership.

Hybrid or routed AI

A design that answers some requests on the device and forwards the harder ones to a server. It is a sensible engineering trade-off and a poor privacy claim, because the outcome depends on a routing rule that the person typing usually cannot see or predict. What it does not guarantee: that any particular message stayed local. Unless the app tells you per message which path it took, "runs on-device" and "sometimes runs on-device" are indistinguishable from the outside.

Self-hosted AI

You run the inference server yourself, on hardware you own or a cloud tenancy you control. You set the retention policy because you are the one storing things. What it does not guarantee: security. Self-hosting moves the responsibility rather than removing it, and an inference endpoint exposed to the open internet is a self-inflicted version of the problem it was meant to solve. Our self-hosted AI guide covers the practical options.

Private cloud, dedicated instance, VPC deployment

Vendor-operated infrastructure isolated for a single customer, commonly inside a virtual private cloud. It is a genuine and meaningful separation from other customers' workloads. What it does not guarantee: separation from the vendor. Someone still operates the machine, still holds the keys in most designs, and still writes the policy that governs what their staff can access.

Group 2: what happens to the data after it arrives

These terms only apply when the text has already been transmitted. They are the vocabulary of contractual privacy, and their most important feature is that they are narrower than they sound.

Zero data retention

A stated policy that inputs and outputs are not persisted once a request completes. It is one of the strongest contractual commitments available. What it does not guarantee: that nothing is stored at all. Zero-retention arrangements commonly carve out a short abuse-monitoring window, and they describe a server that still receives your plaintext in order to process it.

Training opt-out ("we do not train on your data")

A commitment that your content will not be used to adjust model weights. What it does not guarantee: anything about storage. Retention, human review and training are three separate commitments, and this phrase makes only the third. Content can be transmitted, logged, kept for a defined period and read during a safety review without ever being used for training. Our breakdown of what happens to your data with major cloud assistants walks through how the three usually differ.

Human review

Staff or contractors reading a sample of conversations, normally for safety, abuse or quality work. It is a legitimate practice and it is worth knowing about, because it is the point where "your data is processed" becomes "a person read this". What it does not guarantee, when absent from a policy: that it does not happen. Silence on human review is not a denial of it.

Retention window

The stated period content is kept for, together with the purpose. A specific window attached to a named purpose is a more useful commitment than an unqualified claim that nothing is stored, because it is concrete enough to be wrong. What it does not guarantee: deletion from backups on the same schedule, unless the policy says so.

Pseudonymised, anonymised, de-identified

These three are routinely used as synonyms and are not. Pseudonymised means direct identifiers are replaced by a pseudonym that could be linked back using information held separately, and under the GDPR pseudonymised data is still personal data, still in scope of the regulation and still subject to your rights over it. Anonymised means a person can no longer be identified by any means reasonably likely to be used, which is a far higher bar, and data that genuinely clears it falls outside the GDPR entirely. De-identified is a looser umbrella word, common in US-influenced policies, that often describes what the GDPR would call pseudonymisation. What none of the three guarantees: that free-form text has stopped being identifying. A conversation about your employer, your street, your diagnosis or your unreleased product identifies you in its substance, not in a field that can be stripped.

Group 3: how the data is protected

Encryption in transit

Transport-layer encryption, normally TLS, protecting data as it crosses the network. What it does not guarantee: anything about the destination. The receiving server decrypts and works with the plaintext, which is the whole point. Every credible service has this, so it is a baseline rather than a differentiator.

Encryption at rest

Stored data written to disk in encrypted form. It defends against a stolen drive or an unauthorised copy of the storage. What it does not guarantee: protection from the service itself, which normally holds the key it needs in order to read the data back.

End-to-end encryption

Only the communicating endpoints hold keys, so no intermediate server can read the content. This is the strongest familiar claim in messaging, and it sits awkwardly with cloud AI: a server has to read a prompt in order to generate a reply from it. What it does not guarantee, when used loosely: that the provider cannot read your prompt. Check whether the phrase is describing the transport hop or the whole path.

Confidential computing, trusted execution environment (TEE)

Running a workload inside a hardware-isolated environment that the machine's own operator is not supposed to be able to read into. This is the serious answer to the problem above and the mechanism behind server-side designs that claim the provider itself cannot see requests. What it does not guarantee on its own: two things. First, that the environment is running the software you think it is, which is what the next term is for. Second, that the isolation holds, since the guarantee is inherited from a chip vendor's implementation and published side-channel research has broken TEE isolation on more than one platform. It is a strong design, not a law of physics. One term to keep separate here is Apple's Secure Enclave, which is a coprocessor for keys and biometric data rather than a place general workloads such as a language model run.

Remote attestation

A cryptographic proof that a remote machine is running a specific, identified software build. It is the piece that converts a confidential-computing promise into something a client can check rather than accept. What it does not guarantee: that the attested build behaves well. Attestation proves identity of code, not intent of code, which is why published or independently inspectable builds matter alongside it.

Air-gapped

A machine physically disconnected from any network. Stronger than offline-capable, because there is no path out even if software attempted one. What it does not guarantee: the same thing when the gap is policy rather than wiring. A "policy air gap" on a machine that still has a working network interface is an administrative control, and administrative controls get bypassed, which is the whole reason the physical version has a name. Nor does it guarantee convenience, since model files and updates then have to arrive by hand.

Offline capable

Able to do its job with no network available. For a chat app this is the single most checkable privacy-adjacent property, because you can cut the network and see whether it still answers. One trap: on iOS, airplane mode does not necessarily switch Wi-Fi off, and iOS remembers if you turned Wi-Fi back on while airplane mode was active, so check the Wi-Fi and cellular toggles rather than trusting the aeroplane icon. What it does not guarantee: that the app stays offline once a connection returns. See our roundup of which iPhone AI apps work in airplane mode for how the test plays out in practice.

Group 4: statistical terms that are often misread

Differential privacy

A formal guarantee that calibrated noise bounds how much any one person's presence can change a released result. The bound is set by a privacy budget, conventionally written as epsilon, and smaller is stronger. That parameter is the whole claim: a deployment at a small epsilon is a serious protection, and a deployment at a large one can be close to meaningless while still being truthfully labelled "differentially private". What it does not guarantee: a useful bound, if the epsilon is unpublished. Nor does it guarantee that your conversation was not transmitted or stored, because differential privacy protects an individual's influence on an aggregate result, which is a different question from whether one chat was kept.

Federated learning

Training in which updates are computed on many devices and only the updates, not the raw data, are sent to a central server. What it does not guarantee: that the updates reveal nothing. Model updates are derived from the data that produced them, and published reconstruction attacks recover training content from them, which is why credible deployments layer secure aggregation or differential privacy on top rather than treating "the data stayed on the device" as the end of the argument. It also guarantees nothing about inference: a product can use federated learning to improve a model while still answering your prompts on a server.

Group 5: identity and jurisdiction

No account required

The product is usable without creating an identity: no sign-up, no email address, no phone number. It removes the identifier you would otherwise hand over, and it removes the account record that ties a history together. What it does not guarantee: anonymity, because a networked app can still be associated with an IP address or a device identifier. On an app that generates locally, though, there is no request to attach anything to. More on the distinction in our guide to AI chat without an account.

Temporary chat, incognito mode

A mode that keeps a conversation out of your visible history and, usually, out of training. What it does not guarantee: that it was not transmitted. The content typically still reaches the service and may be retained briefly for safety purposes. It is a history-management feature that is often read as a transmission guarantee.

Data residency, data sovereignty

Two words that are not the same thing. Data residency is where data is physically stored and processed. Data sovereignty is which legal authority governs it and who can compel access to it. Residency is the one vendors advertise, because it is easy to state, and sovereignty is the one that decides outcomes. What residency does not guarantee: who can read the data. A provider incorporated or staffed in another jurisdiction can still be reachable by that jurisdiction's legal process while storing every byte in your region.

Group 6: two words that get borrowed

Open weights

Model parameters anyone can download and run, under a licence that may still restrict use. What it does not guarantee: privacy. An open-weights model served through somebody's API is exactly as private as that API's policy. Open weights matter for privacy only because they make the on-device and self-hosted routes possible, which is why the GGUF format shows up in almost every local setup.

Open source model

A model released under an open-source licence together with the code and the training-data information someone would need to recreate it. That data requirement is not an extra: the Open Source Initiative's Open Source AI Definition treats it as a condition, which is why several widely publicised "open source" model releases do not meet it. What it does not guarantee: the same thing as open weights, which is the weaker and far more common condition. The two are used interchangeably in announcements, so read the licence rather than the headline.

Local-first

A design where the primary copy of your data lives on your device and any sync is optional and secondary. What it does not guarantee: local computation. A local-first note app that calls a cloud model to summarise a note is still sending the note.

The glossary table

The same terms in one place. The third column is the one worth reading twice: it is what people commonly take the term to mean, and do not get.

Term	What it means	Common misreading	Kind of claim
On-device / local	Model runs on your own hardware	That the app sends nothing at all	Architectural
Edge AI	Computation near the data source	That the edge device is yours	Architectural
Hybrid / routed	Some local, some server-side	That your message stayed local	Mixed
Self-hosted	You operate the server	That it is secure by default	Architectural
Private cloud / VPC	Isolated vendor-run instance	Separation from the vendor	Contractual
Zero data retention	Requests not persisted after processing	That there is no abuse-monitoring exception	Contractual
Training opt-out	Content not used to train models	That it is not stored or reviewed	Contractual
Human review	People read a sample of chats	That silence about it means it does not happen	Disclosure
Retention window	How long content is kept, and why	That backups follow the same schedule	Contractual
Pseudonymised	Identifiers replaced, re-linkable	That it is no longer personal data	Legal
Anonymised	Re-identification not reasonably possible	That it is a synonym for pseudonymised	Legal
In transit (TLS)	Encrypted across the network	Anything about the destination	Baseline
At rest	Encrypted on disk	Protection from the key holder	Baseline
End-to-end encrypted	Only endpoints hold keys	That it can coexist with plain server-side generation	Architectural
Confidential computing	Hardware-isolated execution	That the isolation has never been broken	Architectural
Remote attestation	Proof of the running build	That the attested build behaves well	Architectural
Air-gapped	Physically disconnected machine	That a policy-only gap is equivalent	Architectural
Offline capable	Works with no connection	That it stays offline once one returns	Architectural
Differential privacy	Noise bounds one person's influence	That the bound is strong without knowing epsilon	Statistical
Federated learning	Training updates computed on devices	That the updates leak nothing	Training technique
Data residency	Where data is stored and processed	That it settles who can compel access	Legal
No account required	No sign-up, email or phone number	Full anonymity on a networked app	Product decision
Temporary / incognito	Kept out of visible history	That it was never transmitted	Contractual
Open weights	Downloadable parameters	Privacy of a hosted API using them	Licensing
Open source model	Open licence plus data information	That it is the same as open weights	Licensing
Local-first	Primary data copy on your device	That computation is local too	Architectural

Which claims you can verify yourself

Most of the glossary is policy. Policy can be read, and it can be honest, but it cannot be tested from outside. Three things can, and they are worth separating from the rest:

• Whether an account is required. Visible at first launch. If the app opens straight into a conversation with no sign-up screen, there is no identity attached to what you type.
• Whether generation happens locally. Cut the network, then ask a question. An app that answers with no network available cannot have used a server for that answer, which is the closest thing to a self-service proof in the whole list. Do it properly: airplane mode alone is not enough on iOS, because Wi-Fi can be switched back on while airplane mode is active and iOS remembers that. Check that both the Wi-Fi and cellular toggles are actually off.
• What the app contacts. iOS can log the domains an app reaches, but you have to turn it on first: Settings, then Privacy and Security, then App Privacy Report, then switch it on. It records nothing from before you enabled it and keeps roughly the last seven days. A firewall or local proxy does the same job on a desktop. This does not tell you what was sent, only whether anything was, and it also picks up domains loaded by web content shown inside the app rather than by the app itself.

Two more sources are declarations rather than tests, which still makes them useful. Apple's App Privacy section on an App Store listing and Google Play's Data safety section are both filled in by the developer, so each is a commitment on the record rather than an independent audit, though both stores reserve the right to act on labels they find inaccurate. A gap between those labels and the marketing copy is a question worth asking.

Questions worth asking before accepting a private AI claim

1. Which of the four arrangements is this: on-device, self-hosted, isolated instance, or shared service under policy?
2. If it is server-side, is the guarantee architectural (confidential computing, attestation) or contractual (retention and training policy)?
3. Does the policy name a retention period and a purpose, or only say that data is not stored?
4. Are retention, training and human review addressed separately, or does one claim stand in for all three?
5. If it says on-device, does it say so for every request, or only for some?
6. Does it work in airplane mode?
7. Does it require an account, and what is that account used for?
8. Where is the claim written down: in the privacy policy, or only in the marketing copy?

Where PocketLLM fits

PocketLLM sits in the first of the four arrangements. You download an open-weights model once, over the network, and after that the app runs it on your iPhone or iPad using an on-device runtime, so prompts and responses are generated by your own device rather than sent to a server. There is no account, no email address and no phone number, and the app collects zero telemetry on your conversations. Conversations are stored on-device with AES-256-GCM encryption. That places its guarantee in the architectural column above, which is the same category as self-hosting, without the server to run.

Three things worth stating plainly, because this page is about claims being precise. PocketLLM is pre-launch: there is a launch list, and no App Store link yet, so nothing here is something you can install and check today. Model downloads are network traffic, which is exactly the distinction drawn under on-device above: generation is local, the initial download is not. And the local-generation property is meant to be checkable at launch by the airplane-mode test above, rather than taken on faith, which is the standard we would want applied to anything on this list. For the wider argument, see why private AI chat matters, or the roundup of private AI chatbots for how the options compare.

Frequently asked questions

What does private AI actually mean?

Private AI is an umbrella phrase rather than a single definition, and it is used for at least four different arrangements: the model runs on your own device, you run the server yourself, a vendor runs an isolated instance for you, or a vendor runs a shared service under a policy limiting what it does with your data. Those are very different guarantees. The useful question is not whether a product calls itself private but which of the four it is, because only the first two remove the need to trust someone else's policy.

Is on-device AI the same as private AI?

On-device AI is the strictest common form of it. If the model file sits on your phone and your phone's own processor generates the text, there is no request to receive, log or retain, so the privacy property comes from the architecture rather than from a promise. Two caveats keep it honest: an app can be on-device for generation and still send analytics or crash reports separately, and a hybrid app can answer some prompts locally while forwarding others. On-device is a claim about where generation happens, not automatically a claim about everything the app does.

Does a training opt-out mean my data is not stored?

No. A training opt-out is narrower than a retention policy. It says your content will not be used to adjust model weights. It does not say the content was never transmitted, never written to a log, never retained for a stated period, or never read by a person during safety review. Retention, human review and training are three separate commitments, and a product can make one of them without making the other two.

Can a cloud AI chatbot be end-to-end encrypted?

Not in the ordinary sense. End-to-end encryption means no intermediate party can read the content, but a server has to read a prompt in order to generate a reply from it, so the two requirements collide. The route around the collision is confidential computing: running the model inside a hardware-isolated environment whose operator cannot read its memory, ideally with remote attestation so a client can verify which software build is running. That is a real design, and it is a different and more complex claim than transport encryption, which every service already has.

Which private AI claims can I verify myself?

Three, without needing to trust anyone. Whether an account is required is visible at first launch. Whether generation happens locally is testable by turning off every radio, checking that Wi-Fi is genuinely off and not just airplane mode, then asking a question: an app that answers with no network cannot have used a server for that answer. And on iOS you can see which domains an app contacts by first switching on App Privacy Report in Settings, Privacy and Security, after which it records the last seven days; a firewall or local proxy does the same job on a desktop. Everything else on this page, including retention windows, training use and human review, is a statement of policy that you can read but cannot test from outside.