Humanitarian crisis & displacement forecasting for anticipatory action

Humanitarian response is usually funded after a crisis becomes visible. Anticipatory action turns forecasts into pre-agreed triggers, plans and money, so help arrives before or as the shock hits. Machine-learning models combine conflict, price, climate and displacement data to estimate how many people will move or go hungry in the coming months. They are decision support for planners, not oracles: accuracy is moderate, worst for sudden surges, and the data and political risks are high.

Problem & value

• Today: agencies (UN, Red Cross/Red Crescent, NGOs), donors and ministries plan with static scenarios, expert judgement and lagging situation reports. Funding follows media attention; supplies are bought and moved late.
• Anticipatory action (AA): OCHA's Centre for Humanitarian Data defines it as a forecast-based trigger embedded in a clear decision process, with pre-agreed action plans and pre-arranged finance; the Centre designs and tests trigger mechanisms and "translates" between modellers and decision makers [1]. Most operational AA triggers today are hazard-based (drought, flood, typhoon: Burkina Faso, Niger, Chad, Bangladesh, Nepal, Philippines) [1]; displacement and conflict-driven food insecurity are the newer, harder frontier.
• Measured model performance (not business ROI):
• Danish Refugee Council's AHEAD (subdistricts of Liptako-Gourma): mean absolute percentage error of 15% over 315 historical forecasts in Burkina Faso versus 21% for two simple benchmarks, and the right act/do-not-act call about 70% of the time at a 1,200-person threshold; the national Foresight model showed a 19% mean and 11% median error over 214 forecasts in 26 countries [2].
• UNHCR's early-warning model for forced displacement (monthly refugee/asylum flows, 219 countries, 1/3/6-month horizons): c-statistic above 0.79, Brier scores of about 0.08-0.16 [3].
• Both papers state that onset of conflict-driven displacement and unprecedented surges are poorly predicted (AHEAD error rises to 34% when displacement jumps) [2][3].
• Value logic: earlier procurement, pre-positioned stock and cash transfers before shocks. The evidence base for cost-effectiveness is strongest for climate hazards; for displacement it is mainly planning lead time, not yet proven savings. Do not promise ROI figures.

Variants

• Displacement flows: refugee/asylum arrivals by country; internal displacement by subdistrict.
• Food insecurity: IPC-phase projections combining conflict, prices and rainfall (FEWS NET provides 4-month and 8-month IPC-compatible projections [6]).
• Conflict-escalation forecasts as an input feature: ViEWS forecasts 1-36 months ahead at country and 0.5-degree grid level for Africa and the Middle East [5].
• Climate-driven displacement: drought/flood triggers linked to PRED-017 and PRED-027.
• Host-country and EU planning: reception-capacity planning with aggregate arrival scenarios (never individual-level risk scoring, see regulation).
• Private/corporate: supply-chain and duty-of-care teams of NGOs or companies with staff in fragile regions use the same public forecasts for travel and operations planning.

How it works

1. public + partner data (conflict, prices, climate, satellite, displacement stats)
2. harmonisation by country/admin unit and month (HDX, APIs, data lake)
3. feature engineering (lags, anomalies, PCA, conflict-forecast inputs)
4. models: gradient boosting / ensembles, time-series foundation models, scenario simulation
5. calibration (Platt/isotonic) + backtesting by rolling origin
6. probabilities per threshold and horizon
7. trigger review board (analysts + country office + affected-community input)
8. pre-agreed action plan and pre-arranged finance (e.g. CERF, START, DREF-type mechanisms)
9. monitoring and post-action learning

• Core models: tabular gradient boosting is state of the art in the published systems [2][3]; time-series models (ETS, Prophet, TimesFM/Chronos-style foundation models) serve as baselines and for price/arrival series. LLMs are used for reading reports, news and sitreps into structured events and briefings, not for producing the numbers.
• Human-in-the-loop: forecasts do not trigger funding automatically. UNHCR's author explicitly frames the model as decision support to be recalibrated as data arrives and combined with local expertise [3].

Data preparation

Needed are conflict event data (ACLED, UCDP), food-price and market data, climate and satellite indices, displacement figures (UNHCR, IOM DTM, IDMC), crisis indices and IPC classifications. Most come from public portals and APIs; the organisation's own field reports, assessments and beneficiary data sit in file shares, mail, Excel sheets and sometimes country-office systems.

Typical gaps: different admin-region boundaries and spellings, irregular reporting intervals, missing months, revisions of published figures, licence terms that restrict redistribution, and scattered field knowledge in documents. Own beneficiary data are personal and sensitive and should stay out of the model.

Preparation steps: (1) map required sources and gaps (PREP-002); (2) set up scheduled API pulls and a harmonised region table (PREP-005); (3) restructure Excel assessments into tidy tables (PREP-011); (4) define target variables and thresholds with programme staff (PREP-019); (5) extract facts from situation reports (DOC-014); (6) build a back-test set of past crises (PREP-018); (7) pseudonymise any personal data (PREP-022). Tools: Python (pandas, Prophet or gradient boosting), PostgreSQL, scheduled pipelines (n8n, Airflow).

