Discussion 2: privacy, on-device processing and meaningful choice
We often judge an app’s privacy by reading its policy.
Who can access the data? How long is it stored? Is it shared with advertisers? Can we delete it?
Those are important questions. But perhaps there is an earlier one:
Did this information need to leave my device in the first place?
An app can have a clear privacy policy, responsible developers and secure servers. Sending data to a server does not automatically make an app unsafe. Encryption, access controls and good operational practices can protect information in the cloud.
But once personal data leaves a phone or computer, privacy depends on a longer chain of trust. We may need to trust the app company, its hosting provider, its technical partners, its security procedures, its future business model and the legal environment in which the data is processed.
Even when everyone behaves responsibly, another copy of the data exists somewhere outside the person’s direct control.
That changes the nature of privacy.
Privacy policy or privacy architecture?
A privacy policy explains what a company promises to do. Architecture determines what the system is capable of doing.
If a service is designed so that personal notes, photos, calendar information or health records remain on the device, the company does not need to promise that it will avoid looking at that information. In normal operation, it never receives it.
This is an important difference.
It moves privacy away from “Trust us with everything” and closer to “We designed the system so that you do not have to.”
European data-protection rules use the ideas of data protection by design and by default. This means considering privacy from the beginning and, by default, processing only the personal data necessary for a specific purpose.
It does not mean that every service must work locally. On-device processing is one practical way to reduce unnecessary collection and make data minimisation part of the product’s structure.
What on-device processing can change
When work happens on the device, an app may be able to organise a calendar, search notes, analyse patterns or prepare a report without uploading the underlying information to its own servers.
That can offer several practical benefits:
Sensitive information does not need to travel across the internet for every task.
A central database containing many users’ personal histories may not need to exist.
Some features can continue working without an internet connection.
The user’s own device remains the primary place where the information lives.
Deleting the local information can have a clearer and more immediate meaning.
The difference becomes especially interesting with AI.
AI becomes more useful when it has context. To answer meaningful personal questions, it may need access to calendars, notes, documents, photos or health information. The easiest technical solution is often to upload that context to a remote model.
But “easy” for the system is not always the best default for the person.
Smaller models and local processing can already handle some tasks on modern devices: organising information, extracting structure, searching, classifying or preparing a first summary. More demanding requests may still benefit from a cloud model.
The useful distinction is not “local good, cloud bad.” It is whether the user has a real choice.
A privacy-respecting system could work locally by default, clearly explain when a task requires external processing, show what information will be sent and let the person decide each time.
Cloud AI then becomes an optional tool rather than an invisible pipeline through which everything passes.
On-device does not automatically mean private
Keeping data locally is not a magic shield.
A device can be stolen. Another app may have excessive permissions. An unencrypted backup can expose information. Malware, weak passwords or an unlocked screen can defeat otherwise careful design.
If there is no reliable backup, a lost or damaged device can also mean losing years of personal history.
Good local-first software still needs encryption, careful permissions, safe recovery, understandable backups and usable exports.
There is also a difference between information stored in a cloud service with strong end-to-end encryption and information that the service provider can read. “Stored in the cloud” and “available to the company” are not always the same thing.
The point is not to replace one simplistic privacy label with another. The point is to understand what actually happens to the data.
Questions worth asking before trusting an app
Instead of asking only whether an app describes itself as private, we could ask:
Which features work without an internet connection?
What information leaves my device, and for what exact purpose?
Is cloud processing necessary, or simply the default?
Can I choose separately when AI receives personal context?
Does the company store a readable copy of my information?
How are local data and backups protected?
Can I export my information in a useful format and leave?
Most people will not inspect a system’s technical architecture. They should not have to. These answers ought to be understandable from the product itself.
Privacy can be a property, not only a promise
Cloud services make many valuable things possible: collaboration, syncing, recovery and access from different devices. The goal does not need to be a completely offline life.
But personal information should not leave a device merely because that is the easiest architecture for the developer.
Perhaps the better default is simple: do as much as reasonably possible close to the person, send only what is necessary, and make every additional use visible and optional.
I’m curious how others think about this:
Do you check whether an app works locally, or mainly read its privacy policy?
Would you accept fewer or slower features in exchange for keeping sensitive data on your device?
When an AI feature needs cloud processing, what should the app show before you agree?
Do you consider end-to-end encrypted cloud storage as private as local storage?
Maybe the most trustworthy privacy promise is the one a company does not need to make—because it never receives the data.
Sources: The European Commission explains data protection by design and by default. The European Data Protection Board describes it as building protection into systems from the start and making privacy-protective settings the default.