AI on your phone: how to tell what runs on the device

Saying that a phone has on-device AI could describe a processor capability, a particular feature or one part of a workflow. By itself, it does not prove that every intelligent tool on the phone runs locally. An app might use an installed model for one task and turn to servers for another, or combine both methods during a single interaction. That is why it is more useful to ask which task is processed where than whether the phone “has local AI.” The distinction is practical, not merely a matter of terminology: a broad product label may refer to technology that is available to developers without explaining how a user-facing feature actually works.

The distinction matters for practical reasons. If an operation takes place on the phone itself, it might remain available without a connection, although that depends on the app and its other requirements. If a server is involved, a connection and service availability may be necessary. The processing location is also relevant to understanding data handling, but local execution does not automatically mean guaranteed privacy. You still need to check what data the app collects, what it syncs and what controls it provides. A claim about where computation happens answers only that particular question; it does not, on its own, describe every part of the data flow or the conditions attached to using the feature.

Start with the exact name of the feature, rather than general language used in a campaign. Look for documentation from the manufacturer or developer that explains that specific feature, and check whether it says that processing happens on the device, in the cloud or through a combination of both. Android’s developer documentation, for example, describes how to integrate language-model inference on Android using Google AI Edge. It helps verify that a technical route for local execution exists, but it does not prove that a particular feature on a commercial phone uses it. A platform guide and a product’s implementation are different kinds of evidence, so avoid treating one as confirmation of the other.

Also note any conditions that could change the result: device model, operating-system version, language, region, whether the model must be downloaded first, permissions and connectivity. Advertised availability may depend on these requirements and may not be the same for every user. To keep the check organized, compare the following points. Look for statements that apply to the exact feature and its current configuration, rather than assuming that a requirement listed for one device or region applies everywhere. If the documentation leaves one of these points unclear, record that uncertainty instead of filling the gap with an inference.

• Task: the exact action described by the source, such as summarizing text or recognizing an image.
• Processing: whether it explicitly says computation happens locally, on servers or through a hybrid approach.
• Requirements: connection, device model, version, region, language and settings.
• Data: what information is sent, retained or associated with an account, according to the applicable policy.

A developer guide can establish that a platform supports running models on the device. Google AI Edge documents language-model inference on Android through MediaPipe. That clarifies an implementation possibility, but it does not automatically identify which apps adopt it, which model they use or whether they send additional requests to the cloud. Platform capability and the behavior of a feature are not the same claim. A technical guide is useful for understanding what developers can build; to establish how a particular consumer feature works, you need evidence that refers to that feature. Keep those levels of evidence separate when drawing a conclusion.

It is also important to distinguish local execution from working entirely independently of the network. An app might calculate an answer on the phone and still need a connection to sign in, download resources, update data or sync results. Conversely, the fact that a feature works offline in one test does not by itself reveal what happens in other states of use. Android’s guide to offline-first architecture treats offline availability as a design choice for an app and its data layer; it does not let you infer where any particular product runs AI. A no-connection test can therefore be informative about availability in that test, without resolving the broader questions of processing location or data handling.

To assess privacy, look for separate information about processing, retention and controls. Apple’s documentation on Apple Intelligence distinguishes on-device processing from requests that may use Private Cloud Compute for certain tasks. Apple describes its cloud system as designed to protect data during that processing. This is the provider’s account of its architecture and stated safeguards; it should not be turned into a universal claim about every assistant, manufacturer or service. When reading such material, note what it says about the specific ecosystem and requests in question, and do not assume that the same arrangement applies to unrelated products.

A useful description should make it possible to identify what data is processed, when it leaves the phone, for what purpose and what happens afterward. If the text only promises that data is “protected” or that AI is “private,” without specifying the flow, a question remains unanswered. Also check history, activity, synchronization and data-use settings, and whether they belong to the operating system or a third-party app. Do not confuse an advertised security measure with an absence of data transfer, or the absence of a public explanation with proof that data is sent. A careful conclusion should state what the available documentation confirms, what it does not establish and which details remain unspecified.

When reviewing a feature, the conclusion should reflect the scope of the evidence. If feature-specific documentation says that a task is processed locally, you can describe it that way, including the stated requirements and limits. If a document only explains a developer tool or a platform’s general capability, the conclusion should stay at that level. If there is no verifiable explanation for the feature, the appropriate conclusion is that the processing method has not been confirmed by the sources consulted. This approach avoids turning a technical possibility into a claim about a finished product, and avoids presenting an unknown as either local or cloud-based.

Before choosing a phone or enabling a tool, it is reasonable to make four checks: find documentation for the exact feature, identify its requirements, review the relevant data policy and test offline behavior only as a practical check of availability. That last test does not replace privacy documentation or prove by itself what happens to each piece of data. The research available here does not substantiate a specific recent announcement or allow a processing method to be assigned to every feature from one brand. This guide is therefore a verification method, not news about a launch. Keep the conclusion specific to the task, evidence and conditions that have actually been checked.