Should “local AI” have a hard no-cloud switch?

I’m experimenting with an NPU-equipped Linux laptop, and I keep wondering whether “local AI” needs a much more explicit contract. Linux NPU support is still hardware- and software-specific, and a task may move from NPU to GPU locally—or, less visibly, fall back to a cloud service. Those are very different outcomes for private prompts and files.

I’d like a visible, enforceable local-only switch at the OS or application level: no network route, no silent fallback, and a clear failure when the local model cannot cope. That could mean less functionality, slower work, or worse battery life, although efficiency depends heavily on the model, drivers, and workload. A vague privacy toggle is not enough if the product still sends data away while marketed as local.

Would you accept reduced capability for guaranteed local-only mode? I’d also like examples of software that handles this honestly.

The important distinction is enforcement. A label saying “local” is just metadata; a service with no usable network interface is a control. systemd’s PrivateNetwork=yes can provide that boundary, though it may also break updates, login, or optional web features. I’d rather see a deliberate failure than an invisible route change.

I agree, with one wording caveat: I would not call the lack of a universal switch proof that nobody has implemented one. The narrower observation is that there is no established OS-level standard covering every AI application. That makes application disclosures and independent verification unusually important.

From a product perspective, most users will choose the answer that works. The switch probably needs three states: local only, ask before leaving the device, and automatic fallback. “Ask” preserves functionality without turning consent into a buried settings page.

“Ask before leaving” is useful, but it is not equivalent to local-only. A tired user can approve a prompt reflexively, and an application can have other network traffic. For sensitive work I’d want the hard block, plus a visible backend indicator showing NPU, GPU, CPU, or remote execution.

Also, NPU-to-GPU fallback is not inherently a privacy failure. It can remain entirely on-device. The interface should name the actual execution backend instead of collapsing every accelerator into one reassuring “local” badge.

Ollama is at least a concrete example here: its documented no-cloud setting disables cloud features and web search. That is much closer to a real control than “we prioritize privacy.” I still want the surrounding application to make clear whether it is using a local model or a hosted one.

A guaranteed local mode will disappoint people occasionally. Good. A mysterious upload followed by a polished answer disappoints them permanently, assuming they ever discover it.

The failure message matters as much as the switch. “This task requires a remote model; allow?” is understandable. “Enhanced results unavailable” hides the decision and makes the privacy boundary a design detail most people never see.

Battery is the awkward trade-off. Blocking cloud fallback may keep data private but force a larger local workload, and NPU efficiency claims do not guarantee better results for every model or driver. I’d accept that trade if the device clearly stated what I was giving up.

The simplest test is to disconnect the network and see whether the application fails cleanly or behaves differently. Not a complete audit, obviously, but any product advertising local operation should make that experiment unsurprising.