Does on-device AI provide better privacy?

What on-device AI does and does not mean

Local inference means the model's computation happens on your phone, tablet, computer, or another device you control, rather than on a remote server. If the relevant input remains in the app's local memory and files, that removes a major recipient of the data. It can also reduce latency and allow a feature to work without an internet connection. Google's Android developer documentation describes on-device prompting as processing prompts and data directly on the device without sending them to a server, and identifies privacy and offline reliability as benefits. Android on-device inference guidance gives a concrete example.

That advantage is conditional. A local model still runs inside an operating system, a signed application, and a device that may be shared, lost, infected, unlocked, or backed up. The app developer can still choose what it collects, stores, or transmits around the model. A cloud service can still receive data from linked search, web, calendar, email, document, or account features. A local response can still be saved in a history, search index, clipboard, screenshot, diagnostic report, or synced folder.

Do not read "encrypted" as "never leaves the device." Encryption in transit protects a network connection from ordinary interception. Encryption at rest protects stored data under a particular key-management design. Neither tells you whether an app sent a prompt, who could decrypt it at the destination, whether it was logged, or whether it will appear in a backup. Privacy depends on data flow, access control, retention, and accountability together.

The whole path matters

The table is why an honest product description should say more than "on-device." A useful statement identifies which operation is local, whether any fallback exists, what is retained, and which settings alter that behavior. A vague claim leaves the user unable to decide whether their particular data stays private.

Cloud fallback makes the boundary hybrid

Many capable systems are deliberately hybrid. A device may handle simple transformations locally and route larger, slower, or tool-using requests to a cloud service. That can still be a privacy-conscious design, especially if the remote service uses strict technical controls, but it is not the same claim as "nothing leaves the device."

Apple documents this distinction clearly. Apple Intelligence first determines whether a request can be processed on device; more complex requests can use Private Cloud Compute. Apple says that a user can create an Apple Intelligence Report showing both OnDevice and PrivateCloudCompute model requests. Apple Intelligence privacy information and the Apple Intelligence Report documentation show why product-level labels are insufficient. A feature can be local sometimes and remote at other times.

Do not assume a cloud fallback is automatically unsafe, or that it is indistinguishable from ordinary cloud AI. Apple describes Private Cloud Compute as stateless for personal request data and designed for public inspection of production software, but those are claims and controls specific to that architecture. Apple's Private Cloud Compute Security Guide explains the stated boundary. For any other service, look for comparable, specific information about what is sent, who can access it, retention, model training, subprocessors, and independent verification. If the answer is only marketing language, treat the feature as unverified for sensitive work.

Telemetry, permissions, logs, and local storage

An AI app needs access to data before it can process it locally. That access is still powerful. A photo summarizer may need only the picture you select, whereas an app with broad photo-library access can examine more than the one item you meant to share. A voice feature should request microphone access when you start recording, not quietly retain it for unrelated functions. Android's guidance recommends minimising permissions and using scoped alternatives such as photo and contact pickers where possible. Android permission minimisation guidance is a useful standard for judging an app's request.

Permissions tell you what an app may read or record. They do not by themselves reveal where the data goes. On iPhone and iPad, App Privacy Report can show recent access to privacy-sensitive data and sensors, as well as domains contacted by apps. The report is collected only after you turn it on and is stored encrypted on the device. Apple's App Privacy Report documentation explains both its coverage and its limits. On Android 12 and later, the Privacy Dashboard can show when apps accessed location, camera, and microphone, and system privacy indicators notify you of microphone or camera access. Android privacy checklist describes these controls.

Local logs deserve the same scrutiny as network traffic. A crash report or debug message may contain parts of a prompt, a filename, an account identifier, or an error response. Android identifies sensitive information in application logs as a confidentiality risk and advises that production logs be sanitised or removed. Android guidance on log disclosure is aimed at developers, but its warning applies to users deciding whether a supposedly local tool has a safe retention design. Check whether an app has a diagnostic-data switch and whether its support instructions ask you to upload logs.

Local storage can be excellent protection against a remote provider while still creating a risk from someone who obtains an unlocked computer or phone. Use a strong device passcode, keep the operating system and app updated, and use separate accounts on shared computers. Platform encryption is valuable, but it is not a defence against an authorised app while the device is unlocked, a malicious extension, or malware already running with high privilege.

Backups and sync can quietly change the answer

A file can be processed locally and later copied to the cloud by backup or sync. This is easy to miss because it may happen overnight and outside the AI app's user interface. Android Auto Backup, for example, automatically backs up most app data to a user's Google Drive by default for eligible apps; developers can exclude files or disable backup. Android's documentation also states that the default set includes files in app internal storage and app databases. Android Auto Backup documentation explains the default and the available exclusions.

The protection of a cloud backup depends on the service and settings, not on where the model ran. Apple's standard iCloud protection encrypts data in transit and on its servers, with keys secured in Apple data centres. Apple's optional Advanced Data Protection expands end-to-end encryption to more categories, including device backup and third-party app data in iCloud Backup. Apple's iCloud data security overview explains the difference. Other platforms and backup providers have different defaults. Check the exact account, device, and app settings rather than assuming all encrypted backups have the same trust boundary.

