AI Chatbots for Crisis-Affected People

Last updated: 2026-08-15

An AI chatbot serving crisis-affected people is safe to deploy when it answers stable procedural questions, states clearly that it is not a person, and offers a route to a human at every turn. It is unsafe when it is the only channel available, when it is asked to assess eligibility or risk, or when a wrong answer changes what someone does in an emergency.

When an AI chatbot for refugees or crisis-affected people is safe to deploy, when it is not, and the design conditions that separate the two.

AI Chatbots for Crisis-Affected People

Conversational interfaces are the most requested and least examined humanitarian AI application. The appeal is obvious: enquiry volume vastly exceeds staff capacity, questions repeat, and a chatbot answers at three in the morning. The risk is equally clear once stated: the people asking cannot go elsewhere, often cannot judge whether an answer is right, and may act on it in ways that are hard to reverse.

What makes this population different

A commercial chatbot user who receives a wrong answer is inconvenienced and tries another company. Neither condition holds here.

The person asking may have no alternative source of information, no way to verify what they are told, and no standing to complain. They may be making a decision with a deadline attached: whether to attend an appointment, whether a document is required, whether a route is open. They are frequently reading in a second or third language, through an interface designed by people who have never used it under stress.

There is also an authority effect that is easy to underestimate. A message that appears to come from an aid organisation carries the weight of that organisation. A hedged, probabilistic answer is read as an instruction.

Where a chatbot is defensible

The safe territory is narrow and genuinely useful: stable procedural information. Opening hours, office locations, what documents a process requires, how to reschedule an appointment, what a status means. These have correct answers that do not change with the individual, can be grounded in a document the organisation controls, and cause limited harm when the user simply asks staff to confirm.

Three conditions make even this defensible.

Ground every answer in a controlled source. The system should retrieve from the organisation's own published guidance and answer from that, rather than from model memory. Where it cannot find a grounded answer, it should say so instead of producing a plausible one. Retrieval-augmented generation is the mechanism, and how RAG works covers it.

Disclose that it is not a person, in the first message and in the user's language. Not in a footer, and not once at sign-up.

Offer a human at every turn. Not only when the system fails, because a system that is confidently wrong does not know it has failed. The route to a person should be present in every exchange.

Where it is not defensible

Some applications should not be built as chatbots regardless of model quality.

Eligibility and entitlement. Any exchange that tells someone whether they qualify for assistance is a decision, not information, and belongs to a caseworker with a name and an appeal route.

Protection, legal, and medical advice. These carry consequences the system cannot see and cannot be accountable for.

Anything that becomes the only channel. The most common failure mode is not a bad answer. It is a chatbot deployed as a cost saving, with the human channel quietly reduced behind it. At that point the safeguard has been removed and the disclosure that "you can speak to a person" is no longer true.

Distress and crisis disclosure. People will disclose serious harm to a chatbot precisely because it feels less exposing than telling a person. The system must be designed for this before launch: recognise the disclosure, stop trying to be helpful, and route to a human immediately with the right escalation path. A system that responds to a disclosure of violence with an FAQ answer has done real damage.

Testing before deployment

Test against the population, not the specification. That means the languages and dialects people actually use rather than the standard written form, transliterated and mixed-script input, misspellings under stress, and the questions users ask rather than the questions the organisation expects. Language coverage here is a protection issue: a person the system cannot understand is a person excluded from the service behind it. The wider argument is in the Last-Mile AI framework, and dialect evaluation specifically in AI governance in the Arab region.

Measure the right thing. Deflection rate is the wrong headline metric because it improves when the system stops offering a human. Better measures are the proportion of grounded answers, the rate at which people reach a person when they need one, and the accuracy of responses on questions with a verifiable correct answer.

The decision

Before building, answer four questions from the use case discovery playbook: what happens to a person if the system is wrong, can they appeal, who owns the decision by name, and is there a route to a human at the point where the system stops being confident. A chatbot for crisis-affected people that cannot answer all four is not ready, and the honest response is to narrow its scope rather than to strengthen its disclaimers.

Written by Shahzad Asghar, Head of Data and Digital Solutions at UNESCWA. See all articles, the playbooks, and the templates.