Local AI: the excuse is about to disappear.

The AI headlines this month have been dominated by two launches. Anthropic released Claude Opus 4.7 on 16 April. OpenAI released GPT-5.5 on 23 April, calling it "a new class of intelligence for real work." Both are impressive. Both are cloud models that, for ordinary organisational use, usually mean sending prompts and files to a US company's cloud infrastructure. Ethan Mollick, whose newsletter tracks AI capability shifts more closely than most, called GPT-5.5 "a noteworthy step along the way" and noted that the frontier keeps moving outward. He is right. But for humanitarian teams, the more important question is not where the frontier is now. It is that last year's frontier just became free, private, and available on a desktop.

The release that may matter most for humanitarian AI happened three weeks earlier, and I have not seen a single piece in the sector about it.

At the start of April, Google released Gemma 4, an open-weight model family under an Apache 2.0 licence that organisations can download, run, and deploy commercially. The largest version, at 31 billion parameters, is already ranked among the strongest open models globally. On several public benchmarks it is now competitive with models that many organisations treated as frontier-grade only a year ago. GPT-4o was only retired from ChatGPT in February, which is a useful reminder of how quickly last year's frontier becomes this year's baseline. Gemma 4 runs on a desktop computer that costs less than a year of ChatGPT subscriptions for a small team. And if deployed correctly, nothing you put into it ever leaves the machine.

This is the fifth piece in a series I started last November. Shadow AI. The Liar's Dividend. The three principles we teach at AidGPT. Last week's piece on what the ACF UK training data actually showed, and the quiet failure mode that keeps me up at night. Each of those pieces assumed something I never stated directly: that using AI in humanitarian work meant sending your data to a US technology company. That was true when I started writing this series. It is about to stop being true.

What changed

At the start of April 2026, Google released Gemma 4 under an Apache 2.0 licence. Anyone can download, run, modify, and deploy the model commercially, without usage-based fees, subject to the licence terms. The model family includes four sizes, from a 2-billion-parameter version aimed at high-end phones to a 31-billion-parameter version that runs on a desktop.

The 31B model is currently ranked near the top of open-model leaderboards. It scores 89.2% on the AIME 2026 maths benchmark, up from 20.8% on Gemma 3 a year earlier. It supports more than 140 languages, processes text and images, and has a 256,000-token context window. A year ago, this level of local capability would have looked unrealistic for ordinary office hardware. Today it runs on a Mac Mini.

The Mac Mini on your desk

A Mac Mini M4 Pro with 48GB of unified memory and a 1TB drive costs around $2,000. Gemma 4 31B fits comfortably within this class of machine when compressed for local use. The first installation can be as simple as a single command. No cloud account. No API key. No subscription. If configured to run fully locally, the data never leaves the room.

A team of ten using ChatGPT Plus subscriptions pays $200 a month, $2,400 a year. In a year, they have spent more than the Mac Mini costs. And under ordinary ChatGPT use, those prompts and files have still passed through OpenAI's cloud infrastructure. The Mac Mini pays for itself inside a year, runs indefinitely with zero marginal cost per query, and keeps everything local.

What this changes for humanitarian teams

When a programme officer in Cox's Bazar uploads a forty-page needs assessment to ChatGPT for summarisation, they may be using AI in exactly the way we teach: on a specific source document, not from the model's memory. And if their organisation has an enterprise licence, a data processing agreement, and the right retention settings, the provider may be contractually committed not to train on or reuse that data.

But that does not remove the harder questions. The document may contain location data, caseload figures, protection concerns, names, and details shared by people who were never asked whether they were comfortable with their information being processed by a US AI company. It may also bring the data within a foreign legal jurisdiction, including the possibility that a US provider can be compelled to disclose information under legal process, sometimes without the organisation or affected people being told. That is not the same risk as "OpenAI will train on your data". It is a sovereignty, consent, neutrality, and trust risk.

This is the tradeoff I have watched staff make, quietly, in every training cohort since NRC Sudan. They know the data risk. They also know the operational reality: seven deadlines, no additional staff, and a forty-page document nobody has time to read properly. So they make a judgement call.

Local models can reduce that tradeoff for the document-analysis workflows that matter most. You can still use AI's mind, not its memory: upload the source document, use the AI's analytical capacity, and keep the data on the machine. The AI Workflow Card still matters. The data classification question still matters. But the answer changes when the sensitive document does not leave the room.

What free compute actually unlocks

