The label does not answer every question

When an AI feature is advertised as “on-device,” the phrase usually indicates that at least some of its processing may take place on the phone. It is not enough, however, to conclude that the entire task is completed there, that no information is sent to a server, or that the feature works in the same way without an internet connection. Those answers depend on how the particular feature is implemented and on its current documentation. A label is a starting point for checking, not a full account of a feature’s data flows.

It helps to separate three questions that are often conflated: where the model runs, what data the app needs to perform the task, and what additional services are involved. A local operation could coexist with synchronization, a remote query, or a model download. Conversely, the fact that an app uses cloud services does not mean that every AI feature sends all of its content there. These are distinct possibilities, and general information about a platform cannot settle which one applies to a specific tool. Without feature-specific information, any such conclusion would be an extrapolation rather than a documented fact.

What Android AICore tells us

Android’s documentation describes AICore as a system component related to generative AI features on supported devices. This helps explain that Android has a software component intended to facilitate certain capabilities on the device itself. It does not establish that every Android AI feature uses AICore, or that a particular phone includes every capability. Availability may vary by device, software version, and feature. The documentation should therefore be read within its stated scope, rather than treated as a universal description of Android phones or applications. Android AICore documentation.

The same caution applies to apps. In its developer materials, Android describes a sample catalog and different ways to build AI experiences. That resource is about development options; it is not a comprehensive inventory of features active on each phone, nor a statement about how every app handles data. To understand a user-facing feature, find the documentation for that feature and distinguish it from general platform materials. Developer examples can show what developers may build, but do not, on their own, explain the data handling of a particular product in use. Android AI sample catalog.

Local, cloud, or a combination: how to read the documentation

A useful product page needs to say more than “uses AI.” Look for whether it identifies processing as local, remote, or hybrid; whether it specifies network requirements; and whether it explains what content is transmitted when the feature is used. If the documentation explains what a tool does but not where it processes data, that silence neither confirms nor rules out cloud processing. Keep a clear distinction between what a source explicitly states and what it leaves unspecified. An absence of detail is not evidence for either answer.

The scope of the wording matters too. “Available offline” might apply to one particular feature, not every associated service; “on-device processing” does not automatically establish how long input is retained; and a general privacy policy may cover several products or uses. The location of computation and the rules governing data are related dimensions, but they are not equivalent. To make an informed assessment, look for information about each separately and confirm that the explanation applies to the version, country, and device model you use. A statement about one feature or setting should not be extended to another without supporting documentation.

Privacy: what can and cannot be concluded

Local processing can reduce the need to send certain data to a server to complete an operation, if that operation really does take place on the phone. But this is not a blanket privacy guarantee: by itself, it says nothing about permissions, logs, backups, synchronization, or other related data handling. Privacy needs to be assessed feature by feature and data flow by data flow, rather than inferred from a label applied to a device or platform. Even when processing is local, the relevant questions about permissions and associated services remain separate.

Likewise, it would be inaccurate to claim that a feature uses the cloud just because it needs a connection at some point. It might need connectivity to update components or provide related services while another stage happens locally. And if a feature stops responding without internet access, that behavior alone does not prove what data was sent while it was connected. Describing that flow would require explicit documentation or specific technical evidence. The sources available here do not establish a particular architecture for individual features such as Gemini or Circle to Search, so no such architecture should be attributed to them on that basis.

Practical checks before using a feature

To reduce uncertainty, first identify the exact feature name and the provider that offers it; do not stop at the broad category “Android AI.” Open the help page or policy linked from the app and check that it refers to that tool, and to the relevant country and version. Android’s official page presents features such as Gemini and Circle to Search, but that general overview is not enough to establish where each interaction is processed. A feature listing and an explanation of its data flows answer different questions. General information about AI on Android.

Next, look for explicit answers to these questions: Is the input processed on the phone, on servers, or in both places? What data is transmitted, and for what purpose? Is a connection required to perform the task, or only for complementary services? What options does the provider offer for activity, history, permissions, or deletion? If an answer is not provided, treat it as unknown—not as a favorable guarantee, and not as proof that data is shared. Checking the applicable documentation and settings is more reliable than inferring a data flow from a feature name or from whether the phone happens to be connected.

In practice, the responsible conclusion may be limited: we know that Android documents AICore and provides AI development resources, but that general information does not by itself explain how a particular feature works or handles data. Before submitting sensitive information, review the feature-specific documentation and the options available on your device. The answer may depend on the precise feature, version, and circumstances of use. There is no single answer to “AI on Android”: each feature needs to be checked separately.