Rough share of effort: 50 to 60 percent. See GUIDE-003.

Implementation paths

Which path for whom

• Enterprise (NGOs, international agencies, donors): Path B, because no off-the-shelf product covers the mix of conflict, price, climate and displacement data, and cloud APIs plus managed compute allow quick integration with the own early-warning workflow.
• Developer: Path C, because open datasets and open-source forecasting libraries (and open-weight LLMs for situation briefs) run on HW1 and make models reproducible and auditable.
• Public (ministries, development agencies): Path B, on sovereign EU or German cloud, because procurement rules and sovereignty needs favour EU-hosted infrastructure while the data are mostly public or aggregated.

Path A — Buy (off-the-shelf)

• Use public forecast products instead of buying a model: ViEWS (Uppsala University and PRIO, EU-funded by the ERC, monthly releases, open data) [5]; FEWS NET food-security outlooks (operating, with monthly reports and a data explorer) [6]; WFP HungerMap LIVE; OCHA Centre's AA frameworks and catalogue of predictive models [1]; GloFAS and EMS from Copernicus (EU) for flood hazard.
• Commercial risk-intelligence vendors (country-risk and conflict-analytics providers) exist for corporate security teams; check methodology transparency. The humanitarian sector largely relies on open and in-house models.
• Choose A when: you are a smaller NGO, a company or a municipality that needs to consume forecasts, not produce them.

Path B — Build on cloud APIs

• Ingest ACLED, UCDP, FAO/World Bank prices, ERA5/Copernicus climate data and HDX datasets via APIs into an EU-region data platform (e.g. Azure/AWS/GCP EU, or EU clouds such as STACKIT, OVHcloud, IONOS).
• Train gradient boosting (LightGBM, XGBoost, H2O) and time-series models in managed ML services; use an LLM API (Claude, Gemini, GPT, Mistral as EU provider) with structured outputs to turn situation reports and news into event features and to draft briefs.
• Choose B when: you have a small data-science team and want a production pipeline in months; recommended default for most organisations that build.

Path C — Self-host (open source)

• Python stack: LightGBM/XGBoost, statsforecast, Darts, scikit-learn calibration, DuckDB/Postgres+PostGIS, Dagster/Airflow, MLflow; geospatial with GeoPandas and Xarray; open ViEWS code and data as inputs [5].
• Open-weight LLM (e.g. Qwen3, Mistral, Llama class) for report extraction, served via vLLM.
• Hardware: CPU server or workstation suffices (HW1); an LLM for text extraction needs HW2.
• Choose C when: data-protection or donor requirements forbid external cloud, or in field offices with limited connectivity.

Path D — Custom training

This is the core of the use case: no off-the-shelf model fits a specific context. Train and validate country- or region-specific models on 5-10 years of monthly history; the published models rely on official displacement and conflict data (AHEAD: 315 and Foresight: 214 backtested forecasts) [2]. Invest as much in backtesting, calibration and uncertainty communication as in the model; AHEAD authors note that the models do not estimate uncertainty in the official figures they are trained on [2].

State of the art (2026)

• Gradient boosting on aggregated indicators with calibrated probabilities for threshold exceedance remains the practical standard (UNHCR: 95 features from ACLED, INFORM, food prices, GDELT-based indices, EM-DAT, reduced to principal components) [3].
• Conflict forecasting is an upstream dependency: ViEWS publishes monthly forecasts, e.g. its release of 30 Sep 2026 for state-based armed conflict covering Sep 2026 to Aug 2029 [5]; UNHCR's model depends heavily on conflict-forecast quality [3].
• Government adoption: OCHA material points to governments moving anticipatory action from pilot to policy (a March 2026 Centre item) [1].
• Data responsibility is now a design input: the OCHA Data Responsibility Guidelines (2021, updated January 2025) require safe, ethical handling of personal and non-personal data [4].
• Limits and failure modes: overconfidence at high probabilities for sudden increases; weak below about 5,000 people; poor onset and surge prediction; dependence on possibly unreliable official numbers; performance driven by local context [2][3]. Forecasts can be misused (e.g. perceived as encouraging or enabling displacement, or by parties to conflict), so publish aggregates at appropriate granularity [2].
• Funding and data fragility: parts of the humanitarian data ecosystem depend on a few donors (FEWS NET describes itself as not official U.S. Government information) [6]; plan fall-back sources.

Shared resources & combinations

• Same stack (time-series + tabular-ml + remote-sensing): PRED-017 (AI weather forecasting) supplies rainfall and heat inputs; PRED-027 (flood forecasting) supplies hazard triggers; PRED-036 (physical climate and nat-cat risk) shares exposure data and geospatial pipelines.
• Related forecasting: PRED-008 (commodity/food price forecasting) feeds market features; PRED-047 (economic nowcasting) shares macro-indicator pipelines and evaluation practice.
• Contrast, not combination: PRED-029 (public-service client risk profiling) and PRED-039 (crime hotspot forecasting) work on individuals or sensitive places; this use case must stay at aggregate level.
• Text layer: DOC-014 (document parsing for RAG) turns situation reports and IPC analyses into searchable context; AGENT-018 (continuous compliance monitoring) pattern applies to trigger monitoring.
• Hardware: CPU-heavy batch jobs (HW1); a shared HW2 GPU server can host the LLM used for report extraction across these use cases.

