Imagine asking a phone to summarize a private note. One implementation could process it entirely on the device. Another could send a request to a specified cloud service; a third could switch between the two. The button and the result might look much the same. To assess the privacy claim, follow the note: where computation occurs, which components can receive its contents and what records remain after the summary appears.
On-device AI describes an important part of that journey. If inference happens locally, the prompt need not be sent to a remote model for that computation. But a complete application can do more than inference. It can synchronize notes, store conversation history, collect diagnostics or route a difficult request elsewhere. The location of the model is a useful fact, not a description of every surrounding data flow.
Follow three possible journeys. They are architectural examples rather than a test of a particular phone. Real behavior depends on the application, feature, supported device, operating-system version and settings. The point is to make those boundaries visible enough to evaluate, instead of asking a broad label to answer questions it leaves unspecified.
Journey one: the computation stays with the note
In the first arrangement, an application reads the note and invokes a model running on the phone. The model produces a summary and returns it to the app. No remote inference is needed for this step. That can reduce a particular disclosure path and make the feature usable without a network connection once the required components are available.
Google’s Gemini Nano documentation, updated in October 2026, describes on-device execution through Android’s AICore service. It states that AICore isolates requests, does not retain inputs or outputs after processing and uses a separate service for indirect internet access such as model downloads. These are claims about the documented component and architecture, not proof that every app using the component sends no information elsewhere.
The distinction between inference traffic and model delivery is especially useful. Downloading an updated model can require a connection even when processing the note does not. Seeing network activity therefore does not automatically show that the note was uploaded. Conversely, observing one successful offline summary does not establish that every feature of the application works locally under every condition.
The app still controls the note before and after inference. It may already synchronize the document under the user’s account. It may save the summary into that synchronized document. Those actions can be legitimate parts of the product, but their privacy description belongs alongside the local-inference description. Keeping one computation on the device does not undo other transfers the user has authorized or the app performs.
Local execution also does not remove the need for ordinary device security. Access to the app, the device’s lock state, available permissions and the handling of stored records remain relevant. A locally generated summary displayed on an unlocked screen can be exposed without any cloud model being involved. The threat being addressed should be stated precisely enough that the remaining responsibilities are understandable.
There are performance constraints as well. A supported model must fit the intended device and task. Context limits, hardware capability and the feature’s quality target can influence which requests are handled locally. These constraints do not make on-device processing an inferior idea. They explain why a product needs a policy for requests outside its local capability rather than a promise of unlimited offline intelligence.
That policy is part of the privacy experience. If the feature cannot complete the note locally, it could explain the limit, offer a smaller task or request a separately understood cloud operation. Automatically changing the processing boundary may preserve apparent convenience while changing the substance of the user’s choice. A product should make clear which behavior it has chosen.
Journey two: the computation leaves under a defined cloud design
In the second arrangement, the request is processed remotely. That fact should not be disguised by calling the product broadly on-device. It also should not end the inquiry with an assumption that all cloud processing has identical properties. The questions concern the actual service: what is transmitted, which infrastructure handles it, who can access it and how long information remains available.
Apple’s 2024 Private Cloud Compute design account describes a more specific mechanism than a promise of operator discretion. A device checks cryptographically attested software measurements against a release in a public transparency log before wrapping the request’s encryption key for the processing nodes. Code measurements and software images are made available for researchers to inspect. In this design, identifying the code that may decrypt a request is part of deciding where to send it.
That mechanism addresses a gap in ordinary cloud disclosure: a provider can publish code without proving that the published version is the one receiving a user’s data. Attestation and the log are intended to connect those two claims. They do not establish that software has no bugs, or that a third-party app’s separate server belongs to the same protected service. The account also describes stateless processing and restrictions on privileged access. These are features of a defined architecture, not properties inherited by every feature bearing the same device brand.
The infrastructure boundary can change over time. In June 2026, Apple announced an expansion of PCC to Google Cloud infrastructure, describing cooperation with Google and NVIDIA and saying its core privacy requirements would remain the same. The announcement also described a staged preview ramp. An announcement of intended protections is not a measurement of every request’s current routing or proof that every planned deployment stage has finished.
That development illustrates why the location of a company’s own data centers is not a sufficient privacy model. What matters is the actual trust boundary, implementation and verification process for the service handling the request. Hosting infrastructure and the party controlling the relevant software can be different. A product needs to describe the relationship accurately enough that those distinctions are not hidden behind a brand name.
For the fictional note, the user-facing explanation should preserve the basic change: this request is leaving the phone for a specified processing arrangement. An appropriate design may transmit only what is needed for the task. The user should not have to infer the boundary from subtle changes in response speed or from a general marketing page that combines several distinct features.
Cloud processing can be a reasonable choice when its capabilities and controls fit the intended use. Some users may prefer a local-only limit; others may accept the described remote processing. The useful product decision is to support an informed choice or clearly defined policy. Presenting capability as if it silently establishes consent leaves an important part of that decision unmade.
Journey three: local first, cloud when something changes
The hybrid arrangement makes the boundary harder to see because most requests may follow the first journey while selected requests follow the second. Selection might depend on device support, task complexity, availability or a routing setting. The same button can therefore initiate different processing paths on two devices or on two occasions.
Android’s current Gemini Nano documentation explicitly discusses hybrid inference and cloud fallback when the local model is unavailable or unsupported. That establishes the existence of an architectural option; it does not mean every application using Nano has enabled it. The app’s actual integration and disclosure determine which journey the note takes.
The important test is what happens at the edge of local capability. A product demonstration that selects only supported requests can be truthful while leaving fallback behavior unexamined. A review should include an unsupported device, an oversized request or whatever condition legitimately triggers the app’s alternate path. The aim is to observe the promised policy under a meaningful limit, not to manufacture a failure unrelated to normal use.
Failure should not become an invisible permission expansion. If the user selected a local-only mode, an unavailable local model should produce behavior consistent with that choice. If the product offers a hybrid mode, its description should identify the possible remote service and relevant controls. The routing policy is part of the feature’s contract with the user, even when the technical implementation makes fallback easy.
There is also an output-quality question. A local model and a remote model may produce different results. The application should test the feature’s acceptable behavior across supported routes rather than assume that a common interface makes them equivalent. A privacy choice should not be undermined by hiding important capability differences until after the user depends on the result.
For organizations, a device-management policy can add another layer. A feature available to an individual user may be restricted under a managed configuration. The application should respect the applicable boundary rather than let a fallback bypass it. The precise mechanism depends on the platform and environment; the general requirement is consistency between the configured policy and the executed path.
The journey continues after the answer
All three arrangements eventually return a summary. The output can contain sensitive information derived from the note, so its handling deserves attention too. Saving it in a history, synchronizing it to another device or copying it into a shared message changes who may see it. A privacy explanation that stops at the instant inference ends misses the result the user actually receives.
Diagnostics need a separate account. Developers legitimately need to understand failures and performance, but a useful record does not always require the full note or generated answer. The app should distinguish operational measurements from content records and explain relevant retention. A local model’s no-retention behavior does not automatically apply to logs created by the surrounding application.
Updates can alter the path as well. A new model might support a task previously routed remotely; a new feature might introduce another service. A meaningful privacy description should track those changes. Maintaining the same broad slogan while changing the route can leave users relying on an obsolete understanding of the product.
One practical review follows the fictional note through normal use, a supported fallback and an ordinary failure. It asks which components received content, what persisted and whether the displayed explanation matched the actual path. That is a narrower test than declaring a platform private, but it is one whose result can be examined and repeated.
Keep the record of that review separate from a packet count. A model-download connection, a synchronized note and an inference upload answer three different questions about the same device. An encrypted connection may reveal its destination and timing without revealing its payload to an observer. Traffic alone cannot settle what it contained; an offline success cannot settle what other routes would do. Combine the app’s documented routing, relevant settings and an authorized observation of the request path before making the narrower claim each supports.
The best boundary is consequently one the product can name. Local inference can be a substantial privacy benefit. A carefully specified cloud service can have meaningful protections. Hybrid routing can provide useful flexibility. None of those descriptions should erase the others. The user asked for a summary of a note; the system still owes an intelligible account of the journey it chose.
Sources & context
This article draws on the sources linked in the text. Analysis and illustrative scenarios are identified separately from reported findings.
- Gemini Nano documentation
- 2024 Private Cloud Compute design account
- June 2026, Apple announced an expansion of PCC to Google Cloud infrastructure
