On-Device Small Models Move the Data Problem, Not the Risk

"It runs on the device, so the data never leaves" is the most persuasive sentence in an AI privacy review, and it is true about the network. It is not true about the risk, which moves from a monitored server to a device you do not control.

What moves with the model

• The corpus follows the model. Local assistants index mail, messages and documents to be useful, creating a searchable copy of sensitive data on the handset.
• Cached context persists. Conversation history and retrieved snippets sit in app storage, surviving the session and often the backup boundary.
• The model file itself is an asset. A fine-tuned model embeds the behaviour and sometimes the content of what it was trained on, and it is copyable.
• No server-side audit. There is no log of what was asked. Incident response has nothing to reconstruct.
• Patch lag is the user's choice. A vulnerable inference runtime stays vulnerable until the user updates.

Controls that fit the model

1. Classify before you approve

On-device is a good answer for personal productivity data and a poor one for regulated records that must remain auditable.

2. Require managed devices for managed data

If the assistant indexes corporate content, the device needs enrolment, encryption, remote wipe and a runtime patch policy — the same bar as any other data store.

3. Bound the local index

Scope what the assistant may index, and expire the cache. An unbounded local index is an unmanaged data lake in someone's pocket.

4. Sign and verify model files

A swapped model file is a swapped program. Verify signature and version at load, and pin the runtime.

5. Keep a local audit trail

Even a minimal on-device record of what the assistant accessed makes a future investigation possible. Nothing is not an option for regulated use.

Local inference removes the network exposure and hands the residual risk to the least managed asset in the estate.