AI and Localisation Pull in Opposite Directions

The sector spent a decade committing to shift capability toward local actors. AI accumulates wherever the data, compute and engineers already are, which is almost never the local organisation. Nobody is choosing this, and it will keep happening unless it is designed against.

Published 2026-09-04 · By Shahzad Asghar

The humanitarian sector has spent a decade committing to localisation: shifting funding, decision-making and delivery toward national and local organisations rather than international ones. It is one of the few reform agendas the sector agrees on in principle.

Artificial intelligence pulls the other way. Not because of anything about the technology, but because of where its inputs sit. AI capability accumulates wherever the data, the compute and the engineers are, and in this sector that is almost never the local organisation.

Nobody is choosing this. It is the default outcome of how these systems get built, and it will keep happening unless it is designed against.

How the concentration works

Data flows upward. Local organisations collect it — registrations, assessments, feedback, case notes. Aggregation happens centrally, because that is where the data warehouse and the analysts are. The organisation that gathered the data becomes a supplier of inputs rather than a user of outputs.

Models are built centrally and pushed down. A national NGO receives a tool. It did not specify it, cannot inspect it, and cannot change it. Whether the tool fits how that organisation actually works is discovered afterwards.

The ability to evaluate sits centrally too. This is the one that compounds. Being able to tell whether a vendor's claims are true is scarcer than being able to use the product, and it concentrates even faster. An organisation that cannot evaluate a system cannot meaningfully consent to using it.

Procurement happens above the local level. Contracts are signed by whoever holds the budget. The local entity is often not a party to the agreement governing a system it operates daily and whose data describes its own community.

Failure cannot be fixed locally. When the system produces a wrong answer, the local office raises a ticket. It does not hold the model, the code, or the contract. The people closest to the harm have the least ability to stop it.

Each of these is individually reasonable. Together they describe a sector that has spent ten years trying to move capability outward, adopting a technology that moves it inward.

The consent problem underneath

There is a sharper version of this at the level of individual people.

A displaced person asked to accept automated processing of their data has, in practice, one option if they want assistance. Consent that cannot be refused without losing access to food, shelter or registration is not consent in any meaningful sense. The sector knows this — it is why humanitarian data protection guidance generally does not rely on consent as a lawful basis, and uses vital interests or public interest instead.

That is the correct legal answer, and it places the entire ethical burden on the organisation. If the person cannot meaningfully decline, then every safeguard has to be built in by the people deploying the system. Nothing is delegated to the user's judgement, because the user has no real choice to exercise.

Which returns to the same problem: the organisation best placed to judge whether a system is appropriate for a given community is usually the local one, and it is the one with the least influence over whether the system is used.

Why this is not an argument against AI

Some things genuinely need scale. Training a model on a large corpus, maintaining infrastructure, defending against attacks, negotiating with vendors — these do not decentralise well, and pretending otherwise produces worse outcomes rather than more equitable ones.

The argument is narrower. Right now the split between what is centralised and what is local is being set by convenience rather than by design. The result is that everything ends up central, including the parts that did not need to be.

What localised AI would actually require

Move the model to the data, not the data to the model. Small models now run on modest hardware, so a national organisation can process its own case notes without shipping them anywhere. That was not realistic three years ago and is now routine — see running AI locally without a GPU for what it takes in practice.

Fund the ability to evaluate, not only the ability to use. Training somebody to operate a tool creates a user. Training somebody to test whether the tool works creates an organisation that can say no. The second is cheaper than most people expect and worth considerably more.

Name local entities in contracts. If an organisation operates a system, holds the relationship with the affected community, and bears the consequences of failure, it should be party to the agreement governing it. Where that is impossible, someone should be able to say why.

Build the stop condition locally. Whoever is closest to the harm should be able to halt the system without escalating through three levels first. This is the single most under-implemented control in the sector, and it costs nothing to grant.

Design for the exit. The test is what happens when the vendor withdraws or the grant ends. If the answer is that the capability disappears, it was never localised — the same argument that applies at national scale in what sovereign AI cannot buy.

The test worth applying

Before deploying anything, ask: after the vendor and the international agency leave, who can change this system?

If the answer is nobody, the project has increased dependency, whatever the proposal said about capacity building. That is not always unacceptable — sometimes a dependency is worth taking on deliberately. But it should be a decision somebody made, rather than a fact discovered two years later when the funding ends.

The related question is who can stop it, which is the same test at a shorter time horizon. A system that only its author can halt is not under the control of the organisation running it.

Where this leaves practitioners

If you work in an international organisation, the useful question is which parts of what you are centralising genuinely need to be central. The honest answer is usually fewer than the current architecture assumes. Data aggregation is often a convenience rather than a requirement.

If you work in a national organisation, the highest-value investment is evaluation capacity rather than tooling. Being able to assess what you are offered changes your position more than any single system will. The staged approach in the practical AI roadmap for national NGOs assumes exactly that sequence.

If you fund this work, notice that capacity building is usually budgeted as training people to use a tool. Funding the ability to judge tools would do more for localisation than another deployment.

None of this is an argument for slower adoption. It is an argument that where capability lands is a design decision, and it is currently being made by default. The sector spent a decade arguing that proximity to affected people should carry more weight. AI is a test of whether that was meant.

For the wider picture, see AI in humanitarian operations and AI for refugee operations. For monitoring once a system is live, how to tell a last-mile AI system is failing.

Frequently asked questions

Does AI undermine humanitarian localisation?

Not inherently, but by default it does. AI capability accumulates where data, compute and technical staff are concentrated, which is rarely the local organisation. Unless the split between central and local is designed deliberately, adoption tends to move capability away from local actors.

Can affected people meaningfully consent to AI processing?

Usually not, when declining would mean losing access to assistance. This is why humanitarian data protection guidance generally does not rely on consent as a lawful basis. It places the full ethical burden on the deploying organisation, because the individual has no real choice to exercise.

What would localised AI actually look like?

Models running where the data already sits rather than data being shipped centrally; local staff funded to evaluate systems rather than only operate them; local entities named in contracts; a stop condition that can be exercised locally; and a design that survives the vendor or the grant ending.

Should humanitarian data always stay in country?

Not always, but the default should be examined rather than assumed. Aggregation is frequently a convenience rather than a requirement, and small models on modest hardware now make local processing realistic for many workloads that previously needed a central platform.

What is the single best test before deploying AI in a humanitarian setting?

Ask who can change the system after the vendor and the international agency leave, and who can stop it today. If the answer to either is nobody local, the deployment has increased dependency — which may still be the right call, but should be a decision rather than a discovery.

Is training staff to use AI tools enough capacity building?

No. Training someone to operate a tool creates a user; training someone to evaluate whether it works creates an organisation that can decline. The second is what shifts the balance, and it is usually cheaper than the deployment it governs.

← All articles