For a sensitive local workflow, decide deliberately whether to keep inputs and results out of cloud backup and sync. Look for an app setting such as "do not back up," a local-only folder, or an exclusion for generated history. If no such control exists, assume that a file stored in ordinary app data may be backed up when the platform and app permit it. Deleting a chat from the visible history may not delete copies from exports, backups, or crash records, so read the deletion and retention documentation too.

Match the checks to your privacy concern

Privacy is better when the design addresses the person or organisation you are worried about. Start with a specific concern instead of a general desire for "privacy." The table below does not rank threats. It shows why local inference helps some more than others.

For example, a person who does not want a cloud model provider to receive a draft contract may accept a well-maintained local editor on a locked work laptop, with backups approved by their employer. A journalist protecting a source from a potentially compromised laptop, untrusted browser extension, or cloud-synced screenshots has a different problem and needs stronger operational security. In both cases, "on-device" is helpful information, but it is not the whole answer.

How to verify a local-AI privacy claim

You usually cannot prove an arbitrary commercial app is never sending data just by reading a slogan. You can, however, gather useful evidence and make the claim more precise. Test only with harmless sample text, an invented image, or a non-sensitive voice note. Do not use real secrets as a test prompt.

1. Name the feature precisely. A product may have local transcription but cloud search, local image categorisation but cloud editing, or local chat with a remote fallback. Read the help page, privacy policy, and settings for the specific button or mode you plan to use.

2. Set up the local capability first. A model may need a one-time download before it can work offline. Note its size, publisher, version, and the app's update setting. A successful download does not prove later inference is local, but it distinguishes setup traffic from request-time traffic.

3. Run a simple offline test. After setup, disable Wi-Fi and cellular data or use airplane mode, then try a harmless request. If it works, that is evidence that the tested operation can run locally in that configuration. If it fails, the feature may require cloud access, a licence check, a network tool, or a fallback. Either result is informative, but neither alone proves what happens in all situations.

4. Review permissions before and after the test. Remove broad access that is not necessary, use selected-photo or one-time permissions where available, and watch microphone and camera indicators. On platforms that offer an activity report, compare the app's data and sensor access with the feature you actually used.

5. Observe network destinations in a controlled test. An operating-system privacy report, local firewall, trusted router log, or privacy-respecting network monitor can show when the app contacts domains. Record the time, feature, and destination. Domain names and traffic volume cannot reveal every payload, and encrypted connections usually prevent an ordinary observer from reading contents. They can still reveal that a supposedly offline feature is making requests.

6. Inspect storage, history, and backup behavior. Look for local chat history, generated files, temporary media, export folders, and sync settings. Delete the harmless test, then see whether its preview or result remains. Check whether the app has a clear export and deletion policy. Review device backup and cloud-sync settings separately.

7. Repeat after updates or when the feature changes. A later model, app version, region, subscription tier, or request type can introduce a new route. Keep a short record of the version and settings you verified. For high-risk data, prefer a product that documents its design and lets independent parties inspect or reproduce key privacy claims.

Network testing has limits. A monitor may attribute system traffic imperfectly, a domain can serve many functions, and installing a traffic-inspection certificate or a poorly vetted VPN can create a new privacy risk. Use destination-level observation as a signal, not a licence to intercept other people's data or defeat application security. When the consequence of disclosure is serious, obtain an expert review rather than relying on a home test.

Example

Consider a hypothetical receipt-organising app that says its summarisation feature is "fully on device." The input is an image containing a shop name, purchase items, date, and perhaps part of a payment number. The intended action is to extract the total and category without sending the receipt to a cloud model.

First, download the optional local model over a trusted connection, then test the feature with a made-up receipt while the device is offline. Grant only selected-photo access rather than the whole library if the operating system offers it. Turn on the device's privacy activity report before testing, watch whether the app contacts a domain when it runs, and check whether the resulting summary is stored in an app history or a cloud-synced folder. Finally, review whether the app's data is included in device backup and whether that backup has the protection you expect.

The privacy benefit depends on these checks. If the feature works offline after setup, uses only the selected image, has no unexpected network activity, keeps the result in a protected local location, and is excluded from untrusted sync, it is substantially more private from a cloud model provider than uploading the receipt to a web chatbot. It is still not safe to assume the device itself, its backups, or every future app update are harmless.

Choosing a sensible level of caution

For ordinary personal notes, local transcription, photo categorisation, or document cleanup, choosing a fully offline mode, limiting permissions, disabling optional analytics, and checking backups is often proportionate. Keep the software updated and avoid installing unknown models, extensions, or "privacy tools" that demand broad device access. Local processing can improve privacy while remaining practical.

Raise the bar for passwords, authentication codes, health information, legal strategy, intimate images, unreleased business material, client records, source-identifying information, or other data whose exposure could cause serious harm. Use an approved organisational workflow when one exists. If no local option has a documented data path, appropriate device security, controlled backups, and an acceptable fallback policy, do not treat the word "on-device" as authorisation to submit the data.

The most useful purchasing question is therefore not "Is the AI on device?" Ask: "For this feature, on this version and with my settings, which data is read, what leaves, what is retained, who can access it, and how can I verify or change that?" A provider that answers those questions precisely is offering a privacy property. A provider that only repeats a local-AI label is offering a claim you still need to test.