Personalisation Without Sending Data Home: Adapters, Caches and What Still Leaves

Personalising a model on-device is usually described as fine-tuning on the user’s data. In practice fine-tuning is the last and most expensive of four layers, three of which are cheaper, immediate and responsible for most of the perceived improvement.

Four places personal state can live

The ordering is deliberate. Each layer is roughly an order of magnitude more expensive than the one above and none of them requires the one below. Teams that begin at the bottom spend months on training infrastructure to achieve something the top two layers would have given them in a fortnight.

Start with the cheap layers

Prompt state and a retrieval index between them cover most of what users mean by “it knows me”: it uses my name and my preferred tone, it remembers that I always want metric units, it can quote something I wrote last month.

1. Keep the profile small and structured. A handful of explicit fields — preferred language, tone, units, recurring entities — beats an accumulating free-text memory that grows without bound and silently consumes context.
2. Make it visible and editable. A settings screen listing everything the system believes about the user is the cheapest trust mechanism available, and it doubles as the deletion interface you will need anyway.
3. Embed locally, index locally. A small embedding model runs comfortably on a phone and the index is a local file. The general design considerations are the same as any embedding-based retrieval; the differences on-device are that the corpus is one person’s and that re-embedding everything is not free on battery.
4. Bound the retrieval budget. Retrieved context competes with everything else for a context window that is already short on-device, and the KV cache arithmetic in the phone memory budget gives you the exact price per token of extending it.

Local adapters, and what training on device costs

Where behaviour genuinely must change — a domain vocabulary the base model does not have, a formatting convention it will not follow reliably from instructions — a low-rank adapter trained locally is the mechanism. The base model stays frozen and shared; the adapter is small enough to be a personal artefact.

• Size. Adapters are typically a small fraction of a per cent of base model parameters, which is why the low-rank decomposition is what made this practical at all. Tens of megabytes against a multi-gigabyte base, which also means one device can hold several.
• Training cost. A backward pass needs activations retained and optimiser state held, so peak memory during training is several times inference peak. On a phone this is frequently the binding constraint, not the time.
• When to run it. Charging, idle, screen off, thermal headroom available. Treat it as a background maintenance job with preconditions, not as something triggered by user action.
• How much data is enough. Personal corpora are small, and a small corpus overfits fast. Prefer a handful of epochs on a few hundred examples over many epochs on fifty, hold out some of the user’s own data to detect the overfit, and be willing to conclude that this user does not have enough data for the adapter to help.
• Always keep the unadapted path. An adapter that makes things worse must be revertible without reinstalling, and the decision to revert should be automatic when the held-out score regresses.

What still leaves the device

This is the section that distinguishes an honest privacy claim from a marketing one. Even in a design where no personal content is ever transmitted, several things still cross the boundary:

• Telemetry, and it is derived from the data. “Adapter training completed, 240 examples, loss 0.31” is a statement about the user’s corpus. Aggregate metrics computed from personal data are personal-data-derived, and the fact that they are numbers rather than text does not change that. Decide deliberately what you collect, and consider whether a differential privacy guarantee is warranted for the ones you keep.
• Crash reports. A stack trace from an inference crash can contain the input in a buffer. Scrub or exclude the model path from crash reporting explicitly; the default is to include memory contents.
• Base model downloads and version checks. Each is a network request with an IP address and a version fingerprint, revealing which model a device is running and when it was updated. Modest, and not nothing.
• Escalated requests. If your design falls back to a hosted model for hard cases, the hard cases go up — and hard cases are frequently the unusual, identifying ones. The escalation rule is a privacy boundary, and it deserves the same review as the storage design.
• Anything the user shares. Exported, synced or shared output carries whatever the personalisation put into it. Personalised output is personal data in transit.

None of these makes local personalisation a bad design — it remains substantially stronger than the alternative. The point is that “your data never leaves your device” is a claim about the corpus, and it should be written as a claim about the corpus rather than about the system.

Backup, transfer and deletion

A personalised artefact on a device has a lifecycle that ordinary app data does not, and each stage has a decision in it.

1. Backup. Both platforms back up application data by default. An adapter trained on a user’s private messages is then in a cloud backup — possibly one they did not think about. Decide explicitly whether to exclude it, and if you include it, say so in the privacy policy in those words.
2. Device transfer. When a user moves to a new phone, either the adapter migrates or personalisation resets. Both are defensible; silently resetting after a transfer is the one that generates support tickets, because the product visibly gets worse for no visible reason.
3. Deletion. Deleting the profile must delete the adapter and the index, not just the visible settings. And it must be possible to delete personalisation without deleting the user’s content, which is a distinction people care about a great deal.
4. Base model updates. A new base model may invalidate an adapter trained against the old one. Version the pairing explicitly, refuse to load a mismatched pair, and decide in advance whether the update retrains, discards or postpones — this is the same version-skew problem described in updating models on devices you do not control.

Evaluating something you cannot see

You cannot look at the outputs, so evaluation has to be designed rather than performed.

• Hold out on device. Reserve some of the user’s own data, score the adapted model against it locally, and use that score as the gate for activating the adapter. Nothing about this needs to leave the phone; only the decision does, and even that is optional.
• Use implicit signals carefully. Acceptance rate of suggestions, edit distance between a generated draft and what the user sent, undo rate. These are meaningful and they are also behavioural data about an individual, so they belong under the same policy as everything else.
• Test the mechanism on synthetic personas. Build a set of fictional users with distinct styles and corpora, run the whole personalisation pipeline against them in your own lab, and assert that adaptation moves the outputs in the expected direction. This is how you catch a broken pipeline without ever touching a real user’s data.
• Watch for the collapse case. Personalisation that over-fits produces a model that agrees with the user about everything, including things they are wrong about. Keep a general-capability check in the held-out set so that a model which has become excellent at imitating one person and useless at the task fails the gate.