Privacy by architecture: when on-device AI is the right design

People scan passports, bank statements, medical reports and contracts with their phones. Many scanning apps upload those images to a server for processing. Usually that is done for sound engineering reasons — servers are powerful and easy to update — but it means the most sensitive documents people own leave their device.

For some products, the best privacy policy is an architecture that makes collection impossible.

Policy versus construction

A privacy policy is a promise about what a company will do with data it receives. Privacy by construction is a design in which the data is never received at all. The difference matters to users, and it matters to engineers too: a system that never receives sensitive data cannot leak it from a server and does not need a retention schedule for it.

On Android, a strong and verifiable form of this is a release build that does not request the internet permission. Without it, no code in the app — including third-party libraries — can open a network connection.

When on-device is the right choice

On-device processing is a strong fit when:

• the data is highly sensitive (identity, financial, medical or legal documents),
• the task can be done well by models that fit on a phone (OCR, document detection, speech recognition, translation between a few languages),
• users need the product to work without connectivity,
• the product does not need cross-user data to function.

It is a poor fit when the task needs very large models, shared data across users or frequent model updates.

What it costs

Being honest about the trade-offs is part of the design:

• App size. Models for OCR, speech and translation are large. Google Play supports install-time asset packs, so models install with the app instead of downloading at runtime, but the download is still bigger.
• Device diversity. A model that runs smoothly on a recent phone may struggle on an older one. Benchmark on real, modest hardware early, and set a clear minimum.
• Updates. Improving a model means shipping an app update rather than redeploying a server.
• Testing. Much of the behaviour lives in native code and models, so you need instrumentation tests on physical devices, not only unit tests.

Design rules that help

• Encrypt at rest by default. Keep records in an encrypted database and keys in the platform keystore. Do not write plaintext images to shared storage, even temporarily.
• Keep the native core independent of the UI framework. A clean channel contract between the interface and the native engine makes the engine testable on its own and makes a future port to another platform far easier.
• Make sharing explicit. If users want to send a document, use the system share sheet with temporary, scoped permissions — the user decides where data goes.
• Say what you do not do. “No account, no ads, no tracking, no internet permission” is a feature, and users can verify it.

The broader lesson

Cloud processing is the default for good reasons, but it should be a decision, not an assumption. For products that handle the most sensitive data people have, choosing on-device AI turns privacy from a promise into a property of the software.