There is a third argument for local models that has nothing to do with data sovereignty or subscription costs. It is about what becomes possible when you stop paying per query.

Cloud AI pricing pushes users toward single-shot workflows. You ask once, you accept the output, you move on. The economics push you toward trusting the first answer, which is exactly the behaviour the ACF training data showed is most dangerous.

The two-agent verification workflow I described last week costs more than a single query: one pass to generate, another to verify, often a third to correct. On a cloud API, every pass adds cost. On a capped subscription, serious team use quickly hits limits. On a local model, you can run that workflow on every document. Every time. Without watching a meter.

Think about what that means in practice. A country office could batch-process an entire quarter of SitReps overnight to extract trends nobody had time to spot manually. Every draft donor report could run through a verification pass before anyone reads it, as a standing workflow rather than a special effort.

We built one of these ourselves: an open-source OSINT research agent that searches in seven languages, scores findings across five quality dimensions, and runs on a schedule with no manual intervention. On cloud APIs it would be expensive to run continuously. On a Mac Mini running Gemma 4, the LLM processing has zero marginal cost. The codebase is at github.com/marketimpact/opensource_airesearchtools.

Local compute does not just make AI cheaper. It makes a different kind of AI use viable. The kind where verification is built into every pass, on every document, running overnight while the team sleeps.

What local models do not fix

Last week I wrote about the failure modes that worry me most: not the fabricated statistic that gets caught, but the AI summary that silently drops a village from a prioritised list, inverts a trend, or misattributes a caseload figure. The error that looks like clean text. The summary that becomes the input to the next meeting, the next decision, the next plan. Nobody checks the source because nobody has time to read the original forty pages.

Local models do not fix this. I want to be completely clear about that. A Gemma 4 model running on a Mac Mini will still hallucinate, drop information, and produce confident errors. The verification problem is identical. The two-agent workflow we taught at ACF is just as necessary for a local model as for a cloud model. The skills that moved furthest in the ACF data, verification and data safety, are the same skills that matter here.

What local models do fix is the other half of the problem. The part where a stretched programme officer, at eleven at night, decides not to use AI for the summary because they know the data is sensitive and they do not want to upload it to a US company's servers. That officer is making the right call on data protection and the wrong call on their own capacity. They end up reading the forty pages badly, or not at all, and the summary they write themselves at midnight is no more reliable than the one AI would have produced.

Local models give that officer a third option. Use AI. Use its mind, not its memory. Verify the output. And keep the data in the room.

I could write a piece that stops there: "Local AI solves everything, buy a Mac Mini, you're welcome." That would be dishonest, and you would see through it.

Local models do not set themselves up. Someone has to download the model, configure it, keep it updated, and support staff who have questions. Most humanitarian IT teams are already stretched. Adding "run and maintain a local AI system" to their job description without additional capacity is the kind of unfunded mandate this sector specialises in.

There are also practical limitations. In practice, a Mac Mini M4 Pro running the 31B model locally is likely to feel slower than ChatGPT for interactive back-and-forth. That is fine for batch tasks such as summarising a document, drafting a report, or running a verification workflow. For many of the document-heavy workflows humanitarian teams actually need AI for, this rarely matters. But it is a real limitation, and I am not going to pretend otherwise.

Local models also do not come with the guardrails that commercial products build in. ChatGPT has content filters, usage policies, admin controls, and a support team. A local model is a raw capability. The organisation has to provide its own guardrails, which means governance, training, and exactly the kind of sustained adoption work the ACF piece described.

And local models do not eliminate the need for judgement. A local model can still fabricate statistics, miss nuances, and produce fluent but misleading outputs. If your team does not have the habit of checking AI outputs against source material, local AI may make the quiet failure mode worse, not better, because it removes one of the frictions that was causing some staff to hesitate. Local processing solves part of the problem. It does not solve the human one.

What organisations should be doing now

The organisations that will be ready are the ones doing three things now.

First, training staff on verification, data classification, and sustained adoption. The ACF data shows these skills can be taught. It also shows they fade in six weeks without team-level structures. Start now, because the learning curve does not get shorter.

Second, testing local models internally. You need someone in your organisation who has run Gemma 4 on a Mac Mini, knows what it can and cannot do, and can give an honest assessment of whether it meets the threshold for your workflows. That person does not need to be a data scientist. They need to be a curious programme officer with an afternoon and someone who can type "ollama run gemma4:31b" into a terminal.

