The future of AI is local-first

A cloud-only future makes growth in AI use dependent on centralised inference capacity. The International Energy Agency estimates that data-centre electricity use grew by 17% in 2025, reaching about 485 terawatt-hours. Its central projection approaches 950 TWh by 2030 (IEA, Key Questions on Energy and AI).

The constraint is not only how much electricity exists globally, but where and when it can be delivered. The IEA estimates that a data centre can be built in one to three years, while new grid infrastructure can take five to fifteen (IEA, Electricity 2026: Grids).

Better chips will not remove that pressure by themselves. The IEA estimates that the electricity used per AI task has fallen by at least an order of magnitude annually in recent years, while total data-centre demand has continued to grow. Cheaper inference creates more users, more uses, and more intensive workloads (IEA, Key Questions on Energy and AI).

Local-first does not eliminate energy consumption. It changes how intelligence scales. When an adequate model runs on hardware already deployed, that task no longer requires remote inference or network transport. Cloud expansion is no longer the only way to expand access to AI.

Local inference is the natural default when suitable hardware is already present and a smaller model can meet the task's requirements. Modern phones and computers increasingly contain neural-processing hardware whether or not it is fully used. In that situation, a routine task can draw on capital that has already been purchased instead of calling a remote accelerator every time.

The case becomes stronger when:

• a smaller model can meet a defined quality threshold;
• the interaction happens frequently;
• the input contains personal or commercially sensitive information;
• latency, reliability, or offline access matters;
• the source is a large audio, video, or sensor stream; or
• local processing can reduce that stream to a small, useful signal before anything is transmitted.

Consider a camera that needs to detect one type of event. Sending a continuous video feed to a distant model moves and stores far more data than sending the event itself. The same logic applies to a device listening for a wake word, indexing personal files, or monitoring industrial equipment. The International Telecommunication Union now explicitly recommends dynamic placement across device, edge, and cloud, including local filtering, compression, and anomaly detection to avoid unnecessary transmission (ITU-T L.1341).

Privacy is another reason to keep computation close, although “local” should not be confused with “secure by definition”. A poorly protected device can still leak data. The architectural benefit is narrower and important: information that never leaves the device is not exposed to the network or a remote service in the first place.

Local execution also changes the economics of access. It still consumes electricity and device capacity, but it need not create a new per-token charge. For frequently repeated, modest tasks, that difference is what can turn AI from a metered service into ordinary computing infrastructure.

The cloud remains the right location for many workloads. Frontier models may require more memory and processing power than a consumer device can provide. Training, complex scientific work, and high-volume shared services benefit from large clusters, fast interconnects, and expert operation. Central systems can keep knowledge current, coordinate across users, and deploy one model update instead of distributing it to millions of devices.

Utilisation matters too. For a demanding task performed twice a month, shared compute may be more sensible than provisioning powerful local hardware that otherwise sits idle.

The cloud is also a pool of capability. It lets users rent exceptional performance occasionally without owning exceptional hardware permanently.

The mistake is not using the cloud. It is treating the cloud as the default answer before the task has been examined.

The most defensible design rule is:

Start with the smallest adequate model on the nearest available layer. Escalate only when the task requires it.

The placement decision depends on more than model quality. It must account for latency, privacy, network transfer, utilisation, device wear, facility overhead, embodied hardware, carbon intensity, and money. The ITU's 2026 guidance for assessing AI's environmental impact makes the same methodological point: the system boundary should cover training, inference, storage, data transfer, cooling, and relevant end-user devices across the lifecycle (ITU-T L.1801).

A well-designed system can make that decision in layers.

1. Device: Handle private, frequent, and latency-sensitive tasks with a compact local model.
2. Edge: Use a nearby shared server when the device is insufficient but distance and data volume still matter.
3. Cloud: Escalate work that needs frontier capability, large memory, current shared knowledge, or exceptional scale.

Local-first is a routing policy: begin on the nearest layer capable of meeting the requirements and escalate only when necessary.

Only the information necessary for the next layer should move with the request. This is no longer a theoretical pattern. Apple describes Apple Intelligence as processing on-device whenever possible and using Private Cloud Compute for more sophisticated requests that need larger models (Apple, Private Cloud Compute Security Guide).

The significance is not that Apple's implementation settles every privacy or efficiency question. It is that a major commercial system already treats device and cloud as complementary layers.

Local-first is not local-only. It is an ordering of defaults.

Routine intelligence begins close to the user. Work moves outward only when the device cannot satisfy the task's requirements. This preserves centralised capacity for the problems that genuinely benefit from it while keeping common, private, and latency-sensitive work under local control.

A frontier research problem, a private document search, and a camera detecting motion have different requirements. Forcing them through the same model in the same location is not simplicity. It is waste disguised as standardisation. Intelligence should be proportional to the problem being solved, and scale should be reserved for the moments when it improves the result enough to justify its cost.

The future of AI will not be one enormous brain in the cloud, nor billions of isolated models on devices. It will be a hierarchy of computation: private and immediate where possible, shared and powerful where necessary. Local by default. Cloud by exception. Scale when scale earns its cost.