Running AI Where the Network Is Not

Last updated: 2026-08-15

Running AI in low-connectivity settings means designing for intermittent rather than absent networks: work is queued locally, synchronised when a connection appears, and the interface tells the user what has and has not been sent. Systems fail in field conditions rather than in the laboratory because laboratories supply reliable power, one language, clean input, and users who expect the system to work.

How to run AI in low-connectivity and offline settings, and why systems that pass every laboratory test fail in field conditions.

Running AI Where the Network Is Not

A system that performs well in testing and fails in a field office is not suffering a model problem. It is meeting the conditions it was never designed for, and those conditions are predictable enough to design against.

Why laboratory success does not transfer

A development environment supplies, without anyone noticing, a set of guarantees: reliable power, a stable network, input in one language typed by someone familiar with the system, a device with a modern browser, and a user who assumes the tool works and will retry if it does not.

Remove those guarantees one at a time and most systems degrade in ways their tests never exercised.

Power is intermittent, so sessions terminate mid-task. The network is present but poor, which is harder to handle than absent, because requests hang rather than fail. Input arrives in several languages and scripts, transliterated, abbreviated, and typed under time pressure. Devices are older, sometimes shared, often with constrained storage. And the user has no reason to trust the system: one confusing failure and they revert to the paper process permanently, which is a rational choice that no amount of later improvement reverses.

The general argument is set out in the Last-Mile AI framework. What follows is the engineering that goes with it.

Design for intermittent, not offline

The common framing is a binary: online or offline. Field reality is intermittent, and that distinction changes the architecture.

Make the local state authoritative for the duration of the task. Work is captured on the device, held there, and synchronised when a connection appears. A user should never lose an hour of work because a network dropped at the moment they submitted.

Queue and reconcile rather than block. Actions are recorded with enough context to be replayed. Conflicts, two edits to the same record from different offices, need an explicit resolution rule decided before deployment rather than an error message afterwards.

Show the sync state honestly. The most damaging pattern is an interface that implies success when data is still queued. Users make decisions about whether to repeat work based on what the screen tells them, and a false confirmation destroys trust faster than a visible failure.

Fail toward the human process. When the system cannot function, the fallback should be the paper or verbal process that existed before, not a blank screen. Staff need a defined route to keep serving people while the system is unavailable.

Where the model actually runs

Three placements, each with a distinct trade.

Server-side with a thin client. The strongest models, no device constraints, and nothing works without connectivity. Appropriate where offices have reliable connections and the work is not time-critical.

On-device, small model. Runs regardless of network, keeps data local, and accepts a real capability reduction. This is the frugal AI position: choosing a smaller model that is adequate for a narrow task over a larger one that cannot be reached. It works well for classification, transcription of short utterances, structured extraction, and language identification, and poorly for open-ended reasoning.

Hybrid. A small local model handles the common path and preserves function when the network is down; requests that exceed it are queued for server-side processing when a connection returns. This is usually the right answer for humanitarian operations, and it costs more to build than either pure option because both paths must be correct.

Voice is often the right channel

The most effective field decision is frequently not about the model. Where users have basic handsets, limited literacy, and no data plan, a voice service reaches people an application never will. A voice-based appointment system built on that reasoning at UNHCR was used by more than 700,000 refugees and reduced registration service time by 83 percent, described in AI for refugee operations.

Choosing the channel people already hold, rather than the channel that is convenient to build, tends to matter more than model selection.

Testing that predicts field behaviour

Test on the oldest device in the deployment, not a current one. Test on a throttled and unreliable connection rather than an absent one, because hanging requests are the failure mode. Test with input in the languages and scripts the population actually uses, including transliteration and mixed script. Test the interruption path: power loss mid-task, and what the user sees on return. And test the fallback, because the fallback is what runs on the worst day.

A system that has not been tested under these conditions has been tested against an environment it will never encounter.

Written by Shahzad Asghar, Head of Data and Digital Solutions at UNESCWA. See all articles, the playbooks, and the templates.