Mobile AI features need product boundaries

A mobile AI feature has to earn its place in the product. It is not enough to say the app uses an LLM, embeddings, agents or on-device inference. The user does not care about the architecture until the feature helps them do something better.

The first question is product-shaped: what user decision becomes easier, faster or safer because AI is involved?

Without that boundary, AI becomes a demo inside the app instead of a product capability.

Mobile users feel waiting differently. A half-second pause during typing, navigation or camera capture can make the feature feel broken even if the model is fast by backend standards.

AI features need explicit latency design. What happens immediately? What can stream? What can be computed in the background? What can be cached? What must wait for the user to confirm?

A good architecture does not only ask where inference runs. It asks what the user sees while intelligence is being produced.

Mobile apps often hold sensitive context: location, contacts, health, finance, messages, photos, documents and behavioural signals. Sending that context to a model is not a small implementation detail.

The team needs rules for what data can leave the device, what must stay local, what is redacted, what is logged, how prompts are stored and how users can understand the behaviour.

On-device AI is attractive because it can reduce latency and privacy risk, but it also has constraints: model size, battery, memory, accuracy and update cadence.

Where inference runs, on the device, in the cloud or split between them, gets its own chapter in Controlled Change, inside a part that treats AI as a new client and server boundary with its own budgets and threat model.

A receipt app adds a button that extracts an expense from a photo. The demo returns a merchant, a date and a total. The harder question is what the user may trust before they submit. Write the contract before choosing where inference runs:

From a receipt photo the user selected, propose merchant, date, currency and total. Show the fields as a draft. The user can edit or discard them and must confirm before submission. If extraction is unavailable, manual entry remains available.

A draft limits what a wrong result can do, so make review easy: the receipt beside the fields, and nothing that styles a proposed total as approved. Show a processing state at once, and if the user starts typing while extraction is pending, a late result must not overwrite their edits. Then decide what verifies each data route:

Test the mistake that changes an expense: several amounts on one receipt, an ambiguous date, a partly hidden total. Record wrong and ambiguous outputs separately. An average score hides a wrong total.

AI features fail in more ways than normal features. They can be slow, unavailable, uncertain, wrong, overconfident or inconsistent between attempts.

The product should define fallback behaviour before launch. Can the user continue manually? Is there a confidence threshold? Do we show sources? Do we ask for confirmation? Do we hide the feature when the model is unavailable?

If the fallback is not designed, the user becomes the fallback.

For every AI feature, ask: what context is needed, where does inference run, what data can leave the device, what latency is acceptable, what happens when the answer is wrong and how do we measure trust?