Third, planning procurement. Not buying yet, but making sure that when the time comes, the IT team knows what to order, the finance team knows how to code it, and the procurement process does not take six months to approve a desktop computer. The sector is very good at buying laptops. A Mac Mini with extra memory is just a laptop without a screen.

And here is why the urgency is real. The Mac Mini is today's benchmark. It will not be the benchmark for long. Google's Gemma 3n, released in mid-2025, already runs on a smartphone with 3GB of memory. Within twelve to eighteen months, it is plausible that models approaching today's Gemma 4 31B capability will run acceptably on much cheaper hardware. Standard-issue field laptops with enough memory. When that happens, local AI will not be a procurement decision. It will be something any staff member can install, on hardware the organisation already owns, without asking anyone. The Shadow AI problem from November comes back, except this time it is local, invisible, and carries no API trail.

The excuse

I titled this piece "the excuse is about to disappear" and I should say what I mean.

For the past year, every time I have spoken to a senior leader about AI adoption in their organisation, I have heard some version of the same response. "We know it is happening. We know we need to act. But it is expensive, the data risks are real, no donor will fund the subscriptions, and we do not have the IT capacity."

Those were reasonable responses in 2025. Some of them are still reasonable today. But the gap between "we cannot do this safely" and "we have not yet decided to do this safely" is narrowing fast.

When a model that handles summarisation, verification, report drafting, and document analysis runs on a roughly $2,000-class desktop with no ongoing costs and no data leaving the building, the cost argument weakens. The data sovereignty argument changes. The donor funding argument becomes harder to sustain. What remains is the training argument, the verification argument, and the sustained adoption argument. Those are harder. They require investment in people, not hardware. But they are the arguments this series has been building toward since November.

That is why this matters beyond data sovereignty. Local AI may unlock adoption in organisations that have held back not because they do not see the value of AI, but because they cannot accept losing control of sensitive data. The goal is not local AI for its own sake. The goal is better decisions, better analysis, and better outcomes without forcing organisations to choose between capability and control.

The technology is not the hard part. It never was. The hard part is whether organisations will invest in teaching their staff to use it well, building the team-level structures that keep those skills alive, and taking seriously the quiet failure modes that happen when AI outputs go unchecked.

A Mac Mini on a desk does not solve that. It does not verify a source, train a team, classify sensitive data, or stop a bad summary becoming a bad decision. Training does. Verification workflows do. Sustained adoption structures do. The Workflow Card does.

But a Mac Mini on a desk removes one of the strongest reasons organisations have had for doing nothing.

The excuse is about to disappear. The responsibility is not.

Where we come in

This is not just an argument we are making from the sidelines. It is the adoption problem we work on directly.

If your team needs to build the skills described in this piece, verification, data classification, responsible AI use, sustained adoption, that is the work we do through AidGPT. The next Responsible AI in Practice cohort starts Tuesday 2 June 2026. Six interactive ninety-minute sessions over three weeks, Tuesdays and Thursdays at 16:00 East Africa Time. €350 per person, capped at twenty participants. Register at aidgpt.org/training/apply.

If your organisation needs an independent assessment of how AI is being used across your programmes, whether your current tools are fit for purpose, and what the responsible adoption pathway looks like, that is the consultancy work we do at MarketImpact Digital Solutions Ltd. We have delivered this work for organisations including NRC, GIZ, the Digital Convergence Initiative, Action Against Hunger, and NORCAP.

Training your teams: AidGPT.org Assessing your organisation: MarketImpact Digital Solutions Ltd

You can reach me on LinkedIn or send us a message at marketimpact.org.

Discussion

Is your organisation already testing local models? If so, what are you running and what have you learned?

For those in IT or IM roles: what would it actually take for your organisation to approve, procure, and deploy a local AI setup? Where are the real blockers?

And for programme staff: if a local model were available on your office machine tomorrow, would you trust it more or less than ChatGPT? Why?

Share what you are seeing. This is moving fast and I do not think any of us have the full picture.

Tom

Tom's Aid and Dev Dispatches is a weekly newsletter on humanitarian and development trends, read by 9,000+ people working in the sector. If someone forwarded this to you and you'd like the next one in your inbox, you can subscribe on LinkedIn.

#HumanitarianAI #AidGPT #ResponsibleAI #LocalAI #DataSovereignty #OpenModels #OpenWeights #Gemma4 #HumanitarianTech #AITraining #DigitalTransformation