What is the difference between a privacy policy and private by design?

A policy governs a party. A design decides whether that party is there at all.

A privacy policy describes how a party says it handles data it receives. A design can reduce or remove a provider from a particular processing path. The surrounding app may still disclose other data, and “on-device” alone does not describe those paths.

That is a difference in topology, not in sincerity. One arrangement routes your words to a machine somebody else administers, then constrains what may be done with them there. The other never opens the route. The first can be honored perfectly and still fail through a breach, a court order, or a change of ownership. The local path can still be affected by software updates, device security, or other app features that use a network.

Policies are a real guarantee, just a different kind

Policies can have legal force. In jurisdictions with data-protection rules, a company may face penalties for using data outside a stated purpose. Enforcement and available remedies depend on the law and circumstances; a policy cannot by itself prevent every disclosure or breach.

A policy has a defined scope and may change under its terms or applicable law. Retention, subprocessors, and backup handling depend on the service’s practices. Technical design can constrain some data paths, while software and operating practices may also change.

How to tell which one you are reading

Read the verb, and ask what the sentence is actually about. Some claims describe behavior. Some describe protection in motion. A claim about where computation happens can be investigated with network observations, though one observation cannot reveal every data path or prove what happens under all conditions.

A network inspector or device-level traffic log can help inspect observed connections during a test. It may show destinations and other metadata, not necessarily the contents sent. A feature can compute locally without an inference request at that moment; other app functions may still communicate, and brief tests cannot prove year-round behavior.

• Conduct: "We never sell your data." A decision a later document can revise, and one that says nothing about sharing, licensing or training.
• Transport: “Your data is encrypted.” Necessary and useful. Conventional inference processes readable input at the server; specialized approaches can use different trust models and limits.
• Location: "It never leaves your device." Not a description of behavior at all. It says which computer does the work, and it can be falsified by watching the network.

Where it depends: most software is a mixture

Almost nothing is all one thing. An app can run a model on the device while still holding an account, syncing settings, backing content up to a server and sending crash reports. Local inference and local storage are separate decisions, and so is whether the app requires a sign-in.

A sign-in is worth watching for on its own, because it changes what a policy is about. An account can associate records or service rules with an identity, though the extent depends on how the service uses it. So the useful question is per feature: which computer does the work, and is there an account for a record to attach to? “Processed on device” may describe one path while other app functions communicate with a server.

What the design costs to build

Building it this way is constrained by hardware instead of by legal language. A model that answers on a phone has to fit in the phone's memory alongside everything else running, and it has to respond fast enough to feel immediate, which is why local models ship compressed. That is a general fact about the engineering, not a claim about any one product.

The arrangement shows why privacy depends on where information is processed, not only on what a policy promises. For any system, understanding the path from input to computation is a useful place to start.