Building Ethical AI for Crisis Response: Lessons From Humanitarian Data Infrastructure

The case for learning from humanitarian data

The humanitarian data community has spent two decades building systems that handle some of the highest-stakes personal data in the world, in environments with little margin for error, under regulatory regimes that vary country by country. Those systems are not perfect; well-documented failures (the Rohingya biometric data-sharing incident, the 2020 OCHA-Microsoft partnership controversies, recurring questions about WFP biometric registration in conflict zones) have produced public lessons that the broader AI ethics field is only now arriving at. Anyone building AI for crisis response should start with those lessons rather than re-derive them at the cost of the same affected populations.

Six lessons that have aged well

### 1. Data minimisation is the strongest privacy control

The principle is older than AI: collect only what the operational decision requires, retain it only as long as the decision requires, share it only with parties whose mandate requires it. UNHCR and ICRC data-protection guidance both build on this principle. The AI-era corollary is the same: do not train a model on personal data you did not need to collect, and do not retain training data on the assumption that it might be useful later. The default is delete; retention is the exception.

### 2. Consent in crisis contexts is conditional, not free

A refugee being asked to consent to biometric registration in exchange for assistance is not in a position to refuse meaningfully. The sector has accepted this for a decade and built compensating safeguards: independent oversight, strict purpose limitation, and prohibitions on data sharing for non-protection purposes. AI systems deployed against the same populations inherit the same condition. Marketing copy that treats consent as a sufficient ethical justification has not absorbed the lesson.

### 3. Interoperability is a protection risk as well as an efficiency win

The benefits of interoperable identity and assistance systems are obvious. The protection risks (data flowing from a humanitarian system to a government with hostile intent toward the population in question) are equally obvious to anyone who has worked in protection. The lesson is that interoperability needs to be designed with the assumption that some receiving parties cannot be trusted, and that some flows must be one-way, audited, or blocked entirely.

### 4. Vendor lock-in is an accountability problem

Closed AI systems deployed in humanitarian operations create accountability gaps when something goes wrong. The agency cannot explain the model's decision, the vendor will not, and the affected population has no recourse. The sector's response has converged on contractual requirements for model documentation, audit access, exit clauses, and (increasingly) preference for open-weight models where operational requirements permit. Funders are starting to write these requirements into grants.

### 5. The threat model includes the agency itself

The hardest lesson is that the threat model for humanitarian data has to include the humanitarian agency. Staff turnover, sub-contractor access, partnership data sharing, and the steady accretion of internal users with broader access than their role requires all create insider-risk vectors. The same applies to AI: the model has the same access as the team that built and operates it, and that access needs governance.

### 6. Documentation is governance

Datasheets for datasets, model cards for models, and decision logs for deployments are not bureaucratic overhead. They are the substrate on which any post-hoc accountability rests. The agencies and NGOs who have weathered scandal best are the ones whose documentation made the post-mortem possible. The ones who have not had this discipline have learned the lesson the expensive way.

What good practice looks like in 2026

For funders, NGOs, and the AI ethics community moving into crisis-response work, the operational picture in 2026 has a shape.

• Data-protection impact assessments precede deployment. The IASC operational guidance and the UNHCR Data Protection Policy both require this for new processing activities. AI deployments are processing activities.
• Population-specific evaluation is the norm, not the exception. Aggregate accuracy hides the failures that matter most. Disaggregated evaluation across language, age, gender, and population group is now expected of any model used in protection-sensitive contexts.
• Procurement contracts encode the ethics. Audit rights, retention limits, prohibition on training-data reuse, model documentation requirements, and exit clauses live in the contract or they do not live at all.
• Affected-population participation moves from consultation to co-design. The shift is uneven but visible: from asking a refugee panel for feedback on a finished system to involving them in the design of what the system is for.
• Human-in-the-loop is specified, not gestured at. Operational guidance now defines which decisions require human review, who the human is, what authority they have, and what happens when they disagree with the model.
• Independent oversight is funded. Watchdog capacity within the sector and outside it (academic researchers, independent auditors, investigative journalists) is increasingly resourced rather than treated as a critic to manage.

What funders should fund

Three funding lines have outsized returns.

• Local technical capacity. Models built and maintained by teams in the regions they serve outperform models parachuted in. Sustained investment in local AI engineering and data-science capacity is the highest-leverage line item in this space.
• Independent evaluation. The sector underinvests in evaluating its own AI deployments against the populations being served. Funding for third-party performance equity audits closes a structural accountability gap.
• Open-source humanitarian AI infrastructure. Shared models, shared evaluation suites, and shared data-protection tooling reduce the per-deployment cost of doing this responsibly. Several initiatives exist; few are fully funded.

What is still unsolved

The honest list of unsolved problems is long.

• Cross-border data flows in sanctioned environments remain under-governed.
• Generative AI use by affected populations themselves (refugees using chatbots for legal advice, for example) creates a class of risks no agency owns.
• The accountability gap for AI in military and intelligence systems that operate in the same physical spaces as humanitarian operations is unresolved.
• The carbon and water footprint of large-scale model use is rising, with no agreed sectoral position on procurement preferences.
• The labour conditions of the annotation and moderation workforce behind humanitarian-AI training data are largely undocumented.

These are not reasons not to deploy AI in crisis response. They are reasons to deploy it with humility, with documentation, and with the assumption that the affected populations will hold the system accountable in ways the builders did not anticipate.

The closing point

Ethical AI for crisis response is not a thing that gets built once and certified. It is a practice that gets maintained, audited, corrected, and occasionally rebuilt. The humanitarian data community has been at this long enough to know that the institutions which take maintenance seriously are the ones that survive the inevitable failures with their trust intact. Anyone joining this work in 2026 should plan to build for the failure, not against it.

Sources and further reading

• UNHCR Data Protection Policy and Guidance: https://www.unhcr.org/data-protection
• ICRC Handbook on Data Protection in Humanitarian Action: https://www.icrc.org/en/data-protection-humanitarian-action-handbook
• IASC Operational Guidance on Data Responsibility in Humanitarian Action: https://interagencystandingcommittee.org/
• OCHA Centre for Humanitarian Data: https://centre.humdata.org/
• Signal Code on Human Rights in Humanitarian Information Activities: https://signalcodeorg.wordpress.com/
• Joint UNHCR-World Bank Joint Data Center: https://www.jointdatacenter.org/