Effort, cost & KPIs

• Path A: days to weeks to adopt public forecasts into planning; mostly analyst time.
• Path B: 3-6 months for a country or regional pipeline with backtesting; cost drivers are data engineering and data-science staff, not compute.
• Path C: similar effort plus operations; low infrastructure cost.
• Path D: 6-12+ months per context including trigger design, validation and governance.
• KPIs: Brier score and log loss per horizon; calibration error; hit rate/false-alarm rate at the trigger threshold; lead time gained versus previous practice; share of triggers reviewed by humans; time from trigger to disbursement; post-action review of whether the action reached people.

People & change

Start with management and the head of the programme or early-warning unit, because forecasts feed financing triggers and decisions about aid. Regional and country staff are the end users and the best source of ground truth, so involve them in defining targets and checking forecasts. IT handles pipelines and hosting; data owners and partner organisations (suppliers of data) must agree on licences and sharing. The DPO is needed if beneficiary or displacement data on individuals are used; for aggregated public data a DPIA is usually not required, but check (GUIDE-005).

Works council: depends. The tool forecasts regions, not staff, so co-determination usually does not apply; if staff usage is logged or work processes change substantially, §87(1) no. 6 and §90(1) no. 3 BetrVG may apply, or the staff council for public bodies (GUIDE-004). Inform the council early either way.

Support AI literacy (Art. 4 AI Act) with training on probabilistic forecasts, thresholds and limits (GUIDE-006). Pilot with one crisis context and compare forecasts with retrospective outcomes before tying money to triggers (GUIDE-009). Typical concerns: false alarms, wasted funds, and trust in models over local knowledge. Address them with published uncertainty, local expert review before any trigger fires, and clear human sign-off on funding releases (GUIDE-008).

Risks, regulation & compliance

• EU AI Act: depends. Forecasting on aggregate country or regional data is generally not an Annex III system, and systems used exclusively for military, defence or national security are excluded (Art. 2(3)); systems developed solely for scientific research are excluded (Art. 2(6)) [7][8]. Risk rises to high-risk if public authorities use such tools in migration, asylum and border control contexts (Annex III, point 7) in a way that assesses individuals, and individual-level profiling of migrants for risk or eligibility must not be built from this use case. Classify the concrete deployment and document it (see SEC-022).
• GDPR / data protection: core inputs are aggregate and public; however, displacement registries and survey microdata contain special-category data of vulnerable people. Apply data minimisation, aggregation and statistical disclosure control; humanitarian organisations often rely on privileges and immunities rather than GDPR, but EU-based funders, processors and NGOs remain bound.
• Do no harm: forecasts of where people will move can be misused to restrict movement, or targeted by armed actors; restrict granularity and access, run a data-impact assessment, and follow the OCHA Data Responsibility Guidelines and the IASC operational guidance [4].
• Model risk: overconfidence, concept drift as conflicts change, and unreliable ground truth; mitigate with calibration, rolling backtests, human trigger boards and monthly recalibration [3].
• Dependence and legitimacy: triggers that release funds need documented, pre-agreed criteria and community consultation; avoid presenting forecasts as certainty.

Getting started

1. Define the decision first: which action, which money, which lead time, who decides. A forecast without a pre-agreed action plan is only a report.
2. Start from existing public forecasts (ViEWS, FEWS NET, UNHCR/OCHA data on HDX) and check how they would have performed historically in your region.
3. Build a simple baseline (last value, seasonal naive), then a calibrated gradient-boosting model; backtest with rolling origins and report Brier score and calibration plots.
4. Set up a data-responsibility review and data-impact assessment before using any disaggregated or sensitive data.
5. Pilot with a trigger review board in one country; document false alarms and misses and recalibrate.

Sources

1. OCHA Centre for Humanitarian Data — What is anticipatory action? — https://centre.humdata.org/anticipatory-action/
2. Data & Policy (Cambridge University Press) — Pushing the boundaries of anticipatory action using machine learning (AHEAD, Foresight) — https://www.cambridge.org/core/journals/data-and-policy/article/pushing-the-boundaries-of-anticipatory-action-using-machine-learning/5CA9D6358F29AE35C886B92492CFFF65
3. Henningsen, G. (UNHCR) — An Early Warning Model for Forced Displacement, arXiv:2505.06249 — https://arxiv.org/html/2505.06249v1
4. OCHA Centre for Humanitarian Data — Data Responsibility Guidelines — https://centre.humdata.org/data-responsibility/
5. ViEWS (Uppsala University & PRIO) — Violence & Impacts Early-Warning System — https://viewsforecasting.org/
6. FEWS NET — Famine Early Warning Systems Network — https://fews.net/
7. Regulation (EU) 2024/1689 (AI Act), Article 2 (scope) — https://artificialintelligenceact.eu/article/2/
8. Regulation (EU) 2024/1689 (AI Act), official text — https://eur-lex.europa.eu/eli/reg/2024/1689/oj