If you visit DEEP on the Wayback Machine, you will not find the AI-powered humanitarian analysis platform that UN OCHA, UNHCR, UNICEF, and the Internal Displacement Monitoring Centre had built for their secondary data review workflows around for nearly a decade.
You will find this: “The DEEP was a trusted humanitarian analysis platform that fostered collaborative and innovative solutions. Due to funding cuts, it is no longer available, but its legacy will continue to live on.”
That is what failure looks like in our sector in 2026. A tool that worked. Funding that did not work.
DEEP, the Data Entry and Exploration Platform, is one of the 11 case studies documented in NetHope’s new Harnessing AI for Humanitarian Impact report. It is also the only one in the report that no longer exists. The report’s framing of why it died deserves to be quoted in full because it indicts something much larger than DEEP:
- “discontinued not because it failed but because its funding did.”
Read that sentence again with the rest of the report’s case studies in mind.
- CRS dashboards needing maintenance budgets that don’t exist.
- NRC self-hosting AI infrastructure to control costs.
- PDC scaling to enterprise infrastructure without enterprise funding.
Every one of these tools is potentially the next DEEP. The only difference is timing.
Sign Up Now to advert disaster in your next project
Misdiagnosing Pilotitis for Years
The ICT4D community has spent years blaming pilotitis on the projects themselves. Bad design. Wrong context. Insufficient local ownership. No business model. Every conference panel on this topic eventually circles back to the same set of project-level remedies:
- better needs assessments,
- more co-design,
- stronger M&E,
- clearer theories of change.
DEEP punctures that diagnosis. By any measure ICT4D advocates have published over the last decade, DEEP was the success story. It had everything we keep saying makes pilots succeed.
- Multi-stakeholder governance with OCHA, UNHCR, UNICEF, and IDMC.
- Real users running real workflows.
- Documented operational impact across multiple humanitarian responses.
- Open source code so no single vendor could hold it hostage.
- Eight years of iterative development.
It still got switched off.
The Digital Impact Alliance calls the four-to-five-year mark the “funding valley of death.” DEEP made it past year eight and still fell in. NetHope’s framing is the sharpest line in the report:
- “The sector is using project-cycle grants to build what functions as long-term digital public infrastructure, financing roads like meals, expecting one-time investment to sustain something that requires perpetual upkeep.”
The diagnosis is structural, not behavioral. You cannot fix it with a better logframe.
Donor Funding Is Fickle. Government Is Not.
Most NGO leaders know that donor funding is structured to be fickle.
Foundations rotate strategic priorities every five to seven years. Bilateral aid agencies change direction with each administration, as anyone who watched USAID’s death or FCDO’s cuts can confirm. Even committed donors operate on grant cycles that rarely exceed three years, because that is how their own boards measure them.
This is not a flaw in donor behavior. It is the design specification.
Donors are supposed to take catalytic risks, fund innovation, and exit. They are not supposed to operate digital infrastructure in perpetuity. When we build humanitarian AI tools that depend on continuous donor funding to survive, we are asking donors to do a job they were never structured to do.
Government funding works differently. National budgets are annual but recurrent.
Once a tool is integrated into a ministry’s line items, it persists across administrations because civil service continuity carries it.
- DHIS2 now sits in more than 75 national health information systems and serves over 40 percent of the world’s population because ministries of health pay to keep their own systems running.
- PATH transitioned its ImmReg digital immunization registry into a government-led national system in Vietnam through early and continual inclusion of the national government, not through better grant writing.
Design for Government Funding
Most humanitarian AI tools cannot follow the DHIS2 path because they operate across borders, in conflict zones, or in spaces where no single government has authority.
- A flood prediction model for the Sahel cannot be owned by one ministry.
- A chatbot serving displaced Rohingya cannot depend on the Bangladeshi government’s annual budget.
The DEEP problem is harder than the DHIS2 problem. But “harder” is not the same as “impossible.” The shift starts with three concrete design choices, all of which need to happen at the proposal stage, not at the year-three sustainability review.
1. Identify the government procurement pathway before you write the technical specification.
Our recent analysis of why digital health pilots fail at scale made this point bluntly: the real challenge isn’t proving your intervention works. It is designing something the government can procure within existing systems.
For multi-country humanitarian tools, this means identifying which national agencies, regional bodies, or UN member-state contributions could plausibly absorb operational costs once the donor exits, and designing the tool to fit those procurement vehicles from day one.
2. Build the tool to integrate into existing government infrastructure rather than parallel to it.
fAIr’s mapping outputs feed OpenStreetMap, which governments already use. GiveDirectly’s flood triggers could feed national disaster management agency workflows. The tools that survive donor exit are the ones that have made themselves indispensable to systems governments are already paying to operate.
3. Treat donor funding as the catalytic phase, not the operational phase.
NetHope’s recommendation that funders shift to multi-year operational endowments is necessary but not sufficient. Even multi-year endowments end.
The sustainable funding plan names a non-donor entity (a government, a regional body, a recurring user-fee structure, a private-sector integration) that will carry the operational cost in year six and beyond.
If your proposal cannot name that entity, you are building DEEP again. A sustainable humanitarian AI tool is one that survives its donor exit. Everything else is just timing.
